Mit KC_MODIFY_OBJECT können Sie Anwendungsparameter und Objekteigenschaften ändern sowie Aktionen für die Objekte der Anwendung durchführen. Folgende Änderungen können Sie durchführen:
Aktionen für die Objekte der Anwendung
- Verbindungen zu Clients, Druckern, Partner-Anwendungen auf- bzw. abbauen 
- den automatischen Verbindungsaufbau zu Clients, Druckern, Partner-Anwendungen veranlassen 
- Clients, Drucker, Partner-Anwendungen, Benutzerkennungen einschließlich ihrer Queues, Transaktionscodes und TAC-Queues sperren und wieder zulassen 
- die Zuordnung zwischen Client/Drucker und LTERM-Partner ändern 
- das Passwort für eine Benutzerkennung ändern 
- Keys in Keysets ändern 
- den Timer für die Überwachung von Leerlaufzuständen einer Session ändern oder die Überwachung ausschalten 
- den UTM-BCAM-Trace Objekt- und Benutzer-spezifisch ein- und ausschalten 
- Lademodule bzw. Shared Objects/DLLs eines Anwendungsprogramms austauschen 
- die Master-LTERMs zweier LTERM-Bündel austauschen oder das LTERM in eine LTERM-Gruppe aufnehmen 
- das Speichern von Asynchron-Nachrichten in der Dead Letter Queue (TAC-Queue KDCDLETQ) festlegen 
- Lademodule auf BS2000-Systemen , die in Common Memory Pools geladen sind, für den Austausch mit KC_CHANGE_APPLICATION vormerken 
- die maximale Anzahl der Clients auf BS2000-Systemen, die gleichzeitig über einen Multiplexanschluss mit der Anwendung verbunden sein können, ändern 
- Rechnernamen und Filebase-Namen einer Knoten-Anwendung ändern 
- Datenbank-Benutzernamen und -Passwort ändern 
Aktionen für die Anwendungsparameter
- die Timer der Anwendung ändern 
- Statistikdaten zurücksetzen 
- Maximalwerte der Anwendung ändern 
- Diagnosefunktionen ein- und ausschalten (z.B. BCAM-Trace) 
- die Anzahl der Prozesse (TASKS) festlegen, die für die Anwendung arbeiten sollen 
- die maximale Anzahl der Prozesse festlegen, die gleichzeitig Asynchron-Aufträge oder Vorgänge mit blockierenden Funktionsaufrufen (z.B. KDCS-Aufruf PGWT) bearbeiten dürfen 
- Timer für die gegenseitige Überwachung der Knoten-Anwendungen ändern 
- In UTM-Cluster-Anwendungen die Statistikwerte für die Belegung des Cluster Pagepools zurücksetzen 
Übergabe der neuen Objekteigenschaften und Anwendungsparameterwerte
Zur Übergabe der neuen Objekteigenschaften bzw. Anwendungsparameter stehen in der Header-Datei kcadminc.h Datenstrukturen zur Verfügung. Für jeden Objekttyp und für jeden Parametertyp gibt es eine eigene Datenstruktur. Der Name der Datenstruktur entspricht dem Namen des Objekttyps/Parametertyps (in Kleinbuchstaben) mit dem Suffix „_str“ (objecttyp_str, parametertyp_str). In der folgenden Beschreibung ist angegeben, in welchen Feldern der Datenstrukturen Sie die neuen Eigenschaften übergeben müssen. Die vollständige Beschreibung der Datenstrukturen finden Sie im Abschnitt „Datenstrukturen zur Informationsübergabe".
Beim Ändern von Objekteigenschaften oder Parametern des Anwendungsprogramms ist Folgendes zu beachten
Bei der Änderung von Objekteigenschaften können Sie mit einem KC_MODIFY_OBJECT-Aufruf nur die Eigenschaften eines Objektes ändern. 
Im Identifikationsbereich müssen Sie dabei den Namen des Objektes vollständig angeben, so dass UTM das Objekt eindeutig identifizieren kann. 
Objektnamen sind nicht modifizierbar.
Bei der Änderung von Anwendungsparametern können Sie innerhalb eines Aufrufs alle Parameter ändern, die zu demselben Parametertyp gehören, d.h. in einer Datenstruktur enthalten sind.
Die bei einem KC_MODIFY_OBJECT-Aufruf angegebenen transaktionalen Änderungen werden entweder alle zusammen durchgeführt oder keine der Änderungen wird durchgeführt. Für Änderungen, die nicht der Transaktionssicherung unterliegen, gilt dies nicht.
Wirkungsdauer / Transaktionssicherung / Cluster
Der Zeitpunkt, zu dem eine Änderung wirksam wird, und ihre Wirkungsdauer sind abhängig von der Art der Änderung. Von der Art der Änderung hängt es auch ab, ob die Änderung der Transaktionssicherung unterliegt oder nicht.
In einer UTM-Cluster-Anwendung gilt (Unix-, Linux- und Windows-Systeme):
Der Aufruf kann sowohl Aktionen anstoßen, die Cluster-global wirken als auch solche, die Knoten-lokal wirken. Global wirkende Aktionen werden für jede Knoten-Anwendung der UTM-Cluster-Anwendung wirksam, unabhängig davon, ob eine Knoten-Anwendung gerade aktiv ist oder nicht. Lokal wirkende Aktionen wirken sich nur auf die Knoten-Anwendung aus, an der der Aufruf durchgeführt wird. Abhängig vom Objekt, wirken alle Parameter eines Objekts global oder alle lokal oder auch gemischt global/lokal. Die Änderung kann über den aktuellen Lauf der Cluster-Anwendung hinaus wirken oder nur für den aktuellen Lauf. Modifikationen, die Auswirkungen auf die UTM-Konfiguration haben, wirken immer Cluster-global, um die Generierung konsistent zu halten. Diese globale Wirksamkeit ist in der Spalte des Operationscodes KC_MODIFY_OBJECT mit „G“ gekennzeichnet. Bei einer Kennzeichnung, in der kein „G“ enthalten ist, ist die Wirkung in einer UTM-Cluster-Anwendung Knoten-lokal.
Eine genaue Beschreibung des Wirkungsbereichs der einzelnen Parameter jedes Objekts ist bei der Beschreibung der Datenstrukturen zu finden.
Die folgenden Änderungstypen können auftreten:
IR/GIR
Die Änderung unterliegt nicht der Transaktionssicherung. Sie wirkt sofort (Immediate) und nur für den aktuellen Lauf der Anwendung/der UTM-Cluster-Anwendung (Run). Ein in der gleichen Transaktion nachfolgender RSET-Aufruf setzt die Änderung nicht zurück.
ID/GID
Die Änderung unterliegt nicht der Transaktionssicherung. Sie wirkt sofort (Immediate) und, unabhängig von der Generierungsvariante (UTM-S oder UTM-F), über den aktuellen Lauf der Anwendung/der UTM-Cluster-Anwendung hinaus (Durable). Ein in der gleichen Transaktion nachfolgender RSET-Aufruf setzt die Änderung nicht zurück.
PR/GPR
Die Änderung unterliegt der Transaktionssicherung. 
Sie wird erst beim Transaktionsende wirksam (Pend). Die Änderung wirkt nur für den aktuellen Lauf der Anwendung/der UTM-Cluster-Anwendung (Run). Sie ist durch einen RSET-Aufruf in der gleichen Transaktion rücksetzbar.
P/GP
Die Änderung unterliegt der Transaktionssicherung. 
Sie wird erst beim Transaktionsende wirksam (Pend). Die Dauerhaftigkeit der Änderung ist abhängig von der Generierungsvariante der Anwendung. Bei UTM-F wirkt die Änderung nur für den 
aktuellen Anwendungslauf, bei UTM-S über den aktuellen Anwendungslauf hinaus. Sie ist durch einen RSET-Aufruf in der gleichen Transaktion rücksetzbar.
PD/GPD
Die Änderung unterliegt der Transaktionssicherung. 
Sie wird erst beim Transaktionsende wirksam (Pend). 
Die Änderung wirkt, unabhängig von der Generierungsvariante, über den aktuellen Lauf der Anwendung/der UTM-Cluster-Anwendung hinaus (Durable). Sie ist durch einen RSET-Aufruf in der gleichen Transaktion rücksetzbar.
A/GA
Es wird ein Auftrag (Action) erzeugt um die gewünschte Änderung (z.B. Verbindungsaufbau/-abbau oder Anwendungsprogrammaustausch) zu bewirken. Wann der Auftrag bearbeitet wird, hängt von der Auslastung der Anwendung ab. Ob der Auftrag erfolgreich ausgeführt wurde oder nicht, können Sie nur durch eine spätere Informationsabfrage (z.B. mit KC_GET_OBJECT) erfahren. Der Auftrag ist nicht rücksetzbar.
Hinweis zur Wirkungsdauer in UTM-Cluster-Anwendungen (Unix-, Linux- und Windows-Systeme):
- Ist die Änderung nicht generierbar, so gilt die administrative Änderung auch nach dem Start einer Knoten-Anwendung mit neuer Generierung weiter, aber längstens bis Ende des Laufs der UTM-Cluster-Anwendung. Der Lauf einer UTM-Cluster-Anwendung beginnt mit dem Start der ersten Knoten-Anwendung und endet mit dem Beenden der letzten Knoten-Anwendung. 
- Ist die Änderung auch generierbar, so gilt ab dem Start einer Knoten-Anwendung mit neuer Generierung der Generierungswert, nicht der administrativ geänderte Wert. 
In der Beschreibung der möglichen Modifikationen unter Punkt "Datenbereich" ist angegeben, zu welchem Änderungstyp die einzelnen Änderungen gehören. Es werden die oben stehenden Abkürzungen verwendet.
| Einen Teil der Modifikationen können Sie auch mit den Administrationskommandos durchführen. Welche Kommandos das sind, können Sie der Beschreibung unter Punkt "Datenbereich" entnehmen. | 
Versorgung der zu übergebenden Bereiche
| Funktion des  | Angabe im | |||
| Parameterbe- | Identifikationsbereich | Selektionsbereich | Datenbereich | |
| Eigenschaften eines Objektes ändern | obj_type:  | Name des Objektes | —— | Datenstruktur des Objekttyps mit den neuen Eigenschaftswerten | 
| Anwendungsparameter ändern | obj_type: | —— | —— | Datenstruktur des Parametertyps mit den neuen Parameterwerten | 
1 In allen Fällen muss im Parameterbereich der Operationscode KC_MODIFY_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_MODIFY_OBJECT | 
| KC_NO_SUBOPCODE / KC_IMMEDIATE / KC_DELAY | |
| Objekttyp / Parametertyp | |
| 1 / 0 | |
| Länge Objektname im Identifikationsbereich / 0 | |
| select_lth | 0 | 
| Länge der Datenstruktur im Datenbereich | |
| Objektname / — | |
| Selektionsbereich | |
| — | |
| Datenstruktur des Objekttyps bzw. Parametertyps / — | |
| KDCADMI-Aufruf | 
| KDCADMI (¶meter_area, &identification_area, NULL, &data_area) oder | 
| Rückgaben von UTM | |
| Parameterbereich | |
| Feldname | Inhalt | 
| Returncodes | |
subopcode1
Bei obj_type = KC_DB_INFO müssen Sie im Feld subopcode1 KC_IMMEDIATE angeben, wenn die Änderung des Datenbank-Passworts sofort wirksam werden soll. Bei KC_DELAY wird die Änderung des Datenbank-Passworts erst beim nächsten Start der Anwendung wirksam. Eine Änderung des Datenbank-Benutzernamens wird immer erst beim nächsten Start der Anwendung wirksam.
Bei allen anderen Werten für obj_type müssen Sie in subopcode1 KC_NO_SUBOPCODE angeben.
obj_type
Im Feld obj_type müssen Sie den Typ des Objektes, dessen Eigenschaften geändert werden sollen, bzw. den Typ der Anwendungsparameter, die geändert werden sollen, angeben. Folgende Angaben sind erlaubt:
Objekttypen:
- KC_CLUSTER_NODE 
 (nur möglich in einer UTM-Cluster-Anwendung) geben Sie an, wenn Sie Rechnernamen und/oder Filebase-Namen einer Knoten-Anwendung ändern wollen.
 KC_CLUSTER_NODE müssen Sie z.B. angeben, wenn Sie einer Reserve-Knoten-Anwendung tatsächliche Werte für den Rechnernamen des Knotens und den Basisnamen der KDCFILE der Knoten-Anwendung zuordnen möchten (siehe openUTM-Handbuch „Anwendungen generieren“ und openUTM-Handbuch „Einsatz von UTM-Anwendungen auf Unix-, Linux- und Windows-Systemen“).
- KC_DB_INFO 
 geben Sie an, wenn Sie für eine XA-Datenbank das Datenbank-Passwort und/oder den Datenbank-Benutzernamen ändern wollen.
- KC_KSET 
 geben Sie an, wenn Sie Keys in einem Keyset ändern wollen.
- KC_LOAD_MODULE 
 geben Sie an, wenn Sie Lademodule einer UTM-Anwendung auf BS2000-Systemen bzw. Shared Objects/DLLs einer UTM-Anwendung auf Unix-, Linux- oder Windows-Systemen austauschen wollen, also eine andere Version eines Lademoduls/Shared Objects/DLLs ins Anwendungsprogramm laden wollen.
- KC_LPAP 
 geben Sie an, wenn Sie eine Aktion für einen LPAP-Partner der Anwendung durchführen, d.h. die logischen Eigenschaften einer LU6.1-Partner-Anwendung ändern wollen.
- KC_LSES 
 geben Sie an, wenn Sie die Eigenschaften einer Session mit einer LU6.1-Partner-Anwendung ändern wollen.
- KC_LTAC 
 geben Sie an, wenn Sie die lokalen Eigenschaften eines fernen Services ändern wollen, d.h. die Eigenschaften eines LTACs.
- KC_LTERM 
 geben Sie an, wenn Sie die Eigenschaften eines LTERM-Partners ändern wollen.
- KC_MUX (nur auf BS2000-Systemen) 
 geben Sie an, wenn Sie die Eigenschaften eines Multiplexanschlusses ändern wollen.
- KC_OSI_CON 
 geben Sie an, wenn Sie die Eigenschaften der Verbindungen zu einer OSI TP-Partner-Anwendung ändern wollen.
- KC_OSI_LPAP 
 geben Sie an, wenn Sie eine Aktion für einen OSI-LPAP-Partner durchführen, d.h. die logischen Eigenschaften einer OSI TP-Partner-Anwendung ändern wollen.
- KC_PTERM 
 geben Sie an, wenn Sie Aktionen für Terminals, Drucker, Client-Anwendungen oder TS-Anwendungen durchführen wollen.
- KC_TAC 
 geben Sie an, wenn Sie die Eigenschaften eines Transaktionscodes, der einem lokalen Service zugeordnet ist, oder einer TAC-Queue ändern wollen.
- KC_TACCLASS 
 geben Sie an, wenn Sie die maximale Anzahl der Prozesse ändern wollen, die gleichzeitig Aufträge für eine bestimmte TAC-Klasse bearbeiten dürfen.
- KC_TPOOL 
 geben Sie an, wenn Sie die Eigenschaften der LTERM-Partner oder die Anzahl der aktiven LTERM-Partner eines LTERM-Pools ändern wollen.
- KC_USER 
 geben Sie an, wenn Sie die Eigenschaften einer Benutzerkennung oder deren Queue ändern wollen.
Parametertypen
- KC_CLUSTER_CURR_PAR 
 geben Sie an, wenn Sie in einer UTM-Cluster-Anwendung die Statistikwerte des Cluster Pagepools zurücksetzen möchten.
- KC_CLUSTER_PAR 
 geben Sie an, wenn Sie für eine UTM-Cluster-Anwendung- die Parameter ändern wollen, die die Verfügbarkeitsprüfung der einzelnen Knoten-Anwendungen untereinander regeln. 
- die Parameter ändern wollen, die den Zugriff der Knoten-Anwendungen auf die Cluster-Konfigurationsdatei und das Cluster-Administrations-Journal regeln. 
 
- KC_CURR_PAR 
 geben Sie an, wenn Sie Anwendungs-spezifische Statistikwerte zurücksetzen wollen.
- KC_DIAG_AND_ACCOUNT_PAR 
 geben Sie an, wenn Sie Diagnosefunktionen ein- oder ausschalten oder die Einstellungen des UTM-Accounting ändern wollen.
- KC_MAX_PAR 
 geben Sie an, wenn Sie Maximalwerte (MAX-Parameter) der Anwendung ändern oder die Datenlieferung an openSM2 ein- oder ausschalten wollen.
- KC_TASKS_PAR 
 geben Sie an, wenn Sie Werte ändern wollen, die sich auf die Prozessanzahl der Anwendung beziehen, d.h. Gesamtzahl der Prozesse, Maximalzahl der Prozesse für die Bearbeitung von Asynchron-Aufträge usw.
- KC_TIMER_PAR 
 geben Sie an, wenn Sie die Einstellung von Timern ändern wollen.
 
 
Unter Punkt Datenbereich wird für jeden Objekttyp und Parametertyp beschrieben, welche Modifikationen möglich sind.
obj_number
Welche Angabe Sie im Feld obj_number machen müssen, ist abhängig von der Angabe im Feld obj_type:
- obj_number=1 geben Sie an, wenn Sie in obj_type einen Objekttyp angeben (Ausnahme: KC_TACCLASS, siehe unten). 
- obj_number=0 geben Sie an, wenn Sie in obj_type einen Parametertyp angeben oder wenn Sie bei obj_type = KC_TACCLASS Werte für für alle TAC- Klassen zurücksetzen möchten. 
id_lth
Welche Angabe Sie im Feld id_lth machen müssen, ist abhängig von der Angabe im Feld obj_type:
- geben Sie in obj_type einen Objekttyp an, dann müssen Sie in id_lth die Länge der Datenstruktur angeben, die Sie im Identifikationsbereich an UTM übergeben.Ausnahme: Bei obj_type = KC_DB_INFO und KC_TACCLASS müssen Sie id_lth=2 angeben. 
- geben Sie in obj_type einen Parametertyp an, dann müssen Sie id_lth=0 setzen. 
data_lth
Im Feld data_lth geben Sie die Länge der Datenstruktur an, die Sie im Datenbereich an UTM übergeben.
data_lth=0 ist nicht erlaubt.
Identifikationsbereich
Im Identifikationsbereich übergeben Sie den Namen des Objektes, dessen Eigenschaften Sie ändern wollen. Das heißt:
- geben Sie in obj_type einen Objekttyp an, dann müssen Sie im Identifikationsbereich den vollständigen Namen des Objektes an UTM übergeben 
 Ausnahmen:- Bei obj_type = KC_TACCLASS und Rücksetzen von Werten für für alle TAC-Klassen müssen Sie binär null eintragen. 
- Bei obj_type = KC_DB_INFO müssen Sie eine Ziffer zur Identifikation einer Datenbank angeben. Diese Ziffer repräsentiert die Datenbanken in der Reihenfolge, wie sie im KDCDEF-Lauf generiert wurden und an der Administrationsschnittstelle bei KC_GET_OBJECT zurückgegeben werden. 
 Welche Angaben Sie machen müssen, ist unter Punkt abhängig vom Objekttyp beschrieben. Geben Sie in obj_type einen Parametertyp an, dann müssen Sie keinen Identifikationsbereich an UTM übergeben. Angaben im Identifikationsbereich werden von UTM ignoriert.
 
Datenbereich
Im Datenbereich übergeben Sie die Datenstruktur des in obj_type angegebenen Objekt- bzw. Parametertyps. Für jeden einzelnen Objekt- bzw. Parametertyp steht eine eigene Datenstruktur zur Verfügung, die Sie über den Datenbereich legen müssen. In der Datenstruktur müssen Sie die neuen Eigenschafts- bzw. Parameterwerte an UTM übergeben. Die restlichen Felder der Datenstruktur, d.h. die Felder der Eigenschaften bzw. Parameterwerte, die Sie nicht verändern wollen oder dürfen, müssen Sie vor dem Aufruf mit binär null versorgen.
In openUTM auf Unix- und Linux-Systemen müssen bei obj_type = KC_LOAD_MODULE nicht immer Daten im Datenbereich übergeben werden, da zum Austausch von Shared Objects ohne Versionsangabe der Name des Shared Objects im Identifikationsbereich ausreichend ist.
In den folgenden Tabellen im Abschnitt "obj_type=KC_CLUSTER_NODE" sind die erlaubten Modifikationen abhängig vom Objekttyp/Parametertyp beschrieben. Sie können der Beschreibung entnehmen, welche Eigenschaften/Parameter Sie ändern können und wie die Felder zu versorgen sind. Die gesamten Datenstrukturen sind im Abschnitt „Datenstrukturen zur Informationsübergabe" beschrieben.
retcode
Im Feld retcode liefert UTM den Returncode des Aufrufs zurück, siehe „Returncodes".
