Mit IBM i arbeiten mit IBM Bob

Wenn du noch nie eine Zeile RPG geschrieben hast, ist IBM i eine der faszinierendsten Plattformen für Produktion im großen Maßstab. Wenn du ein paar Millionen Zeilen davon geschrieben hast, weißt du bereits, wo die alltäglichen Schmerzen liegen. Dieser Beitrag deckt beides ab: eine technische Skizze dessen, was IBM i einzigartig macht, wo Modernisierungsreibung tatsächlich auftritt, wie IBM Bob heute in einen IBM i-Workflow passt, die Setup-Schritte für den Einstieg und was als Nächstes auf der Roadmap für die Plattform steht.

Was IBM i tatsächlich ist

IBM i ist kein Legacy-Betriebssystem im Sinne von "wir sollten das neu schreiben". Es ist eine integrierte Plattform – das OS, die Datenbank, das Sicherheitsmodell und die Runtime sind als eine Einheit konzipiert und ausgeliefert – die seit Jahrzehnten Umsatz für Banken, Versicherer, Krankenhäuser, Hersteller und Logistikunternehmen generiert. Wir sollten es also legendär nennen.

Ein paar Details, die Entwickler beim ersten Mal überraschen:

Single-level storage. RAM und Festplatte teilen sich einen virtuellen Adressraum. Objekt-Pointer bleiben über Neustarts hinweg bestehen. Das OS behandelt Speicher und Storage als eine einzige Ebene und paged transparent zwischen ihnen. Die meisten modernen Systeme holen das immer noch auf.
TIMI, das Technology Independent Machine Interface. RPG-Binaries, die auf Hardware aus den 1990ern kompiliert wurden, laufen unverändert auf aktuellen POWER-Chips. Das OS übersetzt unter der Haube gegen den neuen Instruction Set. Das nächste moderne Analogon ist WebAssembly, Jahrzehnte früher.
Objektbasiertes OS. Programme, Dateien, Queues und Berechtigungen sind typisierte Objekte mit Attributen – keine Dateien mit aufgesetzten Metadaten. Sicherheit wird auf Objektebene durchgesetzt.
Db2 for i ist integriert, nicht aufgesetzt. SQL und natives Record-Level-I/O greifen auf dieselben Daten zu. Eine 40 Jahre alte Physical File kann durch eine moderne SQL-View abgefragt werden, ohne ein Migrationsprojekt.
Source kann auf dem System oder in Git leben – deine Wahl. Historisch wurde IBM i-Source als Members innerhalb von Source Physical Files (QSYS) gespeichert, direkt auf dem System kompiliert. Die Plattform positionierte ursprünglich die LPAR als Source of Truth. Aber IBM i hat sich weiterentwickelt: Die Compiler und das OS unterstützen jetzt vollständig moderne Git-zentrierte Workflows, IFS-Stream-Files und lokale Entwicklung, wenn du das möchtest. Viele Shops nutzen immer noch QSYS-Libraries, aber die Plattform gibt dir Optionen

Die Plattform unterstützt auch moderne Delivery-Patterns out of the box: native REST-API-Engines als Teil des OS, Hybrid Cloud durch Power Virtual Server und KI-Inferenz, die auf derselben Hardware wie transaktionale Workloads läuft. RPG, COBOL, CL und SQL koexistieren mit den Entwicklungspraktiken, die der Rest deiner Engineering-Organisation bereits nutzt.

Die Plattform ist nicht das Problem. Die Reibung liegt drumherum.

Wo die Reibung auftritt

Vier Muster tauchen in fast jedem IBM i-Shop auf. Keines davon betrifft RPG selbst – die Sprache ist in Ordnung – sondern den Kontext um den Code herum, der nie aufgeschrieben wurde, und die Art, wie die Plattform diesen Kontext speichert und teilt.

Impliziter Kontext, by design. Ein funktionierendes RPG-Programm kann vier Sprachgenerationen in einem Source umfassen – RPG II, RPG IV, /COPY-Copybooks (gemeinsame Deklarationen, die zur Compile-Zeit eingezogen werden) und Free-Format-Prozeduren – mit spaltensensibler Syntax und nummerierten Indikatoren (*IN01–*IN99), die die Arbeit machen, die strukturierter Control Flow und benannte Booleans in den meisten anderen Sprachen tun. Die Syntax ist in einer Woche erlernbar; die Konventionen und Business Rules drumherum leben in den Köpfen der Senior Engineers.
Änderung ist nie lokal. Der Typ eines Feldes wird nicht im Programm deklariert, das es nutzt – er wird in der Datenbanktabelle selbst deklariert, in einer separaten Source-Datei (einem DDS-Member). Jedes Programm, das diese Tabelle liest oder schreibt, erbt diese Definitionen einfach durch Referenzierung der Datei am Anfang. Eine Spalte von 10 auf 12 Ziffern zu verlängern ist also nie ein Ein-Programm-Edit: Es breitet sich durch jedes Programm aus, das die Datei berührt, und die Liste dieser Programme ist selten irgendwo aufgeschrieben. Jede Änderung an einer kritischen Workload trägt daher Kontinuitätsrisiko, und Modernisierung stockt.
Source lebt selten dort, wo moderne Tooling es erwartet. Die kanonische Kopie eines Programms ist auf dem System, nicht in einem Git-Repo auf einem Laptop. Code zu lesen, den jemand anderes vor fünfzehn Jahren geschrieben hat, beginnt damit, ihn auf der LPAR zu finden, zu exportieren und dann zu entscheiden, ob der Export die kanonische Kopie ist – ein Workflow, an den jedes Tool, das einen lokalen Working Tree annimmt, angepasst werden muss, bevor es sich bewährt.
Fixed-Form-RPG sieht nichts wie moderner Code aus. Die meiste Produktions-RPG wurde in Fixed-Form geschrieben: spaltensensible Syntax, wo Operation Codes in Spalten 26–35 leben, Factor 1 in 12–25 und Kommentare nur nach Spalte 80 passen. Es liest sich wie Assembler-Sprache für jeden, der auf Python oder JavaScript trainiert wurde. IBM hat die Sprache mit vollständig Free-Format-RPG (RPG IV, später einfach "RPG") neu erfunden, das aussieht und sich anfühlt wie eine moderne prozedurale Sprache – strukturierte Blöcke, benannte Variablen, Standard-Expressions. Die Syntax-Lücke ist real, aber die Sprache selbst hat sich entwickelt. Die Reibung ist, dass Jahrzehnte funktionierender Code immer noch in Fixed-Form vorliegen und das Umschreiben ein Risiko trägt, das die meisten Shops nicht rechtfertigen können.

Was Bob bei einer RPG-Anwendung für IBM i macht

Richte Bob auf ein RPG-Programm und starte im Ask-Modus:

"Führe mich durch, was dieses Programm macht und welche Files es berührt."
"Wo wird CUSTNO gesetzt und welche Programme lesen es danach?"
"Was würde brechen, wenn ich die Länge dieses Feldes ändere?"

Wechsle in den Plan-Modus, wenn du eine Änderung im Kopf hast: eine Free-Format-Konvertierung, eine SQL-Migration von Record-Level-I/O oder das Aufbrechen eines Monolithen in Module. Bob produziert einen Plan, die Dependencies, die es berührt hat, und die Schritte, die es zu unternehmen beabsichtigt, bevor eine Datei modifiziert wird.

Wechsle in den Code-Modus, um die Änderung anzuwenden. Bob:

Konvertiert Fixed-Format-RPG zu Free-Format mit wiederholbaren Patterns, Datei für Datei.
Migriert Record-Level-I/O zu Embedded SQL, wo angemessen.
Generiert RPGUnit-Test-Suites gegen bestehende Prozeduren, sodass die Konvertierung verifizierbar ist, nicht nur kompiliert.
Produziert Plain-Language-Dokumentation und Mermaid-Diagramme aus dem Source – durchsuchbare, teilbare Artefakte, die jeden einzelnen Engineer überleben.

Derselbe Workflow handhabt RPG II/III/ILE, CL, DDS, SQL und COBOL, sodass ein neuer Mitarbeiter, der ein Programm liest, das geschrieben wurde, bevor er geboren wurde, nicht mehr durch die Syntax blockiert wird.

Mach deinen IBM i-Source Bob-ready

Bob arbeitet heute gegen Source auf deinem lokalen Computer. Das Setup ist kurz:

Pull deinen Source runter. Exportiere deine RPG-, RPGLE-, CL-, DDS- und SQL-Members in einen lokalen Ordner. Der Code for i Project Explorer dokumentiert den Export aus Physical File Members: migrate source
Öffne den Ordner in Bob. File → Open Folder auf dem Source-Root. Bob indiziert die Codebase beim ersten Öffnen.
Installiere die IBM i-Toolchain. Füge aus dem Extensions-Panel das IBM i Development Pack (das Code for i-Bundle) und einen Mermaid-Renderer für die Diagramme hinzu, die Bob produziert.
Starte eine Session im Ask-Modus. Wähle ein einzelnes Programm – idealerweise eines, das niemand im Team vollständig versteht – und bitte Bob, es zu erklären. Das ist der schnellste Weg zu sehen, ob Bob seinen Platz in deinem Workflow verdient.

Wenn dein Team von SEU oder RDi kommt, ist die Migration hauptsächlich der Export-Schritt oben plus die Extension-Installation. Die Editing-Oberfläche ist eine moderne VS Code-Family-Umgebung mit Syntax-Highlighting, Code-Completion und dem oben beschriebenen KI-Workflow; Zeilennummern sind immer noch verfügbar für Engineers, die sie wollen.

Was als Nächstes für Bob auf IBM i kommt

Das kürzlich angekündigte Premium Package for i bietet native & optimierte Experience für IBM i-Entwicklungsteams. Premium Package for i wird am 24. Juni allgemein verfügbar.

Premium Package for i. Mit dem GA am 24. Juni wird Bob direkt mit deinem IBM i verbinden. Aus einer einzigen Session liest du Source Members direkt aus QSYS, bearbeitest sie mit demselben Workflow oben und führst Compile- und Test-Zyklen direkt gegen das System aus. Neben der Konnektivität nimmt Bob eingebaute Skills und Workflows auf, die auf IBM i-Entwicklung abgestimmt sind – Fixed-to-Free-Konvertierung, Refactoring, Dokumentgenerierung – sodass ein Starting Prompt auf einer RPG-Codebase direkter auf IBM i-Konventionen out of the box landet. Konkret bedeutet das:

Eine Bob-Session, die mit einer Development-LPAR verbunden ist; keine separate Export-Edit-Import-Schleife.
Compile-Fehler und Test-Ergebnisse vom IBM i tauchen zurück in der Konversation auf, in der Bob bereits ist.
Eingebaute Skills & Workflows für die Refactoring-, Konvertierungs- und Test-Generierungs-Patterns, die IBM i-Shops wiederholt ausführen.

Weiter draußen – End-to-End-SDLC. Drei Threads sind in aktivem Design für zukünftige Releases:

DevOps-Integration. Bob nimmt an Build, Deploy, Monitor und CI/CD für IBM i-Workloads teil – führt einen Regression-Pass gegen eine Test-LPAR aus, promoted eine Änderung durch Umgebungen und bringt ein Runtime-Issue zurück in eine Session.
SQL-Performance. Datenanalyse und Index-Optimierung als First-Class-Capability, zusätzlich zu den Embedded-SQL-Migrationspatterns, die Bob heute bereits produziert.
IBM i Knowledge Assistant. Retrieval-grounded Answers über die Codebase, Design-Dokumentation und Tickets hinweg – sodass Kontext, der außerhalb des Source lebt, aus derselben Konversation erreichbar ist.

Für ein Team, das Bob heute adoptiert, ist der Local-File-Workflow oben der richtige Startpunkt; die Items in diesem Abschnitt beschreiben, wie dieser Workflow kürzer wird und sich erweitert, während das IBM i-Angebot reift.

Kundenreferenzen

Teams in Healthcare, Landwirtschaft, Enterprise IT und Logistik nutzen Bob heute gegen Produktions-IBM i-Codebasen:

MEDHOST. Healthcare-Anwendungen, die mehrere RPG-Generationen über US-Krankenhaus-Deployments hinweg umfassen. Das Team nutzt Bob für Impact-Analyse und Fixed-to-Free-Konvertierung und für das Onboarding neuerer Entwickler auf Programme, deren ursprüngliche Autoren längst weg sind.
NI+C. Japanischer Enterprise-Integrator mit RPG-Programmen, die über ein Jahrzehnt unverändert liefen, ohne überlebende Design-Dokumentation. Bob produzierte Design Docs und Mermaid-Diagramme, die genau genug waren, dass Engineers, die zuvor von KI-Assistenten abgeprallt waren, es für echte Arbeit weiter nutzten.
Heartland Co-op. Iowa-basierte landwirtschaftliche Genossenschaft, die Echtzeit-IoT-Sensordaten in ihre IBM i-Umgebung für Getreidequalitäts- und Equipment-Monitoring streamt. Bob hilft Entwicklern, über die Interdependenzen zwischen der IoT-Pipeline, Grain Accounting und Core Operational Systems hinweg zu denken, und verkürzt die Ramp-up-Zeit für neue Mitarbeiter.
Carreras Grupo Logístico. Einer der ersten Enterprise-Bob-Adopter in Spanien, der es nutzt, um Legacy-Programmlogik zu erklären, Dokumentation zu generieren und über Module einer Logistikplattform hinweg zu refactoren.

Der gemeinsame Thread über alle vier hinweg ist derselbe: Die bestehende IBM i-Codebase bleibt an Ort und Stelle, und die Erklärungs-, Konvertierungs- und Dokumentationsarbeit läuft neben dem Produktionssystem, anstatt vor einem Replacement-Projekt.

Loslegen

Starte einen kostenlosen Trial
Pull ein RPG-Programm in einen lokalen Ordner und öffne es in Bob.
Im Ask-Modus fordere einen Walkthrough und ein Mermaid-Diagramm seines Data Flows an.

Diese Session – ein Programm, eine Konversation – ist der kürzeste Weg zu einer echten Antwort darüber, ob Bob zu der Art passt, wie dein Team arbeitet.