Every few months, someone tells me RPG is a dead language. It isn't — and the distance between that assumption and reality is exactly where the risk lives.
RPG — IBM's Report Program Generator — is the business programming language still running core applications on AS/400, iSeries, and IBM i systems inside banks, insurers, manufacturers, and distributors around the world. It was born in 1959 to do one thing: generate business reports, fast. More than six decades later it's doing far more than that, and most of the people who understood how have retired. Indispensable and increasingly opaque — that combination is what makes RPG one of the harder problems in enterprise technology today, and why comprehensive data lineage has become essential to working with it.
A language that was brilliant for its job
To understand why RPG endures, you have to appreciate what it was built to do. Its fixed-logic "program cycle" automatically read a record, processed it, and wrote the output — the machine handled the plumbing so the programmer could focus on the business rule. Paired with native, direct access to IBM's databases, with record locking and journaling built in, it made transactional processing fast, reliable, and remarkably quick to write, chewing through enormous data volumes with almost no overhead. For its purpose, it was excellent.
It also kept evolving. RPG II brought the classic fixed-format style; RPG III (1978) added subroutines and better file handling on the System/38 and later AS/400; RPG IV and ILE RPG (1994) finally introduced modular procedures and modern structure; and free-format RPG (2013) dropped the rigid column rules so code could read like a contemporary language. IBM's near-obsessive backward compatibility meant every generation kept running — RPG II code can often still execute, untouched, on a current IBM i box. That's a real engineering achievement.
Why it's so hard to work with now
That same longevity is the source of the problem. Backward compatibility means a single system today can carry four or five distinct RPG dialects stacked on top of each other — 1960s fixed-format sitting beside 1990s ILE procedures and modern free-format sections, all running together, each following the conventions of a different decade. Working with a codebase like that is less like reading a program than excavating one.
The language doesn't make it easier. Traditional RPG leans on cryptic operation codes — CHAIN, SETLL, READE — and column-specific formatting that looks alien to anyone trained on modern languages, and even current versions lack full object-oriented capabilities. Because it's a proprietary IBM ecosystem, expertise concentrated among specialists instead of a broad community, and there was never much documentation culture — the program cycle was assumed to make the logic self-evident. It wasn't, at least not once the original authors were gone. Hardest of all, RPG's tight coupling to the database means business rules are frequently embedded directly in file operations and the program cycle itself, and applications often depend on externally described files (DDS) whose definitions live outside the code entirely.
The real problem isn't the language — it's the loss of visibility
Here's the reframe I'd offer any leader staring at an RPG estate: the code isn't your liability. The business logic inside it is often irreplaceable — decades of hard-won rules about how your business actually works, still processing your most critical transactions every day. The liability is that you can no longer see what it does. When the people who understood it have left and the documentation never existed, an asset quietly becomes a risk — not because it fails, but because no one can safely change, migrate, or even explain it. That's a visibility problem, not a language problem. And visibility is something you can fix.
Making legacy RPG legible again
This is exactly what modern data lineage — and specifically Zengines Contextual Data Lineage — is built to do for RPG, COBOL, and PL/1. Rather than asking a shrinking pool of specialists to trace logic by hand, it reads across every RPG variant in a system at once, giving unified visibility from 1960s fixed-format through modern free-format code. It maps the database relationships RPG applications are built around, and surfaces the business rules by analyzing how data actually transforms as it moves through the programs. Before you change anything, it shows the downstream dependencies — so legacy system modernization becomes an informed decision about what to keep, replace, or retire instead of a leap of faith. None of it requires touching the running system; it just makes it knowable again.
Treat RPG as an asset worth understanding
RPG will outlive most predictions of its death, because the businesses running on it can't afford to switch off the logic it holds. The teams that do well with these systems are the ones that stop treating them as archaic code to be tolerated and start treating them as repositories of critical business knowledge to be understood. The language isn't the problem. Losing sight of what it does is — and that one's solvable.
Interested in preserving and understanding your RPG-based systems? Schedule a demo today.
Frequently Asked Questions
What is the RPG programming language? RPG (Report Program Generator) is IBM's business-oriented programming language, first released in 1959 and still widely used on AS/400, iSeries, and IBM i systems. It's designed for database-driven business applications and report generation.
Is RPG still used today? Yes. RPG runs core transactional applications in banking, insurance, manufacturing, and distribution across thousands of IBM i (AS/400) systems, and IBM continues to support and update it — including modern free-format RPG.
What's the difference between RPG and RPG IV / ILE RPG? Older RPG (II/III) uses a rigid, column-based fixed format and a built-in program cycle. RPG IV / ILE RPG (1994) added modular procedures, prototypes, and the Integrated Language Environment; free-format RPG (2013) removed the column rules, letting code look like modern languages.
What systems run RPG? RPG runs on IBM's midrange line — System/3 through System/38, AS/400, iSeries, and today's IBM i — tightly integrated with the DB2 for i database.
How do you modernize RPG code? Modernizing RPG starts with understanding it: mapping the data flows and extracting the business rules embedded across RPG II through free-format code. Data lineage makes that logic visible so teams can safely refactor, replace, or migrate without breaking the business processes RPG quietly runs.