Binden von LLMs

Als LLMs sollten Sie alle Modulgruppen vorbinden, die in einem logischen Zusammenhang stehen. Dies können sein:

• Teile der Laufzeitsysteme

• logisch zusammengehörige Teile einer UTM-Anwendung, wie z.B. alle Teilprogramme eines oder mehrerer Vorgänge einschließlich Vorgangsexits

• FHS-Formate samt der zugehörigen Teilprogramme

Damit beim dynamischen Binden eines LLM die Externverweise dieses LLM befriedigt werden können, müssen Sie beim Erzeugen des LLM unbedingt folgende BINDER-Anweisungen angeben:

/START-LLM-CREATION    INTERNAL-NAME=int-name     - ——————————————————  (1) 
/                     ,INTERNAL-VERSION=int-vers  - 
/                     ,...
/SET-EXTERN-RESOLUTION SYMBOL-TYPE=*REFERENCES    - ——————————————————  (2) 
/                     ,RESOLUTION=*STD
/SAVE-LLM          ...,ELEMENT=*INTERNAL-NAME(    - ——————————————————  (3) 
/                      VERSION=*INTERNAL-VERSION) -
/                     , ... 

1. Hier legen Sie schon Name und Version des LLM fest, unter denen das LLM zum Abschluss des Bindens in der Bibliothek abgespeichert wird.

2. Die Behandlung unbefriedigter Externverweise wird festgelegt. Die angegebenen Operandenwerte sind die Standardwerte, die auf keinen Fall geändert werden dürfen.

3. Das LLM muss unter dem internen Namen abgespeichert werden; das Format des LLM muss korrekt sein (mindestens LLM-Format 2 wie im Beispiel).

   Wird beim Abspeichern ein anderer Name als der interne gewählt und wird bei der UTM-Generierung LOAD-MODULE,...,ALTLIB=YES angegeben, so kann openUTM bei einem Programmaustausch das Modul nicht finden und meldet einen UNBIND-Fehler (K078 UNBIND 0C010174).

Mehrfach vorkommende Elemente

Beim Vorbinden von LLMs müssen Sie beachten, dass eingebundene Elemente
(Sub-LLM / OM) nicht in mehreren, evtl. vorgebundenen LLM / OM vorkommen. Falls dies doch der Fall ist, müssen Sie die externen Namen, die in mehrfach eingebundenen Modulen enthalten sind, durch die BINDER-Anweisung MODIFY-SYMBOL-VISIBILITY maskieren.

Autolink-Funktion für das Nachladen von Lademodulen

Die Autolink-Funktion wird in der LOAD-MODULE-Anweisung durch den Operanden ALTERNATE-LIBRARIES gesteuert.

• ALTERNATE-LIBRARIES=NO
  schaltet die Autolink-Funktion des BLS aus. D.h. für alle dynamisch generierten Lademodule, die auf diese Weise geladen werden, müssen alle offenen Verweise eines solchen Lademoduls durch die zum Ladezeitpunkt geladenen Module (Start-LLM und andere Lademodule) und durch den Shared Code befriedigt werden. Externverweise ins Laufzeitsystem werden bei Lademodulen, die nur aus C- oder Datenobjekten bestehen, immer dann befriedigt, wenn beim Binden des Start-LLM ein RESOLVE-BY-AUTOLINK auf die Bibliothek SYSLNK.CRTE.PARTIAL-BIND angegeben wurde.

• ALTERNATE-LIBRARIES=YES
  schaltet die Autolink-Funktion des BLS ein. Diese können Sie für solche Lademodule verwenden, die beim Laden und Austausch weitere Module des Laufzeitsystems benötigen, die sich noch nicht im Speicher befinden. Beim Binden werden offene Externverweise zunächst im Link-Kontext und dann im Shared Code gesucht (siehe auch Handbuch „Bindelader - Starter“). Wenn danach Externverweise unbefriedigt geblieben sind, wird die Bibliothek durchsucht, die Sie im LIB-Operanden angegeben haben. Wird eine passende Definition gefunden, dann wird das zugehörige Modul eingebunden und die Suche abgebrochen. Ansonsten wird in den Bibliotheken weitergesucht, die Sie vor dem Start der Anwendung durch ein SET-FILE-LINK-Kommando mit den Linknamen BLSLIBnn (wobei 00<=nn<=99), verknüpft haben. Die Bibliotheken werden in aufsteigender Reihenfolge der nn bearbeitet.

  Die Behandlung der Module des Laufzeitsystems in Verbindung mit UTM-Anwendungen wird ausführlich auf "Laufzeitsysteme binden" beschrieben.

Der Autolink-Mechanismus sollte nicht auf benutzereigene Bibliotheken angewandt werden, da bei einem Programmaustausch nur das Lademodul und nicht die ganze Ladeeinheit, die zusätzlich alle durch Autolink geladenen Module enthält, entladen wird.

Die Autolink-Funktion für das Start-LLM kann über die Parameter des Kommandos START-EXECUTABLE-PROGAM beeinflusst werden, siehe auch das Beispiel im Abschnitt "Module laden".

Beispiel

• UTM-Generierung und LINK-Anweisung

  UTM-Generierung:

  LOAD-MODULE     lm-name -
                  ,VERSION             = llm-version -
                  ,LIB                 = lm-lib      -
                  ,LOAD-MODE           = ONCALL      -
                  ,ALTERNATE-LIBRARIES = YES 
  

  LINK-Anweisung vor Start der Anwendung:

  /SET-FILE-LINK

  LINK-NAME = BLSLIB00,FILE-NAME = $userid.SYSLNK.CRTE.PARTIAL-BIND

  Zunächst wird mit der LOAD-MODULE-Anweisung das Lademodul lm-name mit LOAD-MODE=ONCALL generiert, d.h. lm-name wird erst beim Aufruf eines darin enthaltenen Programms nachgeladen. Im Beispiel sollte lm-name COBOL-Objekte enthalten.

  Um offene Externverweise beim Laden zu befriedigen, wird erst die im LIB-Operanden angegebene Bibliothek lm-lib durchsucht und dann die Bibliothek
  $userid.SYSLNK.CRTE.PARTIAL-BIND, die über das SET-FILE-LINK-Kommando zugewiesen ist.

• BINDER-Anweisungen

  /START-BINDER
  //START-LLM-CREATION     INTERNAL-NAME    = llm-name   -
  //                      ,INTERNAL-VERSION = llm-version 
  //INCLUDE-MODULES        LIBRARY=benutzerbibliothek    -
  //                      ,ELEMENT=teilprogrammname
  //RESOLVE-BY-AUTOLINK    LIBRARY=(bibliothek1,bibliothek2..)
  //SET-EXTERN-RESOLUTION  SYMBOL-TYPE=*REFERENCES       -
  //                      ,RESOLUTION=*STD
  //SAVE-LLM               LIBRARY=llm-bibliothek        -
  //                      ,ELEMENT=*INTERNAL-NAME(       -
  //                       VERSION=*INTERNAL-VERSION)    -
  //                      ,FOR-BS2000-VERSIONS=*FROM-OSD-V4(...)
  //END
  

  In diesem BINDER-Lauf wird ein Teilprogramm der Anwendung zu einem Lademodul gebunden. KDCROOT wird hier nicht mit eingebunden, weswegen u.a. der Entry KDCS unbefriedigt bleibt.