Voraussetzungen für das dynamische Eintragen von Objekten

Dieser Abschnitt beschreibt, welche Objekte Sie statisch vorgenerieren müssen und welche Voraussetzungen erfüllt sein müssen, damit Sie Teilprogramme und VORGANG-Exits, Transaktionscodes, Benutzerkennungen sowie LU6.1-Verbindungen dynamisch eintragen können.

Beachten Sie bitte, dass die statisch generierten Grenzwerte auch für dynamisch erzeugte Objekte gelten, z.B. gilt für dynamisch erzeugte Keysets der in MAX ...,KEYVALUE= definierte Wert.

Lockcodes, BCAMAPPL-Namen, Formatierungssystem und LPAP-Partner generieren

In KDCDEF müssen folgende Objekte statisch generiert werden:

• Lockcodes, die Sie den Transaktionscodes und LTERM-Partnern als Zugriffsschutz zuordnen wollen, müssen in dem Bereich zwischen 1 und dem mit MAX ...,KEYVALUE=number festgelegten Maximalwert liegen.

  Das Lock-/Keycode-Konzept wird 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 (PTYPE=SOCKET) eigene BCAMAPPL-Namen generiert werden müssen.

• BS2000-Systeme:

  Sollen Benutzerkennungen und LTERM-Partnern Startformate zugeordnet werden, dann muss bei der KDCDEF-Generierung mit der Anweisung FORMSYS ein Formatierungssystem generiert werden. Werden #Formate als Startformate verwendet, dann muss zusätzlich ein Anmelde-Vorgang generiert werden.

• Falls Sie LU6.1-Verbindungen oder Sessionnamen dynamisch eintragen möchten, dann müssen die LPAP-Partner sowie die Sessioneigenschaften (SESCHA-Anweisung) statisch generiert sein.

Voraussetzungen für Teilprogramme und VORGANG-Exits

Neue Teilprogramme und VORGANG-Exits können Sie nur dann dynamisch in die Konfiguration der Anwendung aufnehmen, wenn die UTM-Anwendung folgende Bedingung erfüllt:

• BS2000-Systeme:

  Die Anwendung wurde mit Lademodulen generiert (KDCDEF-Generierung mit LOAD-MODULE-Anweisungen) und zum Binden und Laden des Anwendungsprogramms wird die Funktionalität des BLS genutzt.

  Das neue Teilprogramm muss in ein Lademodul gebunden werden, das bei der KDCDEF-Generierung definiert wurde. Dieses Lademodul darf nicht statisch ins Anwendungsprogramm eingebunden sein (LOAD-MODE=STATIC), weil ein solches Lademodul nicht dynamisch ausgetauscht werden kann.

• Unix-, Linux- und Windows-Systeme:

  Die Anwendung wurde mit Shared Objects bzw. DLLs generiert (KDCDEF-Generierung mit SHARED-OBJECTS-Anweisungen).
  Das neue Teilprogramm muss in ein Shared Object bzw. DLL gebunden werden, das 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.

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.

Voraussetzungen für Transaktionscodes

Für die dynamische Konfigurierung von Transaktionscodes 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 konfiguriert 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. Dazu gibt es zwei Möglichkeiten:

  • Sie generieren einen Transaktionscode, für den Sie im Operanden TACCLASS (TAC-Anweisung) eine TAC-Klasse angeben, die daraufhin von KDCDEF implizit erzeugt wird.

  • 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.

  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 16 zuordnen. Die TAC-Klassen werden dann von openUTM implizit erzeugt. Diese TAC-Klassen 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 (9 bis 16) werden von openUTM jedoch nur erzeugt, wenn Sie bei der 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) statisch generiert wurden.
  Dialog- und Asynchron-TAC-Klassen mit PGWT=YES müssen also bei der KDCDEF-Generierung explizit mit TACCLASS-Anweisungen generiert werden. 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 (TAC ...,PGWT=YES), nur dann dynamisch erzeugen, wenn bei der KDCDEF-Generierung MAX TASKS-IN-PGWT>0 gesetzt wurde.

Voraussetzungen für Benutzerkennungen

Benutzerkennungen können Sie nur dynamisch eintragen, wenn Ihre Anwendung mit Benutzerkennungen generiert wird. Dazu muss Ihre KDCDEF-Generierung mindestens eine USER-Anweisung enthalten. Mindestens eine Benutzerkennung muss mit Administrationsberechtigung konfiguriert werden, damit die Aufrufe zur dynamischen Administration von dieser Benutzerkennung ausgeführt werden können.

BS2000-Systeme:

Sollen im Betrieb auch Benutzerkennungen mit Ausweiskarte konfigurierbar sein, dann müssen Sie beim Reservieren der Tabellenplätze mit der RESERVE-Anweisung explizit angeben, wieviel Prozent der Tabellenplätze für Benutzerkennungen mit Ausweiskarte belegt werden können.

Für Benutzerkennungen mit Ausweiskarte muss bei der KDCDEF-Generierung mit der MAX-Anweisung die Länge der Ausweisinformation statisch generiert werden:
MAX...,CARDLTH=length