Damit Sie Objekte dynamisch in die Konfiguration Ihrer UTM-Anwendung aufnehmen können, müssen Sie bei der Generierung der Anwendung mit KDCDEF die im Folgenden beschriebenen Vorbereitungen treffen.
Für das Löschen von Objekten aus der Konfiguration sind keine Vorbereitungen bei der KDCDEF-Generierung nötig.
Plätze in den Objekttabellen der KDCFILE reservieren
Die Konfigurationsdaten einer UTM-Anwendung werden in den Objekttabellen der KDCFILE abgelegt, die bei der KDCDEF-Generierung der Anwendung erzeugt wird. Bei der KDCDEF-Generierung wird auch der für diese Tabellen zur Verfügung stehende Platz festgelegt. Deshalb müssen Sie für Objekte, die Sie erst im laufenden Betrieb in die Konfiguration der Anwendung aufnehmen wollen, bei der KDCDEF-Generierung leere Tabellenplätze reservieren. Dazu dient die KDCDEF-Anweisung RESERVE (siehe openUTM-Handbuch „Anwendungen generieren“).
In der RESERVE-Anweisung geben Sie an, wieviele leere Tabellenplätze für jeden einzelnen Objekttyp angelegt werden sollen, d.h. Sie geben an, wieviele LTERM-Partner dynamisch eintragbar sein sollen, wieviele Transaktionscodes usw. Die Reservierung der Tabellenplätze erfolgt Objekttyp-spezifisch, d.h. ein Tabellenplatz, den Sie z.B. für einen LTERM-Partner reserviert haben, kann nicht von einem Transaktionscode belegt werden usw.
Während des Anwendungslaufs können Sie genau so viele Objekte eines Typs dynamisch eintragen, wie leere Tabellenplätze mit KDCDEF reserviert wurden. Durch das Löschen eines anderen Objekts vom gleichen Typ wird i. a. kein Tabellenplatz für ein neues Objekt frei. Eine Ausnahme bilden Benutzerkennungen und Verbindungen für die verteilte Verarbeitung über LU6.1 bei stand-alone-Anwendungen. Diese können Sie durch „sofortiges Löschen“ aus der Konfiguration herausnehmen (siehe Abschnitt „Objekte dynamisch aus der Konfiguration löschen"). Die Tabellenplätze dieser Benutzerkennungen bzw. LU6.1-Verbindungen werden dann sofort freigegeben und können durch neue Benutzerkennungen bzw. LU6.1-Verbindungen belegt werden.
Bei der Reservierung der Tabellenplätze mit RESERVE ist Folgendes zu beachten:
Für jeden UPIC-Client und für jede TS-Anwendung (Client vom Typ APPLI oder SOCKET), die Sie dynamisch in die Konfiguration eintragen, erzeugt openUTM intern eine Benutzerkennung. In UTM-Anwendungen, die mit Benutzerkennungen generiert sind (d.h. die KDCDEF-Generierung enthält mindestens eine USER-Anweisung), wird deshalb für jeden dynamisch eingetragenen Client vom Typ APPLI, SOCKET oder UPIC zusätzlich ein reservierter Tabellenplatz für Benutzerkennungen belegt. Diese Tabellenplätze werden beim Löschen der Clients nicht freigegeben. In Anwendungen ohne Benutzerkennungen werden diese Tabellenplätze von openUTM intern reserviert.
Zum Reservieren der Tabellenplätze siehe openUTM-Handbuch „Anwendungen generieren“, Steueranweisung RESERVE.
Lockcodes, BCAMAPPL-Namen und Formatierungssystem generieren
Im KDCDEF-Lauf müssen Sie bereits bestimmte Objekte oder Werte statisch vorgenerieren, wenn Sie diese später bei der dynamischen Konfiguration referenzieren wollen; Beispiele hierfür sind der Wertebereich von Lockcodes und die Namen der Transportsystemzugangspunkte der lokalen Anwendung.
Lockcodes (Zugriffsschutz), die Sie den Transaktionscodes und LTERM-Partnern zuordnen wollen, müssen in dem Bereich zwischen 1 und dem in KEYVALUE (MAX-Anweisung) festgelegten Maximalwert liegen. Deswegen sollten Sie den Wert von KEYVALUE hinreichend groß wählen. Das Lock-/Keycode-Konzept ist ausführlich im openUTM-Handbuch „Konzepte und Funktionen“ beschrieben.
Alle Namen der lokalen Anwendung (BCAMAPPL-Namen), über die die Verbindungen zu Clients oder Druckern aufgebaut werden sollen, müssen mit KDCDEF generiert werden. Denken Sie insbesondere daran, dass für die Anbindung von TS-Anwendungen über die Socket-Schnittstelle oder HTTP-Clients (PTYPE=SOCKET) eigene BCAMAPPL-Namen generiert werden müssen.
Nur auf BS2000-Systemen: Sollen Benutzerkennungen und LTERM-Partnern Startformate zugeordnet werden, dann muss bei der KDCDEF-Generierung ein Formatierungssystem generiert werden (Anweisung FORMSYS). Werden #Formate als Startformate verwendet, dann muss zusätzlich ein Anmelde-Vorgang generiert werden.
Voraussetzungen für das Eintragen von Teilprogrammen und VORGANG-Exits
Neue Teilprogramme und VORGANG-Exits können Sie nur dann dynamisch in die Konfiguration der Anwendung aufnehmen, wenn die Anwendung folgende Voraussetzung erfüllt:
Eine UTM-Anwendung auf BS2000-Systemen muss mit Lademodulen generiert werden (KDCDEF-Generierung mit LOAD-MODULE-Anweisungen). Das Teilprogramm darf jedoch nicht in ein Lademodul gebunden werden, das statisch ins Anwendungsprogramm eingebunden ist (Lademodus STATIC).
Eine UTM-Anwendung auf einem Unix- oder Linux-System muss mit Shared Objects generiert werden (KDCDEF-Generierung mit SHARED-OBJECT-Anweisungen).
Eine UTM-Anwendung auf einem Windows-System muss Windows-DLLs verwenden. Mehr Informationen zur Generierung finden Sie im openUTM-Handbuch „Anwendungen generieren“.
Ein Teilprogramm, das Sie im laufenden Betrieb neu eintragen wollen, muss in ein Lademodul, Shared Object bzw. eine DLL gebunden werden, das/die bei der KDCDEF-Generierung definiert wurde.
Für jede Programmiersprache, in der Sie Teilprogramme Ihrer Anwendung erstellen wollen, muss mindestens ein Teilprogramm mit KDCDEF generiert werden. Nur dann sind die für den Ablauf benötigten Sprachanschlussmodule und Laufzeitsysteme im Anwendungsprogramm enthalten.
Hinweis für BS2000-Systeme:
Für Teilprogramme, die mit ILCS-fähigen Compilern (COMP=ILCS) übersetzt werden, genügt es, wenn Sie bei der KDCDEF-Generierung ein Teilprogramm mit COMP=ILCS generieren. Es müssen keine PROGRAM-Anweisungen für die verschiedenen Programmiersprachen abgesetzt werden.
Für COBOL Programme muss der betreffende LOAD-MODULE mit ALTERNATE-LIBRARIES=YES generiert werden, damit die benötigten RTS-Module per Autolink nachgeladen werden können.
Voraussetzungen für das dynamische Eintragen von Transaktionscodes
Wenn Sie Transaktionscodes dynamisch in die Konfiguration eintragen wollen, müssen Sie Folgendes beachten:
Transaktionscodes für Teilprogramme, die eine X/Open-Programmschnittstelle nutzen, können nur dynamisch erzeugt werden, wenn bei der KDCDEF-Generierung mindestens ein Transaktionscode für ein X/Open-Teilprogramm generiert wurde (TAC-Anweisung mit API
!=KDCS).Wollen Sie die Transaktionscodes in TAC-Klassen einteilen, um die Auftragsbearbeitung steuern zu können, dann müssen Sie bei der KDCDEF-Generierung mindestens eine TAC-Klasse erzeugen.
TAC-Klassen können Sie bei der KDCDEF-Generierung auf drei Arten erzeugen:
Sie generieren einen Transaktionscode, für den Sie im Operanden TACCLASS (TAC-Anweisung) eine TAC-Klasse angeben. Die angegebene TAC-Klasse wird dann von KDCDEF implizit erzeugt.
Wenn Sie die Anwendung ohne Prioritätensteuerung betreiben (die Anwendung enthält keine TAC-PRIORITIES-Anweisung) dann können Sie TAC-Klassen erzeugen, indem Sie eine TACCLASS-Anweisung schreiben.
Sie können implizit TAC-Klassen erzeugen, indem Sie eine TAC-PRORITIES-Anweisung schreiben.
Haben Sie bei der KDCDEF-Generierung eine TAC-Klasse erzeugt, dann können Sie die Transaktionscodes, die Sie dynamisch eintragen, jeder beliebigen TAC-Klasse zwischen 1 und 8 (Dialog) bzw. 9 und 16 (Asynchron) zuordnen. Die TAC-Klassen werden von openUTM implizit erzeugt; sie sind administrierbar.
Ist die Anwendung ohne TAC-PRIORITIES generiert, dann legt openUTM bei implizit erzeugten TAC-Klassen die Prozessanzahl (TASKS) wie folgt fest:
1 für Dialog-TAC-Klassen (Klasse 1 bis 8),
und 0 für Asynchron-TAC-Klassen (Klasse 9 bis 16).Asynchron-TAC-Klassen werden von openUTM jedoch nur erzeugt, wenn Sie bei der KDCDEF-Generierung in der MAX-Anweisung ASYNTASKS > 0 gesetzt haben.
In Anwendungen mit TAC-Klassen ohne Prioritätensteuerung können Sie Transaktionscodes, die Teilprogrammläufe mit blockierenden Aufrufen starten, nur dann dynamisch erzeugen, wenn TAC-Klassen mit PGWT=YES (Dialog- und/oder Asynchron-TAC-Klasse) bei der KDCDEF-Generierung explizit mit TACCLASS-Anweisungen generiert wurden. Zusätzlich muss MAX TASKS-IN-PGWT > 0 gesetzt werden.
In Anwendungen mit Prioritätensteuerung (mit TAC-PRIORITIES-Anweisung) können Sie Transaktionscodes, die Teilprogrammläufe mit blockierenden Aufrufen starten (kc_tac_str.pgwt='Y'), nur dann dynamisch erzeugen, wenn bei der KDCDEF-Generierung MAX TASKS-IN-PGWT>0 gesetzt wurde.
Voraussetzungen für das dynamische Eintragen von Benutzerkennungen
Benutzerkennungen können Sie nur dynamisch in die Konfiguration aufnehmen, wenn Ihre Anwendung mit Benutzerkennungen generiert wird. Dazu muss Ihre KDCDEF-Generierung mindestens eine USER-Anweisung enthalten und mindestens eine Benutzerkennung muss Administrationsberechtigung haben (USER mit PERMIT=ADMIN).
Hinweis für BS2000-Systeme:
Sollen im Betrieb auch neue Benutzerkennungen mit Ausweiskarte in die Konfiguration eingetragen werden, dann müssen Sie dies beim Reservieren explizit angeben. Dazu geben Sie in der RESERVE-Anweisung an, wieviel Prozent der Tabellenplätze, die für Benutzerkennungen angelegt werden, von Benutzerkennungen mit Ausweiskarte belegt werden können (Operand CARDS in der RESERVE-Anweisung).
Sollen im Betrieb auch Benutzerkennungen mit Kerberos-Authentisierung dynamisch erzeugt werden, müssen diese mit dem Operanden PRINCIPALS der RESERVE-Anweisung reserviert werden.