kc_cluster_node_str - Knoten-Anwendungen einer UTM-Cluster-Anwendung

Für den Objekttyp KC_CLUSTER_NODE ist die Datenstruktur kc_cluster_node_str definiert. In kc_cluster_node_str liefert openUTM bei KC_GET_OBJECT die Eigenschaften der einzelnen Knoten-Anwendungen (Instanzen) einer UTM-Cluster-Anwendung (Unix-, Linux- und Windows-Systeme) zurück.

mod1	Datenstruktur kc_cluster_node_str
-	char node_indx[4];
x(GID)	char hostname[8];
x(GID)	struct kc_file_base filebase;
-	char bcamappl[8];
-	char port_nbr[8];
-	struct kc_admi_date_time_model kdcdef_time;
-	struct kc_admi_date_time_model startup_time;
-	struct kc_admi_date_time_model shut_n_time;
-	char start_type;
-	char node_state;
-	char monitored_node[4];
-	char monitoring_node[4];
-	struct kc_admi_date_time_model state_change_time;
x(GID)	char virtual_host[8];
-	node_name[8]
x(GID)	char hostname_long[64];
x(GID)	char virtual_host_long[64];

¹ Feldinhalt mit KC_MODIFY_OBJECT modifizierbar; siehe Abschnitt "obj_type=KC_CLUSTER_NODE"

Die Felder der Datenstrukturen haben die folgende Bedeutung:

node_indx

Nummer (Index) der Knoten-Anwendung innerhalb der UTM-Cluster-Anwendung. Die Nummer wird Cluster-intern vergeben und für die Diagnose verwendet. Über den Index ist die Knoten-Anwendung innerhalb der UTM-Cluster-Anwendung eindeutig identifizierbar.
Der Knoten-Index ergibt sich aus der Reihenfolge der CLUSTER-NODE-Statements im KDCDEF-Input: Der Knoten, der durch das erste auftretende Statement beschrieben wird, hat den Index '1', der zweite '2' usw.

KC_MODIFY_OBJECT:
Wenn Sie die Eigenschaften einer Knoten-Anwendung ändern wollen, müssen Sie die Nummer der Knoten-Anwendung im Identifikationsbereich übergeben. Ggf. müssen Sie die Nummer zuvor durch einen KC_GET_OBJECT-Aufruf ermitteln. Sie können nur Knoten modifizieren, die nicht aktiv sind.

hostname

enthält den primären Rechnernamen des Knotens, auf dem diese Knoten-Anwendung abläuft.
Der in diesem Feld zurückgegebene Name ist ggf. auf 8 Zeichen verkürzt. Der vollständige bis zu 64 Zeichen lange Rechnername wird in dem Feld hostname_long zurückgegeben.

KC_MODIFY_OBJECT:
Geben Sie den primären Namen des Knotens an, auf dem die Knoten-Anwendung ablaufen soll.

Der Name kann bis zu 8 Zeichen lang sein.

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.

Der Name wird in dem Element filebase vom Typ kc_file_base übergeben:

struct kc_file_base

char length[2];

char fb_name[42];

fb_name enthält den Basisnamen, length die Länge des Basisnamens.

KC_MODIFY_OBJECT:
Sie können den Basisnamen der Knoten-Anwendung ändern. Dabei ist Folgendes zu beachten:

• Die Basisnamen der einzelnen Knoten-Anwendungen einer UTM-Cluster-Anwendung müssen sich voneinander unterscheiden.

• Geben Sie das Dateiverzeichnis an, das die UTM-Systemdateien der Knoten-Anwendung enthält. Der hier angegebene Name muss aus Sicht aller Knoten das gleiche Dateiverzeichnis bezeichnen. Er kann bis zu 27 Zeichen lang sein.

bcamappl

Name des Transportsystemendpunktes (BCAMAPPL-Name), der für die Clusterinterne Kommunikation verwendet wird. Er wird bei der Generierung in der CLUSTER-Anweisung festgelegt.

port_nbr

Nummer des Listener-Ports, der für die Cluster-interne Kommunikation verwendet wird. Er wird bei der Generierung in der CLUSTER-Anweisung festgelegt.

kdcdef_time

Zeitpunkt, an dem die KDCFILE dieser Knoten-Anwendung generiert wurde.

Datum und Uhrzeit werden in dem Element kdcdef_time vom Typ kc_admi_date_time_model zurückgeliefert:

struct kc_admi_date_time_model

struct kc_admi_date_model admi_date;

struct kc_admi_time_model admi_time

wobei

struct kc_admi_date_model

char admi_day [2];

char admi_month [2];

char admi_year_4 [4];

char admi_julian_day [3];

char admi_daylight_saving_time

und

struct kc_admi_time_model

admi_hours [2];

admi_minutes [2];

admi_seconds [2]

startup_time

Zeitpunkt des letzten Starts dieser Knoten-Anwendung.

Datum und Uhrzeit des Starts werden in dem Element startup_time vom Typ kc_admi_date_time_model zurückgeliefert (siehe kdcdef_time).

shut_n_time

Zeitpunkt, zu dem diese Knoten-Anwendung zuletzt normal beendet wurde.

Datum und Uhrzeit werden in dem Element t shut_n_time vom Typ kc_admi_date_time_model zurückgeliefert (siehe kdcdef_time).

state_change_time;

Zeitpunkt der letzten Status-Änderung dieser Knoten-Anwendung (siehe node_state).

Datum und Uhrzeit werden in dem Element state_change_time vom Typ kc_admi_date_time_model zurückgeliefert (siehe kdcdef_time).

start_type

Art des letzten Starts dieser Knoten-Anwendung:

'C'	Der letzte Start der Anwendung war ein Kaltstart nach einem normalen Anwendungsende (COLD).
'W'	Der letzte Start der Anwendung war ein Warmstart nach einem abnormalen Anwendungsende (WARM).
'D'	Die Knoten-Anwendung wurde nach dem Generierungslauf das erste Mal gestartet (DEF).
'U'	Die Knoten-Anwendung wurde nach einem KDCUPD-Lauf gestartet (UPDATE).

node_state

Status der Knoten-Anwendung:

'G' (Generated)

Die Knoten-Anwendung wurde nach dem Generierungslauf noch nicht gestartet.

'R' (Running)

Die Knoten-Anwendung läuft zur Zeit.

'T' (Terminated)

Die Knoten-Anwendung läuft nicht. Sie wurde normal beendet.

'A' (Abnormally terminated)

Die Knoten-Anwendung läuft nicht. Sie wurde abnormal beendet.

'F' (Failure)

Die Knoten-Anwendung wurde von ihrer überwachenden Knoten-Anwendung als ausgefallen erkannt.

monitored_node

Nummer (Index) der Knoten-Anwendung, die von dieser Knoten-Anwendung überwacht wird, d.h. deren Verfügbarkeit zyklisch überprüft wird.

monitoring_node

Nummer (Index) der Knoten-Anwendung, die die Verfügbarkeit dieser Knoten-Anwendung überwacht. 

virtual_host

Durch die Angabe von HOSTNAME kann die Absenderadresse für Netzverbindungen spezifiziert werden, die von dieser Knoten-Anwendung aus aufgebaut werden.

Leerzeichen bedeuten, dass bei Verbindungsaufbauten die Standard-Absenderadresse des Transportsystems verwendet wird. Diese Funktion wird in einem Rechnerverbund benötigt, wenn beim Verbindungsaufbau als Absenderadresse die relocatable IP-Adresse und nicht die stationäre IP-Adresse verwendet werden soll.

Der in diesem Feld zurückgegebene Name ist ggf. auf 8 Zeichen verkürzt. Der vollständige bis zu 64 Zeichen lange Rechnername wird in dem Feld virtual_host_long zurückgegeben.

node_name

Referenzname der Knoten-Anwendung.

Standardwert: NODEnn
nn = 01..32, wobei nn durch die Reihenfolge der CLUSTER-NODE-Anweisungen bei der Generierung bestimmt wird.

hostname_long

enthält den primären Rechnernamen des Knotens, auf dem diese Knoten-Anwendung abläuft.

KC_MODIFY_OBJECT:
Geben Sie den primären Namen des Knotens an, auf dem die Knoten-Anwendung ablaufen soll.

virtual_host_long

Durch die Angabe von virtual_host_long kann die Absenderadresse für Netzverbindungen spezifiziert werden, die von dieser Knoten-Anwendung aus aufgebaut werden.

Leerzeichen bedeuten, dass bei Verbindungsaufbauten die Standard- Absenderadresse des Transportsystems verwendet wird. Diese Funktion wird in einem Rechnerverbund benötigt, wenn beim Verbindungsaufbau als Absenderadresse die verschiebbare (relocatable) IP-Adresse und nicht die stationäre IP-Adresse verwendet werden soll.