Arbeitsschritte

1.

Zuständige AOR identifizieren. 
Bis jetzt bietet sich in keinem CICS-System die Möglichkeit, die Zuordnung einer Region zu einer bestimmten Anwendung als Systeminformation zu speichern. Diese Zuordnung geschieht implizit, bei der Installation der Programme und Transaktionen. Es obliegt jedem Adminstrator, wo und wie dokumentiert wird in welcher Region eine Anwendung läuft. Aus diesem Grund ist es sehr schwierig herauszufinden, welche Region gerade ein Problem hat, wenn nur die Information zur Verfügung steht, daß eine bestimmte Anwendung nicht gestartet werden kann. Die applid des Gateway-Servers kann man zur Not aus der Initialisierungsdatei des CICS-Client ermitteln (wenn sichergestellt ist, daß diese Anwendung vor kurzer Zeit mit dieser Konfiguration noch lief) und dann in den Definitionen der Transaktionen und Programme etwaige Routing-Einträge suchen, die auf andere CICS-Regions verweisen. Das ist jedoch eine sehr unsichere Methode, da es verschiedene Routing-Mechanismen gibt (Default-Routing, Explizites Routing, Routing-Sessions) und daher die Spuren nicht immer nachvollzogen werden können.

2.

Prüfen der Funktion der AOR.  
Um die Funktion einer Region zu testen, versucht man sich lokal an dieser Region mit einem CICS-Terminal anzumelden. Funktioniert das nicht, kann man noch in den Log-Dateien nachsehen. Die Vorgehensweise dazu wird im nächsten Punkt genauer beschrieben. In den Log-Dateien des CICS-Systems kann aufgrund der Meldungen auf den Zustand der Region schließen. Ist die letzte Meldung beispielsweise ein shutdown of region xyz completed successfully, wurde diese Region heruntergefahren und nicht wieder gestartet.

3.

Log-Datei-Einträge der AOR auf Fehlermeldungen hin analysieren.  
Zum Beispiel deuten Meldungen, daß Transaktionen abgebrochen wurden (ABEND-Codes ) oder Dateisysteme voll sind, auf mögliche Ursachen hin. Dabei muß zuerst das Terminal ermittelt werden, über das sich ein Benutzer am CICS-System angemeldet hat. Bei diesem Schritt bekommt man gleichzeitig den netname des CICS-Client, unter dem er dem Transaction-Server bekannt ist.

• CICS/ESA:

  (a)

  Die Transaktion CEBR ermöglich die Anzeige der Log-Dateien, die in eine Data-Queue geschrieben werden. Dieses Werkzeug ist direkt aus dem CICS heraus zu verwenden.

  (b)

  Mit der Anwendung SDSF ist es möglich, aus dem TSO, einer Art Kommandointerpreter unter MVS, den Joboutput einer Anwendung formatiert anzuzeigen. Da CICS selbst auch eine Anwendung ist, kann man mit SDSF die CICS-Log-Dateien ansehen.

• CICS/6000: Log-Dateien werden im CICS/6000 als einfache ASCII-Dateien in das /var-Verzeichnis geschrieben und sind dort mit jedem Editor zu lesen. Es gibt mehrere Log-Dateien, die wichtigste ist console.log, in der zum Beispiel der Start des CICS-Systems, Datenbank-Anforderungen und Fehlermeldungen von Transaktionen geschrieben werden. Daneben gibt es noch Dateien für den automatischen Terminal-Installer, der das Anmelden von CICS-Clients ermöglicht, und für Terminals, die direkt per Emulation an das CICS gehen.
• CICS for OS/2: Die Log-Datei CICSMSG.LOG im Installationsverzeichnis des CICS-Servers enthält alle Informationen über Terminals, Namen von Clients und Systemen. Sie ist im ASCII-Format und kann mit einem Editor gelesen werden.

4.

Bei Fehlern die Ursachen prüfen.  
(z. B. Transaktionen, Programme oder Files, die zur Anwendung gehören, prüfen.)
Es gibt bis jetzt keine Informationsquelle, die alle Betriebsmittel liefert, die einer Anwendung zugeordnet sind! Ein erstes Kriterium bei einem bestehenden System könnten die CICS-Groups  sein, die eine Strukturierungsmöglichkeit der Definitionen bieten. CICS gestattet es, Operationen (installieren, verfügbarmachen, usw.) auf gesamte Gruppen auszuführen. Wenn Anwendungen so im System definiert wurden, daß jede Anwendung einer Gruppe angehört, läßt sich diese Information natürlich nutzen, verbindlich ist sie jedoch nicht. Findet man in einer Log-Datei einen Eintrag, daß eine bestimmte Transaktion abgebrochen wurde, also der TP-Monitor die Transaktion mit einem ABEND-Code beendet hat.

5.

Prüfen der Funktion der TOR.  
(Siehe Prüfen der Funktion der AOR)

6.

Prüfen der Verbindung zwischen TOR und AOR.  

• CICS/ESA: Mit der Transaktion CEMT kann man mit den Parametern INQUIRE CONNECTION den Status aller definierten Connections anzeigen.
• CICS/6000: Im CICS/6000 kann man mit smit in den Communication Definitions den Status von Connections und Sessions abfragen. Ihr Vorhandensein ist Voraussetzung für einen erfolgreichen Verbindungsaufbau.
• CICS for OS/2: Wie im CICS/ESA gibt es auch im CICS for OS/2 die Transaktion CEMT.

7.

Protokoll-Verbindung zum Client prüfen. 

• TCP/IP: Wenn der CICS-Client über TCP/IP mit dem CICS-Server kommunizieren, wie in diesem Szenario, kann man die Werkzeuge ping oder auch traceroute verwenden, um die Protokollverbindung zu testen.
• NetBios: Es bietet sich nur die Möglichkeit, einen Requester starten und eventuelle Fehlermeldungen während des Startes zu analysieren. Testwerkzeuge, wie ping oder traceroute gibt es für dieses Protokoll nicht. prüfen.
• SNA: Hier gilt bezüglich der Testwerkzeuge das gleiche, wie für NetBios. Eine Auswertung von Fehlermeldungen ist manchmal schwierig, weil nicht zwangsläufig eine Fehlermeldung angezeigt wird. In diesem Fall dauert der Aufbau einer Session länger als üblich. Der Status einer Session ist dann im System über eine längere Zeitspanne hinweg 'Im Aufbau', was mit der Transaktion CEMT nachgeprüft werden kann.

8.

Konfiguration des Clients prüfen. 

• Einträge in der Konfigurationsdatei CICSCLI.INI prüfen, zum Beispiel, ob die Servernamen und TCP/IP-Adressen stimmen und die richtigen Portnummern eingetragen sind.
• TCP/IP-Konfiguration überprüfen, ob die richtigen Router eingetragen sind.
• Testen, ob die Namensauflösung funktioniert, zum Beispiel der richtige DNS-Server eingetragen ist.