Die Ladestruktur einer Anwendung bestimmt maßgeblich die Zeit, die zum Starten der ersten Task und der Folgetasks einer Anwendung benötigt wird. Ebenso legen Sie damit fest, welche Programmteile später während des Anwendungslaufs ausgetauscht werden können. Deshalb sollten Sie folgende Empfehlungen beachten:
Der mit dem Kommando START-EXECUTABLE-PROGRAM zu ladende statisch gebundene Teil des Anwendungsprogramms (Start-LLM) sollte möglichst klein gehalten werden. Er muss die ROOT-Systemmodule und die von diesen Modulen benötigten Laufzeitmodule enthalten.
Das Administrationsprogramm KDCADM muss zum Start der Anwendung zur Verfügung stehen. Es muss daher entweder statisch zum Start-LLM oder beim Start der Anwendung nachgeladen werden. Im zweiten Fall muss es entweder direkt mit LOAD-MODULE KDCADM,...,LOAD-MODE=STARTUP generiert werden oder in ein Lademodul eingebunden werden, das mit LOAD-MODE=STARTUP definiert ist. Selbstgeschriebene Administrationsprogramme sollten wie das Lademodul KDCADM beim Start der Anwendung geladen werden, also wie dieses statisch zum Start-LLM gebunden oder beim Start der Anwendung nachgeladen werden. Ein Lademodul, das das Administrationsprogramm KDCADM enthält, darf im Betrieb nicht ausgetauscht werden. Daher dürfen Sie selbstgeschriebene Administrations-Programme, die austauschbar sein sollen, nicht mit dem KDCADM zusammenbinden.
Die Event-Exits START, SHUT, INPUT und FORMAT und die Event-Services BADTAC, MSGTAC und SIGNON sollten entweder statisch zum Start-LLM oder zu einem eigenen Lademodul gebunden werden. Dieses Lademodul muss beim Start der Anwendung geladen werden, d.h. es muss mit LOAD-MODULE ...,LOAD-MODE=STARTUP generiert werden. Es sollte im Betrieb nicht ausgetauscht werden, da Fehler beim Austausch dieses Moduls zu einem abnormalen Anwendungsende führen können.
Programmteile, die später ausgetauscht werden sollen, dürfen nicht statisch gebunden oder in anwendungsglobale Common Memory Pools oder in den Systemspeicher geladen werden.
Programmteile, die von mehr als einer Anwendung benötigt werden, sollten shareable, z.B. als nicht-privilegiertes Subsystem, geladen werden.
Alle übrigen Anwendungsteile, die shareable sind, sollten Sie zu einem Lademodul vorbinden und diesen in einen Common Memory Pool laden. Werden aus bestimmten Gründen mehrere Lademodule mit shareable Programmteilen benötigt, so sollten diese trotzdem nur in einen Common Memory Pool geladen werden.
Viele Compiler erlauben es, das shareable Modul mit dem nicht-shareable Modul gemeinsam in einem LLM abzulegen. Dies vereinfacht die Verwaltung der Module, da sich beide Teile immer in einem Container befinden. In diesem Fall sollten Sie die shareable und die nicht-shareable Teile nicht getrennt vorbinden, sondern die LLMs mit Public und Private Slices, wie sie vom Compiler erzeugt wurden, in ein oder mehrere LLMs vorbinden.
openUTM lädt den Public Slice eines solchen LLM in einen Memory Pool und den Private Slice beim Start der Anwendung bzw. beim Aufruf eines Programms aus einem solchen LLM in den task-lokalen Speicher, wenn Sie das LLM mit LOAD-MODULE ..., LOAD-MODE=(POOL,...,STARTUP) bzw. LOAD-MODE= (POOL,...,ONCALL) generieren.
Programmteile, die nur gelegentlich benötigt werden, sollten so generiert werden, dass sie erst zum Aufrufzeitpunkt nachgeladen werden
(LOAD-MODULE ..., LOAD-MODE= ONCALL). Dadurch kann die Startphase verkürzt werden. Diese Lademodule sollten Sie zu kleinen logischen Einheiten vorbinden, da das Laden kleiner Module weniger Zeit benötigt als das Laden großer Module.Anwendungsteile, die logisch zusammengehören, sollten Sie zu einem Lademodul vorbinden. Das können z.B. Programmteile sein, die sich gegenseitig referenzieren, oder die zu einer Folge von Teilprogrammläufen in einem Vorgang gehören.
Alle Programmteile, die nachgeladen werden sollen, sollten Sie als LLM vorbinden. Der Start der Anwendung sowie das Laden von Lademodulen wird dadurch erheblich beschleunigt, da der dynamische Bindelader (DBL) LLMs wesentlich performanter verarbeiten kann als OMs.
Die Anzahl der Lademodule, die zum Zeitpunkt des Starts des Anwendungsprogramms geladen werden (LOAD-MODE=STARTUP oder LOAD-MODE=(POOL,...,STARTUP), sollte so klein wie möglich gehalten werden. Aus diesem Grund sollten Sie nur die Teile der Anwendung mit STARTUP generieren, die häufig benötigt werden.
Weil das Laden weniger großer Lademodule weniger Zeit benötigt als das Laden vieler kleiner Lademodule, sollten diese Teile des Anwendungsprogramms zu größeren Lademodulen vorgebunden werden.Es sollte nur ein anwendungslokaler Common Memory Pool (MPOOL ...,SCOPE=GROUP) definiert werden. In diesen können Sie mehrere vorgebundene Lademodule laden. Damit wird die Zeit zum Einrichten und Laden der Common Memory Pools verkürzt und somit die für den Start der Anwendung benötigte Zeit minimiert.
OMs und LLMs sollten Sie in unterschiedlichen Programmbibliotheken bereitstellen, da auf diese Weise der Suchalgorithmus des BLS optimiert wird.
Module, die weder Teilprogramme des Anwendungsprogramms noch Datenbereiche (AREA) sind (z.B. die Module der Laufzeitsysteme der Programmiersprache), brauchen Sie nicht einzeln mit dem Generierungstool KDCDEF als nachzuladende Module zu deklarieren, selbst wenn diese Module nicht statisch eingebunden sind. Sie können diese Module zu größeren Lademodulen (LLM) vorbinden und müssen nur den Namen des Lademoduls in der LOAD-MODULE-Anweisung generieren.
ACHTUNG!
Ob die mit der Anweisung LOAD-MODULE und den Operanden LOAD-MODULE in der PROGRAM- und AREA-Anweisung definierte Zuordnung der tatsächlichen Aufteilung der Lademodule in den Bibliotheken entspricht, kann von openUTM nicht verifiziert werden. openUTM verlässt sich beim Nachladen der Lademodule auf die in der UTM-Generierung gemachten Angaben. Sie müssen deshalb sicherstellen, dass die von Ihnen verwendeten Bindeprozeduren für die einzelnen Teile des Anwendungsprogramms mit den in der UTM-Generierung gemachten Angaben übereinstimmen. Andernfalls kann openUTM nicht sicherstellen, dass mit einem bestimmten Lademodul das gewünschte Programm in den Arbeitsspeicher geladen wird.