Gerade in Entwicklungs- oder Testsystemen muß ein Administrator häufig eine CICS-Region stoppen und sie gleich danach wieder starten, um Verklemmungen oder Endlosschleifen von Programmen, die das System blockieren aufzulösen. Das kann in CICS-Systemen vorkommen, da, wie bereits in der Vorstellung des CICS erläutert, diese ein kooperatives Multitasking unterstützten, wodurch unkooperative Programme nur noch schwer zu unterbrechen sind. Dieses Stoppen und anschließende Starten von Regions ist jedoch ein triviales Problem, da hierfür eigene Kommandos zur Verfügung stehen. Die Variationen, die auftreten können, sind Sperren durch Lock-Dateien und Prozesse, die sich nicht beenden lassen. Die Lock-Dateien, die beim Stoppen eines Systems nicht ordnungsgemäß gelöscht wurden und ein Starten verhindern, sind über Betriebssystem-Kommandos vom Administrator zu löschen, dann kann das System neu gestartet werden. Prozesse, die sich nicht automatisch beenden lassen muß man von Hand beenden. Danach kann kann die Region heruntergefahren und erneut gestartet werden.
Ein sehr komplexes Szenario aus dem Konfigurations-Management, das Installieren einer neuen CICS-Region, wurde nicht als Beispiel herangezogen, da der CICS-Domain-Manager (CDM) vorerst nicht für diesen Einsatzbereich gedacht ist. Der CDM soll ein integriertes Management auf verschiedenen Plattformen ermöglichen und Systemverwaltern die täglichen Aufgaben erleichtern. Das Einrichten eines neuen CICS-Systems ist jedoch eine Aufgabe für Spezialisten für die jeweilige Plattform und wird aufgrund der Komplexität durch die Menge der Subsysteme und der hohen Performance-Anforderungen auf jeden Fall in naher Zukunft nicht durch einen Automatismus zu lösen sein. Man braucht sich dazu nur vorzustellen, daß ein UNIX-Spezialist die VTAM-Definitionen niederschreiben muß, die einem CICS/ESA-System die Kommunikation mit anderen Systemen ermöglichen.
In dieser Arbeit wurde bisher ausschließlich die Server-Seite betrachtet - die Client-Seite also völlig vernachlässigt, da sich die Installation eines CICS-Clients nur auf den Aufruf eines Installationsprogrammes beschränkt und die Konfiguration über eine Initialisierungsdatei vollzogen wird. Die Managementanforderungen an CICS-Clients sind demnach eher gering und damit von untergeordnetem Interesse für diese Arbeit. Die Initialisierungsdateien werden in der Regel über Software-Verteilungs-Programme auf die Clients kopiert und CICS-Clients darüber hinausgehend kaum vom Arbeitsplatz des Administrators gepflegt. Da es sich häufig um Windows- oder OS/2-Rechner handelt, kann man sich auf ihnen auch nicht von fremden Rechnern aus anmelden.
Die folgenden Szenarien wurden ausgewählt, weil sie zu den häufigsten Aufgaben eines Administrators zählen und zusätzlich noch in sich abgeschlossen sind. Viele der anderen Szenarien sind Teilmengen und Spezialfälle der unten beschriebenen Szenarien, wobei gerade beim Fehlermanagement die Variationen der Ursachen nahezu beliebig groß sind.
In den Szenarien wird der Einfachheit wegen nur von den CICS-Varianten
für MVS/ESA, AIX und OS/2 ausgegangen, die am weitesten verbreitet
sind. Dies ist ausreichend, um die Arbeitsschritte zu beschreiben und
die Heterogenität der Werkzeuge zur Manipulation der Systemtabellen
aufzuzeigen. Ebenso kann man schon an diesen Beispielen die
Unterschiede in der Art und Weise der Definitionen aufzeigen.
Vorbemerkung: Definitionen werden im CICS/ESA und im CICS for
OS/2 mit der Transaktion CEDA eingetragen. Sie dient als
Editierwerkzeug für die Systemtabellen, in denen die Definitionen
eines CICS-Systems gespeichert werden. Unter IBM AIX werden
Betriebsmittel mit dem graphischen Werkzeug smit,
bzw. smitty als textorientierte Variante, festgelegt.
Seit Juni 1996 hat IBM ein Produkt, den IBM CICS System
Manager, der eine graphisch Benutzerschnittstelle bietet und die
meisten Definitionen editieren kann. Der Analyse dieser Werkzeuge ist
jedoch ein eigenes Kapitel gewidmet.