IBM RPG und Java im Vergleich – Terminologie, Konzepte und Einsatzgebiete auf IBM i

Was bedeutet „Library“ im Vergleich zu einem Schema? Ist ein IBM-i-Job ein Thread? Und wann ist RPG die bessere Wahl als Java – oder umgekehrt?

1. Kurzfassung: RPG vs. Java auf IBM i

RPG und Java werden oft gegeneinander gestellt. Das ist verständlich, aber meistens zu grob. RPG ist auf IBM i tief verwurzelt, sehr nah an klassischen Geschäftsprozessen, Batch-Verarbeitung, 5250-Anwendungen und Db2-for-i-Datenstrukturen. Java ist stärker in plattformübergreifenden Architekturen, APIs, Webanwendungen, Frameworks, Integrationen und verteilten Systemen zu Hause.

Modernes RPG, insbesondere ILE RPG mit freier Syntax und vollständig freiem Quellformat, ist deutlich lesbarer und modularer als ältere feste Spaltenformate. Java wiederum bringt ein riesiges Ökosystem mit: Build-Tools, Frameworks, Testbibliotheken, REST-Stacks, Observability, Cloud-Integration und eine große Entwicklerbasis.

2. AS/400, System i, IBM i – erst die Namen sortieren

Viele sprechen bis heute von „AS/400“. Gemeint ist damit in der Praxis häufig eine moderne IBM-i-Umgebung auf IBM Power Systems. Historisch ist das aber nicht dasselbe. Die AS/400 wurde 1988 vorgestellt. Später kamen Namen wie iSeries und System i. Seit 2008 spricht man vom Betriebssystem IBM i auf IBM Power Systems.

Diese Unterscheidung ist mehr als Kosmetik. Wer „AS/400“ sagt, meint manchmal Hardware, manchmal Betriebssystem, manchmal 5250-Oberfläche, manchmal RPG-Anwendung und manchmal einfach „das alte System im Keller“. Für technische Entscheidungen ist das zu ungenau. Besser ist:

• IBM i für das Betriebssystem.
• IBM Power Systems beziehungsweise Power-Server für die Plattform.
• Db2 for i für die integrierte relationale Datenbank.
• RPG / ILE RPG für die Programmiersprache beziehungsweise Laufzeitumgebung.
• 5250 für die klassische Terminal-orientierte Benutzeroberfläche.

3. RPG und Java: zwei Sprachen, zwei Denkwelten

RPG entstand aus der Welt der geschäftlichen Datenverarbeitung. Ursprünglich ging es stark um Berichte, Dateien, Satzverarbeitung und klar strukturierte Geschäftsabläufe. Genau deshalb passt RPG bis heute gut zu vielen Kernprozessen: Auftrag, Kunde, Bestand, Buchung, Rechnung, Versand, Tagesabschluss.

Java entstand später mit einem anderen Versprechen: eine Sprache und Laufzeitumgebung, die auf unterschiedlichen Plattformen lauffähig ist. In Unternehmenssystemen wurde Java vor allem durch die JVM, breite Bibliotheksunterstützung, Server-Frameworks und eine große Community stark.

Der spannendste Punkt ist: Beide Sprachen können auf IBM i relevant sein. IBM i unterstützt Java über IBM Technology for Java beziehungsweise aktuelle JDK-Optionen. Gleichzeitig bleibt RPG für bestehende IBM-i-Geschäftsanwendungen sehr wichtig, weil dort oft jahrzehntelang gewachsene Fachlogik steckt.

4. Terminologie: IBM-i-Begriffe sauber übersetzt

Viele Übersetzungen von IBM-i-Begriffen sind nur Annäherungen. Eine Library ist nicht einfach ein Ordner. Ein Job ist nicht einfach ein Thread. Und ein Logical File kann je nach Kontext eher an einen Index, eine View oder einen Zugriffspfad erinnern. Genau deshalb lohnt sich eine vorsichtige Terminologie-Tabelle.

5. Datenbankdenken: Physical Files, SQL-Tabellen und Db2 for i

Db2 for i ist tief in IBM i integriert. Das unterscheidet die Plattform deutlich von Umgebungen, in denen Datenbankserver, Betriebssystem und Anwendungsschicht klar getrennte Produkte sind. Auf IBM i können traditionelle Datei-Zugriffe und SQL-Zugriffe auf ähnliche Datenbestände treffen – aber sie sprechen teilweise unterschiedliche Sprachen.

Der alte Artikel setzte „Physical File = SQL Table“ und „Logical File = SQL Index / SQL View“ sehr direkt gleich. Als Einstieg ist das okay, aber fachlich sollte man vorsichtiger sein. Eine Physical File kann wie eine Tabelle behandelt werden. Eine SQL-Tabelle ist ebenfalls ein Datenbankobjekt. Aber die Historie, DDS-Definitionen, Member-Konzepte, Zugriffspfade und Namenslogik können Unterschiede machen.

Gerade Java-Teams unterschätzen oft, wie viel Geschäftslogik in Datenstrukturen, DDS-Beschreibungen, Triggern, Programmen, Jobumgebung, Bibliotheksliste und Batch-Abläufen steckt. Umgekehrt unterschätzen klassische IBM-i-Teams manchmal, wie wichtig explizite API-Verträge, automatisierte Tests und saubere Deployment-Pipelines für moderne Systemlandschaften sind.

6. Laufzeitmodell: Jobs, Programme, Threads und Services

Ein IBM-i-Job ist eine eigene Welt: Benutzerprofil, Jobbeschreibung, Bibliotheksliste, Aktivierungsgruppen, Meldungen, Protokoll, Umgebung und Ressourcen hängen daran. Deshalb ist die Gleichsetzung „Job = Thread“ zu kurz.

Für Integrationsarchitekturen ist diese Ebene entscheidend. Java kann RPG-Programme aufrufen, Daten über JDBC lesen, REST-Schnittstellen bereitstellen oder als separate Service-Schicht neben IBM i laufen. Aber jeder Zugriff auf bestehende Logik muss die IBM-i-Laufzeitrealität respektieren: Bibliotheksliste, Berechtigungen, CCSID, Sperren, Commitment Control, Fehlerkanäle und Antwortzeiten.

7. Mini-Codevergleich: gleiche Aufgabe, anderes Denken

Ein einfaches Beispiel zeigt den Unterschied ganz gut. Die fachliche Aufgabe lautet: Für einen Kunden wird der Umsatz aus Bestellungen gelesen und ausgegeben. In RPG denkt man häufig näher an Db2 for i und bestehender Programmlogik. In Java denkt man oft stärker in Repository, Service und Objektmodell.

**FREE
ctl-opt dftactgrp(*no) option(*srcstmt:*nodebugio);

dcl-s customerNo packed(7:0) inz(4711);
dcl-s amount     packed(11:2) inz(0);

exec sql
  select coalesce(sum(order_total), 0)
    into :amount
    from orders
   where customer_no = :customerNo;

dsply ('Umsatz: ' + %char(amount));

*inlr = *on;
return;

import java.math.BigDecimal;

public class CustomerRevenueService {
    private final OrderRepository orders;

    public CustomerRevenueService(OrderRepository orders) {
        this.orders = orders;
    }

    public BigDecimal revenueForCustomer(int customerNo) {
        return orders.sumOrderTotalByCustomerNo(customerNo);
    }
}

Das Beispiel ist bewusst klein. In echten Anwendungen wäre die RPG-Seite oft in bestehende Programme, Serviceprogramme oder Stored Procedures eingebettet. Die Java-Seite hätte Tests, Dependency Injection, Logging, Fehlerbehandlung, Transaktionsgrenzen und eine API-Schicht. Der Punkt ist: Beide können dieselbe Fachfrage beantworten, aber sie organisieren Verantwortung unterschiedlich.

8. Einsatzgebiete: Wann RPG, wann Java?

Die beste Wahl hängt selten nur an der Sprache. Wichtiger sind Zielbild, Risiko, Datenmodell, Schnittstellenbedarf, Team und Lebensdauer der Anwendung.

9. Modernisierung: Ergänzen ist oft klüger als Ersetzen

Modernisierung bedeutet nicht automatisch Migration. Ein gesundes Zielbild kann so aussehen:

• Alte RPG-Programme in verständliche Module und Serviceprogramme schneiden.
• Feste Formatquellen schrittweise in freiere, lesbarere RPG-Formen überführen.
• SQL-Zugriffe, Datenmodell und Transaktionsgrenzen dokumentieren.
• RPG-Fachlogik über definierte Schnittstellen verfügbar machen.
• Neue APIs, Weboberflächen und Integrationen mit Java oder anderen modernen Stacks bauen.
• Tests, Logging, Monitoring und Deployment-Pipelines ergänzen.

Ein Rewrite kann sinnvoll sein, wenn die bestehende Anwendung fachlich verstanden, technisch stark begrenzt, schlecht wartbar oder strategisch nicht mehr tragfähig ist. Aber ein Rewrite ist kein Selbstzweck. Gerade bei IBM-i-Systemen steckt viel Wissen in kleinen Details: Sonderfälle, Datenkorrekturen, jahrzehntelang gewachsene Regeln, Betriebsfenster, Sperrlogik, Batch-Reihenfolgen und Ausnahmebehandlungen.

10. Entscheidungsmatrix für Projekte

Für konkrete Projekte hilft eine nüchterne Matrix. Nicht sexy, aber wirksam. Architekturentscheidungen sollten nicht aus Bauchgefühl entstehen, sondern aus nachvollziehbaren Kriterien.

Eine gute IBM-i-Modernisierung respektiert die Plattform und öffnet sie gleichzeitig dort, wo es fachlich sinnvoll ist. Genau darin liegt der Charme: Nicht nostalgisch am Alten kleben, aber auch nicht blind alles neu bauen, nur weil ein Stack moderner klingt.

11. Fazit

Der alte Vergleich „RPG ist Legacy, Java ist Zukunft“ ist zu billig. Besser ist: RPG ist oft das fachliche Gedächtnis des Unternehmens. Java ist oft die Brücke zu modernen Architekturen. Wer beides versteht, kann IBM-i-Landschaften deutlich risikoärmer modernisieren.

Quellen