RPG – quo vadis?

Wer heute den Begriff RPG hört, verbindet damit je nach Generation sehr unterschiedliche Bilder.
Für den einen sind es C-Specs, Indikatoren und Programme, deren Bedeutung sich teilweise erst erschliesst, wenn man weiss, in welcher Spalte ein Zeichen steht. Für den anderen ist RPG eine vollständig freie Programmiersprache mit Procedures, lokalen Variablen, komplexen Data Structures, Embedded SQL, APIs und modernen Entwicklungswerkzeugen.
Beide Bilder sind richtig.
RPG gehört zu den ältesten Programmiersprachen, die noch täglich für geschäftskritische Anwendungen eingesetzt werden. IBM entwickelte die Sprache Ende der 1950er-Jahre ursprünglich als "Report Program Generator" für kommerzielle Datenverarbeitung. Aus einer stark formular- und recordorientierten Sprache wurde über RPG II, RPG III, RPG/400 und RPG IV schrittweise eine moderne Business-Programmiersprache für IBM i.1
Die interessantere Frage ist deshalb heute nicht, ob RPG alt ist: Das ist unbestritten.
Die interessantere Frage lautet: Wo steht RPG heute – und wohin entwickelt sich die Sprache?

Von RPG/400 zu ILE RPG

Ein wesentlicher Wendepunkt war RPG IV beziehungsweise ILE RPG.
Mit dem Integrated Language Environment wurde RPG von der Vorstellung gelöst, dass ein Programm zwingend eine grosse, in sich abgeschlossene Einheit sein muss. Programme konnten aus Modulen aufgebaut werden, Procedures konnten gekapselt und gemeinsam genutzte Funktionen in Service Programme ausgelagert werden.
Service Programme ermöglichen es, Funktionen als definierte Schnittstellen mehreren Programmen zur Verfügung zu stellen. IBM beschreibt sie ausdrücklich als Mittel zur Wiederverwendung gemeinsamer Funktionen und zur Vereinfachung der Wartung.2
Damit waren viele Konzepte vorhanden, die man heute mit modularer Softwareentwicklung verbindet:
  • Procedures
  • Modules
  • Service Programs
  • Prototypes
  • lokale Variablen
  • klar definierte Schnittstellen
  • Trennung von öffentlicher und interner Funktionalität
Trotzdem sah eine RPG-Source noch lange nach klassischem RPG aus. Der nächste grosse Wandel war deshalb weniger architektonisch als optisch und syntaktisch.

Die Befreiung von den Spalten

Wer RPG/400 oder frühes RPG IV kennt, weiss, wie stark die Sprache von festen Positionen im Source Member geprägt war.
2013 ermöglichte IBM Free-Form-Deklarationen unter anderem für H-, F-, D- und P-Specifications. 2015 folgte Fully Free RPG. Damit konnte RPG-Code erstmals vollständig ohne die traditionelle Spaltenstruktur geschrieben werden.3
Ein modernes RPG-Programm kann beispielsweise so beginnen:
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;

// Businesslogik ...

end-proc;
Mit dem klassischen Bild von RPG II oder RPG/400 hat diese Syntax nur noch wenig gemeinsam.
Das ist mehr als nur Kosmetik. Wenn eine Programmiersprache nicht mehr durch Source-Spalten definiert wird, können moderne Editoren, Source-Control-Systeme, automatische Formatierung und Codeanalyse wesentlich einfacher eingesetzt werden.

Wie modern ist RPG heute?

RPG verfügt heute über viele Sprachelemente, die man von einer modernen prozeduralen Business-Sprache erwartet.
Dazu gehören unter anderem:
  • vollständig freie Syntax
  • lokale Procedures
  • Prototypes und Procedure Interfaces
  • qualifizierte und verschachtelte Data Structures
  • Arrays
  • Enumerations
  • Exception Handling
  • ON-EXIT-Verarbeitung
  • FOR-EACH
  • SELECT-Strukturen
  • zahlreiche Built-in Functions
  • Unicode-Unterstützung
  • Datenverarbeitung mit DATA-INTO und DATA-GEN
  • Verarbeitung von XML
  • sehr enge Integration mit Db2 for i und Embedded SQL
IBM erweitert RPG ausserdem nicht nur mit neuen Major Releases. Viele Sprachfunktionen werden inzwischen über PTFs für bestehende Releases ausgeliefert. RPG Cafe dokumentiert eine kontinuierliche Reihe solcher Erweiterungen über viele Jahre.4
Damit unterscheidet sich die Situation deutlich von einer Programmiersprache, die lediglich aus Kompatibilitätsgründen noch unterstützt wird.

Was kam mit IBM i 7.6 hinzu?

IBM i 7.6 brachte weitere Verbesserungen für ILE RPG. Dabei ist wichtig: Ein Teil dieser Funktionen wurde oder wird auch über PTFs für frühere Releases bereitgestellt. Zu den Erweiterungen gehören beispielsweise neue Möglichkeiten bei Datumskonvertierungen, zusätzliche Built-in Functions und Verbesserungen rund um Procedures und ON-EXIT.
IBM erwähnt ausdrücklich, dass viele der in 7.6 enthaltenen Erweiterungen auch über PTFs für IBM i 7.4 und 7.5 verfügbar sind.5
Das zeigt auch eine interessante Veränderung in der Produktpflege: Früher war eine neue Sprachfunktion stark mit einem neuen Betriebssystemrelease verbunden. Heute kann IBM RPG unabhängig davon wesentlich kontinuierlicher weiterentwickeln. Noch interessanter als der Stand beim Erscheinen von IBM i 7.6 sind deshalb die Erweiterungen danach.

Juli 2026: IBM erweitert RPG erneut

Im Juli 2026 veröffentlichte IBM neue ILE-RPG-Funktionen für IBM i 7.5 und 7.6.
Dazu gehören6:
  • ASSERT-T und ASSERT-F
  • generische Message IDs für ON-EXCP
  • LIKE(*EXT)
  • %LOOKUPNE und %TLOOKUPNE
  • zusätzliche Jobinformationen in der Program Status Data Structure
Keine dieser Erweiterungen revolutioniert RPG.
Aber gerade das ist interessant: IBM versucht offensichtlich nicht, RPG in eine völlig andere Sprache zu verwandeln. Stattdessen werden laufend konkrete Schwächen beseitigt und Funktionen ergänzt, die für moderne Business-Anwendungen und moderne Entwicklungsverfahren nützlich sind.

Assertions – eine kleine Erweiterung mit grosser Aussage

Besonders bemerkenswert sind ASSERT-T und ASSERT-F.
Eine Assertion beschreibt eine Bedingung, von der ein Programmierer erwartet, dass sie an einer bestimmten Stelle im Programm wahr beziehungsweise falsch sein muss.
Beispielsweise:
RPGLE
ASSERT-T customerNo > 0
%MSG('Customer number must be greater than zero');
Assertions können dazu verwendet werden, Vor- und Nachbedingungen einer Procedure zu überprüfen.
IBM nennt auch ausdrücklich einen zweiten Anwendungszweck: Das Unit-Testing.
Über unterschiedliche Assertion Modes kann festgelegt werden, was bei einer fehlgeschlagenen Assertion geschehen soll. Im Modus ASSERT(*CALL:...) kann beispielsweise eine Procedure für jede Assertion aufgerufen werden und das Testergebnis auswerten.7
Dass IBM RPG im Jahr 2026 um Sprachmittel erweitert, die ausdrücklich auch Unit Tests unterstützen, ist ein wichtiges Signal.

Eine Sprache, die lediglich noch aus Gründen der Rückwärtskompatibilität am Leben gehalten wird, würde kaum um derartige Entwicklungsfunktionen erweitert

RPG und SQL wachsen weiter zusammen

Eine der wichtigsten Veränderungen moderner RPG-Anwendungen hat mit RPG selbst nur teilweise zu tun: Es ist SQL.
Traditionelle IBM-i-Anwendungen arbeiten häufig mit Record-Level Access: CHAIN, SETLL, READE, WRITE, UPDATE und DELETE sind tief in der Geschichte von RPG verankert. Diese Funktionen werden nicht verschwinden.
Trotzdem hat sich das Verhältnis zwischen RPG und Datenbank verändert.
Komplexe Datenoperationen können mit SQL häufig klarer und effizienter formuliert werden. Gleichzeitig ist SQL auf IBM i längst mehr als eine reine Datenbanksprache. IBM erweitert QSYS2- und SYSTOOLS-Services laufend und stellt darüber zahlreiche Betriebssystem- und Systeminformationen zur Verfügung.
Für moderne Anwendungen ergibt sich deshalb zunehmend eine sinnvolle Arbeitsteilung:
RPG für Businesslogik
SQL für Datenlogik
Natürlich ist die Grenze nicht scharf. Gerade die enge Verbindung zwischen RPG und Db2 for i gehört aber zu den grössten Stärken der Sprache. Ein RPG-Entwickler der Zukunft wird deshalb mindestens ebenso selbstverständlich SQL beherrschen müssen wie RPG.

RPG muss nicht alles können

RPG ist keine Universalprogrammiersprache. Und wahrscheinlich sollte sie auch keine werden.
Wer heute eine plattformunabhängige mobile Anwendung, ein Machine-Learning-Modell oder einen allgemeinen Internetdienst entwickelt, wird dafür kaum RPG wählen. Warum auch? - Die Stärke von RPG liegt woanders.
RPG läuft dort, wo sich in vielen Unternehmen ein erheblicher Teil ihrer geschäftskritischen Logik und ihrer wichtigsten Daten befindet: auf IBM i. Dort kann RPG direkt auf Db2 zugreifen, IBM-i-Objekte und APIs nutzen, bestehende Programme und Service Programme aufrufen und ohne zusätzliche Middleware tief in die Plattform integriert arbeiten.
Die Zukunft von RPG hängt deshalb nicht davon ab, ob man künftig jede Aufgabe mit RPG lösen kann, sondern ob RPG jene Aufgaben gut löst, für die IBM i eingesetzt wird.

Von der abgeschlossenen Anwendung zur API

Das klassische Anwendungsmodell sah vereinfacht häufig so aus:
5250
 |
RPG
 |
Physical File
Das heutige Modell kann völlig anders aussehen:
Web-Anwendung / Mobile Client / Fremdsystem
 |
REST API
 |
RPG Businesslogik
 |
SQL / Db2 for i
Ein RPG-Programm muss seine Benutzeroberfläche nicht mehr selbst darstellen. Es kann eine Businessfunktion bereitstellen und andere Anwendungen können diese Funktion konsumieren.
Damit wird die jahrzehntealte Businesslogik nicht zwangsläufig ersetzt, sondern in eine moderne Architektur eingebettet. Das ist ein wesentlicher Unterschied zwischen Modernisierung und Neuentwicklung.

Moderne RPG-Entwicklung bedeutet mehr als Free Format

Man kann ein 15'000 Zeilen grosses monolithisches Programm vollständig in Free Format schreiben. - Modern wird es dadurch aber nicht.

Die Zukunft von RPG hängt deshalb mindestens ebenso stark von den Entwicklungsverfahren ab wie von neuen Sprachfunktionen.
IBM investiert intensiv in Code for IBM i für Visual Studio Code. Die Extension ermöglicht unter anderem die Bearbeitung und Compilation von RPGLE, CL, COBOL und C/C++ direkt aus Visual Studio Code. Mit IBM i 7.6 und den folgenden Technology Refreshes wurden unter anderem Git-Unterstützung, Debugging, Code Coverage, RPG-Unterstützung und weitere Entwicklungsfunktionen ausgebaut.8
Auch die Zahlen aus der IBM i Marketplace Survey 2026 sind bemerkenswert:
- 74% der Befragten verwenden noch Werkzeuge aus dem klassischen Application Development Tool Set mit SEU und PDM.
- Gleichzeitig verwenden bereits 58% Visual Studio Code und 57 Prozent RDi. Damit lag VS Code in dieser Erhebung erstmals knapp vor RDi.9
Das ist kein kleiner kosmetischer Wechsel des Editors. Damit verändern sich die Entwicklungsverfahren:
Source Members werden zu Git-Repositories.
Änderungen können über Branches und Pull Requests geführt werden.
Code kann automatisiert gebaut werden.
Tests können in Build-Prozesse integriert werden.
Code Reviews werden einfacher.
Deployment und Change Management können automatisiert werden.
Modernes RPG bedeutet deshalb nicht einfach: "Keine C-Specs mehr."
Modernes RPG bedeutet jetzt und in Zukunft: Git → Entwicklung → Review → Build → Test → Deployment.

Das eigentliche Problem ist möglicherweise gar nicht RPG

In der IBM i Marketplace Survey 2026 wurden fehlende IBM-i-Fachkräfte erstmals als grösste Sorge der Befragten genannt. 10 Das wird häufig als Argument gegen RPG verwendet. Aber möglicherweise wird hier Ursache und Wirkung verwechselt.
Eine jahrzehntealte, kaum dokumentierte Anwendung mit grossen monolithischen Programmen, wenig Modularisierung, keiner automatisierten Testumgebung und Source Control ausschliesslich über traditionelle Source Files ist für einen neuen Entwickler schwierig zugänglich.
Das Problem ist hier nicht die Programmiersprache. Ein gut strukturiertes Fully-Free-RPG-Projekt mit Procedures, Service Programs, SQL, Git, einer modernen IDE, Dokumentation und Tests ist etwas völlig anderes.
Die entscheidende Zukunftsfrage lautet deshalb möglicherweise nicht: "Wie lange gibt es RPG noch?"
Sondern: "Wie entwickeln wir RPG-Anwendungen weiter?"

Würde man heute eine neue Anwendung in RPG schreiben?

Die Antwort lautet weder grundsätzlich Ja noch grundsätzlich Nein.
Für eine geschäftskritische Anwendung, die langfristig auf IBM i betrieben wird, intensiv mit Db2 for i arbeitet und vorhandene IBM-i-Businesslogik verwendet, ist RPG weiterhin eine ausgesprochen sinnvolle Wahl.
Warum sollte man in einer solchen Umgebung die Vorteile der nativ integrierten Sprache nicht nutzen?
Anders sieht es bei einer Anwendung aus, deren Hauptanforderungen ausserhalb IBM i liegen:
Eine mobile App muss nicht in RPG geschrieben werden.
Ein AI-Modell muss nicht in RPG geschrieben werden.
Ein plattformunabhängiger Webdienst muss nicht in RPG geschrieben werden.
Diese Komponenten können trotzdem mit RPG-Anwendungen zusammenarbeiten. Gerade darin liegt die zukünftige Architektur:
Nicht mehr eine Programmiersprache für alles, sondern mehrere Technologien, von denen jede dort eingesetzt wird, wo sie ihre Stärken besitzt.

RPG – quo vadis?

RPG wird kaum die nächste universelle Trendprogrammiersprache. Es wird keine Armee von Python-, JavaScript- oder Java-Entwicklern plötzlich RPG lernen.
Aber das ist auch nicht die relevante Messgrösse.
RPG besitzt eine aussergewöhnlich grosse installierte Basis geschäftskritischer Software auf IBM i. IBM entwickelt die Sprache weiterhin aktiv. Gleichzeitig investiert IBM in Visual Studio Code, Git-orientierte Entwicklung und AI-gestützte Modernisierung.11
Die Reise scheint deshalb nicht in Richtung einer vollkommen neuen Sprache zu führen. Sie führt zu einem RPG, das seine Herkunft nicht verleugnet, aber immer weniger von ihr eingeschränkt wird.
  • Weniger monolithisch
  • Mehr Procedures und Service Programs
  • Mehr SQL
  • Mehr APIs
  • Mehr Tests
  • Mehr Git
  • Mehr Automation
  • Mehr Unterstützung durch AI
  • Und vermutlich weniger Diskussion darüber, ob RPG "alt" ist
Denn eine Programmiersprache ist nicht allein deshalb veraltet, weil sie alt ist. Entscheidend ist, ob sie weiterentwickelt wird, ob sie ihre Aufgabe effizient erfüllt und ob sich mit ihr Software nach heutigen und zukünftigen Qualitätsmassstäben entwickeln lässt.
Nach diesen Kriterien ist RPG im Jahr 2026 keineswegs am Ende seines Weges. Die interessantere Phase könnte gerade erst begonnen haben.