Einführung

Der IBM CICS System Manager  (SM ) ist ebenso, wie smit ein graphisches Werkzeug, mit dem man Definitionen für CICS-Systeme treffen kann. Der SM ist modular aufgebaut und besteht aus einer System Management Application  (SM Application ), einem Graphical User Interface  (GUI ), einem Resource Controller  und einer CICS Agent Transaction , die in einem bestimmten CICS-System läuft und Informationen sammelt. Der Resource Controller und die Agent Transaction bilden zusammen den CICS SM Agent  und kommunizieren über UNIX sockets miteinander. Die System Management Application steht mit dem Resource Controller und dem GUI über DSOM  (Distributed System Object Model ) in Verbindung (Abbildung ).

  

Abbildung: Die Architektur des IBM CICS System Manager

Was den SM von den anderen Werkzeugen grundsätzlich unterscheidet, ist das Konzept, mit dem die Managementinformation verwaltet wird. Der SM ist kein reiner Editor für Systemtabellen, sondern ein verteiltes Werkzeug, das über DSOM mit seinen Komponenten kommuniziert. Gerade dieses Konzept macht ihn für diese Arbeit interessant, weil so über eine CORBA -konforme Schnittstelle die Managementinformation und -Funktionalität nach außen hin zugreifbar wird. Damit erübrigt sich eine Implementierung eines Management-Agenten für CICS - zumindest im ersten, prototypischen Ansatz. Nachdem die Informationen der CICS-Systeme beim SM in CORBA-Objekten gehalten werden, kann man sich auch hier auf vorhandene Teile abstützen. Die Klassen, in denen die eigentliche Information gehalten wird, müssen nicht mehr implementiert werden, was eine große Erleichterung bringt. Diese Implementierung wäre in erster Linie eine Abbildung der Systemtabellen und würde für die Arbeit keinen Fortschritt bedeuten. Interessanter sind in diesem Zusammenhang die Container- und Metaklassen, mit denen die große Menge der Informationen strukturiert werden soll. Durch die Philosophie von SOM/DSOM , alle Objekte und deren Schnittstellen dynamisch zu registrieren, geht aus der Dokumentation nicht unmittelbar hervor, wie die Klassen des SM genau heißen. Deshalb wurde versucht, mit Hilfe eines PERL-Scripts aus dem Interface-Repository des SM einen C++-Header mit den benötigten Klassen zu erhalten. Dazu dienten die Werkzeuge ir2classes und classes2xh, die im Anhang beigefügt sind. Damit kann auch die Vererbungshierarchie der Klassen ermittelt werden. Mit den CASE-Werkzeugen sniff+ und StP wurde aus den Header-Dateien ein Klassendiagramm erzeugt. Dieses Diagramm war jedoch so umfangreich und unübersichtlich , daß dieses Diagramm zum Verständnis des Klassenmodells wenig geeignet ist. Diese Vorgehensweise ist zwar sehr exakt, aber wenig praktikabel. Außerdem ergab sich bei Stichproben, daß ein Klassendiagramm, das mit sniff+ und StP erzeugt wurde, nicht die Vererbungshierarchie hat, die aus dem Interface-Repository und den C++-Header-Dateien hervorgeht. Diese Klassendiagramme sind also als Grundlage für eine fundierte Arbeit nicht geeignet!

  

Abbildung: Die graphische Anwenderschnittstelle des IBM CICS System Manager

Eine zweite Möglichkeit, um Informationen über die Klassen und Attribute zu bekommen, ist im Manual [#!sm_prog!#] beschrieben. In diesem Manual (es wird getrennt von der Software auf einer speziellen CD-ROM vertrieben, die ausschließlich Dokumentation enthält) wird auf ein Werkzeug hingewiesen, mit dem die Klassen der API des SM angezeigt werden können. Dabei kann man auch alle Abhängigkeiten, Attribute und Methoden, mit Parametern, einer Klasse auslesen. Die Sichtweise, die man über dieses Werkzeug auf die SM-Klassen bekommt, ist aber eher eine funktionale Sicht, da hier nicht die eigentlichen Vererbungs- und Enthaltenseinsbeziehungen zwischen den Klassen dargestellt werden, sondern vielmehr die Beziehungen zwischen den CICS-Komponenten. In befindet sich ein PERL-Skript, mit dem automatisch alle Klassen mit Attributen, Methoden und Abhängigkeiten gelesen und in eine C++-Header-Datei konvertiert werden können. Dieser C++-Header kann dann wiederum mit sniff+ und StP in ein Klassenmodell überführt werden. Bei genauerer Analyse der beiden Möglichkeiten, zu einem Klassenmodell zu kommen, fiel auf, daß die Identifikation der Attribute und Methoden von Klassen, die über die API angesprochen werden, nur auf Basis des Interface-Repository sehr schwierig ist. Man muß dabei die gesamte Vererbungshierarchie durchgehen und alle Attribute und Methoden zusammensammeln, wobei mit dieser Vorgehensweise sehr viele Datenelemente gefunden werden, die nicht von aussen zugänglich sind. Weil beim späteren Zugriff auf CICS-Definitionen jedoch entweder über die API zugegriffen werden wird oder gleich eigene Klassen verwendet werden, kann man sich auf die öffentlichen Attribute und Methoden beschränken und den einfacheren und weniger detaillierten Weg gehen. Außerdem werden für den Zugriff auf Attribute ohnehin GET- und SET-Methoden verwendet, die nur einen eingeschränkten Zugriff zulassen.

In einem weiteren Ansatz wurde versucht, auf bereits instanziierte Objekte in einer SM Application oder eines Resource Controllers, also dem Agenten der SM Application, zuzugreifen. Damit kann man sich die Informationen die konkret in einem CICS-System existieren über den Agenten des CICS SM ermitteln. Da der Resource Controller eine standardisierte Schnittstelle besitzt, nämlich SOM/DSOM, ist es naheliegend, direkt über SOM/DSOM auf diese Objekte zuzugreifen. Ein Beispielprogramm in C++ ist im Anhang zu finden. In dieser Form dient das Programm dazu, die Vorgehensweise zu dokumentieren, wie über SOM/DSOM auf Objekte und deren Attribute und Methoden zugegriffen werden kann. Für den konkreten Einsatz ist das Programm noch nicht zu nutzen, da ein Navigationshilfsmittel zu einem bestimmten Objekt bisher fehlt. In der SM Application gibt es ein solches Hilfsmittel nur zum Teil, da man immer ein Kontainerobjekt öffnen muß, um seinen Inhalt zu sehen. Ein Objekt kann nicht direkt mit seinem Namen eingegeben werden, um es zu bearbeiten.

Auf der Grundlage dieser Informationen besteht jetzt die Möglichkeit, die Anforderungen aus dem vorigen Kapitel mit der vorhandenen Funktionalität des SM zu vergleichen.

  

Abbildung: Definition einer Kommunikationsverbindung mit IBM CICS SM