Szenario 2: CICS-Anwendung startet nicht.

Wenn ein Administrator einen Anruf erhält, daß sich eine bestimmte Anwendung nicht starten läßt, muß er zuerst herausfinden, in welchem System diese Anwendung aufgerufen wurde. Bisher ist es nicht üblich, diese Information in einer Anwendung zu speichern, der Administrator ist darauf angewiesen, daß bei der Installation einer Anwendung dokumentiert wurde, in welchem System die Transaktionen, Programme, Dateien und alle übrigen Betriebsmittel installiert wurden. In einer Anwendung muß also dokumentiert werden, in welcher Region sie physisch installiert wurde. Das geschieht im Attribut regionName der Klasse Application auf die im nächsten Abschnitt noch genauer eingegangen wird.

Hat man die Region identifiziert, muß man prüfen, ob diese überhaupt noch in einem aktiven Zustand ist. Dazu meldet man sich über ein Terminal am entsprechenden System an oder analysiert die Log-Dateien. Der Pfad zu den Log-Dateien wird sinnvollerweise im System gespeichert, dazu wird die Klasse System um logPath, errorLogPath und loginLogPath erweitert.

Da es in Großrechnerarchitekturen auch üblich ist, die Logs in eine Daten-Queue zu schreiben, wird es eine Spezialisierung für CICS/ESA geben, in der die Attribute logQueue, errorLogQueue und loginLogQueue vorhanden sind. Konnte man die Log-Datei lokalisieren, sollte am System eine Methode verfügbar sein, mit der man die Logs lesen kann (readLog()), damit ist es nicht mehr wichtig, ob das Dateisystem oder eine Daten-Queue als Log verwendet wird. Zuerst wir über die Userid des Anwenders das Terminal ermittelt, über das er sich angemeldet hat. Die Zuordung von angemeldeten Anwendern (User) zu den Terminal-Nummern (Terminal), die in Log-Dateien geschrieben werden, wird aus einem speziellen Login-Log ermittelt.

Dazu sollte es eine Methode am User geben, mit der dynamisch zur Laufzeit das Terminal ermittelt wird, unter dem der User dem System bekannt ist (getTerminal()). Ebenso ist es vorteilhaft, wenn über das Terminal ermittelt werden kann, welcher User ihm zu diesem Zeitpunkt zugeordnet war. Die Methode getUser() liefert eine userId als Rückgabewert.

Sollten nun Fehler im System aufgetreten sein, steht meist die Transaktion, die abgebrochen wurde, oder das Programm im Fehler-Log. An dieser Stelle kann man bereits sehen, ob das Starten der Anwendung überhaupt zu einem Transaktionsstart geführt hat. Ist das der Fall gewesen, sieht man bei dialogorientierten Anwendungen unmittelbar, welche Abbruchmeldungen bei der letzten ausgeführten Transaktion der Anwendung stehen. Man muß die Transaktionen daher erst einer Anwendung zuordnen. Dazu sind an der Application alle Transaktionen (transactions) referenziert, aus denen sie gebildet wird. Wenn jede Transaktion nur ein Programm enthalten würde, hätte man auch schon die Programme identifiziert, die zu einer Anwendung gehören. Weil aber ein Programm seinerseits wieder beliebig viele andere Programme zur Laufzeit aufrufen kann, muß man noch alle theoretisch aufrufbaren Programme (programs) einer Anwendung in der Application festhalten.

Hatte der Aufruf einer Anwendung jedoch keinen Transaktionsstart zu Folge, muß man die Funktion der Region prüfen, die als Terminal Owning Region, also meist auf einem Gateway-Server, fungiert. Das wird prinzipiell genauso gemacht, wie bei einer Application Owning Region, nur daß in der TOR selten Transaktionen und Programme installiert sind. Die Transaktionen und Programme werden entweder über dynamisches Transaktions-Routing oder mit einem Programm-Link auf eine fremde Region aufgerufen. Diese Eintragungen in der TOR müssen gegebenenfalls geprüft und berichtigt werden.

Es gibt folglich zu einer normalen Transaktion noch ein Gegenstück, die Remote-Transaktion, RemTransaction, und analog für Programme das Remote-ProgramRemProgram. Diese Betriebsmittel sollten ebenfalls in der dazugehörigen Anwendung gespeichert werden, in den Attributen remTransaction und remProgram. Sind in der TOR Remote-Transaktionen gestartet worden, die jedoch in der AOR nicht zu laufen begonnen haben, so liegt nahe, daß an der Kommunikationsverbindung ein Fehler aufgetreten ist. Verbindungen wurden bereits im obigen Abschnitt behandelt, daher wird an dieser Stelle nicht mehr darauf eingegangen. Ist der Aufruf der Transaktion auch in der TOR nicht angekommen, versucht man durch Aufbauen einer Protokollverbindung den Client-Rechner zu erreichen. Eine CICS-Verbindung kann man zu einem Client nicht herstellen, das ist nur in der Richtung vom Client zum Server, also der TOR, möglich. Dazu wird an der Klasse Client eine Methode eingeführt, mit der man die Protokoll-Verbindung aufbauen und testen kann (pingClient()). Hierzu benötigt man noch das Protokoll (clientProtocol), das vom Client verwendet wird, um das richtige Testwerkzeug auszuwählen. Ist mit der Verbindung zum Client alles in Ordnung, bleibt nur noch ein Fehler in der Client-Konfiguration. Für die CICS-Administration kann man sich hier auf die Konfigurationsdatei des CICS-Clients beschränken (clientConfigFile). Dazu muß eine Kopie dieser Datei lokal beim Administrator sein oder der Client einen Dateitransfer beziehungsweise ein Anmelden ermöglichen.

  

Abbildung: Die Klassen aus dem zweiten Szenario mit den Erweiterungen der Klasse System