IBM i for the Web Developer: Surviving RPG in 2026

Or: How I Learned to Stop Worrying and Love the Green Screen

You know that feeling when you join a new company and someone says "the payroll system" in a hushed voice, like they're mentioning a elder god? That was me, week two, staring at a terminal window with a solid green background and amber text — a literal 5250 session — watching a coworker process payroll for 14,000 employees on a system that was last recompiled in 2003.

"It runs on IBM i," they said, the way you'd say "it runs on prayers."

I nodded like I knew what that meant. I did not.

Here's the part that broke my brain: that system had an uptime measured in years. Not months. Years. Meanwhile, the Kubernetes cluster I'd just set up — the one with the slick CI/CD pipeline and the Grafana dashboards — had already had three incidents in two weeks. One of them was because a ConfigMap had a trailing whitespace.

The payroll system didn't have ConfigMaps. It didn't have YAML. It didn't have containers. It had a single executable that compiled in 1997 and had been running, without drama, ever since. And I had to figure out how to build a modern web frontend on top of it.

This is that story.

What IBM i Actually Is (And Isn't)

First, let's clear up the naming mess, because IBM's marketing department has earned every bit of confusion here.

The platform started life as the AS/400 in 1988 — Application System/400. Then IBM renamed it to iSeries around 2000. Then System i in 2006. Then IBM i in 2008. Each rename was IBM's attempt to make the platform sound modern, and each one just confused everyone who already knew what an AS/400 was. If you ask an old-timer, it's still an AS/400. If you ask IBM, it's IBM i. If you ask a recruiter, they've never heard of it.

IBM i is not a mainframe. This is the single most common misconception among web developers. Mainframes run z/OS on z-series hardware. IBM i runs on Power Systems hardware — the same Power architecture that can also run AIX or Linux. The OS is proprietary. The hardware is IBM's own silicon. The database is baked in. Everything is integrated in a way that would make Apple jealous, if Apple made enterprise servers for companies that still run COBOL.

The key insight is that IBM i is an environment, not just an operating system. The OS, the database (Db2 for i), the security model, the storage model, the job scheduler — they're all one thing. You don't install Db2 on IBM i. Db2 is IBM i. The database tables are objects in the integrated file system. The security is object-level, enforced by the OS itself. There's no "oops, I forgot to configure the firewall" because the firewall concept doesn't exist in the way you're thinking — security is baked into every single object on the system.

It's weird. It's old. It's also, in many ways, more thoughtfully designed than anything we've built since.

RPG: Not the Game

RPG stands for Report Program Generator, which sounds like something from a 1960s data center — because it is. RPG was designed in the 1960s to read files, do math, and print reports. It was the COBOL of the midrange world, and if you've ever seen COBOL, you know that's not a compliment.

Traditional RPG — now called RPG III or RPG/400 — uses fixed-format code. Every line is a card image. Columns mean things. If you put your code in the wrong columns, the compiler doesn't give you a friendly error — it just does something else. Here's a taste:

     C           Z-ADDDATE     TODAY

     C           MOVE *ZERO    COUNT

     C           DO   10

     C           ADD  1        COUNT

     C           ENDDO

That's not pseudocode. That compiles. The C in column 1 means it's a calculation specification. The column positions determine whether Z-ADDDATE is an opcode, TODAY is a field, and *ZERO is a literal. If you've never seen it before, it looks like line noise. If you've spent 30 years writing it, it's poetry — bad poetry, but poetry.

Modern RPG — RPG IV, or "free-format RPG" — is a different beast entirely. IBM introduced free-format syntax in the early 2000s and it looks almost... normal:

/free

   today = %date();

   count = 0;

   for i = 1 to 10;

      count += 1;

   endfor;

/end-free

Free-format RPG has variables, procedures, service programs (think shared libraries), data structures, pointers (yes, really), and even something approximating object-oriented programming via modules. It's not going to win any language beauty contests, but it's readable. The problem is that most IBM i shops have a mix of fixed-format and free-format code, often in the same source member, and the fixed-format parts are where the bugs live because nobody wants to touch them.

RPG compiles to machine code. Not bytecode, not interpreted — actual machine instructions for the Power architecture. This is one reason IBM i programs are so fast and so stable. They're compiled to a machine interface (MI) that abstracts the hardware, which means programs compiled in 1997 still run on brand-new Power10 chips without recompilation. Think about that next time your Docker image won't build because the base image changed.

The Culture Shock

If you come from the web development world — npm, pip, containers, Git repos, CI/CD — the IBM i development model will make you question everything you know about software.

Source code lives in "members" inside "source physical files." A source physical file (SPF) is a database table with a specific format. Each row is a line of source code. A "member" is one entry in that table. You don't cat a source file — you open a member in SEU (Source Entry Utility, the green-screen editor) or RDi (Rational Developer for i, the IDE that costs money and occasionally works).

There is no filesystem in the way you think of it. IBM i has an Integrated File System (IFS) that includes a Unix-like directory structure (/home/, /tmp/, etc.), but traditional source code and compiled objects live in a different namespace: the library system. A library is not a shared object file or a package. It's a container for objects — programs, files, data areas, job queues, everything. You can think of it like a directory, but it's not. It's a library. The system library list determines where the OS looks for things, and if your library isn't on the list, your program can't find its files. Sound familiar? It should — it's PATH, but 20 years earlier and weirder.

Compilation is a first-class concept. You don't run source code on IBM i. You compile it into a program object and run that. The compile step creates a bound program that knows its dependencies, its file descriptions, its data layouts. You can't accidentally run half-compiled code. The system won't let you.

There is no npm. There is no pip. There is no package manager in the modern sense. Software is installed via Licensed Program Products (LPPs), which are IBM's version of packages, or via Program Temporary Fixes (PTFs), which are IBM's version of patches. Third-party software comes as a save file (think a tarball, but for IBM i objects) that you restore into a library. Dependency management is... you do it yourself. Manually. With a spreadsheet if you're organized.

This sounds terrible. Some of it is. But some of it is the reason that system from 1997 is still running.

Things IBM i Gets Right

Here's where it gets interesting, because buried under the green screens and the column-sensitive source code are some genuinely brilliant ideas.

Object-level security. Every object on IBM i — every program, every file, every data area, every queue — has an access control list. The OS enforces it. Not a filesystem permission, not a database grant — the object itself knows who can touch it and how. You can't bypass it by going around the database. The database is the object store.

Journaling as a first-class feature. IBM i journals are not an afterthought. You can journal any file, and the journal captures every change — before and after images — in a format that's usable for recovery, auditing, or replication. This is what modern databases call "write-ahead logging," except IBM i has been doing it since the 1980s and it's built into the OS, not bolted on.

Single-level store. This is the one that really bends your brain. IBM i treats all storage — memory and disk — as a single address space. The OS manages what's in memory and what's on disk. Programs don't know and don't care. There's no "loading" a file into memory. You open it, you access it, the OS handles the rest. A program compiled in 1997 doesn't know it's running on an NVMe drive instead of a spinning disk. The abstraction has held for nearly 40 years.

Integrated database. Db2 for i is not a separate product. It's part of the OS. You create a table, it's an object in a library. You can access it via SQL, via native I/O from RPG, via ODBC, via JDBC, via REST. There's no "database server" to configure. No port to open. No connection pooling to tune. The database is just... there. Always.

Backwards compatibility. IBM i is religious about this. Programs compiled for the AS/400 in 1988 will run on a Power10 system today without modification. The machine interface (MI) abstracts the hardware so thoroughly that recompilation is optional. This is not "we maintain a compatibility layer" — this is "the abstraction was designed correctly the first time and we never broke it." Name another platform that can say that with a straight face.

The Integration Story: How Web Developers Actually Touch IBM i

Okay, so you're a web developer. Your company has IBM i. You need to build something that talks to it. Here's how you do that in 2026 without writing a single line of RPG.

REST APIs via Integrated Web Services (IWS). IBM i has a built-in web services engine that can expose RPG programs and SQL statements as REST endpoints. You define the service, map the inputs and outputs, and IWS generates the JSON handling. It's not elegant, but it works, and it's built into the OS. No Node.js server needed.

SQL access via Db2 for i. You can connect to Db2 for i from anything that speaks ODBC or JDBC. The database talks standard SQL. Your Python app can use pyodbc or ibm_db. Your Java app can use JDBC. Your Node.js app can use ibm_db or odbc. The tables are just tables. The data is just data. You don't need to know RPG to query it.

Node.js on PASE. PASE (Portable Application Solutions Environment) is an AIX runtime that runs inside IBM i. It lets you run Unix-style applications — including Node.js, Python, Ruby, and compiled C programs — directly on the IBM i system. Node.js on PASE is a supported, IBM-maintained configuration. You can npm install packages, run Express servers, and call Db2 via the ibm_db driver, all on the same machine as your RPG programs.

Python via yum/dnf in PASE. IBM supports Python on IBM i through the PASE environment, installed via yum or dnf (yes, really — IBM maintains RPM repositories for PASE). If you see references to 5733-OPS, that's the old licensed program number for open-source packages on IBM i. It's been superseded by the RPM-based approach. Use yum install python3 or dnf install python3 in a PASE shell. Same Python, same packages, running on the same hardware as your payroll system.

The key insight is that IBM i is not a walled garden anymore. The data is accessible. The system speaks SQL, REST, and standard protocols. The integration challenge is not technical — it's cultural. The RPG developers and the web developers often don't speak the same language, and the system's documentation assumes you've been reading it since 1988.

Lessons for the Rest of Us

After spending time inside the IBM i world, a few things kept nagging at me — things that apply well beyond this one platform.

Backwards compatibility is an API design problem. IBM i's 38-year compatibility streak isn't luck. It's the result of designing abstractions at the right level. The machine interface (MI) was designed to be stable, and it was. The library system was designed to be stable, and it was. Every time you're tempted to "just change the API," remember that somewhere, someone has built something on top of it that you can't see. IBM i chose stability in 1988 and it's still paying dividends.

"Boring technology" is a feature, not a bug. Dan McKinley's "Choose Boring Technology" essay is practically the IBM i philosophy. The platform doesn't have the latest JavaScript framework. It doesn't have Kubernetes. It has a compiler, a database, a security model, and a runtime that have been battle-tested for decades. When your Kubernetes cluster has an incident because a container image changed, and the IBM i system hasn't had an unplanned outage since the Bush administration, you start to wonder who's really running the boring technology.

The best abstractions are the ones you forget about. Single-level store. Object-level security. Integrated database. These aren't features IBM i advertises anymore — they're just how the system works. You don't think about them. You don't configure them. They're not on a dashboard. That's the sign of a good abstraction: it disappears into the infrastructure and you build on top of it without thinking.

There is value in systems that just run. We've built a culture around shipping fast, iterating constantly, and treating uptime as something you achieve through monitoring and alerting. IBM i shops have a different model: build it right once, compile it, and let it run for 20 years. Neither approach is universally correct, but the IBM i model has something to teach us about the cost of change and the value of stability.

The Payroll System Is Still Running

That payroll system from 1997? Still running. They added a web frontend — a React app that talks to Db2 for i via a REST API on IWS. The RPG programs still do the heavy lifting. The green screens are still there for the HR team who've been using them since before React was a word.

I don't write RPG. I don't want to write RPG. But I respect the hell out of a system that can process 14,000 paychecks every two weeks, without drama, for 29 years straight.

Your Kubernetes cluster could never.

Word count: ~2,200