Verhalten im Fehlerfall

In diesem Abschnitt ist beschrieben, wie sich die Beendigung einer UTM-Anwendung bzw. einer CPI-C-Client-Anwendung auf den Kommunikationspartner auswirkt. Außerdem wird erklärt, was Sie tun müssen, um nach einer Fehlersituation wieder einen Grundzustand für eine erfolgreiche Programm-Programm-Kommunikation herzustellen.

Eine UTM-Anwendung beendet sich

Falls sich die UTM-Anwendung beendet, merkt dies das CPI-C-Client-Programm beim nächsten Aufruf an der Kommunikationsschnittstelle. Dabei können folgende Fälle unterschieden werden:

• Bei einem Receive-Aufruf wird ein Verbindungsabbau erkannt oder

• bei einem Aufruf an der Kommunikationsschnittstelle wird erkannt, dass sich die Anwendung beendet hat, wodurch sich automatisch auch die Conversation beendet hat.

In beiden Fällen wird als Ergebnis CM_DEALLOCATED_ABEND zurückgeliefert.

Ein CPI-C-Programm beendet sich abnormal

Die UTM-Anwendung bekommt die Programmbeendigung in der Regel durch einen Verbindungsabbau angezeigt. In diesem Fall sind keine zusätzlichen Aktivitäten erforderlich.

Falls der UTM-Anwendung kein Verbindungsabbau angezeigt wird, bleibt die Verbindung aus Sicht von openUTM bestehen. Es sind zwei Fälle zu unterscheiden:

• Auf der UTM-Seite ist für die Client-Anwendung ein PTERM oder ein LTERM-Pool mit TPOOL ...,CONNECT-MODE=SINGLE generiert. In diesem Fall kann openUTM die angeschlossenen Clients unterscheiden. Sobald ein Client (nach einem Verbindungsverlust) mit demselben Namen wieder eine Verbindung aufbauen will, baut openUTM die alte Verbindung ab und weist den Verbindungsaufbauwunsch zurück. Ein darauf folgender erneuter Verbindungsaufbauwunsch des Clients wird dann wieder akzeptiert.

• Auf der UTM-Seite ist für die Client-Anwendung ein LTERM-Pool mit TPOOL ..., CONNECT-MODE=MULTI generiert. In diesem Fall können sich von einem Rechner aus mehrere Clients mit demselben Namen bei der UTM-Anwendung verbinden. Die UTM-Anwendung kann dann nicht mehr erkennen, ob sich ein Client neu oder nach einem Verbindungsverlust verbinden will. Eine verlorengegangene Verbindung, für die der UTM-Anwendung kein Verbindungsabbau angezeigt wurde, muss in diesem Fall explizit durch die Administration abgebaut werden. D.h. openUTM baut die „verlorengegangene“ Verbindung beim folgenden Versuch des Client, eine Verbindung aufzubauen, nicht selbst ab.

UPIC-Local (nur Unix-, Linux- und Windows-Systeme)

Folgender Fall kann auftreten:

Die UTM-Anwendung hat nichts von der Beendigung des CPI-C-Prozesses mitbekommen. Sobald sich das CPI-C-Programm wieder mit demselben Programmnamen an openUTM verbindet, baut openUTM die alte Verbindung ab und akzeptiert die neue Verbindung.

Schwerwiegender Fehler im CPI-C-Programm

Tritt während des Ablaufs des CPI-C-Programms ein schwerwiegender Fehler auf, der eine sinnvolle Fortsetzung nicht ermöglicht, wird der Prozess abnormal beendet (in Windows-Systemen mit FatalAppExit; auf Unix- und Linux-Systemen mit abort). Außerdem wird folgende Fehlermeldung in die UPIC-Logging-Datei geschrieben:

UPIC: internal error <reason>

Die Fehlermeldungen, die auf der CPI-C-Seite auftreten können, sind in der folgenden Tabelle beschrieben.

<reason>	Bedeutung
1	Beim Senden von Restdaten ist der Wert für die Datenlänge negativ
9	Das Signal SIGTRAP ist aufgetreten
10	Fehler beim Verbindungsaufbau
11	Fehler beim Empfangen der Bestätigung für den Verbindungsaufbau
12	Nachricht ungleich Verbindungsaufbau erhalten
13	Fehler beim Senden von Daten
14	Fehler beim Empfangen von Daten
15	Empfangen einer ungültigen Nachricht
16	Fehler beim Verbindungsabbau

Zur Fehlerdiagnose siehe auch Abschnitt „Diagnose“.

UPIC-Local (nur Unix-, Linux- und Windows-Systeme)

Bei der lokalen Kommunikation über UPIC-Local können darüber hinaus Fehlermeldungen auftreten, die mit den Buchstaben „IPC“ beginnen. Diese sind durch openUTM verursacht. Sie sind im openUTM-Handbuch „Meldungen, Test und Diagnose auf Unix, Linux- und Windows-Systemen“ bei den Dump-Fehlercodes beschrieben.

Zur Fehlerdiagnose ist der Dump (z.B. core-Dump auf Unix- und Linux-Systemen) zusammen mit dem gebundenen Programm, die UPIC-Trace-Datei und die UPIC-Logging-Datei notwendig.

Nachrichtenaustausch bei programmiertem PEND ER/FR

Wenn im UTM-Teilprogrammlauf ein programmierter PEND ER/FR durchgeführt wurde, können die vor dem PEND ER/FR mit MPUT gesendeten Teilnachrichten empfangen werden. Dies geschieht mit dem Aufruf Receive bzw. Receive_Mapped_Data (solange bis das Ergebnis CM_DEALLOCATED_ABEND ist).

Nachrichtenaustausch bei SYSTEM PEND ER

Falls der UTM-Vorgang im Fehlerfall auf PEND ER läuft, wird beim Aufruf Receive bzw. Receive_Mapped_Data das Ergebnis CM_DEALLOCATED_ABEND geliefert. Zusätzlich wird eine Fehlermeldung in die Logging-Datei geschrieben (siehe auch Abschnitt „UPIC-Logging-Datei“).

Mit dem Aufruf MPUT ES (error system) kann in einem Dialog-Teilprogramm eine eigene Fehlermeldung für einen UPIC-Client erzeugt werden (siehe auch openUTM-Handbuch „Anwendungen programmieren mit KDCS“, Aufruf MPUT ES), die der UPIC-Client mit dem Aufruf Receive bzw. Receive_Mapped_Data lesen kann. In diesem Fall wird keine Fehlermeldung in die Logging-Datei geschrieben.

Probleme beim Verbindungsaufbau

Probleme beim Verbindungsaufbau zur UTM-Partner-Anwendung sind daran zu erkennen, dass der Aufruf Allocate nicht mit dem Ergebnis CM_OK endet. In einem solchen Fall sollten Sie folgendes überprüfen:

• Überprüfen Sie mit einem ping-Kommando, ob überhaupt eine Netzverbindung zwischen Client und Server zustande kommen kann.

  Auf Unix-, Linux- und Windows-Systemen rufen Sie das Kommando ping auf mit:

  ping <internetadresse> oder ping <hostname>

  ping muss in Ihrem Pfad liegen, d.h. die Variable PATH muss entsprechend gesetzt sein.

  Auf BS2000-Systemen rufen Sie ping wie folgt auf:

  Auf BS2000-Systemen rufen Sie ping wie folgt auf:

  /&* für IPV4-Verbindungen
  /START-PING4 <hostname>
  
  /&* für IPV6-Verbindungen
  /START-PING6 <hostname>
  

  Überprüfen Sie das TCP/IP Protokoll. Dazu können Sie eine der Standard-Anwendungen telnet oder ftp benutzen.

• Auf Unix-, Linux- und Windows-Systemen rufen Sie diese Kommandos auf mit:

  telnet internetadresse oder telnet hostname
  ftp internetadresse oder ftp hostname

  Die Anwendungen müssen in Ihrem Pfad liegen, d.h. die Variable PATH muss entsprechend gesetzt sein.

  Auf BS2000-Systemen werden die Anwendungen aufgerufen mit:

  START-TELNET
  START-FTP

• Überprüfen Sie, ob in der UTM-Partner-Anwendung die erforderlichen Betriebsmittel zur Verfügung stehen; es darf z. B. der LTERM-Pool bzw. der LTERM-Partner, über den sich der Client anschließen will, nicht gesperrt sein. Siehe dazu auch das openUTM-Handbuch „Anwendungen generieren“.

• Überprüfen Sie, ob im lokalen System die erforderlichen Betriebsmittel zur Verfügung stehen. In jedem Fall sollten Sie auch die lokale Generierung (Side Information) sowie die Generierung des Partners (openUTM) überprüfen.

  BS2000-Systeme
  Bei einer Konfiguration, die BCMAP-Einträge im BS2000-System erfordert, müssen Sie beachten, dass das Kommando BCMAP keine Update-Funktion besitzt, d.h. dass BCMAP-Einträge zuerst gelöscht und dann neu eingetragen werden müssen. Näheres zum Kommando BCMAP finden Sie in den BCAM-Handbüchern.