Szenario 2: CICS-Anwendung startet nicht.

1.

Zuständige AOR identifizieren.
Da diese Information in keinem CICS-System explizit gespeichert ist, kann auch der SM diese Information nicht ermitteln. Über den Umweg, auf der Terminal Owning Region die Remote-Eintragungen der Transaktionen beziehungsweise der Programme nachzusehen, ist eine AOR zu ermitteln, jedoch wird es schwierig, wenn mehrere Terminal Owning Regions zur Verfügung stehen und die Clients sich dynamisch an verschiedenen TORs anmelden.

2.

Prüfen der Funktion der AOR.
Mit den Discover-Methoden der System-Objekte kann man für CICS/6000 Systeme den Zustand und den Status einer Region abfragen. Für andere Systeme muß auf andere Mechanismen zurückgegriffen werden.

3.

Log-Datei-Einträge der AOR auf Fehlermeldungen hin analysieren.
Für jedes CICS/6000-System gibt es eine Methode an der Klasse, um ein console.log und ein error.log anzuzeigen. Da AIX ein UNIX Dateisystem verwendet und die Log-Dateien in Form von ASCII-Text in das /var-Verzeichnis geschrieben werden, können sie auch mit jedem Editor angezeigt werden.

4.

Bei Fehlern die Ursachen prüfen.
Ein Fehler, dessen Ursache bei den Betriebsmitteln einer Anwendung zu suchen ist, zum Beispiel ein Programm, das installiert wurde und dessen Status danach nicht auf enabled gesetzt wurde, wirft das Problem auf, alle Betriebsmittel einer Anwendung zu kennen. Dieses Problem löst der CICS SM nur zum Teil. Es ist möglich eine Anwendung innerrhalb eines Systems zu definieren und dieser Anwendung Betriebsmittel zuzuordnen. Das Anwendungs-Objekt gibt es aber nur im Kontext eines SYSplex. Da ein SYSplex aber jegliche Managementinformation der Systeme verschattet, wird man davon absehen, einen Plex zu definieren. Man würde sich die Möglichkeit teuer erkaufen, die Information zu Ressourcen einer Anwendung speichern zu können, wenn mit einem Plex die Informationsgewinnung von Last-, Routing- und Prozeßstatusdaten wesentlich schwieriger wird. Daher muß man davon ausgehen, daß der SM die Anwendungen in Form eines Objektes nicht unterstützt. Die Klasse bhg_application kann jedoch in einem eigenen Werkzeug nach diesem Muster in einem allgemeinen Kontext implementiert werden.

5.

Prüfen der Funktion der TOR.
Hier gilt prinzipiell das gleiche, wie für die Funktionsprüfung der AOR, wenn man davon ausgeht, daß auch die TOR ein CICS/6000 System ist. Ist das nicht der Fall, muß abhängig vom System auf spezielle Werkzeuge zurückgegriffen werden.

6.

Prüfen der Verbindung zwischen TOR und AOR.
Eine Verbindung zwischen zwei Regions prüft man am besten durch den Aufbau einer Routing Session. Erst dann kann man sicher sein, daß die erbindung funktioniert. Der SM zeigt für jede half-connection den Status an. Dieser Status bezieht sich aber auf den Zeitpunkt des letzten Aufruf der Methode discover für die CICS-Region, in der die half-connection definiert ist.

7.

Konfiguration des Clients prüfen.
Um die Konfiguration des Clients zu prüfen sind detailierte Informationen aus den Konfigurationsdateien notwendig. Auf diese Informationen kann mit dem SM nicht zugegriffen werden. Ebenso ist ein Verwalten solcher Informationen nicht vorgesehen. Bei automatischen Software-Verteilsystemen für Clients könnte man die standardisierten Konfigurationsdateien, die dann abhängig vom Betriebssystem sind, lokal halten und bei Bedarf darauf zurückgreifen.