Was macht ein AS/400 Developer? Aufgaben, Stack und Karriere‑Entscheidungen für Bewerber:innen

Einstieg: Warum AS/400-Entwicklung heute noch relevant ist

Kurz: Ein AS/400 (IBM i) Developer pflegt und erweitert geschäftskritische Anwendungen auf der IBM i‑Plattform — von Bugfixes und Batch‑Jobs bis zu Schnittstellen, Db2‑SQL und Modernisierungsarbeiten.

Wer in Stellenausschreibungen auf „AS/400“ stößt, trifft in der Regel auf die heutige IBM‑Plattform „IBM i“. Sie wird von IBM kontinuierlich weiterentwickelt, inklusive moderner Entwicklungswerkzeuge und Cloud‑Optionen. Einen schnellen Überblick liefert die offizielle Produktseite von IBM i (IBM nennt u. a. integrierte Datenbank, Security und moderne Toolchains) – siehe dazu die IBM‑Seite zu IBM i.

Für Bewerber:innen bedeutet das: Hinter einem vermeintlich „alten“ Label stecken oft stabile Kernsysteme mit realen Weiterentwicklungs‑ und Modernisierungsaufgaben – von ERP‑Anpassungen bis hin zu API‑Anbindungen.

Was macht ein AS/400 Developer konkret?

Die Rolle variiert je nach Unternehmen und Produkt, folgt aber häufig diesen Linien:

Systempflege und Wartung: Incidents analysieren, Bugs beheben, Jobs/Batch‑Verarbeitung stabil halten, Datenkorrekturen und kleine Changes umsetzen.
Weiterentwicklung bestehender Anwendungen: Anforderungen aus Fachbereichen aufnehmen, Konzepte erstellen, RPG‑/CL‑Code anpassen, Releases begleiten.
Schnittstellen und Datenintegration: Dateischnittstellen betreuen, EDI/CSV/XML‑Austausch, gelegentlich REST/HTTP‑Anbindungen sowie Middleware‑Anschluss.
Datenbankarbeit: Abfragen, Performance‑Checks, Stored Procedures und Views in der integrierten Datenbank Db2 for i bearbeiten.

Diese Mischung findet sich auch in Beispiel‑Stellenprofilen: Entwicklung neuer Lösungen in vorhandenen Systemlandschaften, Pflege/Weiterentwicklung einer ERP‑Software, Qualitätssicherung und Dokumentation sind typische Schwerpunkte (siehe z. B. eine deutsche Anzeige für „Softwareentwickler AS/400“ mit Fokus auf ERP‑Weiterentwicklung und OS/400/Db2‑Kenntnisse).

Tech‑Stack und relevante Sprachen/Tools

Die Plattform bringt vieles „out of the box“ mit. Für Entwickler:innen sind vor allem diese Bausteine relevant:

RPG / ILE RPG: Zentrale Geschäftssprache auf IBM i, heute mit modernen Sprachfeatures (Free‑Form, Prozeduren). Gute Einstiege bietet die IBM‑Dokumentation zu ILE RPG.
CL (Control Language): Skripting für Jobs, Deployments, Automatisierung und Operator‑Tasks.
Db2 for i: Die auf IBM i integrierte relationale Datenbank. Typisch sind Embedded SQL in RPG sowie SQL‑Services. Mehr dazu in der IBM‑Doku zu Db2 for i.
Entwicklungsumgebungen: Rational Developer for i (RDi) als Eclipse‑basierte IDE; zusätzlich nutzen Teams häufig VS Code und IBM Access Client Solutions (ACS) für SQL‑ und Admin‑Tasks.
Debugging und System‑APIs: ILE‑Debugger, Service‑Programme, IBM i‑APIs.
Moderne Ergänzungen: Je nach Haus auch Web‑Frontends (z. B. Java/PHP/JS) oder REST‑Anbindungen; IBM bietet u. a. DevTools für Modernisierung auf IBM i.

Hinweis: IBM positioniert IBM i ausdrücklich mit modernen Entwicklungsoptionen, inkl. Tooling und Bereitstellung on‑prem oder in IBM Power Virtual Server – Details auf der IBM‑Produktseite zu IBM i.

So läuft die Zusammenarbeit im Alltag

Run‑Betrieb vs. Projekte: Der Tagesablauf pendelt zwischen Tickets (Störungen/Änderungen), geplanten Wartungsfenstern und Projektarbeit. Priorisierung erfolgt oft über ein ITSM‑ oder Kanban/Scrum‑Board.
Nähe zu Fachbereichen: Anforderungen kommen häufig aus ERP‑, Logistik‑ oder Finanzprozessen. Gutes Prozessverständnis ist daher so wichtig wie Syntaxkenntnisse.
Qualität und Dokumentation: Änderungen werden getestet (Unit‑/Integrationstests, Fachtests), versioniert und dokumentiert – inklusive Übergaben in Betrieb/Support.

Qualifikationsprofil: Welche Skills zählen?

Fachlich nützlich sind – je nach konkreter Rolle – insbesondere:

RPG/ILE RPG, CL, Verständnis der IBM i‑Laufzeitumgebung (Bibliotheksstruktur, IFS, ILE‑Konzepte)
SQL/Embedded SQL für Db2 for i (Abfragen, Prozeduren, Performance‑Grundlagen)
Tooling: RDi, VS Code, ACS; Debugger/Service‑Programme, System‑APIs
Grundbegriffe zu Sicherheit und Autoritäten auf IBM i
Optional: Web‑/Schnittstellen‑Know‑how (z. B. REST/HTTP, XML/CSV), Testautomatisierung, DevOps‑Praktiken

Ein offizieller Referenzrahmen, was IBM unter einem „IBM i Developer“ versteht, ist die Zertifizierung „IBM Certified Developer – IBM i 7.x“. Die Seite skizziert u. a. SDLC‑Wissen, ILE‑Verständnis, Db2‑Kenntnisse, Debugging/Tools sowie Berührungspunkte zu Open‑Source‑Sprachen.

Entscheidungen und Trade‑offs für deine Karriere

Plattformtiefe vs. Breite: Ein Fokus auf IBM i baut profundes Wissen über eine integrierte Enterprise‑Plattform auf. Wer zusätzlich moderne Web/Cloud‑Stacks pflegt, bleibt flexibler – beides schließt sich nicht aus.
Modernisieren statt neu schreiben: Viele Teams modernisieren schrittweise (Datenbank, Services, UI), statt alles zu ersetzen. Das schafft Chancen für Entwickler:innen, die bestehende Prozesse verstehen und tragfähige Schnittstellen bauen.
Marktbild nüchtern betrachten: IBM i wird außerhalb spezialisierter Kreise teils als „älter“ wahrgenommen. Gleichzeitig gibt es Bestandsumgebungen, die kontinuierlich weiterentwickelt werden.

Markt- und Gehaltsaussichten in Deutschland (transparenter Hinweis)

Belastbare, allgemein gültige Gehaltsbänder speziell für IBM i/AS‑400‑Entwickler:innen auf Deutschland‑Ebene liegen nicht flächendeckend in öffentlich verfügbaren Quellen vor. Kandidat:innen sollten deshalb aktuelle Jobbörsen und konkrete Stellenanzeigen prüfen, um ein realistisches Bild für ihre Region und Erfahrungsstufe zu bekommen.

Als einzelnes, gekennzeichnetes Beispiel: Eine exemplarische deutsche Stellenanzeige (Quelle: FERCHAU, exemplarisches Jobprofil) nennt in vergleichbaren Senioritätskontexten Gehaltsrahmen im Bereich von etwa 55.000–65.000 €; diese Angabe ist jedoch nur ein Einzelfall aus dem Anzeigenmarkt und darf nicht als allgemein gültig interpretiert werden. Vergleiche mehrere aktuelle Anzeigen in deiner Region, achte auf Branche und Unternehmensgröße und frage im Bewerbungsprozess nach dem genauen Gehaltsrahmen.

Vorbereitung auf Bewerbungen und Interviews

Die folgenden Themen tauchen – je nach Rolle – häufig in Gesprächen und technischen Assessments auf. Nutze sie als strukturierte Checkliste für deine Vorbereitung.

Plattformwissen

Bibliotheksliste vs. IFS: Praktische Auswirkungen auf Build/Deploy‑Skripte, Pfadauflösung und Berechtigungen.
Unterschied ILE vs. PASE: ILE beschreibt die native IBM‑i‑Laufzeit (Module, Service‑Programme, native RPG/COBOL), PASE ist eine POSIX‑ähnliche Umgebung auf IBM i, die Unix‑adjazente/portierbare Laufzeiten ermöglicht. Für Build/Runtime bedeutet das: native ILE‑Artefakte laufen im IBM‑i‑Runtime, PASE‑Artefakte brauchen die POSIX‑Schicht und sind sinnvoll, wenn externe Open‑Source‑Tools oder portierbarer Code eingesetzt werden.

Datenbank & SQL

Besondere Merkmale von Db2 for i (Integriertheit, SQL‑Services, Triggers/Procedures).
Embedded SQL vs. Record Level Access (RLA) im RPG‑Code: Wann Embedded SQL klarer ist und wann RLA weiterhin genutzt wird.
Performance‑Basics: Indizes, Explain/Pläne, typische Anti‑Patterns in Batch‑Jobs.

Entwicklung & Tools

ILE‑Konzepte: Module, Service‑Programme, Prototyping/Prozeduren in ILE RPG.
CL‑Skripte für Operationen, Automatisierung und Release‑Tasks.
Arbeiten mit RDi/VS Code/ACS, Quellcodeverwaltung, Debugging mit Breakpoints und Variableninspektion.

Prozesse & Kommunikation

SDLC‑Erfahrung: Von Anforderung über Entwicklung, Test, UAT bis Go‑Live.
Dokumentation und Übergabe in Betrieb/Support, Umgang mit Wartungsfenstern.

Beispielfragen, auf die du Antworten vorbereiten solltest:

Wie erklären Sie den Unterschied zwischen Bibliotheksliste (Library List) und IFS – und welche Folgen hat er für Build/Deploy?
Wann bevorzugen Sie Embedded SQL in RPG gegenüber RLA – und warum?
Skizzieren Sie, wie Sie ein Performance‑Problem in einer nächtlichen Batch‑Verarbeitung angehen.
Welche Schritte gehen Sie beim Debuggen eines ILE‑RPG‑Programms in RDi?
Wie binden Sie eine neue Schnittstelle (z. B. CSV/REST) sauber in eine bestehende ERP‑Transaktion ein?

Nachweise, die in Bewerbung/Interview helfen:

Kleine Codebeispiele (RPG/CL) mit kurzer Doku, die SQL‑Zugriff, Fehlerbehandlung und Tests zeigen.
Auszüge aus System‑ oder Prozessdokumentationen (anonymisiert), die Zusammenarbeit mit dem Fachbereich sichtbar machen.
Ein Mini‑Modernisierungsbeispiel: z. B. eine Funktion als Service/API neu kapseln.

Lernpfade und Zertifikate: pragmatisch vorgehen

Je nach Vorerfahrung kann ein kompakter Lernpfad in einigen Monaten praktikabel sein; die genaue Dauer hängt stark von deinen Vorkenntnissen (z. B. SQL‑Erfahrung, generelle Programmiererfahrung, Vertrautheit mit Enterprise‑Systemen) ab. Vermeide fixe Zeitversprechen ohne Bezug zu deinem Background.

Starte praxisnah mit:

SQL‑Übungen auf Db2 for i (ACS/VS Code), dazu ein kleines RPG‑/CL‑Beispiel mit Embedded SQL.
Debug‑Walkthrough in RDi, inklusive Breakpoints, Variableninspektion und Service‑Programmen.
Einfache Schnittstelle (CSV/XML) lesen/schreiben und robust loggen.

Offizielle Ressourcen:

IBM Training „Getting Started with IBM i Development“ – Grundlagen zu Db2 for i, modernen Tools und dem Coding‑Zyklus in RPG/CL.
IBM‑Zertifizierung „IBM Certified Developer – IBM i 7.x“ – nützlich als strukturierter Kompetenzrahmen; Zertifikate sind kein Muss, können aber Profil und Gespräche ordnen.

Kurze Einordnung: Jobrealität, Stabilität und Lernfelder

Die Jobrealität für AS/400‑ bzw. IBM‑i‑Entwickler:innen ist geprägt von stabilen, geschäftskritischen Systemen, die laufend betreut und schrittweise modernisiert werden. In vielen Unternehmen sind IBM‑i‑Anwendungen Teil der Kernprozesse (z. B. ERP, Logistik, Abrechnung) und erfordern daher Zuverlässigkeit und Betriebskenntnis. Das bedeutet konkret: ein großer Teil der Arbeit ist Erhalt und Anpassung bestehender Funktionen, ergänzt durch punktuelle Modernisierungs‑ und Integrationsaufgaben.

Stabilität heißt nicht Stillstand: IBM selbst positioniert IBM i weiterhin als Plattform mit integrierter Datenbank und modernen Tools, was sich in den angebotenen Trainings und Modernisierungswerkzeugen widerspiegelt. Für Kandidat:innen heißt das, dass fundierte Kenntnisse in RPG/CL und Db2 for i wiederkehrend gefragt sind, parallel zu Fähigkeiten, Schnittstellen zu bauen und bestehende Anwendungen schrittweise zu modernisieren.

Lernfelder sind daher meist praktisch und direkt anwendbar: SQL/Db2‑Know‑how, Umgang mit RDi/VS Code und Debugging‑Workflows, sowie Verständnis für Betriebsabläufe (Job‑Scheduling, Wartungsfenster, Backup/Restore). Wer zusätzliche Web‑ bzw. API‑Kompetenzen mitbringt, erhöht seine Einsatzmöglichkeiten in Projekten zur Modernisierung.

Fazit: Für wen lohnt sich der Einstieg – und wie punktest du?

IBM i/AS‑400‑Entwicklung passt zu Menschen, die stabile Kernprozesse verstehen, gern nah an ERP/Logistik/Finance arbeiten und saubere, belastbare Lösungen liefern. Du punktest, wenn du:

die Plattformbegriffe sicher erklären kannst (ILE, Bibliotheksliste vs. IFS, Db2 for i, Embedded SQL vs. RLA),
ein kleines, lauffähiges RPG/CL‑Beispiel mit SQL‑Zugriff und Debug‑Know‑how zeigen kannst und
mit Fachbereichen klar kommunizierst – vom Anforderungsbild bis zum sauberen Go‑Live.

Praktischer Tipp zum Schluss: Verweise in deinem Lebenslauf oder Git‑Portfolio auf ein kurzes, anonymisiertes Mini‑Projekt. Ein sichtbarer, nachvollziehbarer Workflow von „Anforderung“ über „RPG/SQL‑Umsetzung“ bis „Test/Doku“ zeigt genau die Stärken, die Teams auf IBM i suchen.