kc_load_module_str - Lademodule (BS2000-Systeme) bzw. Shared Objects/DLLs (Unix-, Linux- und Windows-Systeme)

Für den Objekttyp KC_LOAD_MODULE ist die Datenstruktur kc_load_module_str definiert. In kc_load_module_str liefert UTM bei KC_GET_OBJECT Folgendes zurück:

• BS2000-Systeme:Informationen über die Lademodule, die mit der KDCDEF-Steueranweisung LOAD-MODULE generiert wurden.

• Unix-, Linux- und Windows-Systeme: Informationen über die Shared Objects oder DLLs, die mit der KDCDEF-Steueranweisung SHARED-OBJECT generiert wurden.

Mit einem KDCADMI-Aufruf mit Operationscode KC_MODIFY_OBJECT und Objekttyp KC_LOAD_MODULE können Sie einzelne Lademodule, bzw. Shared Objects oder DLLs während des Anwendungslaufs austauschen.

mod1	Datenstruktur kc_load_module_str
-	char lm_name[32];
x(GID)	char version[24];
-	char lib[54];
-	char load_mode;
-	char poolname[50]; (nur auf BS2000-Systemen)
-	char version_prev[24];
-	char changeable;
-	char change_necessary; (nur auf BS2000-Systemen)
-	char altlib; (nur auf BS2000-Systemen)
-	char version_gen[24];

¹ Feldinhalt mit KC_MODIFY_OBJECT modifizierbar; siehe im Abschnitt "obj_type=KC_LOAD_MODULE"

lm_name
	enthält den Namen des Lademoduls, Shared Objects bzw. DLLs.
version
	in version liefert UTM die Versionsnummer des Lademoduls, Shared Objects bzw. DLLs zurück, die zur Zeit geladen ist oder geladen wird. Konnte das Lademodul in der Bibliothek nicht gefunden werden, dann ist version mit Leerzeichen belegt. Nur auf BS2000-Systemen: *HIGHEST-EXISTING Bei KC_MODIFY_OBJECT wird die höchste in der Bibliothek vorhandene Version geladen. *UPPER-LIMIT (bzw. @) Bei KC_MODIFY_OBJECT wird das Lademodul geladen, das als letztes ohne explizite Versionsangabe in die PLAM-Bibliothek gebracht wurde.
lib	der Inhalt von lib hat folgende Bedeutung: In UTM-Anwendungen auf BS2000-Systemen liefert UTM in lib die Programmbibliothek zurück, aus der das Lademodul nachgeladen wird. In UTM-Anwendungen auf Unix-, Linux- und Windows-Systemen enthält lib das Dateiverzeichnis, in dem das Shared Object/DLL abgelegt ist.
load_mode
	enthält den Lademodus des Lademoduls, Shared Objects bzw. DLLs. Der Lademodus gibt an, wann und wohin ein Lademodul/Shared Object/DLL geladen wird.
	'U'	(STARTUP) Das Lademodul/Shared Object/DLL wird beim Start der Anwendung als eigenständige Einheit nachgeladen. Nur auf BS2000-Systemen: Beim Nachladen eines Lademoduls werden Externverweise aus allen bereits geladenen Modulen der UTM-Anwendung, aus allen nicht privilegierten Subsystemen und aus dem Klasse-4-Speicher befriedigt.
	'O'	(ONCALL) Das Lademodul/Shared Object/DLL wird als eigenständige Einheit nachgeladen, wenn eines seiner Teilprogramme oder seiner VORGANG-Exits erstmalig aufgerufen wird. Nur auf BS2000-Systemen: Beim Nachladen eines Lademoduls werden Externverweise aus allen bereits geladenen Modulen der UTM-Anwendung, aus allen nicht privilegierten Subsystemen und aus dem Klasse-4-Speicher befriedigt. Wird mit mehreren Prozessen gearbeitet, so darf während des Anwendungslaufs dieses Lademodul in der Bibliothek (LIB=...) nicht überschrieben werden. Es könnten sonst eventuell unterschiedliche Stände des Lademoduls in einem Anwendungslauf zum Ablauf kommen.
	'S'	(STATIC, nur auf BS2000-Systemen) Das Lademodul ist statisch in das Anwendungsprogramm eingebunden. Das Lademodul kann nicht während eines Anwendungslaufs ausgetauscht werden.
	'P'	(POOL, nur auf BS2000-Systemen) Das Lademodul wird beim Start der Anwendung in einen Common Memory Pool (siehe poolname) geladen. Das Lademodul besteht nur aus einer public Slice (keine private Slice).
	'T'	(POOL/STARTUP, nur auf BS2000-Systemen) Die public Slice des Lademoduls wird beim Start der Anwendung in einen Common Memory Pool (siehe poolname) geladen. Die zu dem Lademodul gehörige private Slice wird anschließend in den prozesslokalen Speicher geladen (private Slice mit Lademodus STARTUP).
	'C'	(POOL/ONCALL, nur auf BS2000-Systemen) Die public Slice des Lademoduls wird beim Start der Anwendung in einen Common Memory Pool (siehe poolname) geladen. Die zu dem Lademodul gehörige private Slice wird in den prozesslokalen Speicher geladen, wenn das erste Teilprogramm aufgerufen wird, das diesem Lademodul zugeordnet ist (private Slice mit Lademodus ONCALL).
poolname (nur auf BS2000-Systemen
	wird nur versorgt, wenn das Lademodul bzw. seine public Slice in einen Common Memory Pool geladen werden (load_mode='P', 'T' oder 'C'). poolname enthält dann den Namen des Common Memory Pools. Der Name kann bis zu 50 Zeichen lang sein.
version_prev
	enthält die Vorgängerversion des Lademoduls/Shared Objects/DLLs, d.h. die Version, die vor dem letzten Programmaustausch geladen war. Wurde das Lademodul/Shared Object/DLL noch nicht ausgetauscht bzw. ist es nicht austauschbar, dann ist version_prev mit Leerzeichen belegt.
changeable
	gibt an, ob das Lademodul/Shared Object/DLL ausgetauscht werden kann.
	'Y'	Das Lademodul/Shared Object/DLL kann während des Anwendungslaufs ausgetauscht werden.
	'N'	Das Lademodul/Shared Object/DLL kann nicht während des Anwendungslaufs ausgetauscht werden.
change_ necessary (nur auf BS2000-Systemen)
	ist nur relevant bei Lademodulen, die entweder ganz in einem Common Memory Pool liegen oder deren public Slice im Common Memory Pool liegt. change_necessary gibt an, ob dieses Lademodul für einen Programmaustausch vorgemerkt wurde. Lademodule im Common Memory Pool müssen zunächst mit KC_MODIFY_OBJECT für den Programmaustausch vorgemerkt werden. Danach muss mit KC_CHANGE_APPLICATION der eigentliche Austausch durchgeführt werden.
	'Y'	Das Lademodul ist für einen Austausch vorgemerkt. Ein Programmaustausch mit KC_CHANGE_APPLICATION ist nötig, um das Lademodul auszutauschen.
	'N'	Das Lademodul ist nicht für einen Austausch vorgemerkt.
altlib (nur auf BS2000-Systemen)
	gibt an, ob das Lademodul mit der Autolink-Funktion des BLS geladen wird.
	'Y'	Laden mit Autolink
	'N'	Laden ohne Autolink
version_gen
	enthält die Version, mit der das Lademodul/Shared Object/DLL generiert wurde.