RPG: The Language Behind Your Business Logic

If your organization runs an IBM i system, the business logic that drives your operations — pricing calculations, inventory management, order processing, financial reporting, EDI transactions, and hundreds of other daily workflows — is almost certainly written in RPG. It is the native programming language of the IBM i platform, and it has been the backbone of business computing for millions of organizations worldwide for over five decades.

Most decision-makers have heard the name RPG but have little visibility into what it is, how it has evolved, or what the practical implications are for their business. This article provides that context.

RPG was introduced by IBM in 1959 as the Report Program Generator — a language designed to produce business reports. That original purpose is reflected in its name, but RPG has evolved far beyond report generation. Over the decades it became a full-featured business application programming language, used to build everything from order entry systems and inventory management to financial processing, warehousing workflows, and complex system integrations.

What made RPG successful was not technical elegance. It was practicality. RPG was designed to be used by business-oriented programmers, not computer scientists. It mapped naturally to the kinds of problems businesses needed to solve: read a record, apply business rules, update the data, produce output. This directness is why RPG applications tend to be tightly aligned with the business operations they support — the language encourages building what the business needs rather than abstract software architectures.

This practicality is also why RPG applications tend to be long-lived. The programs do exactly what the business requires, they run reliably, and they accumulate years of refinement as business rules evolve. An RPG program that has been running in production for 20 years is not a failure to modernize. It is a program that has been tested by two decades of real-world use.

One of the most important things for decision-makers to understand is that RPG is not one static language. It has evolved dramatically over its history, and the RPG being written today bears little resemblance to the RPG of the 1980s.

RPG II and RPG III were the versions that ran on the System/34 and System/36 in the 1970s and 1980s. These were fixed-format, column-dependent languages where the position of each character on a line determined its meaning. Programs were organized around a fixed processing cycle. This is the RPG that people picture when they hear the name — cryptic, dense, and difficult to read for anyone who did not grow up with it.

RPG/400 came with the AS/400 in 1988 and added significant capabilities, but the fundamental fixed-format structure remained. Programs from this era are still running in production at many organizations today.

RPG IV, introduced in 1994 and continuously enhanced since then, was a fundamental modernization of the language. It introduced free-format expressions, built-in functions, subprocedures, service programs, longer field names, and modern data types. RPG IV programs can be organized into modular, maintainable structures that resemble code written in any modern language.

The most significant change came with fully free-format RPG, introduced in IBM i 7.1 and expanded in subsequent releases. Free-format RPGLE eliminates all column dependencies. Code is written in a natural, readable style with meaningful variable names, structured control flow, and modern programming conventions. A developer familiar with Java, C, or Python can read well-written free-format RPGLE and follow the logic.

This evolution matters because it means RPG is not a dead-end language. It is actively developed by IBM, receives regular enhancements, and supports modern programming practices. The decision is not whether RPG can be modernized — it can. The decision is whether and how to invest in that modernization.

In many IBM i environments, knowledge of how the systems work is concentrated in a small number of people. The systems run reliably, so there is rarely a reason for a large team to be involved. Over time, that concentration becomes a business continuity concern.

The practical response is to make the environment more accessible and better documented — not to replace the systems or the people who know them. Converting fixed-format code to free-format RPGLE makes programs readable to a broader pool of developers. Documenting business logic, data flows, and integration dependencies reduces reliance on any single person's memory. Building modern interfaces around existing logic opens the door for other team members and tools to interact with the systems without needing to understand the RPG internals.

These steps reduce risk, extend the useful life of the environment, and create flexibility for whatever staffing or technology changes come next.

When the topic of RPG modernization comes up, many organizations assume it means replacing RPG with something else. This is often the wrong approach and almost always the most expensive and risky one.

Modernization can take many forms that preserve the value of existing RPG code while making it more maintainable, more accessible, and more integrated with modern platforms.

Converting fixed-format RPG to free-format RPGLE makes the code readable and maintainable by a broader pool of developers. The business logic is preserved exactly, but the code is no longer cryptic. This is often the highest-value modernization step and the lowest-risk one.

Wrapping RPG business logic with web service interfaces allows modern applications — web front ends, mobile apps, external integrations — to call existing RPG programs without rewriting them. The business logic stays in RPG where it has been tested for years. The interface to that logic becomes modern and accessible.

Using Java on IBM i through PASE to build new functionality alongside existing RPG is another practical approach. Java services can query the same DB2 for i database, interact with data queues, and participate in the same job and transaction structures. New capabilities are built in Java or Kotlin while existing RPG logic continues to run.

SQL-based access to DB2 for i data allows reporting tools, business intelligence platforms, and external applications to work with the same data that RPG programs manage. Embedded SQL within RPGLE programs themselves replaces older data access patterns with modern, optimizable queries.

The right modernization strategy depends on your specific environment, your business priorities, and where the highest risk and highest value intersect. But in most cases, the answer is not to throw away decades of proven business logic. It is to make that logic more accessible, more maintainable, and better connected to the rest of your technology environment.

If your organization depends on RPG applications, there are practical questions worth answering before a crisis forces the conversation.

How many RPG programs are in production, and which ones are business-critical? Are they documented, or does the documentation exist only in the heads of the people who maintain them? Are you running fixed-format RPG that is difficult for new developers to read, or has the code been modernized to free-format? Do you have more than one person who understands the critical programs? What happens to your operations if that person is unavailable for an extended period?

Are your RPG programs integrated with other systems through modern interfaces, or are they connected through brittle file-based exchanges and manual processes? Could modern reporting and analytics tools access your data if they needed to, or is all data access locked behind RPG programs?

These questions are not technical exercises. They are business continuity questions. The answers determine your risk exposure and inform the most practical path forward.

I have been working with RPG across its full evolution — from fixed-format RPG III on the System/36 through modern free-format RPGLE on current IBM i systems. But what makes that experience relevant is not the number of years. It is the combination of deep RPG knowledge with broad cross-platform expertise in Java, SQL, Linux, and modern integration technologies.

That combination is exactly what the knowledge gap problem requires. Addressing the concentration of knowledge in your RPG environment takes someone who can read and understand decades-old code, but also modernize it, document it, wrap it with modern interfaces, and build the bridges to Java, web services, and external platforms that extend the life and reach of your existing investment.

I work with RPG in the context of the broader environment, not in isolation. That means understanding the database, the integrations, the operational workflows, the reporting requirements, and the business context that the RPG code supports. It also means knowing when RPG is the right tool and when Java, SQL, or another approach is more appropriate.

I have helped organizations modernize fixed-format RPG to free-format, build web service interfaces around existing business logic, integrate RPG applications with Java services and external platforms, recover undocumented business logic from legacy code, and plan phased modernization strategies that reduce risk while preserving operational continuity.

Whether you need ongoing RPG support, modernization planning, integration work, knowledge transfer, or an honest assessment of your RPG environment and its risks, I can help.