KDCPROG - Lademodule/Shared Objects/DLLs austauschen

Mit KDCPROG können Sie Lademodule einer UTM-Anwendung unter einem BS2000-System mit Hilfe der BLS-Schnittstelle austauschen bzw. Shared Objects einer UTM-Anwendung auf Unix- und Linux-Systemen, wenn Sie mit der Funktion „Programmaustausch mit Shared Objects“ arbeiten. Sehen Sie dazu auch das openUTM-Handbuch „Anwendungen generieren“ sowie das betreffende openUTM-Handbuch „Einsatz von UTM-Anwendungen“.

Auf Windows-Systemen werden Shared Objects mit Hilfe von DLLs realisiert. Besonderheiten zu deren Handhabung sind im openUTM-Handbuch „Einsatz von UTM-Anwendungen auf Unix-, Linux- und Windows-Systemen“ beschrieben.

Voraussetzungen für den Programmaustausch mit KDCPROG

Sie können Teile eines Anwendungsprogramms austauschen bzw. nachladen, die die folgenden Bedingungen erfüllen:

• Die Programmteile, die ausgetauscht werden sollen, wurden als eigenständige Lademodule/Shared Objects/DLLs generiert.

• Jedes auszutauschende Lademodul bzw. Shared Object/DLL wurde mit einer LOAD-MODULE-Anweisung (BS2000-Systeme) bzw. SHARED-OBJECT-Anweisung (Unix-, Linux- und Windows-Systeme) statisch generiert.

• Die Lademodule/Shared Objects/DLLs wurden nicht statisch zum Anwendungsprogramm hinzugebunden.

• Auf BS2000-Systemen wurden die Lademodule , die ausgetauscht werden sollen, weder in den Systemspeicher (Klasse-4-Speicher) noch in einen Anwendungsglobalen Common Memory Pool (generiert mit SCOPE=GLOBAL) geladen.

Damit openUTM das Kommando bearbeiten kann, muss ein Lademodul, Shared Object bzw. DLL mit dem angegebenen Namen und der Version version in der Programmbibliothek bzw. im Directory vorhanden sein, die/das ihm durch die KDCDEF-Generierung zugeordnet wurde:

• LOAD-MODULE-Anweisung, Operand LIB (BS2000-Systeme) bzw.

• SHARED-OBJECT-Anweisung, Operand DIRECTORY (Unix-, Linux- und Windows-Systeme).

BS2000-Systeme

Ist in der Programmbibliothek kein Lademodul mit angegebenem Namen und Version vorhanden, dann wird das Administrationskommando abgewiesen und das bisher geladene Lademodul bleibt geladen. Zusätzlich wird die Meldung K234 ausgegeben.

Unix-, Linux- und Windows-Systeme

Ist im angegebenen Directory kein Shared Object/DLL mit der Version version vorhanden, so wird nur das bisher geladene Shared Object/DLL entladen und eine Meldung ausgegeben.

Durch einen erneuten Aufruf von KDCPROG können Sie dann das Lademodul bzw. Shared Object/DLL laden, indem Sie für version eine in der Bibliothek vorhandene Version des Lademoduls/Shared Objects angeben oder das fehlende Lademodul bzw. Shared Object/DLL mit der angegebenen Version in die Programmbibliothek/Programmdateiverzeichnis stellen.

Ablauf des Programmaustausches

Wie der Programmaustausch durchgeführt wird, ist abhängig vom generierten Lademodus des Lademoduls/Shared Objects/DLL.

Den Lademodus generieren Sie in der LOAD-MODULE-Anweisung (BS2000-Systeme) bzw. in der SHARED-OBJECT-Anweisung (Unix-, Linux- und Windows-Systeme) jeweils im Operanden LOAD-MODE.

• LOAD-MODE=STARTUP
  (das Lademodul/Shared Object/DLL wird beim Start der Anwendung als eigenständige Einheit geladen)
  Der Austausch wird für jeden Prozess spätestens nach der Bearbeitung des nächsten Auftrags ausgeführt, ohne dass das laufende Anwendungsprogramm beendet wird. Mehrere Prozesse der Anwendung können gleichzeitig austauschen. Bis der Programmaustausch von allen Prozessen der Anwendung abgeschlossen wurde, dürfen Sie keinen weiteren Austausch mit KDCPROG veranlassen.

  Der Programmaustausch wird durch den Aufruf von KDCPROG nur veranlasst. Der eigentliche Programmaustausch kann sich über einen längeren Zeitraum erstrecken. openUTM informiert mit Meldungen auf SYSOUT und SYSLOG (BS2000-Systeme) bzw. stdout und stderr (Unix-, Linux- und Windows-Systeme) über Erfolg oder Misserfolg des Programmaustausches.

• LOAD-MODE=ONCALL
  (wird geladen, wenn ein Teilprogramm aus dem Lademodul/Shared Object/DLL erstmals aufgerufen wird)
  Der Austausch wird für jeden Prozess erst dann durchgeführt, wenn das nächste Mal in diesem Prozess ein Teilprogramm aus diesem Lademodul/Shared Object aufgerufen wird. Zu einer Zeit können Sie mehrere Prozesse der Anwendung gleichzeitig austauschen.

• LOAD-MODE=(POOL, POOL/STARTUP, POOL/ONCALL, nur auf BS2000-Systemen) (die Public Slice des Lademoduls wird in einen Common Memory Pool geladen)
  In diesem Fall wird durch den Aufruf von KDCPROG der Programmaustausch nicht angestoßen. KDCPROG bewirkt nur ein Vormerken der neuen Version. Erst beim folgenden Austausch des gesamten Anwendungsprogramms mit KDCAPPL PROG=NEW wird die neue Version des Lademoduls in den Common Memory Pool geladen.
  In diesem Fall kann unmittelbar nach dem Aufruf von KDCPROG ein weiterer KDCPROG-Aufruf folgen.
  Sie können durch mehrere KDCPROG-Aufrufe mehrere Lademodule vormerken, die dann beim folgenden KDCAPPL PROG=NEW ausgetauscht werden. Folgt im selben Anwendungslauf kein KDCAPPL PROG=NEW, dann werden die vorgemerkten Versionen beim folgenden Anwendungsstart ausgetauscht.

Wirkung in UTM-Cluster-Anwendungen auf Unix-, Linux- und Windows-Systemen:

KDCPROG wirkt in UTM-Cluster-Anwendungen Cluster-global. Ein Programmaustausch wird in allen laufenden Knoten-Anwendungen durchgeführt.

Wirkungsdauer des Programmaustausches

Die Änderung wirkt über das Ende der Anwendung hinaus.

---

KDCPROG     VERSION={ version | *HIGHEST-EXISTING | *UPPER-LIMIT }

                        BS2000-Systeme:

            , LOAD-MODULE=lmodname

                        Unix-, Linux- und Windows-Systeme:

            , SHARED-OBJECT=shared-object-name

---

Für die Administration über Message Queuing müssen Sie KDCPROGA angeben.

VERSION=version
	Version des Lademoduls/Shared Objects/DLL, die geladen werden soll. Der Wert von version darf maximal 24 Zeichen lang sein. BS2000-Systeme In UTM-Anwendungen auf BS2000-Systemen müssen Sie die zu ladende Version des Lademoduls immer angeben. Für Lademodule, die mit LOAD-MODE=STARTUP generiert sind, dürfen die Versionsnummern von altem und neuem Lademodul übereinstimmen. Für Lademodule, die mit LOAD-MODE=ONCALL generiert sind oder die ganz oder teilweise in einem Common Memory Pool liegen, muss sich die neue Versionsnummer von der alten Versionsnummer unterscheiden. Beim Anstoßen des Austausches muss in der Bibliothek, die dem Lademodul bei der KDCDEF-Generierung zugeordnet wurde (siehe auch KDCDEF-Anweisung LOAD-MODULE...,LIB=), ein Element mit dem Namen lmodname und der in version angegebenen Version vorhanden sein. Wird VERSION=*HIGHEST-EXISTING angegeben, dann wird die höchste in der Bibliothek vorhandene Version dieses Moduls ermittelt und geladen. Wird VERSION=@ bzw. *UPPER-LIMIT angegeben, dann wird das Lademodul geladen, das als letztes ohne explizite Versionsangabe in diese PLAM-Bibliothek gebracht wurde. Wird bei LMS mit expliziten Versionen gearbeitet, kann @ bzw. *UPPER-LIMIT als Version eines Lademoduls nicht verwendet werden. Ist ein Lademodul mit LOAD-MODE=POOL, (POOL,STARTUP) oder (POOL,ONCALL) sowie mit Version *HIGHEST-EXISTING generiert, dann darf bei Version nur *HIGHEST-EXISTING angegeben werden. Ein solcher Modul kann nur über einen Anwendungsaustausch neu geladen werden; dabei wird für einen so generierten Modul immer die höchste verfügbare Version geladen. Sie können keine Lademodule austauschen, die statisch zum Anwendungsprogramm gebunden wurden (Lademodus STATIC). Lademodule mit Lademodus STARTUP, die TCB-Entries enthalten, dürfen ebenfalls nicht ausgetauscht werden. Unix-, Linux- und Windows-Systeme In UTM-Anwendungen auf Unix-, Linux- und Windows-Systemen müssen Sie die Version angeben, wenn das Shared Object mit Lademodus ONCALL generiert ist. Bei Shared Objects/DLLs mit Lademodus STARTUP ist die Angabe der Version optional, wenn Sie das Versionskonzept nicht nutzen.
LOAD-MODULE=lmodname (nur auf BS2000-Systemen)
	Name des Lademoduls, das ausgetauscht werden soll. Dies kann der Name eines OM oder eines LLM sein. Das Lademodul muss (mit diesem Namen) bei der KDCDEF-Generierung mit einer LOAD-MODULE-Anweisung konfiguriert worden sein. Sie dürfen pro Aufruf von KDCPROG nur einen Namen angeben. Der Name darf maximal 32 Zeichen lang sein.
SHARED-OBJECT=shared-object-name (nur auf Unix-, Linux- und Windows-Systemen)
	Name des Shared Objects/DLL, das ausgetauscht werden soll. Der Name muss mit einer SHARED-OBJECT-Anweisung generiert worden sein. Sie dürfen pro Aufruf von KDCPROG nur einen Namen angeben. Der Name darf maximal 32 Zeichen lang sein.

Ausgabe von KDCPROG

Nach dem Absetzen eines KDCPROG-Aufrufs werden am Administrator-Terminal folgende Informationen ausgegeben:

Ausgabe für UTM-Anwendungen auf BS2000-Systemen

LOAD-MODULE         lmodname
VERSION (GENERATED) generated element version
VERSION (PREVIOUS)  old element version
VERSION (CURRENT)   new element version
LIBRARY             name of program library
LOAD MODE           STARTUP | ONCALL | POOL | POOL/STARTUP | POOL/ONCALL

 
Ausgabe für UTM-Anwendung auf Unix-, Linux- und Windows-Systemen

SHARED-OBJECT       shared object name
VERSION (PREVIOUS)  old  version
VERSION (CURRENT)   new  version
DIRECTORY           name of program directory
LOAD MODE           STARTUP | ONCALL 

 
Erläuterungen zur Ausgabe

LOAD-MODULE
	Name des Lademoduls auf BS2000-Systemen
SHARED-OBJECT
	Name des Shared Objects/DLL auf Unix-, Linux- und Windows-Systemen
VERSION (GENERATED)
	generierte Version des Lademoduls auf BS2000-Systemen
VERSION (PREVIOUS)
	bisher geladene Version des Lademoduls/Shared Objects/DLL
VERSION (CURRENT)
	Version des Lademoduls/Shared Objects/DLL, das geladen werden soll
LIBRARY	Name der Programmbibliothek, aus der das Lademodul (BS2000-Systeme) geladen wird.
DIRECTORY	Name des Verzeichnisses, aus dem das Shared Object/DLL (Unix-, Linux- und Windows-Systeme) nachgeladen wird
LOAD MODE	Lademodus des Lademoduls/Shared Objects/DLL: STARTUP Das Lademodul/Shared Object/DLL wird beim Start der Anwendung als eigenständige Einheit geladen. ONCALL Das Lademodul/Shared Object/DLL wird geladen, wenn ein Teilprogramm aus dem Lademodul erstmals aufgerufen wird. Nur auf BS2000-Systemen: POOL Das Lademodul wird beim Start der Anwendung in den Common Memory Pool geladen. Das Lademodul enthält keine Private Slice. POOL/STARTUP Die Public Slice des Lademoduls wird beim Start der Anwendung in den Common Memory Pool geladen. Die zu dem Lademodul gehörende Private Slice wird anschließend in den prozesslokalen Speicher geladen. POOL/ONCALL Die Public Slice des Lademoduls wird beim Start der Anwendung in den Common Memory Pool geladen. Die zu dem Lademodul gehörende Private Slice wird anschließend in den prozesslokalen Speicher geladen, wenn das erste Teilprogramm aufgerufen wird, das diesem Lademodul zugeordnet ist

 
Meldungen zum Programmaustausch mit KDCPROG

Wenn der Austausch von Anwendungsteilen, die mit einem Lademodus von STARTUP (bei BS2000-Systemen auch POOL) generiert wurden, abgeschlossen ist, wird folgende Meldung nach SYSOUT und SYSLOG (BS2000-Systeme) bzw. stdout und stderr (Unix-, Linux- und Windows-Systeme) ausgegeben:

K074 Programmaustausch abgeschlossen;..

Wenn beim Austausch von Anwendungsteilen, die mit Lademodus STARTUP (bei BS2000-Systemen auch POOL) generiert wurden, Fehler auftreten, wird folgende Meldung nach SYSLST und SYSLOG (BS2000-Systeme) bzw. stdout und stderr (Unix-, Linux- und Windows-Systeme) ausgegeben:

K075 Programmaustausch von Task/Prozess .. abgebrochen ...

Treten auf BS2000-Systemen beim Austausch Fehler auf, dann wird für jeden Prozess die Meldung K078 mit der Fehlerursache nach SYSOUT ausgegeben.