Den Namen eines Unterprogramms kann man in der CALL-Anweisung entweder als Literal angeben oder als Bezeichner eines Datenfeldes, das den Unterprogrammnamen bzw. die Unterprogrammadresse enthält. Abhängig von der Art des Unterprogrammaufrufs wird ein Programmsystem unterschiedlich gebunden und geladen.
Unterprogrammaufruf „CALL literal“ bzw. Programmadressbezeichner„ADDRESS OF PROGRAM literal“
Der Name des Unterprogramms ist bereits zur Übersetzungszeit festgelegt. Der Compiler setzt auf diese Unterprogramme Externverweise ab, die in anschließenden Bindeläufen vom jeweils verwendeten Binder befriedigt werden. Enthält ein Programmsystem ausschließlich Aufrufe in der Form „CALL literal“ bzw. „ADDRESS OF PROGRAM literal“, kann es, wie in Kapitel „Binden, Laden, Starten" beschrieben, zu einer permanent oder temporär ablauffähigen Programmausführungseinheit gebunden und anschließend geladen werden.
Unterprogrammaufruf „CALL bezeichner“ bzw. Programmadressbezeichner „ADDRESS OF PROGRAM bezeichner“
Der Name des Unterprogramms muss erst zum Ablaufzeitpunkt bekannt sein (z.B. nach Eingabe an der Datensichtstation). Für Unterprogramme, die nach Bedarf mit „CALL bezeichner“ aufgerufen werden und Programmadressbezeichner „ADDRESS OF PROGRAM bezeichner“, gibt es keine Externverweise; sie werden deshalb vom DBL während des Programmablaufs dynamisch nachgeladen. Programmsysteme mit derartigen Unterprogrammaufrufen können nur auf eine der folgenden Arten zum Ablauf gebracht werden:
Mit dem DBL die bei der Übersetzung entstandenen Module dynamisch binden und die Unterprogramme, auf die es keine Externverweise (im Hauptprogramm) gibt, dynamisch nachladen.
Mit dem TSOSLNK ein Großmodul vorbinden, das das Hauptprogramm sowie die Unterprogramme mit Externverweisen enthält. Mit dem DBL das Großmodul aufrufen und die Unterprogramme, auf die es keine Externverweise (im Hauptprogramm) gibt, dynamisch nachladen.
Mit dem BINDER einen LLM oder mehrere LLMs (vor)binden. Mit dem Bindelader den (Groß-)LLM bzw. den LLM, der das Hauptprogramm enthält, aufrufen und die Unterprogramme, auf die es keine Externverweise (im Hauptprogramm) gibt, dynamisch nachladen.
Vor dem Aufruf des Bindeladers sollte folgende Zuweisung vorgenommen werden:
/ADD-FILE-LINK BLSLIBnn,laufzeitbibliothek
für das Common RunTime Environment (CRTE), das das COBOL-Laufzeitsystem enthält(hierfür darf die Bibliothek SYSLNK.CRTE.PARTIAL-BIND nicht verwendet werden, siehe CRTE-Benutzerhandbuch [ 2]).
Außerdem muss folgende Zuweisung vorgenommen werden:
/ADD-FILE-LINK COBOBJCT,bibliothek
für eine Bibliothek, die die nachzuladenden Unterprogramme enthält.
Dabei ist zu beachten, dass die Verwendung des Linknamens BLSLIBnn nur wirkt, wenn im Aufrufkommando für den DBL
RUN-MODE=ADVANCED(ALTERNATE-LIBRARIES=YES)
angegeben wird (siehe Abschnitt „Dynamisches Binden und Laden mit dem DBL").
Enthält die Ladeeinheit unbefriedigte WXTRNSs (dies ist z.B.dann der Fall, wenn im Unterprogramm weitere Dateien mit anderer Dateiorganisation als im Hauptprogramm verarbeitet werden) dann müssen die Operanden UNRESOLVED-EXTRNS=DELAY undLOAD-INFORMATION=REFERENCES angegeben werden:
RUN-MODE=ADVANCED (ALTERNATE-LIBRARIES=YES, UNRES-EXT=DELAY, LOAD-INF=REF)
Beispiel 13-1
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.
1. Verwendung des DBL (dynamisches Binden)
/ADD-FILE-LINK BLSLIB00,$.SYSLNK.CRTE ————————————————————————————————(1) /ADD-FILE-LINK COBOBJCT,BENUTZER-PROGRAMME ———————————————————————————(2) /START-PROGRAM *MODULE(LIB=BENUTZER-PROGRAMME,ELEM=MAINPROG,——————————(3) /RUN-MODE=ADVANCED(ALT-LIB=YES,UNRES-EXT=DELAY,- /LOAD-INF=REFERENCES))
(1) | Zuweisung der Laufzeitbibliothek |
(2) | Zuweisung der Bibliothek, aus der das Unterprogramm UPROG2 dynamisch nachgeladen wird |
(3) | Aufruf des Objektmoduls mit dem Hauptprogramm MAINPROG. Aus der hier angegebenen Bibliothek BENUTZER-PROGRAMME befriedigt der Bindelader die Externverweise auf die Unterprogramme UPROG1 und UPROG3. |
2. Verwendung des TSOSLNK (Großmodulbinden)
/START-PROGRAM $TSOSLNK MODULE GROSSMOD,LET=Y,UNSAT=N, LIB=MODUL.LIB ——————————————————————————(1) INCLUDE MAINPROG,BENUTZER-PROGRAMME ———————————————————————————————————(2) RESOLVE,BENUTZER-PROGRAMME ————————————————————————————————————————————(3) LINK-SYMBOLS *KEEP ————————————————————————————————————————————————————(4) END /ADD-FILE-LINK BLSLIB00,$.SYSLNK.CRTE —————————————————————————————————(5) /ADD-FILE-LINK COBOBJCT,BENUTZER-PROGRAMME ————————————————————————————(6) /START-PROGRAM *MODULE(LIB=MODUL.LIB,ELEM=GROSSMOD,- /RUN-MODE=ADVANCED(ALT-LIB=YES,UNRES-EXT=DELAY,- ————————————————————(7) /LOAD-INFO=REFERENCES))
(1) | Das zu erstellende Großmodul GROSSMOD wird in der Bibliothek MODUL.LIB abgelegt. |
(2) | Einbinden des Moduls MAINPROG aus der Bibliothek BENUTZER-PROGRAMME |
(3) | Einbinden der Bibliothek BENUTZER-PROGRAMME zur Befriedigung der Externverweise auf UPROG1 und UPROG3 |
(4) | Mit dieser Anweisung werden die Symbole für die Einsprungstellen und die Programmabschnitte für den späteren Ablauf mit dem Bindelader sichtbar gehalten. |
(5) | Zuweisung der Laufzeitbibliothek |
(6) | Zuweisung der Bibliothek, aus der das Unterprogramm UPROG2 dynamisch nachgeladen wird |
(7) | Aufruf des Großmoduls GROSSMOD. |
3. Verwendung des BINDER (LLM-Binden)
Im Unterschied zum TSOSLNK lässt der BINDER 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.
a) 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=REFERENCES))
(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. |
b) Umwandeln der Objektmodule in einzelne Bindelademodule
/START-PROGRAM $BINDER ... //START-LLM-CREATION INTERNAL-NAME=MAINPROG (1) //INCLUDE-MODULES LIB=BENUTZER-PROGRAMME,ELEM=MAINPROG | //SAVE-LLM LIB=MODULE.LLM (1) ... //START-LLM-CREATION INTERNAL-NAME=UPROG1 (2) //INCLUDE-MODULES LIB=BENUTZER-PROGRAMME,ELEM=UPROG1 | //SAVE-LLM LIB=MODULE.LLM,ENTRY-POINT=UPROG1 (2) ... //START-LLM-CREATION INTERNAL-NAME=UNTER2 (3) //INCLUDE-MODULES LIB=BENUTZER-PROGRAMME,ELEM=UNTER2 | //SAVE-LLM LIB=MODULE.LLM,ENTRY-POINT=UNTER2 (3) ... //START-LLM-CREATION INTERNAL-NAME=UPROG3 (4) //INCLUDE-MODULES LIB=BENUTZER-PROGRAMME,ELEM=UPROG3 | //SAVE-LLM LIB=MODULE.LLM (4) //END ... /ADD-FILE-LINK BLSLIB00,$.SYSLNK.CRTE ————————————————————————————————— (5) /ADD-FILE-LINK COBOBJCT,MODULE.LLM ———————————————————————————————————— (6) /START-PROGRAM *MODULE(LIB=MODULE.LLM,ELEM=MAINPROG,- ————————————————— (7) /RUN-MODE=ADVANCED(ALT-LIB=YES,UNRES-EXT=DELAY,- /LOAD-INFO=REFERENCE))
(1) | Erzeugen eines LLM namens MAINPROG; der Name des LLM ist frei wählbar. Einbinden des Objektmoduls MAINPROG aus der Bibliothek BENUTZER-PROGRAMME. Da im SAVE-LLM-Kommando der Elementname weggelassen ist, gilt als Elementname die Angabe aus dem START-LLM-CREATI-ON-Kommando, nämlich MAINPROG. |
(2) | Erzeugen eines LLM namens UPROG1. Einbinden des Objektmoduls UPROG1 aus der Bibliothek BENUTZER-PROGRAMME. Mit ENTRY-POINT=UPROG1 ist dieser LLM als Unterprogramm definiert. |
(3) | Erzeugen eines LLM namens UNTER2. Einbinden des Objektmoduls UPROG2 aus der Bibliothek BENUTZER-PROGRAMME. Mit ENTRY-POINT=UPROG2 ist dieser LLM als Unterprogramm definiert. |
(4) | Erzeugen eines LLM namens UPROG3. Einbinden des Objektmoduls UPROG3 aus der Bibliothek BENUTZER-PROGRAMME. Da im SAVE-LLM-Kommando kein ENTRY-POINT angegeben ist, kann UPROG3 sowohl als Unterprogramm als auch als Hauptprogramm verwendet werden. |
(5) | Zuweisen der Laufzeitbibliothek |
(6) | Zuweisen der Bibliothek, in der die LLMs stehen, mit dem Linknamen COBOBJCT, damit die offenen Externverweise der zuvor erzeugten LLMs befriedigt werden können. |
(7) | Aufruf des LLM mit dem Hauptprogramm MAINPROG. |