Im Folgenden werden die Parameter- und Datenbereiche, die Sie bei einem KDCADMI-Aufruf an UTM übergeben können, allgemein beschrieben.
Genauere Angaben darüber, wie Identifikations-, Selektions-, Datenbereich und die Felder des Parameterbereichs bei den einzelnen Operationen zu belegen sind, finden Sie im Abschnitt „Operationscodes von KDCADMI".
In der folgenden Beschreibung bedeutet:
--> | Es handelt sich um ein Eingabefeld. In diesem Feld übergeben Sie Information an UTM. |
<-- | Es handelt sich um ein Ausgabefeld. In diesem Feld liefert UTM Information an das Administrationsprogramm zurück. |
Parameterbereich: parameter_area
Im Parameterbereich geben Sie an, welche Operation UTM durchführen soll. Dazu stehen die Felder opcode, subopcode1 und subopcode2 zur Verfügung. Im Feld obj_type legen Sie den Objekttyp des zu administrierenden Objektes fest.
Nach der Bearbeitung hinterlegt UTM im Parameterbereich den Returncode und die Länge der zurückgelieferten Daten. Am Returncode können Sie ablesen, ob der Aufruf erfolgreich war oder nicht.
Der Parameterbereich ist wie folgt durch die Struktur kc_adm_parameter festgelegt:
struct kc_adm_parameter |
|
Eingabefelder der Struktur kc_adm_parameter (im Folgenden gekennzeichnet mit -->), die nicht benötigt werden, müssen Sie grundsätzlich mit „binär null“ versorgen. Die Felder version, version_data und opcode müssen bei jedem Aufruf von KDCADMI versorgt werden.
Die Felder der Datenstruktur haben folgende Bedeutung:
-->version
bezeichnet die Version der Programmschnittstelle, die von dem Anwenderprogramm verwendet wird.
Die Version der Programmschnittstelle ist ein Kennzeichen für die Ausprägung der Programmschnittstelle und das Layout der bei dem Aufruf übergebenen Parameterbereiche.
Die Version der Programmschnittstelle müssen Sie bei jedem Aufruf von KDCADMI explizit angeben. Bisher ist als Version nur KC_ADMI_VERSION_1 definiert.
Wird die Ausprägung der Programmschnittstelle in einer Folgeversion geändert, dann wird die Version der Programmschnittstelle erhöht. Sind die Erweiterungen kompatibel und möchten Sie in der neuen openUTM-Version weiter die bisherige Programmschnittstelle nutzen, dann brauchen Sie Ihre Administrationsprogramme nicht anzupassen und können die Version der Schnittstelle weiterhin mit KC_ADMI_VERSION_1 versorgen. Möchten Sie, dass das Administrationsprogramm die neue Programmschnittstelle nutzt, müssen Sie Ihre Programme umstellen und in version die Version der Programmschnittstelle der aktuellen openUTM-Version angeben.
Die Schnittstelle wird jeweils über mehrere openUTM-Versionen sourcekompatibel gehalten.
<--retcode
Im Feld retcode gibt UTM den Returncode des Aufrufs zurück.
Es gibt allgemeine und Funktions-spezifische Returncodes.
Die allgemeinen Returncodes können bei allen Aufrufen auftreten. Sie sind im Abschnitt "Returncodes" beschrieben.
Die Funktions-spezifischen Returncodes können nur bei bestimmten Aufrufen der Programmschnittstelle auftreten und sind deshalb bei der Beschreibung des entsprechenden Aufrufs aufgelistet.
Ist der Parameterbereich nicht in seiner gesamten Länge zugreifbar, dann wird im KB-Rückgabebereich des Vorgangs, in dem der KDCADMI-Aufruf bearbeitet wird, der KDCS-Returncode KCRCCC mit '70Z', der Returncode KCRCDC mit 'A100' belegt. Der Vorgang wird mit PEND ER abgebrochen.
Beim Aufruf müssen Sie das Feld retcode mit der Konstanten KC_RC_NIL belegen.
-->version_data
Version der verwendeten Datenstrukturen.
Die Version der Datenstrukturen ist ein Kennzeichen für das Layout der verwendeten Datenstrukturen. version_data müssen Sie bei jedem Aufruf von KDCADMI explizit angeben. Für version_data sollte in openUTM V7.0 die Konstante KC_VERSION_DATA_11 verwendet werden.
KC_VERSION_DATA (ohne Suffix) bezeichnet immer jeweils die aktuelle Version der Datenstrukturen. Programme, die von der Source-Kompatibilität der Schnittstelle profitieren möchten, sollten die Konstante KC_VERSION_DATA nicht verwenden, sondern bei version_data immer die Versionskonstante KC_VERSION_DATA_xx von der Schnittstellenversion angeben, für die das Programm geschrieben wurde.
KC_VERSION_DATA_11 ist die für openUTM V7.0 gültige Version, KC_VERSION_DATA_10 bezeichnet z.B. die für openUTM V6.5 gültige Version.
Wird das Layout der Datenstrukturen objektkompatibel geändert, dann wird KC_VERSION_DATA nicht erhöht und die Teilprogramme sind in der neuen openUTM-Version ablauffähig.
Wird das Layout der Datenstrukturen bei einer openUTM-Version inkompatibel geändert, z.B. die Datenstrukturen um neue Felder erweitert und dadurch vergrößert, dann wird die Version der Datenstrukturen erhöht. Die Konstanten KC_VERSION_DATA bzw. KC_VERSION_DATA_11 werden in derselben Include-Datei wie die Datenstrukturen definiert. Da die Schnittstelle sourcekompatibel ist, müssen Teilprogramme in diesem Fall nur neu übersetzt werden.
-->opcode, subopcode1, subopcode2
In diesen Feldern geben Sie an, welche Aktion UTM ausführen soll. Das Feld opcode müssen Sie bei jedem Aufruf von KDCADMI versorgen. Es gibt an, welche Operation ausgeführt werden soll. In den Feldern subopcode1 und subopcode2 können Sie abhängig von opcode die Aktion näher spezifizieren, die ausgeführt werden soll.
Was Sie in opcode angeben müssen, damit eine bestimmte Operation ausgeführt wird, ist in der folgenden Tabelle zusammengefasst. Die mit (*) gekennzeichneten Operationscodes sind so genannte Standard-Operationen, die im Abschnitt „Objekt- und Parametertypen für Standard-Operationen" näher erläutert werden.
Funktion | Wert von opcode |
Das gesamte Anwendungsprogramm austauschen. | KC_CHANGE_APPLICATION |
UTM-Dump erzeugen. | KC_CREATE_DUMP |
Neue Objekte in die Konfiguration aufnehmen. | KC_CREATE_OBJECT (*) |
KDCDEF-Steueranweisungen online erzeugen (inverser KDCDEF). | KC_CREATE_STATEMENTS |
Objekt löschen, d.h. aus der Konfiguration herausnehmen | KC_DELETE_OBJECT (*) |
RSA-Schlüsselpaar für die Verschlüsselung der Kommunikation mit Clients erzeugen, aktivieren, löschen oder auslesen. | KC_ENCRYPT |
Informationen über Objekte und Anwendungsparameter abfragen. Über subopcode1 und subopcode2 steuern Sie Art und Umfang der Informationen. | KC_GET_OBJECT (*) |
Nur bei UTM-Cluster-Anwendungen: | KC_LOCK_MGMT |
Objekteigenschaften oder Anwendungsparameter ändern. | KC_MODIFY_OBJECT (*) |
Nur bei UTM-Cluster-Anwendungen: | KC_ONLINE_IMPORT |
Transaktion zurücksetzen, die sich im Zustand PTC befindet. | KC_PTC_TA |
Nur auf BS2000-Systemen: | KC_SEND_MESSAGE |
Anwendungslauf beenden. | KC_SHUTDOWN |
Verbindungen zu Druckern aufbauen, für die Nachrichten vorliegen. | KC_SPOOLOUT |
System-Protokolldatei SYSLOG administrieren. In subopcode1 geben Sie an, welche Aktion durchgeführt werden soll. | KC_SYSLOG |
IP-Adresse eines einzelnen oder aller Kommunikationspartner aktualisieren. Auf BS2000-Systemen müssen die Kommunikationspartner mit T-PROT=SOCKET generiert sein. | KC_UPDATE_IPADDR |
Benutzer-Protokolldatei(en) auf die nächste Dateigeneration umschalten | KC_USLOG |
Vom angegebenen opcode ist abhängig, welche Angaben Sie in den anderen Feldern des Parameterbereichs und im Identifikationsbereich, Selektionsbereich und Datenbereich machen müssen bzw. dürfen. Im Abschnitt „Operationscodes von KDCADMI" ist für jeden Operationscode (Wert von opcode) beschrieben, welche Operationen durchgeführt werden können und welche Angabe Sie dafür in den Datenbereichen machen müssen, die Sie an UTM übergeben. Die Beschreibung erfolgt in alphabetischer Reihenfolge der Operationscodes.
-->obj_type
Im Feld obj_type ist der Objekttyp des Objektes anzugeben, das administriert werden soll, oder der Typ der Anwendungsparameter, die abgefragt oder verändert werden sollen.
Welchen Objekttyp bzw. Parametertyp Sie angeben dürfen, ist abhängig von der gewünschten Operation, also von den Angaben in den Feldern opcode, subopcode1 und subopcode2.
Objekt- und Parametertypen für Standard-Operationen
Die folgenden beiden Tabellen enthalten die Objekt- und Parametertypen, die in UTM für die Standard-Operationen unterstützt werden. Standard-Operationen sind:
Anzeigen
Erzeugen
Modifizieren
Löschen
In der Spalte „opcode“ der Tabelle finden Sie die Operationscodes, bei denen der jeweilige Objekt-/Parametertyp angegeben werden kann. Folgende Abkürzungen werden verwendet:
CRE für KC_CREATE_OBJECT (Erzeugen)
DEL für KC_DELETE_OBJECT (Löschen)
GET für KC_GET_OBJECT (Anzeigen)
MOD für KC_MODIFY_OBJECT (Modifizieren)
Objekttypen
Objekttyp | Wert von obj_type | opcode |
Abstrakte Syntax für die Kommunikation über OSI TP | KC_ABSTRACT_SYNTAX | GET |
OSI TP-Zugriffspunkte der lokalen Anwendung | KC_ACCESS_POINT | GET |
Application Context für die Kommunikation über OSI TP | KC_APPLICATION_CONTEXT | GET |
Namen der lokalen Anwendung, die mit KDCDEF generiert wurden ( BCAMAPPL-Anweisung oder in MAX APPLINAME) | KC_BCAMAPPL | GET |
Nur auf BS2000-Systemen: Namen der Character Sets (CHAR-SET Anweisung) | KC_CHARACTER_SET | GET |
Namen und Eigenschaften einer Knoten-Anwendung in einer UTM-Cluster-Anwendung | KC_CLUSTER_NODE | GET, MOD |
Verbindungen für die verteilte Verarbeitung über LU6.1 | KC_CON | GET, CRE, DEL |
Datenbankanschluss | KC_DB_INFO | GET, MOD |
Nur auf BS2000-Systemen: | KC_EDIT | GET |
Globale Sekundär-Speicherbereiche für KDCS-Teilprogramme zu Austausch von Daten zwischen Vorgängen (GSSB) | KC_GSSB | GET |
| Namen und Eigenschaften der HTTP-Deskriptoren (HTTP_DESCRIPTOR Anweisung) | KC_HTTP_DESCRIPTOR | GET |
Keysets der Anwendung. Keysets legen die Zugriffsberechtigungen von Clients und Benutzern auf Services und LTERM-Partner fest | KC_KSET | GET, MOD, CRE, DEL |
Lademodule einer UTM-Anwendung auf BS2000-Systemen, Shared Objects/DLLs einer UTM-Anwendung auf Unix-, Linux- und Windows-Systemen | KC_LOAD_MODULE | GET, MOD |
LPAP-Partner für den Anschluss von Partner-Anwendungen bei der verteilten Verarbeitung über LU6.1 | KC_LPAP | GET, MOD |
Sessions für die verteilte Verarbeitung über LU6.1 | KC_LSES | GET, MOD, CRE, DEL |
Lokale Transaktionscodes für Services, die Partner-Anwendungen bei der verteilten Verarbeitung über LU6.1 oder OSI TP zur Verfügung stellen | KC_LTAC | GET, MOD, CRE, DEL |
LTERM-Partner für den Anschluss von Clients und Druckern | KC_LTERM | CRE, DEL, GET, MOD |
Benutzereigene Meldungsmodule | KC_MESSAGE_MODULE | GET |
Nur auf BS2000-Systemen: | KC_MUX | GET, MOD |
Associations zu Partner-Anwendungen bei der verteilten Verarbeitung über OSI TP | KC_OSI_ASSOCIATION | GET |
Verbindungen für die verteilte Verarbeitung über OSI TP | KC_OSI_CON | GET, MOD |
OSI-LPAP-Partner für den Anschluss von Partner-Anwendungen bei der verteilten Verarbeitung über OSI TP | KC_OSI_LPAP | GET, MOD |
Transaktionen im Zustand PTC | KC_PTC | GET |
Teilprogramme der UTM-Anwendung und VORGANG-Exits | KC_PROGRAM | CRE, DEL, GET |
Clients und Drucker. Unter „Clients“ sind zusammengefasst: | KC_PTERM | CRE, DEL, GET, MOD |
Temporäre Queues | KC_QUEUE | GET |
Belegung der UTM-Funktionstasten | KC_SFUNC | GET |
Eigenschaften des Anmeldeverfahrens | KC_SIGNON | GET |
IP-Subnetze | KC_SUBNET | GET |
Transaktionscodes lokaler Services und TAC-Queues | KC_TAC | CRE, DEL, GET, MOD |
TAC-Klassen der Anwendung | KC_TACCLASS | GET, MOD |
LTERM-Pools der Anwendung | KC_TPOOL | GET, MOD |
Transfer- Syntax für die Kommunikation über OSI TP | KC_TRANSFER_SYNTAX | GET |
Benutzerkennungen der Anwendung einschließlich ihrer Queues | KC_USER | CRE, DEL, GET, MOD |
Benutzerkennungen der Anwendung einschließlich ihrer Queues (optimierter Zugriff für UTM-Cluster-Anwendungen) | KC_USER_FIX, | GET |
1 | Der Objekttyp kann zwar auf allen Systemen angegeben werden, die Verwendung ist jedoch nur auf BS2000-Systemen sinnvoll. |
Parametertypen
Parametertyp | Wert von obj_type | opcode |
Aktuelle Statistikwerte über die Auslastung einer UTM-Cluster-Anwendung | KC_CLUSTER_CURR_PAR | GET, MOD |
Eigenschaften einer UTM-Cluster-Anwendung (z.B. Name der Cluster-Filebase, Einstellungen für die Überwachung der Knoten-Anwendungen) sowie aktuelle Einstellungen (z.B. Anzahl der gestarteten Knoten-Anwendungen) | KC_CLUSTER_PAR | GET, MOD |
Aktuelle Einstellung von Anwendungsparametern und Statistikwerte über die Auslastung der Anwendung | KC_CURR_PAR | GET, MOD |
Parameter für die Diagnose und das UTM-Accounting | KC_DIAG_AND_ACCOUNT_PAR | GET, MOD |
Daten zur dynamischen Konfiguration: | KC_DYN_PAR | GET |
Anwendungsname, KDCFILE-Name und Maximalwerte der Anwendung wie z.B. Größe des Cache, Größe und Anzahl der Speicherbereiche für KDCS-Teilprogramme und die maximal erlaubte Prozesszahl der Anwendung | KC_MAX_PAR | GET, MOD |
Name, Typ und Format eines Benutzer-spezifischen Meldungsziels | KC_MSG_DEST_PAR | GET |
Aktuelle Belegung des Pagepools | KC_PAGEPOOL | GET |
Allgemeine Informationen über die generierten temporären Queues: Maximale Anzahl Queues, maximale Anzahl Nachrichten für eine Queue, Verhalten voller Queues. | KC_QUEUE_PAR | GET |
Systemparameter: | KC_SYSTEM_PAR | GET |
Prozesszahlen der Anwendung: | KC_TASKS_PAR | GET, MOD |
Timer der Anwendung | KC_TIMER_PAR | GET, MOD |
Globale Werte für die verteilte Verarbeitung, mit Ausnahme der für die verteilte Verarbeitung definierten Timer | KC_UTMD_PAR | GET |
Datenstrukturen für Objekt- und Parametertypen
Für jeden der zu den Standard-Operationen gehörenden Objekt- und Parametertypen steht in der Include-Datei kcadminc.h eine Datenstruktur zur Verfügung, in der Sie Objekteigenschaften bzw. Parameterwerte an UTM übergeben können oder von UTM zurück erhalten. Entsprechende Datenstrukturen gibt es auch für einige der Operationen, die nicht zu den Standard-Operationen gehören. Die Datenstrukturen sind im Abschnitt „Datenstrukturen zur Informationsübergabe" beschrieben. Die Namen der Datenstrukturen sind wie folgt aufgebaut:
Zum Objekt- bzw. Parametertyp „TYP“ gehört die Datenstruktur „typ_ str“, also z.B. zu KC_USER gehört die Datenstruktur kc_user_str, zu KC_MAX_PAR kc_max_par_str.
Analoges gilt für die Nicht-Standard-Operationen. Z.B. gehört zum Opcode KC_APPLICATION_PAR die Datenstruktur kc_application_par_str.
-->obj_number
Anzahl der Objekte, für die die gewünschte Operation durchgeführt werden soll. In obj_number geben Sie z.B. an, über wieviele Objekte UTM bei einer Informationsabfrage (KC_GET_OBJECT) informieren soll.
<--number_ret
In number_ret liefert UTM die tatsächliche Anzahl der Objekte zurück, für die die Operation durchgeführt wurde.
-->id_lth
Im Feld id_lth müssen Sie die Länge des Identifikationsbereichs identification_area angeben, den Sie beim Aufruf übergeben.
Wird kein Identifikationsbereich übergeben, ist id_lth=0 anzugeben.
-->select_lth
Im Feld select_lth müssen Sie die Länge der Datenstruktur angeben, die Sie im Selektionsbereich selection_area an UTM übergeben.
Wird kein Selektionsbereich übergeben, ist select_lth=0 anzugeben.
-->data_lth
Im Feld data_lth müssen Sie die Länge des Datenbereichs data_area angeben, den Sie beim Aufruf übergeben bzw. in den UTM die Daten zurückliefern soll.
Werden keine Daten im Datenbereich übergeben, ist data_lth=0 anzugeben.
<--data_lth_ret
Im Feld data_lth_ret gibt UTM die tatsächliche Länge der im Datenbereich zurückgelieferten Daten an.
Identifikationsbereich: identification_area
Der Identifikationsbereich identification_area dient dazu, das Objekt zu identifizieren, das administriert werden soll. Alle Objekte sind innerhalb der Gruppe eines bestimmten Objekttyps durch ihren Objektnamen eindeutig identifiziert.
Zur Übergabe der Objektnamen legen Sie folgende Union über den Identifikationsbereich.
union kc_id_area |
|
Es ist abhängig vom Funktionsaufruf, ob ein Objekt im Identifikationsbereich eindeutig angegeben werden muss oder nicht.
Zur eindeutigen Identifikation müssen Sie die Objektnamen wie folgt angeben:
bei den Objekttypen KC_CON und KC_PTERM müssen Sie im Unionelement long_triple vom Typ kc_long_triple_str als Objektname das Tripel name, prozessorname, bcamappl-name angeben. Dabei ist name der Name des Objekts (z.B. PTERM-Name), prozessorname der Name des Rechners, auf dem sich das Objekt befindet, und bcamappl-name der Name der lokalen Anwendung, über den die Verbindung zwischen Objekt und Anwendung aufgebaut wird.
struct
char p_name[8];char pronam[64];char bcamappl[8];beim Objekttyp KC_MUX auf BS2000-Sytsemen müssen Sie im Unionelement triple vom Typ kc_triple_str als Objektname das Tripel name, prozessorname, bcamappl-name angeben. Dabei ist name der Name des Objekts, prozessorname der Name des Rechners, auf dem sich das Objekt befindet, und bcamappl-name der Name der lokalen
Anwendung, über den die Verbindung zwischen Objekt und Anwendung aufgebaut wird. Dieses Tripel übergeben Sie in dem Unionelement triple vom Typ kc_triple_str an UTM.
struct kc_triple_str
char p_name[8];char pronam[8];char bcamappl[8];bei einem LTERM-Pool (Objekttyp KC_TPOOL) müssen Sie das LTERM-Präfix, aus dem die Namen der LTERM-Partner des LTERM-Pools erzeugt werden, als Objektname übergeben. Das LTERM-Präfix muss im Unionelement kc_name8 an UTM übergeben werden.
bei dem Objekttyp KC_TACCLASS müssen Sie im Unionelement kc_name2 die Nummer der TAC-Klasse als Objektname übergeben, wenn der Funktionsaufruf für eine bestimmte TAC-Klasse gilt. Ansonsten geben Sie binär null an, d.h. der Aufruf gilt für alle TAC-Klassen.
bei dem Objekttyp KC_DB_INFO müssen Sie im Unionelement kc_name2 die Identifikation der Datenbank (db_id) als Objektname übergeben, wenn der Funktionsaufruf für eine bestimmte Datenbank gelten soll. db_id ist eine Ziffer und repräsentiert die Datenbanken in der Reihenfolge, wie sie im KDCDEF-Lauf generiert wurden.
bei Lademodulen, Shared Objects, DLLs (Objekttyp KC_LOAD_MODULE) und Teilprogrammen (KC_PROGRAM) übergeben Sie den bei der Generierung festgelegten Namen im Unionelement kc_name32.
bei dem Objekttyp KC_SFUNC (UTM-Funktionstasten) müssen Sie im Unionelement kc_name4 die Kurzbezeichnung für die Funktionstaste als Objektname übergeben.
bei der Funktion KC_PTC_TA (Rücksetzen einer Transaktion im Zustand PTC) müssen Sie das Unionelement kc_ptc_id_str mit den Werten aus der Struktur ptc_ident füllen. Den Inhalt von ptc_ident erhalten Sie durch einen vorherigen Aufruf KC_GET_OBJECT mit Objekttyp KC_PTC.
Die Datenstruktur kc_ptc_id_str ist folgendermaßen definiert:
struct kc_ptc_id_str
char vg_indx[10];char vg_nr[10];char ta_nr_in_vg[5];bei den übrigen Objekttypen ist der bei der Generierung angegebene Name des Objekts im Unionfeld kc_name8 zu übergeben, wenn der Funktionsaufruf für ein bestimmtes Objekt gilt. Ansonsten geben Sie binär null an, d.h. der Aufruf gilt für alle Objekte dieses Typs.
Wird der Identifikationsbereich bei einem Aufruf nicht unterstützt, dann müssen Sie als Bereichsadresse den Nullpointer übergeben. Im Parameterbereich müssen Sie dann id_lth=0 setzen.
Selektionsbereich: selection_area
Im Selektionsbereich kann bei der Abfrage von Informationen (Operationscode KC_GET_OBJECT) eine Datenstruktur mit Selektionskriterien an UTM übergeben werden. UTM liefert dann nur Namen und Eigenschaften der Objekte des angegebenen Objekttyps zurück, die den Selektionskriterien entsprechen.
Die Selektionskriterien müssen Sie in der Datenstruktur übergeben, die in kcadminc.h für den Objekttyp (obj_type) definiert ist. In der Datenstruktur müssen Sie die Strukturfelder, nach denen selektiert werden soll, mit den gesuchten Werten besetzen.
Beispiel
Sie wollen Informationen zu Benutzerkennungen abfragen, über die zur Zeit ein Benutzer oder Client angemeldet ist. Dazu legen Sie die Datenstruktur kc_user_str über den Selektionsbereich und geben im Feld connect_mode den Wert "Y" an.
Werden mehrere Selektionskriterien gleichzeitig angegeben, werden nur die Objekte geliefert, die alle Selektionskriterien erfüllen. Die restlichen Strukturfelder sind mit binär null zu versorgen. Nach welchen Kriterien selektiert werden kann, ist bei der Beschreibung von KC_GET_OBJECT im Abschnitt "KC_GET_OBJECT - Informationen abfragen" angegeben.
Wollen Sie Selektionskriterien übergeben, dann müssen Sie beim KDCADMI-Aufruf die Adresse des Selektionsbereichs übergeben und im Feld select_lth des Parameterbereichs die Länge der Datenstruktur angeben, die Sie im Selektionsbereich übergeben.
Wird der Selektionsbereich bei einem Aufruf nicht verwendet, müssen Sie als Bereichsadresse &selection_area den Nullpointer übergeben. Im Parameterbereich müssen Sie dann select_lth=0 setzen.
Datenbereich: data_area
Der Datenbereich wird zur Übergabe von Objekteigenschaften, Parameterwerten und Informationen an bzw. von UTM benutzt. Die Struktur der Daten ist abhängig vom Operationscode und vom Typ des zu administrierenden Objektes.
Werden beim KDCADMI-Aufruf im Datenbereich Daten an UTM übergeben, dann müssen Sie beim KDCADMI-Aufruf die Bereichsadresse des Datenbereichs übergeben und im Feld data_lth des Parameterbereichs die Länge der Datenstruktur angeben, die Sie im Datenbereich übergeben.
Werden Informationen angefordert, die UTM im Datenbereich zurückliefert, dann müssen Sie beim KDCADMI-Aufruf die Bereichsadresse des zur Verfügung gestellten Datenbereichs übergeben und im Feld data_lth des Parameterbereichs seine Länge angeben.
Wird der Datenbereich bei einem Aufruf nicht benötigt, dann müssen Sie den Nullpointer als Bereichsadresse übergeben. Im Parameterbereich müssen Sie dann data_lth=0 setzen.
Der Datenbereich darf maximal 16 MB groß sein.