IBM i für Linux-/Windows-Agenten: Objekte und Bibliotheken statt Dateien und Pfade

Worum es geht

IBM i (früher OS/400, läuft auf Power-Hardware, Versionen 7.4/7.5/7.6) kennt im Kern kein natives Konzept einer Dateihierarchie nach Unix-Art. Alles, was das System verwaltet – Programme, physische und logische Datenbankdateien, Datenbereiche, Benutzerprofile, Jobbeschreibungen –, ist ein typisiertes Objekt. Es wird durch einen Namen mit bis zu 10 Zeichen, einen Objekttyp (*PGM, *FILE, *USRPRF usw.) und die Bibliothek identifiziert, die es enthält. Eine Bibliothek ist selbst ein Objekt vom Typ *LIB; sie ist ein flacher Container, kein Verzeichnis, und kann keine weiteren Bibliotheken verschachteln (alle Bibliotheken sind Objekte in der speziellen Bibliothek QSYS).

Während ein Linux-Prozess einen blossen Befehlsnamen über $PATH auflöst, löst ein IBM-i-Job einen blossen Objektnamen über seine Bibliotheksliste (*LIBL) auf. Das ist eine geordnete Liste von Bibliotheken: ein Systemteil (bis zu 15 Bibliotheken, darunter QSYS), optionale Produktbibliotheken, die aktuelle Bibliothek des Jobs (*CURLIB) und ein Benutzerteil. Jeder unqualifizierte Verweis wie MYPGM durchsucht die Bibliotheksliste des Jobs, sofern der Name nicht als LIBRARY/OBJECT qualifiziert ist (Befehle wie DSPLIB sind selbst *CMD-Objekte und werden auf dieselbe Weise aufgelöst). Zwei Jobs mit unterschiedlichen Bibliothekslisten können dasselbe unqualifizierte MYPGM aufrufen und dabei verschiedene Programme ausführen – das IBM-i-Pendant zu einem $PATH-Shadowing-Fehler; ein qualifiziertes MYLIB/MYPGM ist davon nicht betroffen.

Befehlsnamen folgen meist einem Muster: eine dreibuchstabige Verbabkürzung plus eine oder mehrere Substantivabkürzungen, zum Beispiel CRTLIB (Create Library), DLTLIB (Delete Library), DSPLIB (Display Library), WRKACTJOB (Work with Active Jobs). Hat ein Agent einige Verben (CRT, DLT, DSP, WRK, CHG, STR, END) und Substantive (LIB, OBJ, JOB, USRPRF) entschlüsselt, lassen sich die meisten Befehlsnamen erraten, statt sie auswendig lernen zu müssen.

Für dateiorientierte Werkzeuge stellt das Integrated File System (IFS) den gesamten Objektraum unter /QSYS.LIB/LIBRARY.LIB/OBJECT.TYPE bereit, zum Beispiel /QSYS.LIB/QGPL.LIB/MYPGM.PGM. Dadurch kann ein find oder ls aus einer PASE-Shell klassische Objekte sehen. Die zitierte IBM-Support-Seite beschreibt QSYS.LIB jedoch primär als Dateisystem für Datenbankdateien und andere Bibliotheksobjekte, nicht als universelles Stream-File-System: Stream-I/O funktioniert nur bei wenigen Objekttypen (etwa Members physischer Dateien und Save Files), und viele unter / oder /home übliche Operationen werden dort nicht unterstützt.

Warum es wichtig ist

Ein Agent, der IBM i als «Linux mit ungewöhnlichen Befehlen» behandelt, diagnostiziert «file not found»-Fehler falsch, die in Wahrheit Probleme der Bibliotheksliste sind, und versucht Dateisystemoperationen auf QSYS.LIB, die das Objektmodell nicht unterstützt.

So wird es angewendet

• Vor der Suche nach einem Objekt klären, welche Bibliotheksliste für den aktuellen Job gilt, nicht nur, wie das Objekt heisst.
• Die Qualifizierung LIBRARY/OBJECT wie einen absoluten Pfad lesen; unqualifizierte Namen als relativ zu *LIBL behandeln.
• Unbekannte CL-Befehlsnamen als Verb plus Substantiv entschlüsseln, bevor eine undokumentierte Funktion angenommen wird.
• IFS-Stream-Operationen (direktes Umbenennen, beliebige Byte-Schreibzugriffe) innerhalb von /QSYS.LIB vermeiden; für den Lebenszyklus von Objekten stattdessen CL-Befehle (CRT*, CPY*, DLT*) verwenden.

Stolpersteine

• Annehmen, eine Bibliothek sei ein Verzeichnis, das Unterbibliotheken enthalten kann; das ist nicht möglich.
• Annehmen, *LIBL lasse sich von der Shell des Agenten steuern wie $PATH; es ist ein Attribut pro Job, das aus der Jobbeschreibung oder den Systemwerten QSYSLIBL/QUSRLIBL initialisiert und mit CHGLIBL/ADDLIBLE geändert wird. Ein separater Job (etwa ein abgesetzter Batch-Job) kann deshalb eine andere Liste sehen.