AS/400, IBM i and RPG: what to modernise and what to leave alone

Most of the AS/400 replacement projects we are asked to quote on should not happen. The platform is supported, it is reliable, and replacing it is the most expensive answer available to a problem that is usually about the screen and the hiring market. This guide is about telling those apart.

AS/400, iSeries, System i, IBM i

Four names, one lineage, and a great deal of confusion as a result. If your documentation says one thing and your vendor says another, they are the same machine at different points in time.

The practical consequence of the renaming is that searching for advice returns material spanning thirty years, much of it about problems that no longer exist.

The platform is not the problem

IBM i is still developed, still supported, and still receiving new releases. In reliability terms it outperforms most of what would replace it. Organisations running it very rarely complain about uptime, data integrity or performance.

This matters because a great deal of advice treats "legacy" and "failing" as the same word. On IBM i they are not. A thirty-year-old RPG application on a supported platform is in a fundamentally different position from a Visual FoxPro application whose vendor stopped shipping in 2015.

What people are actually complaining about

When we ask what is wrong, the answers cluster into four, and none of them is the platform:

• The green screen. New staff will not learn a 5250 interface, and training time on it is a real recruitment cost.
• Hiring. RPG programmers are retiring faster than they are being replaced, and the ones remaining are expensive.
• Integration. Other systems reach the data by screen scraping or overnight file drops, both of which are fragile.
• Mobile and remote access. There is none, because 5250 was never designed for it.

Every one of those is an interface or integration problem. Replacing IBM i to solve them is like rebuilding a house because you do not like the front door.

Which RPG you have, and why it matters

Open a source member and look at the shape of the code.

• RPG II and RPG III use fixed columns. Each character position has a meaning, so the code looks like a punch card rendered as text. It is readable once you know the column rules, and almost unreadable if you do not.
• RPG IV, also called RPGLE, allows longer names and more conventional structure.
• Free-format RPG looks like an ordinary modern language and can be read by any competent developer without RPG-specific training.

This matters for one practical reason: converting fixed-format RPG III to free-format is sometimes worth doing on its own, before any other modernisation. It does not change what the program does. It changes who can read it, which is the actual constraint you are up against.

What to modernise instead

1. Put a web interface over the same data

Browser and mobile screens reading and writing DB2 for i directly. The RPG keeps running, the data stays where it is, and the green screen stops being a hiring obstacle. This is the change staff notice and it is a fraction of the cost of a migration.

2. Expose real APIs

Most organisations integrate with IBM i through screen scraping or overnight file transfers. Both work until a screen changes or a job fails silently. Replacing them with proper APIs over DB2 for i is usually the single highest-value piece of work available, because it unblocks every other system you own.

3. Document the RPG

Covered below, because it is the urgent one.

4. Map the CL batch jobs

The overnight CL programs are where a surprising amount of the real processing happens, and they are almost never documented. When an IBM i modernisation goes wrong after cutover, this is usually why.

The one thing that is genuinely urgent

This is the work that never gets prioritised because it produces nothing visible. It is also the work that determines whether a modernisation two years from now is a project or an excavation.

Practically, that means: a written inventory of every program and what it does, the batch schedule and what depends on it, the calculation rules that are not obvious from the code, and the list of things that look wrong but are deliberate. That last category is worth more than the rest combined.

When leaving is justified

There are real cases, and it would be dishonest to pretend otherwise:

• The application is a vendor package and the vendor is gone. You are maintaining somebody else's software with no source and no support, which is a different situation from maintaining your own.
• The hardware is genuinely at end of life and the upgrade cost is comparable to a replacement.
• The business has changed shape such that the application no longer matches how the work is done, in which case you are replacing the process, not the platform.
• A group IT policy requires consolidation, which is a commercial decision rather than a technical one, and worth naming as such.

What does not justify it: being told that the platform is old. It is old and it works, and those are not in tension. The test is whether the specific thing that is wrong can be fixed at the interface and integration layer. Most of the time it can, and that is a much smaller project than the one you have been quoted for.