Vom Glück, das richtige Load Module zu finden!

Transkript

1 Peter Dennler/KSDM 612 Zürich, Version 1.1 d Vom Glück, das richtige Load Module zu finden! Einleitung: Welcher IT-Mitarbeitende kennt das Problem mit dem falschen Module bzw. der falschen Version eines Modules nicht? Solche Situationen gehören heute in einem grossen IT-Umfeld zur Tatsache. Wieviele Stunden haben wir schon "verbraten" mit der Suche nach Fehlerursachen und schlussendlich löste sich das Problem, indem herausgefunden wurde, dass wir zur Ausführungszeit eines Programmes nicht das aktuelle Load Module im Real-Storage hatten, sondern eines aus der Vergangenheit. Teilweise kennt man das Problem auch auf dem PC. Dort werden die Load Module als.exe-files oder als DLL bezeichnet. Das nachstehende Dokument versucht, sich mit allen bekannten Einrichtungen auf der z/architektur unter dem Betriebsystem z/os auseindanderzusetzen, welche in diesem Bereich Einfluss haben. Es gibt übrigens auch Fälle, wo ein eingebundenes Submodule nicht der aktuellsten Programm-Version entspricht. Ich habe mich im Rahmen meiner Teacher-Tätigkeit bei IBM und bei der CS oft mit solchen Problemen befasst und sehe, dass heute immer noch die gleichen Fehler vorkommen wie vor über 20 Jahren. Leider ist die durchschnittliche Halbwertszeit solcher zum Teil existentieller Informationen kürzer, als die Halbwertszeit einiger Spitzenmanager bei gewissen Unternehmungen. Ich hoffe, dieses Dokument wird das Ziel erreichen, in diesem Bereich etwas mehr Licht in diesen Problemkreis zu bringen. Es ist klar, dass dabei nicht das letzte Detail von solchen Vorgängen beschrieben werden kann, sonst entspräche die Seitenzahl dieses Exposees dem des POP (Principles of Operations). Da sich unsere Systeme von Zeit zu Zeit verändern, kann es auch sein, dass die hier beschriebenen Details plötzlich verändert sind. Ich versuche, dem Rechnung zu tragen, indem ich von diesem Dokument bei Bedarf eine neue Version erstelle. Kurze Zusammenfassung dieses Dokumentes: - Wie werden Load Module auf das z/os geladen und welche Mittel habe ich zur Verfügung um diesen Vorgang zu beeinflussen? - Vor- und Nachteile von statischer bzw. dynamischer Programm-Linkage! - Empfehlungen von der IBM und von mir CS P LLA und Extensions Glück gehabt von Peter Dennler / KSDM 612 Seite 1/39

2 Anmerkung: In diesem Dokument gezeigte Print Screens wurden auf den Testsystemen der CS erzeugt und um Toner/Tinte zu sparen verwendete ich eine andere als die übliche TSO/ISPF Farbgebung! Module in diesem Dokument entspricht immer einem Load Module (SMP = LMOD), für dazugelinkte Unterprogramme verwende ich den Begriff Submodule! Inhalt: - 01 / Was ist ein Load Module? - 02 / Wie wird ein Load Module erstellt? - 03 / Wo werden Load Module gespeichert? - 04 / Prüfbare Zusammenhänge in Source/Object und Load Module - 05 / Module-Attributte (Reentrant/Reusable/AC=1/AMODE/RMODE) - 06 / Storage Areas in die ein Programm geladen werden kann - 07 / Program Fetch (Load-/Link-/Attach-/XCTL-Macro + Fetch in PL/I) - 08 / IPL Initial Program Load / LPA Link Pack Area - 09 / Linklist - 10 / LLA Library Lookaside - 11 / VLF Virtual Lookaside Facility - 12 / Static / Dynamic Linkage - 13 / Empfehlungen - 14 / Abkürzungsverzeichnis/Glossar 01 / Was ist ein Load Module? Ein Load Module ist eine Folge von logisch zusammenhängenden OP-Codes (siehe POP), welche in den Central-Storage eines Rechners geladen werden, um dort von den CPs ausgeführt zu werden. Solange sich ein Load Module auf einem Datenträger befindet, ist es auch für das geübte Auge schwierig, herauszufinden, was da abgeht. Wird hingegen ein Load in den Storage geladen, kann es vom Spezialisten unter Zuhilfnahme des POP analysiert werden. Es gibt Möglichkeiten, den Code eines Modules so anzuschauen, wie er geladen wurde. Ueber das TSO/ISPF DDLIST können wir ein Module in unseren User- CS P LLA und Extensions Glück gehabt von Peter Dennler / KSDM 612 Seite 2/39

3 Storage (JPA) zu laden und dort zu analysieren. Auch über Batch-Tools z.b. SPZAP oder AMBLIST kann ein Module gemäss der Bearbeitung im System studiert werden (Service Aids). In vielen Dumps wird der Code des Modules, bzw. der betroffenen Programme sichtbar gemacht. Leider ist hier der vom LE kommende CE-Dump eher beschränkt. Im Fall von PL/I Programmen ist das nicht tragisch, hier existieren andere Möglichkeiten, den Fehler zu analysieren. Bei Assemblerprogrammen ist es aber von Vorteil, einen SYSUDUMP oder SYSMDUMP zu haben, damit wir die beteiligten Code-Sequenzen sehen können. Für Assemblerprogramme gilt die Regel, ein Mnemonic (Instruktions-Kürzel) ergibt eine OP-Instruktion. Diese Regel vereinfacht die Analyse eines Modules erheblich. In den Hochsprachen (PL/I und COBOL) werden vermehrt Elemente aus der Runtime-Umgebung (heute das LE = Language Environment) benutzt, was dazu führt, dass diese LOAD Module schwieriger sind zu analysieren (PL/I LIST-Option!). Abbildung 1: Load-Module YYUUID ab Datenträger die einzelnen Records haben das Format U (Undefined) deshalb hat diese Grafik eine Fortsetzung nach rechts. Deutlich erkennbar der Date- /Timestamp der Assemblierung dieses Modules im letzten Record ab Position 6! IBM stellt uns die bereits erwähnten Tools SPZAP (Pgm = AMASPZAP) und AMBLIST zur Verfügung. Die Möglichkeiten von SPZAP gehen weit über das Auslisten eines Load Modules in Dump-Format hinaus. Sogar Aenderungen lassen sich im Module einbauen, ohne dass ein Load neu erstellt wird. Diese Aenderungen sind bei Kennern unter dem Namen ZAP bekannt. ZAPs werden oft angewendet, auch von den Herstellern. Wenn man an einem Module herumzapt, sollte man jedoch wissen, was man tut, sonst könnte der Spruch: "Wie man hineinzapt, so dumpt es heraus!" rasch einmal Wirklichkeit werden. Um eine gewisse Sicherheit im Umgang mit ZAPs zu haben, verbindet man das ZAP Statement mit einem Verify, d.h. man prüft die bereits bestehende Codesequenz im Module, und wenn diese so zutrifft wie sie im Verify parametriert ist, fügt der SPZAP die neuen Codes ein, indem er die alten Sequenzen überdeckt. Da in einem ZAP ein Load nicht vergrössert werden kann, kommt es vor, dass ein Hersteller oder auch ein Programmierer sogenannte PATCH-Areas in ein Module einbaut. Diese können dann später mit dem SPZAP durch ausführbaren Programmcode ersetzt werden. Der SPZAP ändert die IDR (Identification Records), ohne spezielle Angabe beim AMASPZAP wird er das Datum als IDR-Erkennung eintragen. Mit der Angabe eines IDRDATA-Wertes im AMASPZAP kann man z.b. eine PTF-Nummer oder sonstige Bemerkungen im Module eintragen. So ist im Load jeweils ersichtlich, welchen PTF-Stand ein Module hat. Es sind maximal 19 IDR Einträge im Module möglich, diese können mit dem Binder wieder gelöscht werden. Neben den IDR gibt es auch die Möglichkeit, über einen SSI (System Status Index) einen Versions-Eintrag zu erstellen. Damit dieser existiert, muss er aber bereits beim Binder angegeben werden und kann dann später bei einem SPZAP überschrieben werden. CS P LLA und Extensions Glück gehabt von Peter Dennler / KSDM 612 Seite 3/39

4 Abbildung 2: JCL zu einem SPZAP-Dump Abbildung 3: Darstellung Module YYUUID aus einem SPZAP-Dump / Der SPZAP versucht dabei jeweils in einer zweiten Druckzeile mögliche OP-Instructions aufzulösen! Abbildung 4: JCL zu einem AMBLIST CS P LLA und Extensions Glück gehabt von Peter Dennler / KSDM 612 Seite 4/39

5 Abbildung 5: AMBLIST von Module YYUUID / Falls im Module ZAPs installiert wären, würden diese ab dem RECORD# 2 registriert, momentan ist da die ganze Area mit X'00' abgefüllt! Eine sehr gute Variante, ein Load zu studieren stellt uns TSO/ISPF zur Verfügung mit der Funktion ISRDDN (Aufruf -> TSO ISRDDN oder irgendwo im ISPF -> DDLIST). ISRDDN zeigt nach dem Aufruf sämtliche Allozierungen des entsprechenden TSO-Users an. Nun kann mit dem Command -> LNKLIST die ganze Linklist angehängt werden. Mit dem Command -> LOAD kann ein Module, welches sich in der LINKLIST Verkettung befindet in den Private Storage des TSO-Users geladen werden (JPA). Module aus privaten Libraries können im ISPF mit dem LIBDEF-Service unter dem DD-Namen ISPLLIB alloziert werden. Im RZ1 der CS habe ich dafür eine REXX, welche diese Variante unterstützt, geschrieben -> LOADLDEF. ISPF findet nur Programme aus einer Linklist-Library bzw. LPA, ausser sie wurden als ISPLLIB alloziert (siehe auch Punkt 07 in diesem Dokument Program Fetch)! CS P LLA und Extensions Glück gehabt von Peter Dennler / KSDM 612 Seite 5/39

6 Danach erscheint ein Panel (Bildschirmmaske), welches aufzeigt, wo das Module gefunden wurde und nach der Bestätigung mit der Enter-Taste zeigt das ISPF das ganze Module im Dump-Format an. Abbildung 6: Load-Module YYUUID aus der JPA vom Main-Storage (DDLIST/ISRDDN) ISRDDN ist für den Entwickler im TSO/ISPF Umfeld ein sehr wichtiges Tool und in den entsprechenden ISPF-Manuals, bzw. über die Help-Funktionen kann erforscht werden, wofür es eingesetzt werden kann! 02 / Wie wird ein Load Module erstellt? Load Module werden in einem mehrstufigen Prozess erstellt, wobei mindestens zwei Teile heute zwingend sind. Ueber Assembler für Assembler Source-Programme) bzw. über PL/I- oder COBOL-Compiler wird aus dem Source-Programm ein sogenanntes Object-Module erstellt. Es gibt für z/os viele Produkte bzw. Softwarekomponenten auf dem Markt, bei welchen der jeweilige Programm-Code als Object only Code erhältlich ist, d.h. der Hersteller liefert nur den bereits compilierten Code aus. In einem zweiten Schritt wird mit dem Linkage Editor, bzw. dem Binder ein eigenständig ladbares Load CS P LLA und Extensions Glück gehabt von Peter Dennler / KSDM 612 Seite 6/39

7 erstellt. Oft werden hier Subroutinen statisch 'dazugelinkt', d.h. ein bestehender Object-Code einer oder mehrerer Subroutinen werden dem Code des zu 'linkenden' Programmes hinzugefügt. Auch andere bereits bestehende Loadmodule können in dieser Phase eingebunden werden. Abbildung 7: Von der Programm-Source über Object zum Load Module CS P LLA und Extensions Glück gehabt von Peter Dennler / KSDM 612 Seite 7/39

8 Abbildung 8: Programm-Source von YYUUID CS P LLA und Extensions Glück gehabt von Peter Dennler / KSDM 612 Seite 8/39

9 Abbildung 9: Umwandlungs-Listing von YYUUID aus dem Assemblierer Abbildung 10: Umwandlungs-Listing von KR9921 aus dem Enterprise PL/I Compiler mit Optionen LIST und BLKOFF CS P LLA und Extensions Glück gehabt von Peter Dennler / KSDM 612 Seite 9/39

10 Abbildung 11: Object-Module YYUUID auf dem Disk 03 / Wo werden Load Module gespeichert? Load Module werden in Libraries bzw. auf Neudeutsch in Programm-Bibliotheken gespeichert. Eine Library (PDS = Partitionned Organized Dataset) ist ein Datenbestand, der aus einem Index-Teil (Directory) und dem dazugehörenden Datenteil (Member) besteht. Es gibt heute im z/os zwei unterschiedliche Typen von Bibliotheken. Die altehrwürdigen PDS haben fix getrennte Bereiche für die Directory und für die effektiven Daten der Member. Die Grösse der individuellen Directory muss bereits beim Erstellen der Library bekannt sein. Werden Member geändert oder deleted, bleibt der Datenteil des alten Member trotzdem stehen, obwohl die aktuellen Daten an einem neuen Ort stehen. Der einzige Hinweis auf den neuen Ort wird in der Directory registriert. Haben wir es mit einer Library zu tun, auf welcher es viele Updates gibt, wird der Datenteil sehr stark aufgeblasen. Findet das System irgendwann keinen Platz mehr für ein Member, wird der Adressraum (Job, STC oder TSO-User), welcher die Daten reinschreiben wollte, einen System-Abend S D37 erhalten. Um den Platz der deleted und changed Member wieder freizugeben, ist bei PDS ein Compress notwendig. Der Compress kopiert die aktuellen Member im bestehenden Speicherbereich des betreffenden Dataset aneinander und schafft so wieder Freespace. CS P LLA und Extensions Glück gehabt von Peter Dennler / KSDM 612 Seite 10/39

11 Im Gegensatz dazu ist es in einem PDS/E (PDS/Extended) nicht notwendig, einen Compress durchzuführen, da hier die Bibliothek aus Blocks von jeweils 4 KB besteht. Diese Blocks können für die Speicherung von Daten und auch von der Directory benutzt werden und sind beliebig austauschbar, da die Datenlänge immer genau 4 KB beträgt. Blocks von Membern, welche gelöscht oder mutiert wurden, können später von anderen Membern oder Directory-Entries wieder überschrieben werden. Da PDS/E über einen speziellen Adressraum verwaltet wird, der beim Start des Systems, im Fachjargon IPL (Initial Program Load) noch nicht verfügbar ist, dürfen Libraries, welche in der frühen IPL-Phase vom System gelesen werden müssen nicht als PDS/E erstellt werden. Uebrigens entspricht ein IPL dem Bootvorgang auf einem PC, weil die Systeme aber betreffend Soft- und Hardware-Qualität klar besser sind, ist man auch nach der Erfindung des PC bei der Bezeichnung IPL geblieben. Abbildung 12: Die beiden Bibliotheksvarianten PDS und PDS/E 04 / Prüfbare Zusammenhänge in Source/Object und Load Module Es gibt mehrere Möglichkeiten, die Zusammenhänge zwischen Source-, Object und Loads zu überprüfen bzw. sichtbar zu machen. Die nachstehenden Grafiken sollen uns einige Ideen vermitteln. Um einen brauchbaren Rückschluss auf das Compile-Datum, bzw. Assemblierungs-Datum in einem Programm mitzugeben, können (sollten) diese Angaben als Text-Konstante einprogrammiert werden. Das Datum wird dann während des Compile automatisch vom System eingesetzt und wird im Object, im LOAD CS P LLA und Extensions Glück gehabt von Peter Dennler / KSDM 612 Seite 11/39

12 und auf den Umwandlungslisten sichtbar gemacht. Dadurch besteht die Möglichkeit, auch in einem Load Module zu testen, ob es sich um die richtige Programm-Version handelt bzw. handelte. Abbildung 13: Vom Source-Programm zum Object-Module mit Date-/Timestamp der Umwandlung CS P LLA und Extensions Glück gehabt von Peter Dennler / KSDM 612 Seite 12/39

13 Abbildung 14: Vom Source-Programm zum Umwandlungs-Listing mit Date-/Timestamp der Umwandlung Es ist von Vorteil, wenn die Umwandlungs-Listings espeichert- und archiviert werden. Dies wird in der Regel bei den Umwandlungen in der CS über ChangeMan gemacht. Wenn es später mit einem Load Module Probleme gibt, hat man meistens nur mit einem aktuellen Listing die Chance, den Fehler zu beheben. Jeder und jede, welche schon einmal ein Programm "Debugged" hatten, kann davon ein Lied singen. Beispielsweise, wenn ein Programmierer den Support zur Problemlösung involviert und übereilt eine neue Programm-Umwandlung macht, der Supportmitarbeiter studiert aber immer noch den Abend einer alten Version. Solche Momente gibt es und da wird relativ oft viel Zeit investiert, bis man zum Schluss kommt, dass der Dump nicht mit der Umwandlingsliste zusammenpasst. Ferner gibt es, wie bereits unter Punkt 1 geschildert, die technische Möglichkeit, einem Load Module eine Identifikation in Form von einem IDR mitzugeben. Mit einem SSI kann ein Stamp in die entsprechende Load- Library gemacht werden, damit auch da ersichtlich ist, um welche Version eines Modules es sich handelt. CS P LLA und Extensions Glück gehabt von Peter Dennler / KSDM 612 Seite 13/39

14 Abbildung 15: Vom Object zum Load mit IDR (Identify) und SSI (SETSSI) Statement im Bind Job Der IDR Entry ist nachher bei der Betrachtung des Loads im BROWSE sichtbar (so können oftmals PTF- Stände geprüft werden). Der SSI Eintrag ist so nur auf der Directory der Library ersichtlich. CS P LLA und Extensions Glück gehabt von Peter Dennler / KSDM 612 Seite 14/39

15 Abbildung 16: Vom Object zum Load mit IDR (IDENTIFY) und SSI (SETSSI) Statements im Bind Job Der SSI Eintrag kann später auch von einem Programm mit dem STOW Macro sichtbar gemacht werden oder wie bereits mehrmals geschildert mit dem AMBLIST Programm der IBM. Wird später an einem Load-Module herumgezapt, was hauptsächlich in der Betriebsystemsoftware vorkommt, ist es von Vorteil, wenn die IDR und allenfalls auch SSI Stamps nachgeführt werden. So kann die Programmversion mit dem ZAP von der vorangehenden unterschieden werden. Ueber die Verwendung von ZAP kann man geteilter Meinung sein, aber oft kann dadurch auf einfache und sehr schnelle Art ein Load Module verändert werden. Die Ausführung eines ZAP dauert in menschlicher Zeitmessung wenige Sekunden, in Bezug auf CPU Zeitverbrauch absolut vernachlässigbar. Wird ein ZAP gut dokumentiert, ist es auch möglich, ihn in kürzester Zeit zurückzustellen. CS P LLA und Extensions Glück gehabt von Peter Dennler / KSDM 612 Seite 15/39

16 Abbildung 17: ZAP mit SZAP-Programm und IDRDATA + SETSSI IDR-Eintrag auf Module Abbildung 18: ZAP mit SZAP-Programm und IDRDATA + SETSSI SSI-Eintrag auf Directory CS P LLA und Extensions Glück gehabt von Peter Dennler / KSDM 612 Seite 16/39

17 Wie bereits geschildert, können bis 19 Entries als IDR angefügt werden. Es können dann alle 19 Entries im Module sichtbar sein. Mit AMBLIST kann ich alle diese Einträge auslisten bzw. wäre es möglich, basierend auf die IDR ein Ueberwachungstool zu realisieren. Beim SSI hingegen wird der neue Eintrag auf der Directory den alten überdecken! Auch eine Directory kann ich elektronisch lesen und so wäre auch hier eine Datenbank mit aktuellen SSI möglich. Abbildung 19: ZAP mit SPZAP-Programm und IDRDATA + SETSSI / gut ersichtlich ist der zweite IDR Eintrag im gezapten Module, weitere IDR-Entries würden jetzt im gleichen Record rechts angehängt CS P LLA und Extensions Glück gehabt von Peter Dennler / KSDM 612 Seite 17/39

18 Abbildung 20: ZAP mit SZAP-Programm und IDRDATA + SETSSI der SSI hat nach dem ZAP geändert Abbildung 21: Save-Macro im Source-Code und im Programm-Listing CS P LLA und Extensions Glück gehabt von Peter Dennler / KSDM 612 Seite 18/39

19 Abbildung 22: Compile-Stamps in Load Module und Programm Listing Abbildung 23: Compile-Stamps in Load Module (View im ISRDDN) und Programm Listing CS P LLA und Extensions Glück gehabt von Peter Dennler / KSDM 612 Seite 19/39

20 05 / Module Attribute (Reentrant/Reusable/AC=1/AMODE/RMODE) Load Module werden durch Compilierung (Assemblierung) und den Bind Prozess (Linkage Editor) Attribute erhalten. Je nach Situation ist es von Vorteil, diese Attribute zu kennen, damit wir keine Probleme erhalten. Ich erläutere hier kurz die wichtigsten Attribute: REENTRANT wird beim Binder angegeben Reentrant erlaubt es, im System Load Module zu laden, welche gleichzeitig von mehreren Usern benutzt werden. Der Programm Code bei einem reentrant Module wird nur einmal geladen, kann aber dann von hunderten von Usern zum genau gleichen Zeitpunkt genutzt werden. Eine unabdingbare Sache ist dabei, dass der Speicherplatz der zu verarbeitenden Daten für jeden User separat angelegt wird. Würden die User mit den gleichen Daten arbeiten, wäre die Datenintegrität nicht mehr gewährleistet. In der Regel werden bei der Reentrant-Programmierung zu Beginn eines Programmes die Hauptspeicherbereiche für einen User im User-Adressraum alloziert und kurz vor dem Programmende wieder freigegeben. Es darf sich beim Programm-Code nur um statischen Code handeln, d.h. im Programm selbst darf während der Abbildung 24: User und Common Storage mit Reentrant und Non-Reentrant-Code. Im Reentrant Code werden zwingend die Datenteile vom reinen statischen Programm-Code getrennt! Ausführungszeit absolut nichts geändert werden, sonst wird das vom Betriebsystem mit einem S0C4 Abend honoriert. Ob ein Load Module reentrant geschrieben sein muss, hängt schlussendlich von seiner Verwendung ab. Alle LPA-Module (siehe Punkt 8) müssen zwingend reentrant sein. Es gibt auch im CICS- Umfeld gewisse Vorschriften in Bezug auf die Fähigkeit, reentrant zu laufen. Werden Programme CS P LLA und Extensions Glück gehabt von Peter Dennler / KSDM 612 Seite 20/39

21 geschrieben, welche auf dem System in einem Multitasking-Umfeld eingesetzt werden, kann es auch zwingend sein, das Module reentrant zu schreiben, um bei gleichzeitigem Gebrauch von mehreren Parallelen Tasks keinen Impakt auf die Datenintegrität zu erhalten. In letzter Zeit habe ich oft Assembler-Source-Code gesehen, bei dem das Load zwar reentrant deklariert war, aber effektiv den eigenen Programm-Code verändert, d.h. es ist nicht wirklich reentrant. Es wäre nur suboptimal, zum Beispiel ein solches Module in die LPA zu stellen (S0C4). Reentrant Code darf bei der Ausführung nicht modifiziert werden! Abbildung 25: Da Module in der LPA von verschiedenen Adressräumen gleichzeitig benützt werden, z.b. die TSO-Load-Module, werden die Daten für die Programme in den jeweiligen User-Address-Spaces gespeichert bzw. verarbeitet und nicht im Common Storage! REUSABLE wird beim Binder angegeben Reentrant Programme sind immer auch REUSABLE. Reusable besagt, dass das Programm alle Variablen bei jedem neuen Durchgang im Programm Code wieder initialisiert. AC=1 (Authorization Code Option) wird beim Binder angegeben Das Module wird danach mit AC=1 markiert. Dadurch wird dem Module erlaubt, sofern es von einer APF- Library geladen wurde, semipriviliged und priviliged OP-Instruktionen auszuführen. Grundsätzlich kann jeder User einen Bind eines Modules mit AC=1 durchführen. Matchentscheidend ist, ob es dann auch wirklich autorisiert läuft ist, ob es aus einer APF-Library kommt. APF-Libraries sollten in einer Installation gut CS P LLA und Extensions Glück gehabt von Peter Dennler / KSDM 612 Seite 21/39

22 geschützt sein, um zu verhindern, dass unberechtigte User sicherheitskritische OP-Instruktionen ausführen können. Addressing Mode (AMODE 24 / 31 und 64 Bit) kann in der Programm-Source oder beim Binder angegeben werden, wobei der Binder den stärkeren Einfluss hat! Unterschiedliche Addressing Modes wurden aus Kompatibilitätsgründen seit dem MVS/XA eingeführt. Bis zur Erweiterung von MVS auf MVS/XA liefen sämtliche Programme im 24 Bit Addressing Mode. Obwohl das Betriebsystem MVS damals als sogenannte Wortmaschine (1 Wort = 4 Bytes) galt, wurden für die Berechnung von Hauptspeicheradressen nur 24 Bits verwendet. Unter MVS konnten 16 MB Hauptspeicher adressiert werden. Als IBM 1983 mit dem MVS/XA kam, wollte man die Möglichkeit haben, mehr Speicher zu verwalten bzw. zu adressieren. Es wurde deshalb notwendig, einen neuen Addressing Mode einzuführen, der für die Adressierung 31 Bits zu Hilfe nahm. Um weiterhin abwärts-kompatibel zu sein, musste das sogenannte High-Order Bit (Bit 0) herhalten. Ein besonders erfahrener Teacherkollege (Meister des MVS) bei IBM gab dem Bit 0 den Namen: Chiasso-Bit. Dieses Bit auf 1 gesetzt entspreche dem Verlust einer CH- Bank aus dem Chiasso-SKAndal war seine Begründung. Es wurde und wird auch heute noch dazu genommen, um zu signalisieren, ob ein Programm im 31 Bit Addressing Mode (Bit 0 = 1) oder im 24 Bit Addressing Mode läuft (Bit 0 = 0). Die ganze Sache mit den 2 Modes wurde für viele Programmierer zur Qual. Wenn man in Assembler-Programmen etwas falsch anging, krachte es mit dem, heute immer noch häufigsten Abend S0C4 (Storage Protection). Der durchschnittliche PL/I-Programmierer braucht sich heute praktisch nicht mehr um solche Dinge zu kümmern. Im Assembler hingegen hat IBM 2001 nochmals einen draufgelegt, indem mit z/os 1.4 die Möglichkeit kam, Programme in drei Modes laufen zu lassen. Auf der sogenannten trimodalen Archtektur im 24, 31 oder 64 Bit Addressing Mode! Abbildung 26: Vergleich 24 Bit / 31 Bit und 64 Bit Addressing Modes CS P LLA und Extensions Glück gehabt von Peter Dennler / KSDM 612 Seite 22/39

23 Residency Mode (RMODE 24 / 31 / ANY) kann in der Programm-Source oder beim Binder angegeben werden, wobei der Binder den stärkeren Einfluss hat! Effektiv sagt der RMODE aus, wo ein Module physisch geladen wird. Da es momentan (z/os 1.12) immer noch keinen ausführbaren Code "over the bar", d.h. über 2 GB gibt, wird RMODE 64 nicht zugelassen! Abbildung 27: Residency Mode Hier gibt es entgegen vielen Experten nur 24 / 31 oder ANY (64 Bit Residency Mode ist auch im z/os 1.12 noch unmöglich, da über dem Storage-Bereich von 2 GB kein Programm-Code ausgeführt werden kann!) 06 / Storage Areas in die ein Programm geladen werden kann Ein Programm kann grundsätzlich in den gesamten Virtual Storage eines Adressraumes geladen werden (Private), abhängig vom Residency Mode. Ueber der 2 GB Grenze darf es keinen ausführbaren Programmcode geben. Auch in Hiperspaces und Data Spaces kann kein Programmcode ausgeführt werden. VLF lädt zwar Programmcode in Data Spaces, aber diese dienen nur der Speicherung und nicht der Ausführung. VLF übergibt den jeweiligen Adressräumen eine Kopie Programmcode in die Private Area ebenfalls in Abhängikgkeit vom Residency Mode. CS P LLA und Extensions Glück gehabt von Peter Dennler / KSDM 612 Seite 23/39

24 Abbildung 28: Virtual Storage im z/os 0 bis 16 exabytes Storage wird über 2 gigabytes als Memory- Object mit mindestens 1 MB angelegt, darunter findet immer noch die klassische Adressierung mit 4 KB Pages statt! Der Zugriff auf den Real-Storage läuft über die DAT (Dynamic Address Translation) und dabei wird die virtuelle Adresse in eine Real Storage Address umgerechnet. Das System braucht dafür Tables und hat für jeden Adressraum separate solche Tables. Mit einer Segment-Table kann jeweils 1 MB angesprochen werden. Beim Common Area Bereich verwenden alle Adressräume die gleichen Segment-Tables. Das muss auch so sein, denn deshalb wird für den Common Bereich physisch genau der gleiche Real-Storage verwendet. Die Grenzen zwischen Private und Common Area bzw. zwischen E-Private und E-Common Area müssen deshalb jeweils genau auf einer MB Boundary liegen. Dadurch handelt man sich gelegentlich Probleme ein. Auch ich hatte deswegen schon ein ungeplantes IPL auf allen Produktions-LPARs verursacht. Weil ich zuviele Module in die LPA gebracht hatte, wurde die Private Region Size unterhalb der Line (24 Bit) wegen einiger lächerlichen KB über die nächste MegaByte-Grenze hinaus gedrückt und dadurch soweit reduziert, dass das IMS wegen zu wenig Storage abendierte. Module, welche sehr oft gebraucht werden, können, sofern sie REENTRANT/REUSABLE sind, in eine Link Pack Area geladen werden. Ausführbarer Programmcode kann auch in die CSA bzw. ECSA gestellt werden. Wichtige Betriebsystemroutinen und einige SVC sind im Nucleus geladen und können da ausgeführt werden. CS P LLA und Extensions Glück gehabt von Peter Dennler / KSDM 612 Seite 24/39

25 Abbildung 29: Virtual Storage zwischen 0 und 2 GB 07 / Program Fetch (Load-/Link-/Attach-/XCTL-Macro + Fetch in PL/I) Programme werden entweder mit dem Batch-Loader oder mit dem Program Fetch Feature ins System geladen. Der ganze Suchprozess ist relativ aufwendig und das Grundprinzip ist immer gleich. Es soll möglichst hohe Performance aus dem System geholt werden. Ein z/os versucht, möglichst viel I/O zu vermeiden, denn I/O ist teuer (dauert unendlich lange) und nur nicht durchgeführter I/O ist guter I/O! Deshalb wird ein zu ladendes Module immer zuerst in der JPA (Job Pack Area) gesucht. Die JPA ist im Private Storage eines Adressraumes. Ein Module, welches in der JPA liegt, wird, solange der Adressraum besteht nicht mehr ersetzt, nur ein expliziter DELETE auf ein geladenes Module bringt dieses wieder raus. Wird das Module in der JPA nicht gefunden, prüft das System, ob wir am Adressraum eine STEPLIB / JOBLIB oder TASKLIB haben (unter ISPF kann es die ISPLLIB sein). Wenn solche Bibliotheken gefunden werden, wird zuerst geprüft, ob die in Frage kommenden Libraries von der LLA gemanaged werden. Dann werden die Directory-Entries der entsprechenden Libraries in der LLA durchsucht. Dieser Prozess ist nicht identisch mit dem sonstigen Search in der LLA, da hier nur die betreffenden Bibliotheken durchsucht werden dürfen und nicht alle in der LLA registrierten Module! Ein hier unter der Library verzeichnetes Module wird nun entweder ab dem entsprechenden Disk (Member- Adresse), welche die LLA gespeichert hat geladen, oder wenn eine Kopie des Modules im VLF Adressraum zur Verfügung steht, wird diese vom VLF dem Adressraum zur Ausführung übergeben! CS P LLA und Extensions Glück gehabt von Peter Dennler / KSDM 612 Seite 25/39

26 Ist die entsprechende Library nicht von der LLA verwaltet, werden die entsprechenden STEPLIB, JOBLIB oder TASKLIB durchsucht (physisch auf den Disks). Wird in einem Job mit STEPLIB und JOBLIB gearbeitet, wird nur die STEPLIB durchsucht und die JOBLIB nicht beachtet. Wenn das Module bisher nicht gefunden wurde oder keine Private Library angegeben ist, erfolgt nun der weitere Search zuerst in der Link Pack Area. Da das System wieder unnötigen I/O vermeiden will, werden die LPA-Bereiche nach dem Module in der Folge: 1. FLPA/EFLPA, 2. MLPA/EMLPA und 3. PLPA/EPLPA durchsucht. Die FLPA/EFLPA wird vom System nicht gepaged und deshalb macht es Sinn, zuerst diese zu durchsuchen. Ist nun das Module hier immer noch nicht gefunden, werden alle Libraries aus der Linklist durchsucht, wobei dies in der Regel wieder über LLA und VLF läuft, da im Normalfall alle Linklist-Libraries LLA bzw. LLA und VLF managed sind. Dieser Search geht über den Module Namen und durchsucht allfällige Private Libraries in der LLA nicht! Sollte das Module jetzt noch nicht aufgetaucht sein, wird das System böse und beschert uns einen Abend S806! Wenigstens ist dann kein Dump notwendig; aber der Grund, warum das Module nicht gefunden wurde muss vermutlich trotzdem analysiert werden. Abbildung 30: Suche nach einem Programm / Program Fetch CS P LLA und Extensions Glück gehabt von Peter Dennler / KSDM 612 Seite 26/39

27 Wenn das Module gefunden wurde, und sich nicht in der LPA oder JPA befand, wird es nun in die JPA geladen. Je nachdem über LLA/VLF oder vom Disk. Die CDE (Contents Directory Entry Verzeichnis der aktiven Module in der JPA) wird nun mit den Module-Informationen zum geladenen Module erweitert. Zusätzlich wird die EPA (Entry Point Address) des Modules zurückgegeben Wurde das Module in der Common Area gefunden oder wenn es bereits in der JPA war, wird die EPA zurückgegeben und der Module-Counter um 1 erhöht. Es kann gelegentlich Sinn machen, ein geladenes Module nach dessen Gebrauch wieder freizugeben. Dies erfolgt in einem Assembler Module mit dem DELETE-Macro bzw. im PL/I mit RELEASE. Der Usage- Counter für das Module wird um 1 reduziert und wenn er jetzt 0 ist, werden die Module-Informationen in der CDE gelöscht und der Storage-Bereich in der JPA, wo das Module lag, wieder freigegeben, damit der Speicherplatz wieder für neue Daten oder Programme gebraucht werden kann. Der Usage-Counter sorgt dafür, dass nicht ein Module in der JPA entfernt wird, welches noch in Gebrauch ist. 08 / IPL Initial Program Load / LPA Link Pack Area Des System-Programmierers heilige Kuh ist die SYS1.PARMLIB. Diese Bibliothek enthält die wichtigsten Parameter, um ein z/os zu betreiben. Sie muss ein PDS sein, denn sie wird sehr früh in der IPL-Phase gebraucht, bevor der PDS/E-Adressraum aktiv ist. Meine Erfahrung hat gezeigt, dass man meistens ein zu grosses Geschrei um den Zugriff auf die Parmlib macht. Die Parmlib enthält viele Informationen, welche für den Systembetrieb wichtig sind, aber es steht praktisch nichts Geheimes drin. Ich würde deshalb diese Library relativ grosszügig für READ Access öffnen. Zudem kochen heute alle mit Wasser und deshalb kann man auch nicht viel "abkupfern". Auf der anderen Seite würde ich aber nur sehr wenigen Spezialisten den UPDATE erlauben! Die Parmlib besteht aus Membern und es existiert ein für Laien sehr komplexer Prozess, der es erlaubt, das ganze Gebilde mit den Parametern sehr dynamisch aufzubauen und zum Beispiel mehrere Systeme mit der gleichen Parmlib arbeiten zu lassen. CS P LLA und Extensions Glück gehabt von Peter Dennler / KSDM 612 Seite 27/39