Mit KC_UPDATE_IPADDR können Sie im laufenden Betrieb der UTM-Anwendung die IP-Adressen, die in den Objekttabellen der Anwendung abgespeichert sind, mit den IP-Adressen abgleichen, die in der Hostnamen-Datenbank (hostname database) stehen. Die für Ihren Rechner relevante Hostnamen-Datenbank kann die hosts-Datei (Unix-, Linux- und Windows-Systeme), der DNS (Domain Name Service) oder auf BS2000-Systemen die Processor Table inklusive Socket Host Table sein.
Voraussetzung für einen Abgleich auf BS2000-Systemen ist, dass für den/die Partner der Protokolltyp SOCKET generiert ist.
UTM speichert die IP-Adressen folgender Kommunikationspartner in den Objekttabellen der UTM-Anwendung ab:
Kommunikationspartner, die über die Socket-Schnittstelle (Transportprotokoll SOCKET) mit der UTM-Anwendung kommunizieren. Diese Kommunikationspartner sind als Clients vom Typ 'SOCKET' generiert (Partnertyp KC_PTERM).
Nur auf Unix, Linunx- und Windows-Systemen: Kommunikationspartner, die über das Transportprotokoll RFC1006 mit der Anwendung kommunizieren. Das können Clients vom Typ='APPLI' oder 'UPIC-R' (KC_PTERM), LU6.1-Partner-Anwendungen (KC_CON) oder OSI TP-Partner-Anwendungen (KC_OSI_CON) sein.
Nähere Informationen zur Kommunikation über die Socket-Schnittstelle und zur Kommunikation über RFC1006 finden Sie im openUTM-Handbuch „Anwendungen generieren“.
Bei jedem Start der Anwendung liest UTM die IP-Adressen der Kommunikationspartner aus dem Name-Service und legt sie in den Objekttabellen ab.
Ändern sich während des Betriebs der Anwendung die IP-Adressen der betroffenen Kommunikationspartner, dann können Sie diesen Abgleich mit KC_UPDATE_IPADDR dynamisch anfordern.
Mit KC_UPDATE_IPADDR können Sie im Einzelnen:
die IP-Adresse eines bestimmten Kommunikationspartners mit dem Eintrag im Name-Service abgleichen.
die IP-Adressen aller betroffenen Kommunikationspartner mit den Adressen im Name-Service abgleichen.
Zur Kontrolle können Sie die IP-Adresse, die in der UTM-Anwendung für einen Kommunikationspartner gespeichert ist, mit KC_GET_OBJECT abfragen. UTM liefert die IP-Adresse im Feld ip_addr der Datenstruktur des Objekttyps zurück (kc_con_str, kc_osi_con_str oder kc_pterm_str).
Ablauf / Wirkungsdauer / Transaktionssicherung / Cluster
Der Aufruf unterliegt nicht der Transaktionssicherung. Er wirkt unmittelbar und die IP-Adressen sind bei der Rückkehr in das Teilprogramm bereits aktualisiert. Der Aufruf ist nicht rücksetzbar.
Die mit KC_UPDATE_IPADDR aktualisierten IP-Adressen bleiben in der UTM-Anwendung gespeichert bis zum Anwendungsende bzw. bis zum nächsten KC_UPDATE_IPADDR innerhalb des aktuellen Anwendungslaufs.
In UTM-Cluster-Anwendungen (Unix-, Linux- und Windows-Systeme) gilt:
Der Aufruf wirkt Cluster-global, d.h. der IP-Adressen-Abgleich wird auf jeder aktuell laufenden Knoten-Anwendung ausgeführt.
Versorgung der zu übergebenden Bereiche
Funktion des Aufrufs | Angabe im | |||
Parameterbereich 1 | Identifikations- | Selektions- | Datenbereich | |
IP-Adresse eines Kommunikationspartners aktualisieren | subopcode1:
| Union kc_id_area mit dem Namen bzw. Namenstripel des Partners | —— | Zeiger auf einen Datenbereich, in den UTM die Datenstruktur des Objekttyps mit der neuen IP-Adresse zurückliefert. |
IP-Adressen aller betroffenen Kommunikationspartner mit der Datenbank für Hostnamen abgleichen | subopcode1: | —— | —— | —— |
1 In allen Fällen muss im Parameterbereich der Operationscode KC_UPDATE_IPADDR 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_UPDATE_IPADDR |
KC_PARTNER / KC_ALL | |
KC_CON / KC_OSI_CON / KC_PTERM / KC_NO_TYPE | |
1 / 0 | |
Länge des Partnernamens / 0 | |
select_lth | 0 |
Länge des Datenbereichs / 0 | |
Partnername / — | |
Selektionsbereich | |
— | |
Datenstruktur des Objekttyps / — | |
KDCADMI-Aufruf |
KDCADMI (¶meter_area, &identification_area, NULL, &data_area) oder |
Rückgaben von UTM | |
Parameterbereich | |
Feldname | Feldinhalt |
Returncode | |
Länge der im Datenbereich gelieferten Daten / 0 | |
Datenstruktur des Objekttyps / — | |
subopcode1
Im Feld subopcode1 müssen Sie angeben:
KC_PARTNER
wenn UTM die IP-Adresse eines bestimmten Kommunikationspartners aktualisieren soll. Den Namen des Partners müssen Sie im Identifikationsbereich übergeben.
KC_ALL
wenn UTM die IP-Adressen aller Kommunikationspartner, die über das passende Protokoll mit der UTM-Anwendung kommunizieren, mit den Angaben in der Hostnamen-Datenbank abgleichen soll. Passende Protokolltypen sind:
SOCKET
RFC1006 (Unix-, Linux- und Windows-Systeme)
obj_type
Im Feld obj_type müssen Sie den Objekttyp des Kommunikationspartners angeben.
Bei subopcode1=KC_ALL müssen Sie obj_type=KC_NO_TYPE angeben.
Bei subopcode1=KC_PARTNER sind folgende Angaben möglich:
KC_PTERM
für Partner-Anwendungen, die als Clients von folgendem Typ konfiguriert sind.
- SOCKET (BS2000-Systeme)
- APPLI , UPIC-R oder SOCKET (Unix-, Linux- und Windows-Systeme)
KC_CON (Unix-, Linux- und Windows-Systeme)
für eine LU6.1-Partner-Anwendung.
KC_OSI_CON (Unix-, Linux- und Windows-Systeme)
für eine OSI TP-Partner-Anwendung.
obj_number
In obj_number müssen Sie die Anzahl der Objekte angeben, für die die IP-Adresse aktualisiert werden soll.
bei subopcode1=KC_PARTNER müssen Sie obj_number=1 angeben
bei subopcode1=KC_ALL müssen Sie obj_number=0 angeben. UTM aktualisiert dann die IP-Adressen aller entsprechend konfigurierten Kommunikationspartner.
id_lth
Welche Angabe Sie im Feld id_lth machen müssen, ist abhängig von der Angabe im Feld subopcode1:
bei subopcode1=KC_PARTNER:
müssen Sie in id_lth die Länge der Datenstruktur angeben, die Sie im Identifikationsbereich an UTM übergeben.bei subopcode1=KC_ALL:
müssen Sie id_lth=0 setzen.
data_lth
Im Feld data_lth geben Sie die Länge des Datenbereichs an. Sie müssen Folgendes angeben:
bei subopcode1=KC_PARTNER:
Länge der Datenstruktur des Objekttyps in obj_type.bei subopcode1=KC_ALL:
data_lth=0.
Identifikationsbereich
Wie Sie den Identifikationsbereich versorgen müssen, ist abhängig von subopcode1.
bei subopcode1=KC_PARTNER:
Im Identifikationsbereich müssen Sie die Union kc_id_area mit dem Namen des Kommunikationspartners übergeben. Die Angabe muss den Partner eindeutig identifizieren.Bei obj_type=KC_PTERM müssen Sie in der Struktur kc_long_triple_str der Union das Namenstripel aus Clientname (PTERM-Name), Prozessorname und BCAMAPPL-Name übergeben.
Bei obj_type=KC_CON auf Unix-, Linux- und Windows-Systemen müssen Sie in der Struktur kc_long_triple_str der Union das Namenstripel aus Anwendungsname, Prozessorname und BCAMAPPL-Name übergeben.
Bei obj_type=KC_OSI_CON auf Unix-, Linux- und Windows-Systemen müssen Sie im Feld kc_name8 der Union den Namen der Verbindung zu der OSI TP-Partner-Anwendung angeben.
bei subopcode1=KC_ALL müssen Sie den Nullpointer übergeben.
Datenbereich
Wie Sie den Datenbereich versorgen müssen, ist abhängig von subopcode1:
bei subopcode1=KC_PARTNER geben Sie die Datenstruktur des Objekttyps an (kc_con_str, kc_osi_con_str oder kc_pterm_str).
bei subopcode1=KC_ALL müssen Sie den Nullpointer übergeben.
retcode
Im Feld retcode liefert UTM den Returncode des Aufrufs zurück. Neben den im Abschnitt „Returncodes" aufgelisteten Returncodes können zusätzlich folgende Returncodes auftreten
Maincode = KC_MC_REJECTED Der Aufruf wurde von UTM abgewiesen. Subcodes: |
KC_SC_TPROT_NOT_ALLOWED (nur auf Unix-, Linux- und Windows-Systemen) Transportprotokoll wird nicht unterstützt, d.h. in der Anwendung sind keine Kommunikationspartner für die Kommunikation über SOCKET generiert. |
KC_SC_SOCKET_ERROR Ein Abgleich der IP-Adresse(n) konnte aufgrund eines Fehlers an der Kommunikations-Schnittstelle (Socket-Aufruf) nicht vorgenommen werden. |
KC_SC_INVALID_NAME Der im Identifikationsbereich angegebene Kommunikationspartner existiert nicht oder er kommuniziert nicht über das passende Transportprotokoll mit der UTM-Anwendung. |
KC_SC_NO_IPADDR_FOUND subopcode1=KC_PARTNER: |
KC_SC_AT_LEAST_ONE_OBJ_FAILED Ein Abgleich der IP-Adressen mit subopcode1=KC_ALL ist erfolgt. Es ist aber bei mindestens einem Objekt ein Fehler aufgetreten. |
KC_SC_NO_GLOB_CHANG_POSSIBLE Nur bei UTM-Cluster-Anwendungen: |
Maincode = KC_MC_RECBUF_FULL Subcode: |
KC_SC_NO_INFO Der Puffer mit Wiederanlauf-Information ist voll (siehe openUTM-Handbuch „Anwendungen generieren“, KDCDEF-Steueranweisung MAX, Parameter RECBUF). |
Maincode = KC_MC_REJECTED_CURR Der Aufruf kann zur Zeit nicht bearbeitet werden. Subcode: |
KC_SC_INVDEF_RUNNING Nur bei UTM-Cluster-Anwendungen: |
data_lth_ret
data_lth_ret enthält die Länge der Daten, die UTM im Datenbereich zurückliefert.
bei subopcode1=KC_PARTNER: Länge der Daten, die UTM im Datenbereich zurückliefert
bei subopcode1=KC_ALL: data_lth_ret=0
Datenbereich
Im Fall subopcode1=KC_PARTNER liefert UTM im Datenbereich die Datenstruktur des Objekttyps (kc_con_str, kc_osi_con_str oder kc_pterm_str) mit folgenden Informationen zurück .
Ist die neue IP-Adresse des Kommunikationspartners eine IPv4-Adresse, steht sie im Feld ip_addr der Datenstruktur in der Länge 15. Im Feld ip_v steht V4.
Ist die neue IP-Adresse des Kommunikationspartners eine IPv6-Adresse, steht sie im Feld ip_addr_v6 der Datenstruktur in der Länge 39. Im Feld ip_v steht V6.
Die anderen Felder der Datenstruktur sind nicht versorgt.