Die Änderungen beziehen sich auf eine Knoten-Anwendung einer UTM-Cluster-Anwendung (Unix-, Linux- und Windows-Systeme).
Im Identifikationsbereich müssen Sie die Cluster-interne Nummer (Index des Eintrags dieses Knotens bei KC_GET_OBJECT für Objekt KC_CLUSTER_NODE) der Knoten-Anwendung angeben (Feld kc_name2 der Union kc_id_area). Im Datenbereich müssen Sie die Datenstruktur kc_cluster_node_str mit den neuen Eigenschaftswerten übergeben. Es können nur Knoten geändert werden, die nicht aktiv sind.
In der Datenstruktur kc_cluster_node_str geben Sie Folgendes an:
| Feldname | Bedeutung | 
| hostname_long | hostname_long enthält den primären Rechnernamen des Knotens, auf dem diese Knoten-Anwendung abläuft.  | 
| filebase | Basisname der KDCFILE, der Benutzer-Protokolldatei und der System-Protokolldatei SYSLOG der Knoten-Anwendung. Beim Start der Knoten-Anwendung werden die UTM-Systemdateien unter dem hier angegebenen Namen erwartet. Diese Dateistruktur muss von allen Knoten-Anwendungen aus zugreifbar sein. struct kc_file_base | 
| fb_name: Basisname | |
| length: Länge des Basisnamens | |
| Beachten SIe bei der Änderung des Basisnamens einer Knoten-Anwendung Folgendes: 
 | |
| virtual_host_long | übernimmt für UTM-Cluster-Anwendungen die Funktion des Parameters HOSTNAME der Generierungsanweisung MAX. Den Parameter MAX HOSTNAME dürfen Sie in UTM-Cluster-Anwendungen nicht angeben. | 
| Durch die Angabe von virtual_host_long kann die Absenderadresse für Netzverbindungen spezifiziert werden, die von dieser Knoten-Anwendung aus aufgebaut werden. | 
Wirkungsdauer / Transaktionssicherung: Typ GID ("KC_MODIFY_OBJECT - Objekteigenschaften und Anwendungsparameter ändern")
Die Wirkung ist dauerhaft. Die Information wird in der Cluster-Konfigurationsdatei abgelegt. Die Änderung wird sofort wirksam und kann durch Rücksetzen der Transaktion nicht rückgängig gemacht werden.