Architekturüberblick IBM i —
Systemkomponenten und ihr Zusammenspiel
IBM i ist nicht einfach ein Betriebssystem mit angebundenen Zusatzprodukten. Die Plattform ist als zusammenhängende Einheit aufgebaut — Betriebssystem, Datenbank, Sicherheitsmodell und Work Management greifen architektonisch ineinander.
Wer diesen Aufbau versteht, kann viele Besonderheiten von IBM i besser einordnen: warum Datenbank und Betriebssystem so eng verbunden sind, warum Sicherheit objektbezogen funktioniert und weshalb die Plattform über lange Zeiträume architektonisch konsistent geblieben ist.
Der Artikel zeigt die wichtigsten Ebenen der Plattform, beschreibt die zentralen integrierten Komponenten und ordnet IBM i im Vergleich zu klassischen Server-Architekturen ein. Ziel ist kein vollständiges internes Detailmodell, sondern ein fachlich belastbarer Gesamtüberblick.
Ein vereinfachtes Schichtenmodell der Plattform
Für das Verständnis von IBM i ist es hilfreich, die Plattform in Ebenen zu denken. Das folgende Modell ist eine didaktische Vereinfachung. Es soll die zentrale Logik der Plattform verständlich machen — nicht jede technische Einzelheit der internen Implementierung abbilden.
Die zentralen integrierten Systemkomponenten
Auch andere Plattformen kennen Betriebssystem, Datenbank, Sicherheit und Prozesssteuerung. Der entscheidende Unterschied bei IBM i liegt nicht in der Existenz dieser Funktionen, sondern in ihrer Integration. Sie werden nicht als lose Schichten nebeneinander betrieben, sondern greifen auf gemeinsame Plattformprinzipien zurück.
Db2 for i
Db2 for i ist integraler Bestandteil der Plattform. Datenhaltung, Zugriffsschutz, Sicherung und Verwaltung stehen deshalb enger im Zusammenhang mit dem System als bei Umgebungen, in denen eine Datenbank als separates Produkt neben dem Betriebssystem betrieben wird.
Work Management
Die Verarbeitung auf IBM i erfolgt in Jobs, die in Subsystemen laufen, über Job Queues zugeordnet und durch Speicherpools beeinflusst werden. Work Management ist damit kein Zusatzthema, sondern Teil der Architektur der Plattform.
IBM i
Das Betriebssystem steuert Ressourcen, Objekte, Benutzerkontexte und Ausführungsumgebungen. Es ist nicht nur die technische Laufzeitbasis, sondern der organisatorische Rahmen, in dem auch Datenbank, Sicherheit und Job-Steuerung zusammengeführt werden.
Integriertes Sicherheitsmodell
Zugriffe auf Ressourcen werden über Eigentümer, Autorisierungen und systemweit definierte Regeln gesteuert. Weil Programme, Dateien, Warteschlangen und viele weitere Elemente als Objekte behandelt werden, wirkt das Sicherheitsmodell plattformweit konsistent.
Auf IBM i greifen zentrale Systemfunktionen auf ein gemeinsames objektbasiertes Modell zurück — deshalb hängen Sicherheit, Datenhaltung und Verarbeitung enger zusammen als auf vielen anderen Plattformen.
Genau dieser Zusammenhang ist für Einsteiger wichtig: Wer IBM i nur als Betriebssystem betrachtet, versteht die Plattform zu kurz. Erst das Zusammenspiel von Objektmodell, Db2 for i, Sicherheitsmodell und Work Management erklärt, warum IBM i im Alltag anders funktioniert als Windows- oder Linux-Server.IBM i im Vergleich zu klassischen Server-Architekturen
Für Umsteiger aus Windows- oder Linux-Umgebungen hilft ein konzeptioneller Vergleich. Dabei geht es nicht darum, welches Modell „besser" ist, sondern darum, die architektonischen Unterschiede sauber zu erkennen.
| Aspekt | Windows / Linux | IBM i |
|---|---|---|
| Datenbank | Datenbanken werden typischerweise als eigene Produkte oder Dienste betrieben, mit eigener Installation, eigener Administration und eigenem Wartungszyklus. | Db2 for i ist in die Plattform integriert und architektonisch enger mit dem System verbunden. |
| Datei- und Objektwelt | Im Vordergrund steht üblicherweise ein hierarchisches Dateisystem mit Verzeichnissen und Dateien. | Im Kern arbeitet IBM i objektbasiert; zusätzlich existiert mit dem IFS auch ein hierarchisches Dateisystem. |
| Sicherheitsmodell | Sicherheitsmechanismen sind häufig auf mehrere Ebenen verteilt — Betriebssystem, Datenbank und Anwendung. | Das Sicherheitsmodell wirkt systemweit auf einer gemeinsamen Objektlogik. |
| Programmausführung | Anwendungen werden für eine spezifische Hardware-Architektur kompiliert. Ein Wechsel der Hardware-Generation erfordert in der Regel eine Neukompilierung. | Die sichtbare Plattformarchitektur ist von der internen technischen Umsetzung entkoppelt — Programme laufen auf neuen Hardware-Generationen weiter, ohne Neukompilierung. |
| Verarbeitungsmodell | Prozesse und Threads stehen meist im Vordergrund der Betriebslogik. | Jobs, Subsysteme, Job Queues und Speicherpools bilden eine stärker strukturierte Ausführungsumgebung. |
Wo das Integrated File System (IFS) einzuordnen ist
Zum Architekturüberblick gehört auch das Integrated File System (IFS). Es ergänzt die traditionelle Objekt- und Bibliothekswelt um pfadbasierte Zugriffe und ist besonders für moderne Werkzeuge, Open-Source-Software und Integrationsszenarien relevant.
Innerhalb des IFS bildet QSYS.LIB die klassische Bibliothekswelt in Form einer Verzeichnisstruktur ab. Für Umsteiger ist genau das wichtig: IBM i kennt sowohl die traditionelle objektbasierte Organisation als auch pfadbasierte Zugriffe — aber beide stehen auf derselben Plattform und sind kein Widerspruch.
Betriebssystem, Datenbank, Sicherheitsmodell und Work Management stehen nicht nebeneinander, sondern greifen architektonisch ineinander.
Diese Trennung ist eine wesentliche Grundlage dafür, dass IBM die Plattform über lange Zeiträume konsistent weiterentwickeln konnte.
Artikel 4 erklärt, was ein Objekt auf IBM i ist, welche Objekttypen es gibt und warum dieses Konzept für Administration und Entwicklung zentral ist.
IBM i praxisnah lernen — mit Übungszeit auf einem echten IBM i System und Nachbetreuung durch den Trainer.
Das Objektmodell von IBM i — Objekttypen, Eigentümer und Zugriffsrechte
Der nächste Artikel erklärt das Objektmodell im Detail: welche Objekttypen es gibt, wie Eigentum und Berechtigungen funktionieren und warum dieses Konzept für IBM i grundlegend ist.
▶ Weiter: Das Objektmodell