Mit KC_CREATE_OBJECT können Sie folgende Objekte dynamisch in die Konfiguration der Anwendung eintragen:
Transportverbindungen zu entfernten LU6.1-Anwendungen (KC_CON)
Keysets (KC_KSET)
LU6.1-Sessions (KC_LSES)
Transaktionscodes, über die Service-Programme in Partner-Anwendungen gestartet werden (KC_LTAC)
LTERM-Partner zum Anschluss von Clients und Druckern (KC_LTERM)
Anwenderteilprogramme und VORGANG-Exits (KC_PROGRAM)
Clients und Drucker (KC_PTERM)
Transaktionscodes und TAC-Queues (KC_TAC)
Benutzerkennungen einschließlich ihrer Queues (KC_USER)
openUTM auf Windows-Systemen unterstützt keine Drucker.
Pro KC_CREATE_OBJECT-Aufruf kann genau ein Objekt erzeugt werden. Innerhalb eines Teilprogramms kann KC_CREATE_OBJECT jedoch mehrmals aufgerufen werden, d.h. es können mehrere Objekte gleichen oder verschiedenen Objekttyps erzeugt werden.
Detaillierte Angaben zum dynamischen Eintragen von Objekten in die Konfiguration finden Sie im Kapitel „Konfiguration dynamisch ändern".
Wenn bei UTM-Cluster-Anwendungen (Unix-, Linux- und Windows-Systeme) ein dynamisch erzeugbares Objekt gelöscht werden soll, müssen Sie dies grundsätzlich per Administration löschen. Diese Objekte können nicht durch eine Neugenerierung allein gelöscht werden.
Voraussetzungen für das dynamische Eintragen eines Objektes:
Bei der KDCDEF-Generierung der UTM-Anwendung wurden mit RESERVE Tabellenplätze für den Objekttyp des Objektes reserviert und einer dieser Tabellenplätze ist noch nicht belegt. Mit KC_GET_OBJECT und Parametertyp KC_DYN_PAR können Sie ermitteln, ob noch Tabellenplätze für den entsprechenden Objekttyp frei sind.
Anwenderteilprogramme und VORGANG-Exits können Sie nur dynamisch eintragen, wenn die Anwendung mit Lademodulen (BS2000-Systeme) bzw. Shared Objects/DLLs (Unix-, Linux- und Windows-Systeme) generiert wurde. Das Teilprogramm bzw. der VORGANG-Exit muss mit einem Compiler erzeugt werden, für den bei der KDCDEF-Generierung bereits ein Teilprogramm statisch konfiguriert worden ist (PROGRAM-Anweisung).
Nur auf BS2000-Systemen: Bei ILCS-fähigen Compilern genügt die statische Generierung eines Teilprogramms mit COMP=ILCS.
Transaktionscodes für Teilprogramme, die eine X/Open-Programmschnittstelle nutzen, können nur dynamisch eingetragen werden, wenn bei der KDCDEF-Generierung mindestens ein Transaktionscode für ein X/Open Teilprogramm konfiguriert wurde.
Benutzerkennungen können nur dynamisch konfiguriert werden, wenn die Anwendung mit Benutzerkennungen generiert ist.
Hinweis für BS2000-Systeme:
Benutzerkennungen mit Ausweiskarte können Sie nur dynamisch eintragen, wenn bei der KDCDEF-Generierung explizit Tabellenplätze für Benutzerkennungen mit Ausweiskarte reserviert worden sind und noch einer dieser Plätze frei ist.
Benutzerkennungen mit Kerberos-Authentisierung können Sie nur dynamisch eintragen, wenn bei der KDCDEF-Generierung explizit Tabellenplätze für Benutzerkennungen mit Kerberos-Authentisierung reserviert worden sind und noch einer dieser Plätze frei ist.
Beim Eintragen neuer Objekte ist Folgendes zu beachten:
Beim Eintragen von Objekten, die miteinander in Beziehung stehen, müssen bestimmte Regeln eingehalten werden. Diese Regeln sind im Kapitel „Konfiguration dynamisch ändern" beschrieben. In Beziehung zueinander stehen beispielsweise:
Transaktionscodes zu den ihnen zugeordneten Teilprogrammen und VORGANG-Exits,
Clients/Drucker zu den zugehörigen LTERM-Partnern und den Verbindungs-Benutzerkennungen bzw. den Benutzerkennungen für das automatische KDCSIGN,
Keysets, die von Benutzerkennungen, LTERM-Partnern und Transaktionscodes referenziert werden.
Ablauf / Wirkungsdauer / Transaktionssicherung / Cluster
Der Aufruf unterliegt der Transaktionssicherung. Auf ein dynamisch erzeugtes Objekt kann vor dem Transaktionsende nur innerhalb der eigenen Transaktion zugegriffen werden. Der Anwendungs-weite Zugriff ist erst nach Abschluss der Transaktion möglich. Insbesondere ist die Administration des Objektes erst nach Transaktionsende möglich (auch die Abfrage von Informationen). Innerhalb derselben Transaktion kann auf das Objekt nur beim Eintragen weiterer Objekte zugegriffen werden, die mit ihm in Beziehung stehen.
Der Aufruf wirkt über das Ende des aktuellen Anwendungslaufs hinaus. D.h. die dynamisch eingetragenen Objekte sind auch in folgenden Anwendungsläufen Bestandteil der Konfiguration (sofern sie nicht wieder gelöscht werden).
In UTM-Cluster-Anwendungen gilt (Unix-, Linux- und Windows-Systeme):
Der Aufruf wirkt Cluster-global, d.h. in allen Knoten-Anwendungen werden die Objekte dynamisch in die Konfiguration eingetragen.
Versorgung der zu übergebenden Bereiche
Funktion des Aufrufs | Angabe im | |||
Parameterbereich1 | Identifikations- | Selektions- | Datenbereich | |
Transportverbindungen zur entfernten LU6.1-Anwendung in die Konfiguration aufnehmen | obj_type: | —— | —— | Datenstruktur kc_con_str mit Namen und Eigenschaften des Partners und der Verbindung |
Keyset in die Konfiguration aufnehmen | obj_type: | —— | —— | Datenstruktur kc_kset_str mit Namen und Eigenschaften des Keysets |
LU6.1-Session in die Konfiguration aufnehmen | obj_type: | —— | —— | Datenstruktur kc_lses_str mit Namen und Eigenschaften der beteiligten Partner |
Transaktionscode, über den Service-Programme in Partner-Anwendungen gestartet werden, in die Konfiguration aufnehmen | obj_type:
| —— | —— | Datenstruktur kc_ltac_str mit Namen und Eigenschaften des LTACs und des Partners |
LTERM-Partner in die Konfiguration aufnehmen | obj_type: | —— | —— | Datenstruktur kc_lterm_str mit Namen und Eigenschaften des LTERM-Partners |
Teilprogramm oder VORGANG-Exit in die Konfiguration aufnehmen | obj_type: | —— | —— | Datenstruktur kc_program_str mit Namen und Eigenschaften des Teilprogramms bzw. VORGANG-Exits |
Client/Drucker (PTERM) in die Konfiguration aufnehmen | obj_type: | —— | —— | Datenstruktur kc_pterm_str mit Namen und Eigenschaften des Client/Druckers |
Transaktionscode oder TAC-Queue in die Konfiguration aufnehmen | obj_type: | —— | —— | Datenstruktur kc_tac_str mit Namen und Eigenschaften des Transaktionscodes bzw. der TAC-Queue |
Benutzerkennung (einschließlich Queue) in die Konfiguration aufnehmen | obj_type: | —— | —— | Datenstruktur kc_user_str mit Namen und Eigenschaften der Benutzerkennung und Queue |
1 | In allen Fällen muss im Parameterbereich der Operationscode KC_CREATE_OBJECT angegeben werden. |
Versorgung der Parameter | |
Parameterbereich | |
Feldname | Inhalt |
version | KC_ADMI_VERSION_1 |
retcode | KC_RC_NIL |
version_data | KC_VERSION_DATA_11 |
opcode | KC_CREATE_OBJECT |
Objekttyp | |
1 | |
id_lth | 0 |
select_lth | 0 |
Länge der Daten im Datenbereich | |
Identifikationsbereich | |
— | |
Selektionsbereich | |
— | |
Datenstruktur des Objekttyps | |
KDCADMI-Aufruf |
KDCADMI (¶meter_area, NULL, NULL, &data_area) |
Rückgaben von UTM | |
Parameterbereich | |
Feldname | Inhalt |
Returncodes | |
obj_type | Im Feld obj_type müssen Sie den Typ des Objektes angeben, das erzeugt werden soll. Folgende Objekttypen können Sie angeben: | |
obj_number | Pro Aufruf kann nur ein Objekt erzeugt werden, deshalb ist obj_number=1 zu setzen. | |
data_lth | Im Feld data_lth geben Sie die Länge der Datenstruktur an, die Sie im Datenbereich an UTM übergeben. | |
Datenbereich | Im Datenbereich müssen Sie eine Datenstruktur mit dem Namen des neuen Objektes und den Eigenschaften übergeben, die diesem Objekt zugeordnet werden sollen. Für jeden einzelnen Objekttyp steht eine eigene Datenstruktur zur Verfügung, die Sie über den Datenbereich legen müssen. | |
In den folgenden Tabellen ab Abschnitt "obj_type = KC_CON" sind die Datenstrukturen abhängig vom Objekttyp des zu erzeugenden Objektes beschrieben. Sie können den Tabellen entnehmen, welche Felder in der jeweiligen Datenstruktur zu versorgen sind. In den Tabellen bedeutet die Auszeichnung in der 1. Spalte Folgendes: | ||
o | Versorgung des Feldes ist optional | |
m | die Versorgung des Feldes ist Pflicht (mandatory) | |
(m) | abhängig von den Angaben, die Sie für andere Pflichtparameter gemacht haben, oder vom Betriebssystem, in dem die UTM-Anwendung abläuft, kann die Versorgung des Feldes Pflicht sein | |
Felder der Datenstrukturen, die Sie nicht explizit versorgen, müssen mit binär null vorbesetzt werden. Für diese Felder werden von UTM die Standardwerte eingesetzt. Die Standardwerte finden Sie bei der Beschreibung der Datenstrukturen im Abschnitt „Datenstrukturen zur Informationsübergabe". | ||
retcode | Im Feld retcode liefert UTM den Returncode des Aufrufs zurück, siehe „Returncodes". | |