Nur ein Teil der Anwendung muss statisch zum Anwendungsprogramm gebunden werden (Start-LLM, siehe Abschnitt „Binden des Anwendungsprogramms"). Die anderen Teile des Anwendungsprogramms müssen Sie in Form von dynamisch nachladbaren Lademodulen bereitstellen.
Bei den Lademodulen kann es sich um einzelne Objektmodule (OM) handeln, die in einer Bindemodulbibliothek (OML) oder einer Programmbibliothek als Elemente vom Typ R bereitgestellt werden, oder um Bindelademodule (LLM), die in einer Programmbibliothek als Elemente vom Typ L bereitgestellt werden. Gruppen von Lademodulen können Sie mit dem BINDER zu LLMs vorbinden, siehe Abschnitt „Binden von LLMs".
Bei der KDCDEF-Generierung müssen die einzelnen Lademodule der Anwendung mit LOAD-MODULE-Anweisungen generiert werden.
Im einzelnen legen Sie bei der KDCDEF-Generierung für die Lademodule Folgendes fest:
wann die Lademodule geladen werden sollen
Für Teilprogramme, d.h. Module, die mit der PROGRAM-Anweisung generiert wurden, können Sie zwischen dem Startzeitpunkt der Anwendung und dem Aufrufzeitpunkt des Teilprogramms wählen.
Nicht-shareable Teilprogramme können entweder statisch zum Anwendungsprogramm gebunden, als Lademodul beim Anwendungsstart dynamisch nachgeladen oder als Lademodul zum Zeitpunkt des Teilprogrammaufrufs geladen werden.
Der nicht-shareable Teil (Private Slice) zu einem shareable Teil (Public Slice), der in einem Common Memory Pool steht, kann ebenfalls entweder beim Anwendungsstart oder erst zum Zeitpunkt des Teilprogrammaufrufs geladen werden.
Der Private Slice zu einem Public Slice, der sich in nichtprivilegierten Subsystemen befindet, kann man alternativ auch zum statischen Teil des Anwendungsprogramms binden.
Module und Datenbereiche, die mit der AREA-Anweisung generiert wurden, müssen entweder statisch zum Anwendungsprogramm gebunden oder zum Zeitpunkt des Starts der Anwendung nachgeladen werden, da der Zugriff auf diese Anwendungsteile nicht unter der Kontrolle von openUTM erfolgt.
aus welchen Bibliotheken die Lademodule geladen werden sollen
Sie können Bindemodulbibliotheken (OML) oder Programmbibliotheken (PL), die Elemente vom Typ R oder L enthalten, angeben.
welche Version eines Lademoduls geladen werden soll
In einer Programmbibliothek können gleichzeitig mehrere Versionen eines Elements enthalten sein. Mit der Versionsangabe legen Sie fest, welche Version eines Elements geladen werden soll.
in welchen Speicherbereich die Lademodule geladen werden sollen
Ein Lademodul kann entweder in einen Common Memory Pool oder in den Standardkontext der Anwendung geladen werden. Der Standardkontext enthält den statisch gebundenen Teil des Anwendungsprogramms, der mit dem Kommando START-EXECUTABLE-PROGRAM bzw. LOAD-EXECUTABLE-PROGRAM geladen wurde, sowie die Teile des Anwendungsprogramms, die nicht in Common Memory Pools oder in den Systemspeicher geladen wurden.
Enthält ein LLM Public und Private Slices, dann kann der Public Slice in einen Common Memory Pool und der Private Slice in den Standardkontext im task-lokalen Speicher geladen werden.
ob mit Autolink gebunden werden soll
Die shareable Teile der Lademodule werden stets ohne die Autolink-Funktion geladen. Bei den nicht-shareable Teilen können Sie über die LOAD-MODULE-Anweisung steuern, ob mit oder ohne Autolink-Funktion geladen werden soll.
Wird die Autolink-Funktion des BLS beim Nachladen und beim Programmaustausch unterdrückt, dann werden der Ladevorgang für Lademodule beschleunigt und Inkonsistenzen in dem geladenen Anwendungsprogramm vermieden. In diesem Fall dürfen die Lademodule ausschließlich offene Externverweise auf Programmteile besitzen, die zum Zeitpunkt des Ladens dieses Moduls bereits im Arbeitsspeicher vorhanden sind.
Wird mit Autolink geladen, dann werden beim Laden des Lademoduls die Module, die zusätzlich benötigt werden, nachgebunden. Die Autolink-Funktion sollte nur für Module des Laufzeitsystems, nicht jedoch für benutzereigene Module verwendet werden, da per Autolink geladene Module bei einem nachfolgenden Austausch nicht mehr entladen werden.
Die Zuordnung von Objekten (Teilprogramme und gemeinsam nutzbare Datenbereiche) zu den Lademodulen wird ebenfalls bei der UTM-Generierung festgelegt (Operand LOAD-MODULE in den PROGRAM- und AREA-Anweisungen). Ob die mit KDCDEF definierte Zuordnung der tatsächlichen Aufteilung der Lademodule in den Bibliotheken entspricht, kann von openUTM nicht verifiziert werden. openUTM verlässt sich beim Programmaustausch auf die bei der UTM-Generierung gemachten Angaben.
Mit der Reihenfolge, mit der Sie die Lademodule generieren, bestimmen Sie die Reihenfolge, in der die Lademodule geladen werden. Wenn Sie Lademodule, die mit LOAD-MODE=(POOL, poolname, STARTUP) oder LOAD-MODE=STARTUP generiert wurden, ohne die Autolink-Funktion des BLS laden lassen, ist die Reihenfolge der UTM-Generierung ausschlaggebend für die Auflösung der unbefriedigten Externverweise beim Laden.
 | Ausführliche Informationen zum Generieren der Lademodule finden Sie im |
Hinweise zum Programmaustausch
Mit der Generierung der Lademodule legen sie fest, welche Programmteile später ausgetauscht werden können. Folgendes ist zu beachten:
Programmteile, die später ausgetauscht werden sollen, dürfen nicht statisch ins Anwendungsprogramm eingebunden oder in anwendungsglobale Common Memory Pools oder in den Systemspeicher geladen werden.
Das BLS unterstützt nur das Entladen von Programmteilen, die mit einem Ladevorgang geladen werden. Wenn also eine Gruppe von Modulen ausgetauscht werden soll, müssen Sie diese Module als LLM oder OM vorbinden. Soll ein Einzelmodul ausgetauscht werden, können Sie dieses Modul als LLM oder OM bereitstellen. Es darf dann nicht mit anderen Modulen zusammen gebunden werden.
Ein Lademodul, das das Administrationsprogramm KDCADM, die Event-Exits START, SHUT, INPUT und FORMAT oder die Event-Services BADTAC, MSGTAC und SIGNON enthält, darf im Betrieb nicht ausgetauscht werden.
Bei einer Änderungsgenerierung werden standardmäßig auch die aktuellen Versionsnummern der ausgetauschten Lademodule aus der alten KDCFILE in die neue KDCFILE übertragen.