Vom Glück, das richtige Load Module zu finden!
Werbung
Zürich, 11.09.2011 Peter Dennler/KSDM 612 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 – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 1/39 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 UserCS – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 2/39 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 – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 3/39 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 – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 4/39 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 – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 5/39 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 – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 6/39 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 – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 7/39 Abbildung 8: Programm-Source von YYUUID CS – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 8/39 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 – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 9/39 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 – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 10/39 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 – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 11/39 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 – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 12/39 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 LoadLibrary gemacht werden, damit auch da ersichtlich ist, um welche Version eines Modules es sich handelt. CS – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 13/39 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 PTFStände geprüft werden). Der SSI Eintrag ist so nur auf der Directory der Library ersichtlich. CS – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 14/39 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 – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 15/39 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 – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 16/39 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 – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 17/39 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 – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 18/39 Abbildung 22: Compile-Stamps in Load Module und Programm Listing Abbildung 23: Compile-Stamps in Load Module (View im ISRDDN) und Programm Listing CS – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 19/39 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 CICSUmfeld gewisse Vorschriften in Bezug auf die Fähigkeit, reentrant zu laufen. Werden Programme CS – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 20/39 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 APFLibrary 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 – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 21/39 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 CHBank 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 – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 22/39 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 – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 23/39 Abbildung 28: Virtual Storage im z/OS – 0 bis 16 exabytes – Storage wird über 2 gigabytes als MemoryObject 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 – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 24/39 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 (MemberAdresse), 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 – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 25/39 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 – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 26/39 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 UsageCounter 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 – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 27/39 Abbildung 31: Aufbau der SYS1.PARMLIB / Member-Selektierung Ueber die LOADxx und IEASYMxx sowie IEASYSxx-Member wird die Auswahl der übrigen ParameterMember gesteuert. Die Parameter in den Membern LPALSTxx, IEALPAxx und IEAFIXxx haben Auswirkungen darauf, wie die LPA aufgebaut wird. Natürlich in Zusammenhang mit dem CLPA Parameter im IEASYS00 und den FIX/LPA und MLPA Werten. PROG bestimmt die PROGxx Member, welche für den Aufbau der APF-Libraries und der LINKLIST verantwortlich sind. CMD bestimmt das Command-Member und IEACMD00 enthalten die von IBM per default gelieferten Commands (wird immer aktiviert). Die LPA ist ein Set von Areas im Common Bereich. Es gibt im Prinzip 3 solche Bereiche unterhalb der 16 MB Grenze und 3 darüber. Diese Aufteilung in darüber und darunter kommt von den unterschiedlichen RMODE der Programme. Ein Module im RMODE 24 kann nur unter der Line geladen werden. Die Basis für die LPA bildet die PLPA bzw. die E-PLPA. Der Name Pageable besagt, dass diese Bereiche vom System ausgelagert werden können, d.h. sie können gepaged werden. Wenn ein IPL mit dem CLPA Parameter stattfindet, werden die ganzen Speicherbereiche der PLPA aufgeladen und danach mit einem forcierten Pageout alles auf die Page-Datasets rausgeschrieben. Ein IPL ohne CLPA stellt die PLPA zuerst leer hin und bei einem PageFault werden die Daten von den bestehenden PLPA-Page-Datasets geholt. Deshalb wird bei einem IPL mit fehlendem CLPA-Parameter wieder die alte PLPA basierend auf den Page-Datasets genommen. Die MLPA bzw. E-MLPA (M = Modified) wird jeweils beim IPL neu erstellt, sofern das in der SYS1.PARMLIB so eingetragen ist. CS – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 28/39 Ferner gibt es noch den letzten Bereich, die FLPA bzw. E-FLPA. Das F steht für Fixed und bedeutet, dass diese Bereiche nicht gepaged werden dürfen, d.h. die FLPA ist noch etwas performanter. Bereits abgehandelt wurde, dass LPA Module Reentrant/Reusable sein müssen. LPA Module können heute teilweise dynamisch verändert werden, z.B. kann man ohne IPL ein neues Module auf einem System aktivieren. In solch einer Situation wird das neue Module in die CSA/ECSA geladen und die Adresse vermerkt. So können in den meisten Fällen auch fehlerhafte Module ausgetauscht werden! Abbildung 32: Aufbau der Link Pack Areas Auch die Commands werden je nach System unterschiedlich gestartet, deshalb hat jede LPAR ihr eigenes Command-Member (COMMNDxx). Achtung: Die Commands werden vom System nicht unbedingt in der im Member eingetragenen Reihenfolge ausgeführt und das JES ist zum Zeitpunkt ihrer Ausführung ziemlich sicher noch nicht aktiv! CS – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 29/39 Abbildung 33: Commands z.B. auf LPAR S11 09 / Linklist Wie bereits kurz angetönt ist die LINKLIST eine auf Parametrierung des Systems zurückzuführende Verkettung von Bibliotheken, die in der entsprechenden Reihenfolge durchsucht werden. Die Parameter befinden sich in der Regel alle auf der Parmlib. Meistens wird die ganze Linklist über LLA, bzw. LLA und VLF verwaltet. Ueber sämtliche Linklist-Libraries sollten übrigens alle Benützer und Adressräume einer Installation READ Access haben. Es entstehen sonst Probleme, und es macht keinen Sinn, eine Bibliothek, welche man schützen möchte, in die Linklist-Konkatinierung aufzunehmen. Einzelne Module selbst kann man so schützen, dass sie nicht von jedem Adressraum aus ausgeführt werden können, auch wenn sie in der LINKLIST sind! Heute kann auf einem System mit verschiedenen LINKLISTs gearbeitet werden und teilweise vollständig dynamisch eine neue Konstellation aufgebaut werden. Grundsätzlich ist sehr viel, was früher nach IPL ziemlich statisch war, heute im laufenden System veränderbar! Ich hatte während meiner Zeit bei IBM viele Produkte zu betreuen und wegen neuen Loads in der LINKLIST nie ein IPL durchgeführt. Wenn man weiss, was man macht, sind solche Dinge nicht gefährlich. Ich habe sie zum Teil auch mit Kursteilnehmern an IBM Kursen durchgespielt. Man sollte trotzdem einige Aktionen nur zu Randzeiten tätigen, denn die Commands sollten richtig eingegeben werden. Wo wurde noch nie auf dem falschen System IPL gemacht oder ein falscher Channel offline geforced? CS – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 30/39 Abbildung 34: Linklist und APF Defiinitionen werden heute meistens über die PROGxx-Member in der Parmlib gemacht! Folgende Libraries werden automatisch in die LINKLIST aufgenommen und sind ebenfalls APF authorized: SYS1.MIGLIB SYS1.CSSLIB SYS1.SIEALNKE SYS1.SIEAMIGE SYS1.LINKLIB 10 / LLA – Library Lookaside LLA ist ein Systemadressraum auf einer z/OS LPAR, der dafür sorgt, dass I/O Aktionen massiv verringert werden. Die LLA speichert die physische Adresse eines Load-Modules auf dem Disk aus den Directories und verringert so den Suchaufwand über die physischen Disk-Directories von Load-Libraries. CS – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 31/39 Wird der LLA-Adressraum auf einem stark belasteten System gestoppt oder gerät er ins Stocken, führt das unmittelbar zu Performance-Problemen. Deshalb wird die LLA in den meisten Installationen auch bereits beim IPL gestartet und zwar als Master-Subsystem, d.h. die LLA kann starten, bevor das JES zur Verfügung steht. Wenn die LLA (Procedure) das Programm CSVLLCRE ohne Parameter startet, werden automatisch alle Linklist-Libraries von der LLA verwaltet. Es gibt deshalb auch aus IBM Sicht kein "Default"-Member für die LLA-Parametrierung! Es können natürlich auch für eine Installation separate Definitonen eingetragen werden. Sollen neben den Linklist Libraries auch einige Private Libraries vom Vorteil des rascheren Suchprozesses profitieren, können auch solche Libraries in einem CSVLLAxx-Member in der Parmlib angegeben werden. Beim Start der LLA muss dann zwingend der Suffix des entsprechenden Members definiert werden. Im gleichen Member könnte man auch Einträge erstellen, welche Beispielsweise eine Linklist-Library von der LLA-Verwaltung ausschliessen. Ferner gibt es die Möglichkeit pro Library FREEZE bzw. NOFREEZE anzugeben. Freeze bewirkt, dass die Directory für die LLA, sobald sie einmal geladen wurde nicht mehr verändert werden kann. Es ist dann zwingend ein LLA-Refresh notwendig. Linklist-Libraries werden automatisch als "FREEZE" definiert! NOFREEZE kann dann Sinn machen, wenn man die Directory Zugriffe auf die Library immer noch über DASD machen will, aber die Library trotzdem vom VLF mit verwalten lassen will, d.h. Load-Module der entsprechenden Bibliothek könnten von dem VLF geladen werden (siehe Punkt 11 VLF). Ein totaler LLA-Refresh kann in einem stark belasteten System für kurze Zeit zu einem PerformanceEngpass führen, deshalb wird der LLA-Refresh mit dem Command: F LLA,REFRESH meistens nicht mehr durchgeführt, sondern es können Parmlib-Member erstellt werden, welche einen sehr selektiven Refresh machen entsprechend ihrem Inhalt. Mit dem Command: F LLA,UPDATE=xx kann der Inhalt des Members mit dem entsprechenden Suffix ausgeführt werden. Der Prefix der LLA-Parmlib-Member ist: CSVLLA. Da in der Regel nur wenige Mitarbeiter über das Privileg verfügen, auf der Parmlib Aenderungen einzugeben, kann es vorkommen, dass CSVLLA-Member in speziellen Libraries aufgerufen werden können. Das Original-Member in der Parmlib muss dann den neuen Library-Namen erhalten und den SUFFIX des CSVLLA-Members. Weiter kann definiert werden, ob die LLA einen ENQUEUE mit SHR auf die von ihr verwalteten Libraries durchführt -> GET_LIB_ENQ(YES). Default ist YES gesetzt. Dadurch können wir die entsprechende Bibliothek nicht deleten, moven oder updaten. Die Library muss in solch einer Situation zuerst von der LLA entfernt werden mit REMOVE (CSVLLA-Member mit entsprechendem Statement). Für ein Assembler-Load-Module aus einer APF-Library gäbe es die Möglichkeit, über das LLACOPY-Macro einen LLA Update zu forcieren. Der Adressraum der den LLACOPY absetzt, muss Update-Berechtigung auf den Dataset besitzen entweder in DATASET-Class oder FACILITY-Class. Trifft das nicht zu, wird der LLACOPY nicht durchgeführt und ein SMF-Security-Record geschrieben. Der Sinn hinter dem LLACOPY ist, dass ein Subsystem auf eine von ihm gewünschte Bibliothek den LLACOPY absetzen kann, um dadurch zum Beispiel neue Module zu laden. Im Hintergrund führt der LLACOPY ein BLDL aus. Neben der Memberadresse aus den Directories stellt LLA auch die Anzahl der Aufrufe eines Load-Modules CS – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 32/39 fest. Ist ebenfalls, was heute meistens üblich ist, der VLF-Adressraum aktiv, wird LLA den VLF anweisen, ein Load, das oft gebraucht wird, in die VLF eigenen Dataspaces zu laden, damit bei weiteren Requests nach dem Module überhaupt kein I/O mehr gemacht werden muss. Leider hat alles Positive auch eine Kehrseite. Werden zum Beispiel neue Module in eine LLA-Verwaltete LOAD-Library gestellt, kommen diese natürlich erst nach einem LLA-Refresh bzw. nach einem UPDATE zum Zug. Damit gibt es gelegentlich Probleme. Ferner ist die LLA natürlich LPAR-Abhängig, d.h. wird beispielsweise auf einem System ein LLA-Refresh, oder ein LLA-Update vergessen, werden ev. auf diesen Systemen unterschiedliche Zustände herrschen. Das kann, wenn man das nicht durchschaut zu bösen Ueberraschungen führen und ich kenne einige, bzw. ich selbst habe da auch gelegentlich Zeit investiert, um solche Dinge zu analysieren (wo gehobelt wird, fallen Spähne). Abbildung 35: LLA Parameter und LLA Commands LLA hat die Parallelität, dass bis zu 255 Modify-Commands praktisch gleichzeitig abgesetzt werden können, ohne dass die Task busy Message erscheint. CS – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 33/39 11 / VLF – Virtual Lookaside Facility Der VLF-Adressraum lädt auf Grund von Anweisungen der LLA, Module in seine DataSpaces. Sind seine verfügbaren DataSpaces aufgebraucht, überdeckt er das am wenigsten benutzte Module. VLF stellt dem Adressraum, welcher ein Module sucht, direkt den ausführbaren Programmcode in seine Private Area (JPA). Ein Programm, welches von VLF geladen wird, muss deshalb nicht zwingend reentrant sein, denn jeder Adressraum erhält vom VLF eine Kopie des Codes. VLF hat ein von IBM geliefertes Parameter-Member, welches, sofern in der Procedure keines angegeben wird, den Default-Wert darstellt (COFVFL00). Wenn von der Installation ein anderes aufgerufen werden soll, kann das in der Procedure parametriert werden. VLF wird per default von alllen LLA managed Libraries Programme in den Storage laden (stagen). Es können auch neben Load Modulen REXX oder CLISTS, Cataloge und RACF-Daten in den VLF DataSpaces geladen werden. Das entsprechende Produkt muss aber damit umgehen können. Es gibt technische Unterlagen, welche beschreiben, wie vorzugehen ist, wenn eine eigene Anwendung VLF brauchen möchte. Abbildung 36: Zusammenspiel LLA und VLF Für die aus VLF Sicht zum Laden in Frage kommenden Objekte können Classes definiert werden, und bei CS – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 34/39 einer Class kann das Maximum an Storage in 4 KB (Pages) angegeben werden. So sollten sich die unterschiedlichen Objekte nicht negativ gegeneinander beeinflussen. Bei Loads ist im Prinzip die LLA der Trigger, was geladen wird. Bei einem LLA-Refresh, bzw. Update werden auch die entsprechenden von VLF geladenen Objekte freigegeben, d.h. der Storage wird auch wieder verfügbar für andere Module und früher oder später überdeckt. Abbildung 37: Zusammenspiel LLA / VLF und User-Adressraum 12 / Static / Dynamic Linkage Oft gibt es grosse Diskussionen um Vor- und Nachteile von Dynamic- bzw. Static-Programm-Linkage. Statisch hat den Nachteil, dass Aenderungen meistens umfangreicher sind, da eventuell viele Module neu zusammengelinkt werden müssen. Dafür gibt es während der Ausführung weniger Probleme, wenn einmal das ganze Programmgebilde korrekt erstellt ist. Das Load wird dafür grösser. Dynamic Linkage bringt den Vorteil der einfacheren Aenderung; je nachdem muss nur ein einziges Load geändert werden (z.B. auch ZAP). Dafür besteht eher die Gefahr einer unabsichtlichen Aenderung oder es kann vorkommen, dass in einer ganzen Programmverkettung zur Ausführungszeit ein Module nicht gefunden CS – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 35/39 wird, was zu einem Abend S 806 führt! Man sollte die Vor- und Nachteile sorgfältig gegeneinander abwägen. Habe ich ein Module, welches oft für sich alleine einzelne Aenderungen braucht und das ist in tausenden von Hauptprogrammen dazugelinkt, ist es vermutlich besser, die dynamische Variante zu wählen. Bei einem Hauptprogramm mit hunderten von kleinen Unterprogrammen, welche an anderen Orten nicht oft gebraucht werden, ist es performanter, alle Teile zusammen zu linken. Auf dem System zur Ausführungszeit braucht ein Program Fetch (Dynamic Linkage) auch seine Zeit und das könnte trotz allen in diesem Dokument gezeigten heute zur Verfügung stehenden Instrumenten negative Auswirkungen auf die Performance haben. 13 / Empfehlungen - Time-Stamps aus Compile ins Load bringen + ev. IDR und SSI nutzen (Tracking und Error-Handling wird dadurch einfacher – falsche Pgm-Version). - Wenn möglich keine JOBS mit JOBLIB laufen lassen (gilt nicht für LLA-managed-Libraries!). - LOAD/DELETE bzw. FETCH/RELEASE in komplexen Systemen dynamische Module nach Gebrauch wieder entfernen (ist im Batch nicht unbedingt notwendig, da der RTM das am Schluss selber dafür sorgt). - CLPA – gibt es Fehler mit einem Module aus einer LPA, prüfen, ob ein IPL ohne CLPA gemacht wurde (Time-Stamps erleichtern hier die Arbeit). - Nur Programme als REENTRANT bezeichnen, die es auch wirklich sind! - LLA REFRESH (kompletten) nur in Notfällen oder Randstunden! 14 / Abkürzungsverzeichnis/Glossar AC – Authorization Code Option – erstes Programm in einem autorisierten Umfeld muss mit AC=1 gelinkt werden, dass es bei der Execution autorisiert läuft AMBLIST – IBM Dienstprogramm um Module (Code/SSI/IDR) auszulisten ev. zu drucken AMODE – Addressing Mode – besagt, i n welchem Mode ein Module läuft (24 / 31 / 64) APF – Advanced Program Function – Libraries aus denen Programme laufen, welche speziell autorisiert sind, damit sie privilegierte OP-Instruktionen durchführen können ASCB – Address Space Control Block – Control Block im z/OS der einen Address Space representiert CS – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 36/39 BLDL – Build List – Assembler Macro um Directories von Libraries zu durchsuchen/lessen BROWSE – Menu im ISPF um Daten anzuschauen (= Browsen) CDE – Contents Directory Entry – Verzeichnis von Programmen, welche in der JPA eines Users geladen und aktiv sind CE-Dump – Hauptspeicherauszug der von LE (Language Environment) erstellt wird CPC – Central Processor Complex – Hardware im Systemprogrammer Slang = Blech! CPU – einzelner Central Processor (LPAR kann meistens über mehrere verfügen) CS – hier in diesem Dokument Credit Suisse / im POP ist CS die Compare and Swap Instruktion! CVT – Communications Vector Table – der zentrale Control Block im z/OS Betriebsystem Directory – Inhaltsverzeichnis einer Library/Bibliothek (enthält im Prinzip Adresse von Membern) DDLIST – unter TSO/ISPF aufrufbare Anwendung um die Allozierungen welche unter dem TSO-User gemacht wurden anzuzeigen und vieles mehr (gleich wie ISRDDN) DLL – Dynamic Link Library – Windows Bezeichnung für Module das dynamisch geladen wird und zum Teil für längere Zeit im Speicher bleibt ENQUEUE – Möglichkeit Daten zu reservieren für einen Adressraum (ENQUEUE/DEQUEUE) IDR – Identification Record – im IDR können PTF-Daten oder Versionsdaten zu Programmen festgehalten werden (sind dann auch im Browse auf Load-Library und AMBLIST sichtbar) IMS – Information Management System – Datenbanksystem IPCS – Interative Problem Control System – Dialogoberfläche um Dumps und Traces auszuwerten IPL – Initial Program Load - hochfahren eines z/OS auf einer LPAR ISPF – Interactive System Productivity Facility – SW Ergänzung zum TSO für Dialog-Applikationen ISPLLIB – ISPF dynamische Load-Library ISRDDN – unter TSO/ISPF aufrufbare Anwendung um die Allozierungen welche unter dem TSO-User gemacht wurden anzuzeigen und vieles mehr (gleich wie DDLIST) JES – Job Entry Subsystem (JES2 oder JES3) – verwaltet JOBs / Tasks / User – JPA – Job Pack Area – Speicherbereich im User Storage – In die JPA werden Module geladen, welche im eigenen Adressraum gebraucht werden LLA – Library Lookaside Facility – Adressraum um Directories von Programm-Libraries zu speichern und so den Suchvorgang auf Programme zu beschleunigen (weniger I/O) CS – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 37/39 LE – Language Environment – Gemeinsame Runtime-Umgebung für moderne Hochsprachen (ProgrammierSprachen) wie PL/I, COBOL, C oder auch Assembler LIBDEF – ISPF-Service um dynamisch ISPF-Libraries zu allozieren LINKLIST – Verkettung von System-Programm-Libraries welche definiert sind, um ein Module bequemer zu finden LPA – Link Pack Area – Speicherplatz für Load-Module in einer LPAR – Load Module die einmal in den Speicher geladen werden und von allen Usern da gebraucht werden LPAR – Logische Partition – logisches System z.B. S21 welches auf einem CPC läuft MNEMONIC – Assembler-Kürzel für ein Assembler-Befehlt PageFault – System findet Speicherseite nicht im RealStorage – Seite muss dann vom Auxilliary Storage eingelagert werden (= I/O) PDS – Parrtitionned Organized Dataset = Library/Bibliothek PDS/E – PDS-Extended – Erweiterung von PDS damit kein Compress mehr möglich ist POP – Principles of Operation (z/Architecture) – Die Bibel der Systemprogrammierer (Manual) PSA – Prefixed Save Area – Control Block im z/OS Betriebsystem PTF – Program Temporary Fix – Programm-Flick im IBM-Jargon der aber entgegen dem Namen nicht temporär ist, sondern definitive REENTRANT – Attribut für Module REUSABLE – Attribut für Module REXX – Restructured EXtended executor – interpretative Programmiersprache, welche im TSO/ISPF-Umfeld auf z/OS oft gebraucht wird, aber auch auf vielen anderen Plattformen RMODE – Residency Mode - besagt, wo im Storage (24 Bit / 31 Bit) ein Module geladen wird RZ1 – Im CS Umfeld die Bezeichnung für das Testrechenzentrum SMF – System Management Facility SMFID – System ID aus SMFPRMxx (muss nicht gleich sein wie effektive System ID) SPZAP – Dienstprogramm der IBM um Load-Module zu verändern mittels ZAP (Pgm=AMASPZAP) SSI – System Status Index – Feld zur Aufnahme von z.B. Versions-Bezeichnung eines Modules, welche dann auf der Directory, bzw. im AMBLIST sichtbar werden CS – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 38/39 SVC – SuperVisor Call – Betriebsystemfunktionen für spezielle Aktionen / Open / Getmain / Freemain SYSPLEX – Soft- und Hardwarekomponenten zum Betrieb eines SystemComplexes (IBM Terminologie) nicht SYSMDUMP – Hauptspeicher-Auszug in der Regel nach Abend – M=Machine / Dump ist sehr gross und formatiert, d.h. muss mit dem IPCS ausgewertet werden System z – IBM Mainframe System (Hardware) – Grossrechner SYSUDUMP – Hauptspeicher-Auszug nicht so gross, wie ein SYSMDUMP und formatiert TSO – Time Sharing Option / das Online System auf dem z/OS für das IT-Personal VLF – Virtual Lookaside Facility – Adressraum, der Module und Daten stagen kann, um I/O zu reduzieren z/OS – IBM Betriebsystem (Software) – gilt als weltbestes Betriebsystem (für IBM System Z) Peter Dennler alias Don Krawacki DK/02082011/11092011/KPS#00000266 CS – P00000266 – LLA und Extensions – Glück gehabt von Peter Dennler / KSDM 612 Seite 39/39