LOAD-MODULE - Lademodule (BLS) beschreiben (BS2000-Systeme)

Mit der LOAD-MODULE-Anweisung werden Namen, Version und Eigenschaften von Lademodulen festgelegt. Mit LOAD-MODULE-Anweisungen sind alle Lademodule zu beschreiben, die während des Programmlaufs mit BLS ausgetauscht, bzw. als eigenständige Einheiten nachgeladen werden. Für jedes Lademodul ist eine eigene LOAD-MODULE-Anweisung zu schreiben.

Die Lademodule, die Sie mit dem BLS bearbeiten können, sind entweder LLMs (Link and Load Module) oder OMs (Object Module). Es wird jedoch empfohlen, die nachzuladenden Programmteile und Datenbereiche zu LLMs zu binden (siehe Handbücher zu BLS).

Ein Lademodul kann mehrere Teilprogramme und Datenbereiche enthalten. Die Teilprogramme und Datenbereiche können mit PROGRAM- bzw. AREA-Anweisungen beschrieben werden. Sie können einer LOAD-MODULE-Anweisung eine oder mehrere PROGRAM- und/oder AREA-Anweisungen zuordnen. Die Zuordnung erfolgt über den Namen des Lademoduls lmodname, der auch im Operanden LOAD-MODULE der PROGRAM- bzw. AREA-Anweisung anzugeben ist. Sie können jedoch auch LOAD-MODULE-Anweisungen generieren, denen Sie keine PROGRAM- bzw. AREA-Anweisung zuordnen (z.B. Lademodule, die Teile des Laufzeitsystems einer Programmiersprache enthalten).

Wenn die Funktionalität "Programmaustausch" (KDCAPPL PROGRAM=NEW) auf BS2000-Systemen verwendet werden soll, muss mindestens eine LOAD-MODULE-Anweisung generiert werden.

Mit der Reihenfolge der LOAD-MODULE-Anweisungen und mit dem Operanden LOAD-MODE bestimmen Sie, in welcher Reihenfolge die Lademodule beim Start der UTM-Anwendung geladen werden. Nacheinander werden geladen:

• Der Basisteil der Anwendung inklusive aller Lademodule, die statisch in das Anwendungsprogramm eingebunden werden (LOAD-MODE=STATIC).

• Alle Lademodule, die beim Start der UTM-Anwendung in einen anwendungsglobalen Common Memory Pool geladen werden. Sie werden generiert mit LOAD-MODULE LOAD-MODE=(POOL, poolname,...) und MPOOL poolname,SCOPE=GLOBAL. Die Common Memory Pools werden in der Reihenfolge der MPOOL-Anweisungen im Generierungslauf geladen. Innerhalb eines Pools gilt die Reihenfolge der LOAD-MODULE-Anweisungen zu diesem Pool.

• Alle Lademodule, die beim Start der UTM-Anwendung in einen anwendungslokalen Common Memory Pool geladen werden. Sie werden generiert mit LOAD-MODULE LOAD-MODE=(POOL, poolname,...) und MPOOL poolname,SCOPE=GROUP. Die Pools werden in der Reihenfolge der MPOOL-Anweisungen geladen. Innerhalb eines Pools gilt die Reihenfolge der LOAD-MODULE-Anweisungen zu diesem Pool.

• Alle Lademodule, die beim Start als eigenständige Einheiten nachgeladen werden sollen. Sie werden generiert mit LOAD-MODULE LOAD-MODE=STARTUP. Die Lademodule werden in der Reihenfolge der so definierten LOAD-MODULE-Anweisungen geladen.

Lademodule, die mit LOAD-MODE=ONCALL generiert sind, werden beim erstmaligen Aufruf eines zugeordneten Teilprogramms geladen.

Bitte beachten Sie:

• Lademodule, die TCB-Entries enthalten, können nicht ausgetauscht werden!

• Es ist beim dynamischen Binden eines Lademoduls mit der Generierung ALTERNATE-LIBRARIES=YES darauf zu achten, dass tatsächlich nur RTS-Module nachgebunden werden, da bei einem Austausch der Lademodule nur das Lademodul selbst wieder aus dem Speicher entfernt wird. Wenn mit dem Lademodul per Autolink andere Module nachgeladen werden, dann verbleiben diese Module beim Austausch im Speicher, obwohl sich beispielsweise gemeinsame Datenstrukturen geändert haben.

• Für Lademodule, die nur aus C-Code und ggf. Datenobjekten (AREAs) bestehen, ist beim Binden mit der Bibliothek SYSLNK.CRTE.PARTIAL-BIND die Angabe ALTERNATE-LIBRARIES=YES nicht nötig und sollte daher vermieden werden.

LOAD-MODULE

lmodname   [ ,ALTERNATE-LIBRARIES={ NO | YES }  [ ,LIB=libname ]  [ ,LOAD-MODE={ STARTUP |                  ONCALL |                  STATIC |                  (POOL,poolname,{ NO-PRIVATE-SLICE |                                   STARTUP |                                   ONCALL } )                  } ]    ,VERSION={ version | *HIGHEST-EXISTING | *UPPER-LIMIT }

lmodname	Name des Lademoduls. lmodname kann max. 32 Zeichen lang sein. Für die Namensvergabe gelten die gleichen Regeln wie für Elementnamen einer Programm-Bibliothek. Siehe auch Abschnitt „Format der Namen".
ALTERNATE-LIBRARIES=
	Autolink-Funktion beim dynamischen Binden der Privaten Slice des Lademoduls steuern
NO	Es wird kein Autolink beim Binden des Lademoduls durchgeführt. Standard: NO
YES	Die Autolink-Funktion des BLS wird eingeschaltet. Mit dieser Funktion werden u.a. für Lademodule, die beim Austausch weitere RTS-Module benötigen, die sich noch nicht im Speicher befinden, diese RTS-Module nachgebunden. Vor dem Start der UTM-Anwendung müssen die benötigten RTS-Bibliotheken mit Linkname BLSLIBnn (00 <= nn <= 99) belegt werden. Diese Bibliotheken werden dann beim Nachladen der Lademodule, bei offenen Externverweisen, die sich nicht durch geladene Module befriedigen lassen, anhand nn sequenziell aufsteigend nach passenden Definitionen durchsucht. ALTERNATE-LIBRARIES=YES darf nur zum Nachladen von RTS-Modulen und nicht zum Nachladen von Benutzerprogrammen verwendet werden. Zur Autolink-Funktion siehe auch openUTM-Handbuch „Einsatz von UTM-Anwendungen auf BS2000-Systemen“. Die Kombination der Operandenwerte: LOAD-MODE=STATIC / (POOL,poolname,NO-PRIVATE-SLICE) mit ALTERNATE-LIBRARIES=YES ist nicht zulässig und wird beim KDCDEF-Lauf abgelehnt.
LIB=	libname Angabe der Programmbibliothek, aus der das Lademodul nachgeladen werden soll. libname kann max. 54 Zeichen lang sein. Der Operand LIB= ist bei LOAD-MODE=STATIC ohne Bedeutung. In allen anderen Fällen muss dem Operanden LIB= ein Wert zugewiesen werden, entweder in der LOAD-MODULE-Anweisung oder in einer vorhergehenden DEFAULT-Anweisung.
LOAD-MODE=	Lademodus des Lademoduls
STARTUP	Das Lademodul wird beim Start der Anwendung als eigenständige Einheit nachgeladen. Es werden Externverweise aus dem Subsystem, aus dem Klasse-3/4-Speicher und aus allen bereits geladenen Modulen der UTM-Anwendung befriedigt. Für Runtime-Systemfunktionen siehe auch den Operanden ALTERNATE-LIBRARIES=YES. Lademodule, die mit LOAD-MODE=STARTUP generiert werden und TCB-Entries enthalten, dürfen nicht im laufenden Betrieb ausgetauscht werden. Standard: STARTUP
ONCALL	Das Lademodul wird als eigenständige Einheit nachgeladen, wenn ein Teilprogramm oder VORGANG-Exit, das/der dem Lademodul zugeordnet ist, erstmalig aufgerufen wird. Es werden Externverweise aus dem Klasse-3/4-Speicher und aus allen bereits geladenen Modulen der UTM-Anwendung befriedigt. Lademodule, die TCB-Entries enthalten, dürfen nicht mit LOAD-MODE=ONCALL generiert werden. Wird mit mehreren Prozessen gearbeitet, so darf im laufenden Betrieb dieses Lademodul nicht in der Bibliothek LIB=libname überschrieben werden. Es könnten sonst eventuell unterschiedliche Stände des Lademoduls in einem Anwendungslauf zum Ablauf kommen.
STATIC	Das Lademodul muss statisch in das Anwendungsprogramm eingebunden werden.
(POOL,poolname, NO-PRIVATE-SLICE)
	Der Memory Pool wird mit einer MPOOL-Anweisung definiert. poolname kann max. 50 Zeichen lang sein. Das Lademodul wird beim Start der Anwendung in den Common Memory Pool poolname geladen. Es gibt keine Aufteilung des Lademoduls in Public und Private Slices. Es gibt also kein Private Slice, auch nicht statisch im Anwender-Programm eingebunden.
(POOL,poolname, STARTUP)
	Der Public Slice des Lademoduls wird beim Start der Anwendung in den Common Memory Pool poolname geladen. Das zu dem Lademodul gehörige Private Slice wird anschließend in den tasklokalen Speicher geladen.
(POOL,poolname, ONCALL)
	Der Public Slice des Lademoduls wird beim Start der Anwendung in den Common Memory Pool poolname geladen. Das zu dem Lademodul gehörige Private Slice wird in den tasklokalen Speicher geladen, wenn das erste Teilprogramm aufgerufen wird, das diesem Lademodul zugeordnet ist. Es werden Externverweise nur aus dem Klasse-3/4-Speicher, aus den Subsystemen und aus dem eigenen Memory Pool befriedigt.
VERSION=version | *HIGHEST-EXISTING | *UPPER-LIMIT
	Version des Lademoduls. version kann maximal 24 Zeichen lang sein.
*UPPER-LIMIT	VERSION=*UPPER-LIMIT (bzw. VERSION=@) bewirkt, dass BLS in einer PLAM-Bibliothek das Lademodul lmodname anspricht, das als letztes ohne explizite Versionsangabe in diese PLAM-Bibliothek gebracht wurde. Wird bei LMS mit expliziten Versionen gearbeitet, kann @ als Version eines Lademoduls nicht verwendet werden.
*HIGHEST-EXISTING	Bei jedem Start der Anwendung sowie bei jedem Anwendungsaustausch wird die höchste in der Bibliothek vorhandene Version dieses Moduls geladen, d.h.: UTM ermittelt bei der ersten Task (Anwendungsstart) bzw. bei der initiierenden Task (vor Anwendungsaustausch) die aktuell höchste Elementversion für alle Lademodule, die mit VERSION=*HIGHEST-EXISTING generiert sind. Diese Elementversion wird dann auch zum Laden von Modulen verwendet, die erst später geladen werden, z.B. weil sie mit LOAD-MODE=ONCALL generiert sind. Beim Starten von Folge-Tasks einer Anwendung sowie beim Neuladen des Anwendungsprogramms nach einem PEND ER wird die Version dieses Moduls geladen, die bereits von den anderen Tasks der Anwendung geladen ist bzw. in dieser Task vor dem PEND ER geladen war. Für LOAD-MODULE-Anweisungen, die mit LOAD-MODE=STATIC generiert sind, ist die Angabe von VERSION=*HIGHEST-EXISTING nicht erlaubt. Für die Namensvergabe gelten die gleichen Regeln, wie für die Versionen von Elementen einer Programmbibliothek. Mit einer Einschränkung: wenn version das Zeichen „.“ enthält, so muss die Version mit einem Buchstaben beginnen.