What Is IBM i, Really? Understanding the Platform Before You Touch a Line of RPG
Somewhere behind the scenes of a bank transfer, an insurance claim, or a retail order confirmation, there's a good chance IBM i is doing the work. It's easy to dismiss the platform as legacy technology because of where it came from — the AS/400 line dating back to the late 1980s — but that view misses what actually makes it valuable today: a level of stability and backward compatibility that almost no other enterprise platform can match, combined with active, ongoing development from IBM.
The naming has changed several times over the decades. OS/400 became i5/OS, then IBM i. The hardware went from AS/400 to iSeries to System i, and now runs on IBM Power Systems. What hasn't changed is the underlying architecture, and that's the part worth understanding before writing any RPG code at all.
Three things set IBM i apart from a conventional operating system. First, it's object-based rather than file-based. On Windows or Linux, everything ultimately reduces to a file in a directory. On IBM i, everything — a program, a database table, a library, a job description — is an object with a defined type, and the operating system enforces strict rules about what each type can do. You can't execute a data file. You can't write data into a program object. That boundary is architectural, not a convention developers agree to follow.
Second, IBM i uses a single-level storage model, meaning there's no hard architectural line between memory and disk the way there is on most systems. The operating system manages that transparently, which is part of why the platform has such a strong reputation for reliability.
Third, and arguably most important for day-to-day development, the database isn't a separate product installed on top of the operating system — it's part of the operating system itself. DB2 for i has no install step and no separate server process to manage. It's simply there, integrated into the fabric of the platform.
Understanding objects naturally leads to understanding libraries, since libraries are how IBM i organizes those objects. A library is itself an object — type *LIB — that acts as a container, similar in concept to a schema in a relational database or a namespace in a programming language. When a program calls another program, or a job opens a database file, the system resolves that request by walking through the library list, an ordered sequence of libraries it searches from top to bottom. Whoever controls that library list controls which version of an object gets used, which is exactly how most shops manage development, test, and production environments.
None of this is abstract trivia. Every compile, every deployment, and every production troubleshooting session on IBM i eventually comes back to objects, libraries, and how the system resolves them. Developers who struggle with the platform are frequently struggling because this model was never made explicit to them. Once it clicks, the rest of the platform — and the RPG language that runs on it — starts to make a lot more sense.
This lesson is Lesson 1 of IBM i Platform Foundations in IBM i ILE RPG Mastery, a structured course built for developers who want to move from working knowledge to genuine platform fluency before diving into modern ILE RPG development.