Laufzeitsystem- und ILCS-Module dürfen beim Binden von Großmodulen nicht mit eingebunden werden, wenn diese Großmodule zu einem späteren Zeitpunkt mit anderen Objekten oder Großmodulen zusammengebunden werden sollen. Bestimmte Laufzeitsystem Module wie z.B. IT0PCD oder ITCMPOVH dürfen in einer Anwendung nur einmal vorhanden sein, da anderenfalls der Datenaustausch zwischen den Laufzeitsystem-Modulen nicht korrekt funktioniert. Ausgenommen hiervon sind abgeschottete Subsysteme, auf die im Abschnitt "Abgeschottete Subsysteme“ näher eingegangen wird.
Auch in Assembler- oder COBOL-Anwendungen, die zur Laufzeit Unterprogramme oder Großmodule nachladen, dürfen Laufzeitsystem- und ILCS-Module nicht fest mit eingebunden sein, da anderenfalls die Laufzeitsystem-Module vom nachgeladenen Unterprogramm nicht gefunden werden und dadurch ein zweites Laufzeitsystem nachziehen. Auch hier gilt wieder die Ausnahme: Werden nur abgeschottete Subsysteme nachgeladen, dann kann die Anwendung komplett gebunden werden.
Beispiel
Das folgende Beispiel zeigt Binde- und Ladetechniken für Programmsysteme mit dynamisch nachzuladenden Unterprogrammen.
UPROG1 wird ausschließlich in der Form CALL literal aufgerufen.
UPROG2 wird ausschließlich in der Form CALL bezeichner aufgerufen.
UPROG3 wird auf beide Arten aufgerufen.
Das bedeutet: Für UPROG1 und UPROG3 werden Externverweise abgesetzt, UPROG2 wird dynamisch nachgeladen.
Für diese Programmkonstellation werden im Folgenden die Möglichkeiten gezeigt, das Programm zum Ablauf zu bringen.
Die einzelnen Programme sind als Objektmodule unter den Elementnamen MAINPROG, UPROG1, UPROG2 und UPROG3 in der Bibliothek BENUTZER-PROGRAMME abgelegt
Verwendung des BINDER (LLM-Binden)
Der BINDER lässt standardmäßig alle Externverweise und Einsprungpunkte sichtbar. Dies ist für den anschließenden Bindelader-Lauf unbedingt erforderlich. Ferner können bei Verwendung des BINDER die Externverweise offen bleiben. Deshalb braucht das LZS nicht eingebunden zu werden. Dies ist von Vorteil, wenn für den Programmablauf ein gemeinsam benutzbares LZS verwendet werden soll.
Das nachfolgende Beispiel zeigt das Erzeugen eines einzigen Bindelademoduls.
/START-PROGRAM $BINDER START-LLM-CREA GROSSMOD .....................................(1) INCLUDE-MODULES LIB=BENUTZER-PROGRAMME,ELEM=MAINPROG ........(2) INCLUDE-MODULES LIB=BENUTZER-PROGRAMME,ELEM=UPROG2 ..........(3) RESOLVE-BY-AUTOLINK LIB=BENUTZER-PROGRAMME ..................(4) SAVE-LLM LIB=MODUL.LIB ......................................(5) END /ADD-FILE-LINK BLSLIB00,$.SYSLNK.CRTE ....................... (6) /START-PROGRAM *MODULE(LIB=MODUL.LIB,ELEM=GROSSMOD,- .........(7) RUN-MODE=ADVANCED(ALT-LIB=YES,UNRES-EXT=DELAY,- LOAD-INFO=REFERENCE))
(1) | Erzeugen eines Bindelademoduls mit dem Namen GROSSMOD. |
(2) | Explizites Einbinden des Hauptprogramm-Moduls MAINPROG aus der Bibliothek BENUTZER-PROGRAMME. |
(3) | Explizites Einbinden des Moduls UPROG2 aus der Bibliothek BENUTZER-PROGRAMME, um dynamisches Nachladen zu vermeiden; damit erübrigt sich beim anschließenden Bindeladevorgang die Zuweisung der Bibliothek BENUTZER-PROGRAMME mit dem Linknamen COBOBJCT. |
(4) | Einbinden aller weiteren erforderlichen Module (UPROG1, UPROG3) aus der Bibliothek BENUTZER-PROGRAMME. |
(5) | Abspeichern des erzeugten Bindelademoduls in der Programmbibliothek MODUL.LIB als Element vom Typ L. |
(6) | Zuweisen der Laufzeitbibliothek. |
(7) | Aufruf des Bindelademoduls GROSSMOD. |