Big Dummys Guide To The As400

Getting Started With IBM i Without Losing Your Mind

The AS/400 line from IBM was introduced back in 1988 and has been kept running in production environments ever since. Lots of banks, logistics companies, and government agencies still operate core systems on it. If you are trying to learn how it works, most of the documentation is either IBM's formal manual set that reads like a terms-of-service agreement or scattered forum posts from people who've been doing this for thirty years. Big Dummys Guide To The As400 is one of those community resources that tries to translate the formal jargon into something you can actually use when you are sitting at a 5250 green screen and your manager is asking why the batch job didn't run. I ran into a real problem with it a few years ago when I was trying to help a small team set up a development environment on IBM i 7.3. They had downloaded the guide and were following along with the RPGLE compile examples, but every time they tried to create a *FILE object from their source, the system threw a CPF4396 error about the library not existing. The guide assumes you already know how to create a library and set your library list before you start compiling. It mentions it in passing but doesn't walk through it step by step. I ended up writing a quick shell script that created the library, added it to the library list, and then ran the compilation in sequence. The workaround was basically just adding a prep step before any of the guide's examples that most beginners skip over because they don't realize it's missing.

Big Dummys Guide To The As400

The guide covers the basics of navigating the 5250 interface, understanding object types and libraries, writing simple programs in RPG and COBOL, and managing batch jobs through the job queue system. It is not a comprehensive reference. You will not find detailed coverage of SQL integration, web services on IBM i, or modern development tools like VS Code extensions for i Access. What it does well is taking someone who has never seen a command line on this platform and getting them to a point where they can read a spool file and understand what went wrong with a job. One thing the guide gets right that most beginner tutorials miss is the distinction between a library and a schema. On other platforms, people talk about schemas like they are database containers. On IBM i, a library holds everything: programs, files, data queues, message queues, and yes, database files. When you hear someone say "move it to another library," they are not talking about the database layer specifically. They are talking about moving a bunch of object types at once. This distinction matters when you are migrating applications or setting up deployment pipelines. The section on job queues is where I see the most confusion. IBM i routes batch jobs through job queues, and each user profile has a default job queue assigned to it. If you submit a job and it sits in status *WDLY holding for twenty minutes, it is usually because the default job queue it was submitted to is full or the worker processes attached to that queue are backed up. The fix is rarely complicated. You check the job queue status with WRKJBQ, see if there is a backlog, and then either wait or resubmit to a different queue. I had a situation once where a client's production job queue had accumulated over four thousand jobs from a poorly written monitoring script that submitted a new job every minute without checking for duplicates. The system was not down. The job queue was just a parking lot with no exit ramp. Cleaning it out took about ten minutes.

Another counter-intuitive point that beginners struggle with is how IBM i handles file access. The database files on this system use physical file records with specific record formats. When you open a file in an RPG program, you are not connecting to a database server in the way you would with PostgreSQL or Oracle. You are reading directly from disk blocks managed by the operating system. This means that file locking works differently. If two users try to update the same record, the second one waits for a lock, and if the wait timeout expires, you get aCPF50F3 or CPF50B8 error depending on the configuration. Most people coming from web application backgrounds expect optimistic concurrency or row-level locking with conflict resolution. IBM i does pessimistic locking by default and it will not negotiate with you. The guide also covers CL programming, which is the command language used for job control and automation on IBM i. CL is not exciting. It is not object-oriented. It does not have arrays or complex data structures. But it is remarkably effective for simple task orchestration. I use CL scripts for nightly batch processes that copy data between libraries, clean up old spool files, and send message notifications when jobs fail. A typical CL program for that runs in under three seconds and uses less than two hundred kilobytes of memory. You could probably do the same thing in Python with five hundred lines of code and a dependency chain that would take longer to set up than the job itself. There are real limitations to what this guide can teach you. It assumes you have access to an IBM i system, which means either a physical machine, a virtual partition, or a cloud instance. The free DevOps edition from IBM gives you a limited partition you can run locally, but it is not suitable for production work or for testing anything that involves high-volume I/O. If you are learning this for a job where you will be maintaining legacy systems, the guide gets you to a functional baseline. After that, you are on your own to figure out the enterprise-specific quirks of your organization's implementation.

If you want something more modern and comprehensive, the official IBM Documentation site at ibm.com/docs has extensive coverage of IBM i, including RPG LE, SQL, and WebSphere integration. It is dry but accurate. For hands-on practice, setting up a local IBM i development environment through Docker or the free DevOps edition is the fastest way to start experimenting without spending money on licenses.