RPG – quo vadis?

Today, the term RPG conjures up very different images depending on one's generation.
For some, it means C-Specs, indicators and programs whose meaning sometimes only becomes clear when you know which column contains a particular character. For others, RPG is a fully free-form programming language with procedures, local variables, complex data structures, embedded SQL, APIs and modern development tools.
Both views are correct.
RPG is among the oldest programming languages still used daily for business-critical applications. IBM originally developed it in the late 1950s as the "Report Program Generator" for commercial data processing. Through RPG II, RPG III, RPG/400 and RPG IV, a heavily form- and record-oriented language gradually evolved into a modern business programming language for IBM i.1
So the more interesting question today is not whether RPG is old: that is beyond dispute.
The more interesting question is: Where does RPG stand today – and where is the language heading?

From RPG/400 to ILE RPG

A major turning point was RPG IV, or ILE RPG.
With the Integrated Language Environment, RPG moved beyond the notion that a program necessarily had to be one large, self-contained unit. Programs could be built from modules, procedures could be encapsulated, and shared functions could be moved into service programs.
Service programs make functions available to multiple programs through defined interfaces. IBM explicitly describes them as a means of reusing shared functions and simplifying maintenance.2
This introduced many concepts now associated with modular software development:
  • Procedures
  • Modules
  • Service Programs
  • Prototypes
  • local variables
  • clearly defined interfaces
  • separation of public and internal functionality
Nevertheless, RPG source code continued to look like traditional RPG for a long time. The next major transformation was therefore less architectural than visual and syntactic.

Breaking Free from Columns

Anyone familiar with RPG/400 or early RPG IV knows how strongly the language was shaped by fixed positions in source members.
In 2013, IBM introduced free-form declarations for H-, F-, D- and P-specifications, among others. Fully Free RPG followed in 2015. For the first time, RPG code could be written entirely without the traditional column structure.3
For example, a modern RPG program might begin like this:
RPGLE_FREE
**free

ctl-opt dftactgrp(*no);

dcl-s customerNo packed(9:0);

dcl-proc GetCustomerName;
dcl-pi *n varchar(100);
customerNo packed(9:0) const;
end-pi;

// Business logic ...

end-proc;
This syntax bears little resemblance to the traditional image of RPG II or RPG/400.
This is more than a cosmetic change. When a programming language is no longer defined by source columns, modern editors, source-control systems, automatic formatting and code analysis become much easier to use.

How Modern Is RPG Today?

Today, RPG offers many language features expected of a modern procedural business language.
These include:
  • fully free-form syntax
  • local procedures
  • prototypes and procedure interfaces
  • qualified and nested data structures
  • arrays
  • enumerations
  • exception handling
  • ON-EXIT processing
  • FOR-EACH
  • SELECT structures
  • numerous built-in functions
  • Unicode support
  • data processing with DATA-INTO and DATA-GEN
  • XML processing
  • very close integration with Db2 for i and embedded SQL
Moreover, IBM does not enhance RPG only through new major releases. Many language features are now delivered via PTFs for existing releases. RPG Cafe documents a continuous series of such enhancements over many years.4
This is very different from a programming language maintained solely for compatibility reasons.

What Was Added in IBM i 7.6?

IBM i 7.6 brought further improvements to ILE RPG. Importantly, some of these features have also been, or will be, made available through PTFs for earlier releases. Enhancements include, for example, new date-conversion options, additional built-in functions and improvements involving procedures and ON-EXIT.
IBM explicitly states that many of the enhancements included in 7.6 are also available through PTFs for IBM i 7.4 and 7.5.5
This also illustrates an interesting change in product maintenance: In the past, a new language feature was closely tied to a new operating-system release. Today, IBM can develop RPG much more continuously and independently of that cycle. The enhancements introduced after the release of IBM i 7.6 are therefore even more interesting than its initial feature set.

July 2026: IBM Enhances RPG Again

In July 2026, IBM released new ILE RPG features for IBM i 7.5 and 7.6.
These include6:
  • ASSERT-T and ASSERT-F
  • generic message IDs for ON-EXCP
  • LIKE(*EXT)
  • %LOOKUPNE and %TLOOKUPNE
  • additional job information in the Program Status Data Structure
None of these enhancements revolutionises RPG.
But that is precisely what makes them interesting: IBM clearly is not trying to turn RPG into a completely different language. Instead, it is steadily addressing specific weaknesses and adding features useful for modern business applications and development practices.

Assertions – a Small Enhancement with a Big Message

ASSERT-T and ASSERT-F are particularly noteworthy.
An assertion describes a condition that a programmer expects to be true or false at a particular point in a program.
For example:
RPGLE
ASSERT-T customerNo > 0
%MSG('Customer number must be greater than zero');
Assertions can be used to verify a procedure's preconditions and postconditions.
IBM explicitly mentions a second use case as well: unit testing.
Different assertion modes determine what happens when an assertion fails. In ASSERT(*CALL:...) mode, for example, a procedure can be called for each assertion to evaluate the test result.7
The fact that IBM is adding language features to RPG in 2026 that explicitly support unit tests is an important signal.

A language kept alive merely for backward compatibility would hardly receive development features of this kind

RPG and SQL Continue to Converge

One of the most important changes in modern RPG applications is only partly about RPG itself: it is about SQL.
Traditional IBM i applications often use record-level access: CHAIN, SETLL, READE, WRITE, UPDATE and DELETE are deeply rooted in RPG's history. These operations will not disappear.
Nevertheless, the relationship between RPG and the database has changed.
Complex data operations can often be expressed more clearly and efficiently in SQL. At the same time, SQL on IBM i has long been more than just a database language. IBM continuously expands QSYS2 and SYSTOOLS services, making a wealth of operating-system and system information available through them.
For modern applications, an increasingly sensible division of responsibilities is emerging:
RPG for business logic
SQL for data logic
Of course, the boundary is not rigid. But the close relationship between RPG and Db2 for i is one of the language's greatest strengths. Future RPG developers will therefore need to be as comfortable with SQL as they are with RPG.

RPG Does Not Have to Do Everything

RPG is not a general-purpose programming language. And it probably should not become one.
Anyone developing a platform-independent mobile application, a machine-learning model or a general internet service today is unlikely to choose RPG. Why would they? RPG's strengths lie elsewhere.
RPG runs where many companies keep a substantial part of their business-critical logic and most important data: on IBM i. There, RPG can access Db2 directly, use IBM i objects and APIs, call existing programs and service programs, and work deeply integrated with the platform without additional middleware.
The future of RPG therefore does not depend on whether every conceivable task can be solved with RPG, but on whether RPG performs well at the tasks for which IBM i is used.

From the Self-Contained Application to the API

Traditionally, the application model often looked something like this:
5250
 |
RPG
 |
Physical File
Today's model can look completely different:
Web application / Mobile client / External system
 |
REST API
 |
RPG business logic
 |
SQL / Db2 for i
An RPG program no longer has to present its own user interface. It can provide a business function that other applications consume.
This means decades-old business logic does not necessarily have to be replaced; instead, it can be embedded in a modern architecture. That is a fundamental difference between modernisation and redevelopment.

Modern RPG Development Means More Than Free Format

You can write a 15,000-line monolithic program entirely in Free Format. That does not make it modern.

The future of RPG therefore depends at least as much on development practices as on new language features.
IBM is investing heavily in Code for IBM i for Visual Studio Code. Among other things, the extension enables editing and compiling RPGLE, CL, COBOL and C/C++ directly from Visual Studio Code. With IBM i 7.6 and subsequent Technology Refreshes, Git support, debugging, code coverage, RPG support and other development features have been expanded.8
The figures from the 2026 IBM i Marketplace Survey are also remarkable:
- 74% of respondents still use tools from the traditional Application Development Tool Set, including SEU and PDM.
- At the same time, 58% already use Visual Studio Code and 57% use RDi. In this survey, VS Code was slightly ahead of RDi for the first time.9
This is far more than a minor cosmetic change of editor. Development practices are changing:
Source members become Git repositories.
Changes can be managed through branches and pull requests.
Code can be built automatically.
Tests can be integrated into build processes.
Code reviews become easier.
Deployment and change management can be automated.
Modern RPG therefore does not simply mean: "No more C-Specs."
Modern RPG, now and in the future, means: Git → Development → Review → Build → Test → Deployment.

The Real Problem May Not Be RPG at All

In the 2026 IBM i Marketplace Survey, a shortage of IBM i professionals was identified as respondents' biggest concern for the first time. 10 This is often used as an argument against RPG. But perhaps cause and effect are being confused.
An application that is decades old, poorly documented, built around large monolithic programs, with little modularisation, no automated testing environment and source control based exclusively on traditional source files, is difficult for a new developer to understand.
The problem here is not the programming language. A well-structured Fully Free RPG project with procedures, service programs, SQL, Git, a modern IDE, documentation and tests is something entirely different.
The decisive question for the future may therefore not be: "How much longer will RPG exist?"
But rather: "How do we continue developing RPG applications?"

Would You Write a New Application in RPG Today?

The answer is neither an unconditional yes nor an unconditional no.
For a business-critical application intended to run on IBM i in the long term, working extensively with Db2 for i and using existing IBM i business logic, RPG remains an exceptionally sensible choice.
Why would you not take advantage of a natively integrated language in such an environment?
The situation is different for an application whose main requirements lie outside IBM i:
A mobile app does not have to be written in RPG.
An AI model does not have to be written in RPG.
A platform-independent web service does not have to be written in RPG.
These components can still work with RPG applications. That is precisely where the architecture of the future lies:
No longer one programming language for everything, but multiple technologies, each used where its strengths lie.

RPG – quo vadis?

RPG is unlikely to become the next universally fashionable programming language. An army of Python, JavaScript or Java developers will not suddenly start learning RPG.
But that is not the relevant measure of success.
RPG has an exceptionally large installed base of business-critical software on IBM i. IBM continues to develop the language actively. At the same time, IBM is investing in Visual Studio Code, Git-oriented development and AI-assisted modernisation.11
The journey therefore does not seem to be leading towards a completely new language. It is leading towards an RPG that does not deny its origins but is increasingly less constrained by them.
  • Less monolithic code
  • More procedures and service programs
  • More SQL
  • More APIs
  • More tests
  • More Git
  • More automation
  • More AI support
  • And probably less debate about whether RPG is "old"
A programming language is not obsolete simply because it is old. What matters is whether it continues to evolve, whether it performs its purpose efficiently, and whether it can be used to develop software that meets today's and tomorrow's quality standards.
By these criteria, RPG is by no means at the end of its journey in 2026. The more interesting phase may only just have begun.

This article is an AI-assisted translation of the German original

RPG – quo vadis? (German original)