Folgende Regeln und Einschränkungen müssen Sie bei der Aufteilung der Objekte in Lademodule sowie beim Binden und Nachladen der Objekte beachten:
Die Event-Exits START, SHUT, INPUT und FORMAT und die Event-Services BADTAC, MSGTAC und SIGNON dürfen Sie keinem Lademodul zuordnen, das erst beim Aufruf eines Teilprogramms geladen wird, d.h. mit LOAD-MODE=ONCALL generiert ist. Der Grund dafür ist, dass die Event-Exits und -Services in jedem Prozess der Anwendung verfügbar sein müssen. Sind sie es nicht, dann bricht openUTM den Start des Prozesses ab.
Die Lademodule, die die Event-Exits und -Services enthalten, sollten im Betrieb nicht ausgetauscht werden. Fehler beim Austausch der Lademodule können zu einem abnormalen Anwendungsende führen.Das Administrationsprogramm KDCADM dürfen Sie keinem Lademodul zuordnen, das mit LOAD-MODE=ONCALL generiert ist.
Das Lademodul, in das das Administrationsprogramm KDCADM eingebunden ist, darf nicht ausgetauscht werden.
Ist das Administrationsprogramm KDCADM beim Start der Anwendung nicht verfügbar, dann bricht openUTM den Start ab.Datenbereiche (AREAs) müssen entweder statisch zum Anwendungsprogramm gebunden werden, oder, falls möglich, als LOAD-MODULE mit LOAD-MODE(POOL, STARTUP) oder LOAD-MODE=STARTUP generiert werden.
Das Start-LLM müssen Sie in einer Programmbibliothek bereitstellen. Es kann nicht in einer Datei stehen.
Im Kommando START-EXECUTABLE-PROGRAM müssen Sie die folgenden Operanden angeben:
/ ,DBL-PARAMETERS=*PARAMETERS( - / ,LOADING=*PARAMETERS( - / PROGRAM-MODE=*ANY - / ,LOAD-INFORMATION=*REFERENCES) - ... / ,ERROR-PROCESSING=*PARAMETERS( - / UNRESOLVED-EXTRNS=*DELAY - / ,...))
Die Angabe von PROGRAM-MODE=*ANY ist erforderlich, wenn die Anwendung in den oberen Adressraum geladen werden soll.
Wenn Sie per Administration einen Programmaustausch anfordern, müssen Sie explizit die Version des neu zu ladenden Moduls angeben.
Für Lademodule dürfen Sie nur die Namen von OMs oder LLMs angeben. Aus Performancegründen unterstützt openUTM nicht das Nachladen über CSECT- oder ENTRY-Namen.
openUTM unterstützt maximal acht Common Memory Pools mit SCOPE=GROUP und acht Common Memory Pools mit SCOPE=GLOBAL.
Zwei UTM-Anwendungen sollten möglichst unter unterschiedlichen BS2000-Benutzerkennungen gestartet werden, um Fehler zu vermeiden, die aufgrund von gleichen Modulnamen in shareable Teilen auftreten können. Module, die von mehreren Anwendungen benutzt werden, sollten daher in anwendungsglobale Common Memory Pools oder in nichtprivilegierte Subsysteme geladen werden.
Durch einen Programmaustausch kann kein neu erzeugter Tabellenmodul aktiviert werden.
Die Variantennummer des LMS ist beim Laden von Lademodulen mit BLS ohne Bedeutung.
BLS unterstützt nur das Entladen von Programmteilen, die in einem Ladevorgang geladen wurden. Deshalb müssen Programmteile, die als separate Teile austauschbar sein sollen, in der Form bereitgestellt werden, in der sie geladen und ausgetauscht werden sollen. Soll ein Einzelmodul ausgetauscht werden, dann kann dieses Modul als OM oder LLM bereitgestellt werden; soll eine Gruppe von Lademodulen ausgetauscht werden, dann sind diese Lademodule als LLM vorzubinden.
Lademodule, die TCB-Entries enthalten, dürfen im laufenden Betrieb nicht ausgetauscht werden.
Module, die über die Autolink-Funktion nachgeladen wurden, können nicht ausgetauscht oder entladen werden. Ausnahme: Beim Austausch der gesamten Anwendung (z.B. mit KDCAPPL PROG=NEW) werden alle Anwendungsteile neu geladen.
FHS kann nicht aus der TASKLIB nachgeladen werden. FHS-Format-Module können ausgetauscht werden.
Beim Vorbinden der Lademodule zu LLMs ist zu beachten, dass die eingebundenen Elemente nicht in mehreren Lademodulen vorkommen sollten. Aus diesem Grund sind insbesondere beim Einbinden der Laufzeitsysteme der Programmiersprachen Einschränkungen zu beachten. Wie Sie die für das Anwendungsprogramm benötigten Module der Laufzeitsysteme einbinden können, ist im Abschnitt „Laufzeitsysteme binden" beschrieben.