OS/400

Das OS/400 (OS = Operating System) ist ein vom Unternehmen IBM entwickeltes und 1988 eingeführtes Betriebssystem für die Minirechnerklasse IBM Power Systems, System i, iSeries und AS/400 und eine erweiterte Form des 1979 unter der Bezeichnung CPF eingeführten Betriebssystems für das IBM System/38. Mit Erscheinen der Version 5 Release 3 (V5R3M0) wurde OS/400 in i5/OS umbenannt. Ab Version 6.1 heißt das Betriebssystem IBM i (for Business).

OS/400 Hauptmenü (V4R5M0)

Allgemeines

Zum Verständnis von OS/400 bzw. i5/OS ist es notwendig, das grundlegende Prinzip der System-i-Architektur zu verstehen: Hauptspeicher und Plattenspeicher gehen nahtlos ineinander über. In PC-Begriffen ausgedrückt ist der Hauptspeicher ein "Page-Cache" und der Plattenspeicher eine riesige Auslagerungsdatei (vgl. Paging). Die im Speicher – RAM oder Platte – befindlichen Daten sind generell Objekte, nicht Dateien. Somit war ein Dateisystem zunächst überflüssig. Erst mit der Anbindungsmöglichkeit für externe Datenspeicher wurde dieses Prinzip gebrochen und um ein integriertes Dateisystem ergänzt (mehr dazu unten).

Virtualisierung

OS/400 arbeitet allerdings nicht direkt mit der Hardware zusammen – vielmehr läuft es als virtuelle Maschine. Für die Vermittlung von Soft- und Hardware ist das MI (Machine Interface) oder auch TIMI (Technology-Independent Machine Interface) verantwortlich. Unterhalb der MI-Ebene arbeitet der SLIC (System Licensed Internal Code), welcher das eigentliche Betriebssystem darstellt, mit der Hardware zusammen (zu CISC-Prozessorzeiten hieß dieser Code noch HMC/VMC – horizontal/vertical microcode).

Vergleichbar mit Java erzeugt ein OS/400-Compiler, wie beispielsweise ILE/C, ILE/RPG oder ILE/COBOL, einen Zwischencode auf Machine-Interface-Ebene, der nicht direkt auf der Hardware der AS/400 lauffähig ist. Erst ein Native-Translator im Betriebssystem wandelt den Machine-Interface-Code in den ausführbaren Zielprozessorcode (früher CISC IMPI – Internal Microprogramming Interface Code, heute POWER RISC Code) um. Beides, der Zwischencode (auch als object template bezeichnet) und der ausführbare Zielprozessorcode, wird im Programmobjekt gespeichert. Bei einem Wechsel der Prozessorarchitektur sind keine Programmquelldateien notwendig, d. h. der entsprechende Translator erzeugt, basierend auf dem Zwischencode, den Zielprozessorcode spätestens beim ersten Programmaufruf neu. So wurde auch der Umstieg von der CISC- (48 Bit) auf die RISC-Architektur (64 Bit) bewerkstelligt. Dieses Konzept ist bereits auf eine eventuell später verfügbare 128-Bit-Architektur ausgelegt.

Objektbasiertheit

Das OS/400 ist nach dem Prinzip der Objektbasiertheit aufgebaut, wodurch grundsätzlich alles im Betriebssystem, egal ob Benutzerprofil oder Programm, als Objekt mit Eigenschaften und Funktionen angesehen wird; dieses Prinzip ist jedoch nicht zu verwechseln mit Objektorientierung, wie sie bei Programmiersprachen zu verstehen ist. Gemäß Konvention beginnen alle Systemobjekte mit dem Buchstaben Q (z. B. QSYS oder QSECOFR).

Diese konsequente Objektbasiertheit bewirkt, dass Objekte (Programme, Dateien, Spools, Subsysteme etc.) ausschließlich über einen Satz von abschließend definierten Funktionen angesprochen werden können. Damit ist es beispielsweise nicht möglich, den Binärcode eines Programms frei zu verändern, da diese Art von Schnittstelle zwar für Objekte des Typs Datei (*FILE), aber nicht für Objekte des Types Programm (*PGM) zur Verfügung steht. Dies unterscheidet OS/400 grundlegend von den meisten anderen Betriebssystemen, wo vom Dateisystem lediglich Dateien verwaltet werden, deren Verwendungszweck jeweils nur durch eine Dateiendung und eventuell eine User-Zuordnung festgelegt wird.

Objekte werden in Bibliotheken verwaltet. Diese Bibliotheken können dabei keine Unterbibliotheken enthalten, sondern nur Objekte. Eine Ausnahme ist die Bibliothek QSYS, die sämtliche Bibliotheken enthält. Dateien selbst können in Members unterteilt werden, die man Teildateien nennt. In denen vom Dateityp PF-SRC können zum Beispiel Quellcodes abgelegt werden, in PF-DTA werden Members als indizierbare Datentabellen abgelegt. In OS/400 hat jedes Member eine logische Satzlänge (LRECL). OS/400 kennt ursprünglich keine strukturfreien Dateien wie Unix. Dies wurde erst mit der Einführung des integrierten Dateisystems (IFS) möglich.

Integrierte Anwendungen

OS/400 bietet eine Vielzahl schlüsselfertiger Lösungen, wie beispielsweise ein fest verankertes Datenbankverwaltungssystem (Db2 for i), das keine zusätzliche Installation benötigt. Des Weiteren unterstützt i5/OS die Sprache Java.

Oftmals werden daher Fertiglösungen wie SAP auf System i oder Lotus Notes Cluster auf System i verkauft, die sich auf die systemintegrierten Fähigkeiten stützen und keine weiteren Lizenzen nach sich ziehen.

Befehle

Das Betriebssystem stellt für die Bedienung einige umfangreiche Menüs bereit. Ebenso kann die Bedienung auch durch die Befehle der Steuersprache (engl.: Command Language, kurz CL) geschehen. Diese Befehle sind untergliedert in:

1. Aktion (Was soll durchgeführt werden?)
2. Objekt (Womit soll es durchgeführt werden?)

Beispiele:

DSPOBJD: Der erste Teil DSP steht für DiSPlay, also Anzeigen. Der zweite Teil OBJD steht für OBJectDescription, also Objektbeschreibung. Zusammen mit den beiden Pflichtparametern OBJ und OBJTYPE kann man sich eine Objektbeschreibung anzeigen lassen, beispielsweise DSPOBJD OBJ(QTEMP) OBJTYPE(*LIB).

WRKOUTQ: Mit WRKOUTQ + „Name der Warteschlange“ lässt sich der Inhalt einer Ausgabewarteschlange anzeigen.

Mit dem Befehl GO CMD… wird die Möglichkeit geboten, sich alle Befehle anzeigen zu lassen, die mit einer entsprechenden Aktion verbunden sind. Zum Beispiel listet GO CMDWRK sämtliche Befehle auf, die mit WRK (WRK = Work) in Verbindung stehen. Alternativ ist es auch möglich, z. B. mit wrk*, alle mit WRK beginnenden Befehle anzuzeigen. Der Anwender kann mit der F4-Taste (BT4 auf Terminaltastaturen) eine Bedienerführung zu fast jedem Befehl aufrufen, womit die Eingabe von Parametern erleichtert wird.

Benutzer können auch selbst eigene Befehle anlegen. Hierzu sind Objekte vom Typ *CMD vorgesehen, die mit Befehlen nach hier beschriebenen Mustern angelegt werden können.

Als Tipp: Alle Befehlsnamen sind aus zwei bis drei Teilen zusammengesetzt. Dabei ist es eine zu 90 % gültige Regel, dass man einen Teil des Befehlsnamens erhält, indem man aus dem entsprechenden englischen Wort alle Selbstlaute entfernt und die ersten drei Mitlaute zusammenzieht (bei Wörtern, die mit einem Selbstlaut beginnen, bleibt dieser erhalten). Beispiel WRK = WORK oder DSP = DISPLAY oder STR = START usw. …

Datenschutz

Es gibt drei Sicherheitsebenen:

• Systemebene
• Benutzerebene
• Objektebene

Die Sicherheit auf der Systemebene wird im Systemwert QSECURITY eingestellt. Dabei existieren fünf Stufen, die von keiner Sicherheit bis zur sogenannten C2-Sicherheit, eine von der US-Regierung zertifizierte Stufe, reichen. Die Benutzerebene ist notwendig für das Anmelden an das System, wobei hier bereits diverse Berechtigungen festgelegt sind. Auf der Objektebene können Berechtigungen explizit für jedes Objekt vergeben werden.

Des Weiteren sind Systemobjekte durch das Domain-Attribut des Objektes vor Manipulation geschützt. Ab einem bestimmten Wert in QSECURITY kann trotz Objektberechtigung nicht von einem Programmcode der in der Domäne Benutzer läuft, ändernd auf ein Objekt der Domäne System zugegriffen werden. Bei dieser Verschärfung der Sicherheit ist allerdings zu beachten, dass gewisse Software von Drittparteien auf solche Zugriffe angewiesen ist.

Vordefinierte Benutzerprofile

Es ist wichtig, bei der Erstinbetriebnahme des Systems neben dem QSECOFR (Security Officer) auch die Passwörter für die Systembenutzerprofile QSRV und QSRVBAS zu ändern. Diese Profile sind vorgesehen für den System-Engineer von IBM, und ihre Passwörter lauten nach der Installation wie die Benutzernamen selbst. Obwohl diese Benutzerprofile offiziell in ihrer Berechtigung eingeschränkt sind, kann man mit ihnen sehr leicht das System massiv stören und sogar die Sicherheit aushebeln. Es ist nämlich hier möglich, die System-Service-Tools mit dem Befehl 'strsst' zu starten. Hier kann ein Angreifer dann sämtliche Objekte (auch Benutzerprofile) im System editieren, ohne dass eine Berechtigungsprüfung dies verhindert.

Jobs, Subsysteme (SBS) und ihre Verarbeitung

Jobs lassen sich klassifizieren in Systemjobs, wie z. B.:

• Start-control-program-function (SCPF) (Name stammt vom S/38 Betriebssystem CPF)
• System arbiter (QSYSARB)
• Logical unit services (QLUS)
• Work control block table cleanup (QWCBTCLNUP)
• Performance adjustment (QPFRADJ)
• Database server (QDBSRV01..N)
• Decompress system object (QDCPOBJ1..N)
• Job schedule (QJOBSCD)
• System spool maintenance (QSPLMAINT)
• LU 6.2 resync (QLUR)
• File System (QFILESYS1 and QFILESYS2)
• Database cross-reference system job (QBDSRVXR)

und Subsystem-basierte Jobs. Die Subsysteme und deren Merkmale definieren die Ablaufumgebung von Jobs im System (zugeordnete Hauptspeicherpools, Jobwarteschlangen, Routing Einträge, Jobprioritäten, CPU Zeitscheiben etc.). Z. B. werden über Jobwarteschlangen, Jobklassen bzw. Jobbeschreibungen die Jobs in die gewünschten Subsystemen geroutet.

Die wichtigsten vordefinierten Subsysteme sind:

• QCTL – Controlling SBS (startet alle anderen SBSe, sonst nur für Systemconsole)
• QINTER – Interactive SBS (5250-Datenstromjobs)
• QBATCH – Batch SBS (Batchjobs aller Art)
• QHTTPSVR – Web Server (verschiedene Apache-Instance- + CGI-Jobs)
• QSPL – Spooling SBS (Druckjobs aller Art)
• QSERVER – (File)server SBS (z. B. SMB-Server und Clientrequests)
• QSYSWRK/QUSRWRK – hier laufen die meisten Dienste/Daemonjobs (ODBC/SQL, FTP, SMTP, LDAP etc.)

Die wichtigsten im System laufenden Jobtypen sind:

• Systemjobs SYS (laufen ohne Subsystem)
• Subsystem SBS (ein Subsystem ist selbst eine spezielle Form eines Job)

• Interactive Jobs INT (Beginnt beim Anmelden eines Benutzers an der 5250-Datenstation und endet beim Abmelden)
• Batch(Stapel)-Jobs BCH (Beginnt sobald eine Aufforderung in eine Jobwarteschlange gestellt wird)
• Spool-Jobs SPL (Stellt Ein- und Ausgabedateien bereit – beispielsweise einen Druckauftrag)
• Prestarted Jobs PJ (werden mit dem jeweiligen Subsystem vorgestartet z. B. ODBC/JDBC Requests)

Alle Jobs im System können leicht mit dem Befehl wrkactjob angezeigt und verwaltet werden.

Integriertes File System (IFS)

Das Betriebssystem OS/400 besitzt ebenfalls seit der Betriebssystemversion 3 ein hierarchisches Dateisystem, analog Linux/Unix oder Windows. Hierbei handelt es sich um ein vollständig virtuelles Dateisystem – im Gegensatz zu hardware-/festplattenbasierten Dateisystemen wie FAT, NTFS. Es unterstützt sowohl diverse lokale Dateisysteme als auch vordefinierte Mountpunkte für Remote-Dateisysteme. Jedes Objekt (Pfad bzw. Datei) in lokalen Dateisystemen wird durch einen Vnode (virtueller Indexknoten) repräsentiert. Die Vnode-Struktur enthält Zeiger (Verweise) auf die Blöcke, in denen die Daten und Metadaten über ein Objekt abgelegt sind. Damit ist das OS/400-IFS vielleicht noch am ehesten mit einem „ext2/ext3“-Dateisystem vergleichbar. Die lokalen Dateisysteme des IFS sind journalisierbar.

Die meisten Dateisysteme werden beim IPL (Initial program load) des Betriebssystems gestartet und im Root / gemountet.

lokale Dateisysteme

• Root-Dateisystem (Windows-artig, unterscheidet nicht zwischen Groß/Kleinschreibung)
• QOpenSys (UNIX-artig, unterscheidet Groß/Kleinschreibung)
• QOPT (Mountpunkt für physische bzw. virtuelle optische Laufwerke, sprich CD/DVD-Images)
• QDLS (Document Library Service, 8.3-Namenskonvention, Relikt aus OfficeVision/400-Zeiten)
• QSYS.LIB (dies ist eine andere Sicht auf die OS/400-Bibliotheken)
• udfs (User definierte Dateisysteme – Mountpunkt unter /dev/QASPxx)

Netzwerkdateisysteme

• QFileSvr.400 (Remote IFS einer anderen iSeries/I5)
• QNTC (Remote CIFS/SMB-Server, OS/400 fungiert hier als SMB-Client)
• QNetWare (Remote Netware Server)
• NFS

Um auf die Dateisysteme zuzugreifen, gibt es verschiedene Methoden:

• NFS
• CIFS/SMB
• FTP
• HTTP

Die Dateisysteme Root und QOpenSys unterstützen Hard Links und symbolische Links.

Hard Links

Hard Links können nicht über Dateisystemgrenzen hinweg erstellt werden und bedeuten, dass es mehrere Verweise auf das gleiche IFS-Objekt gibt. Das Löschen des letzten Hard Links zu einem Objekt führt zum Löschen des Objekts selbst.

Symbolische Links

Symbolische Links können über Dateisystemgrenzen hinweg erstellt werden. Das Löschen eines symbolischen Links führt niemals zum Löschen eines Objekts (Verzeichnis bzw. Datei).

Ab i5/OS V5R3 enthält das IFS integrierte Scan-APIs für Virenscanner.

Weblinks

• Allgemeinbeschreibung
• Öffentlicher IBM i Server (PUB400) mit IBM i 7.5