Wer IBMs Repository Manager/MVS installieren will, muß in der Regel viel Zeit und Geld investieren. Der Auf. wand an Manpower, CPU-Zeit und Speicherkosten ist groß. Alfred Moos, Barbara Schneider und Karl Friedrich Rauland* zeigen auf, welchen Auf. wand die Fachhochschule Heidelberg bei der Einführung des Systems betrieben hat.
In einem laufenden CASE-Studienprojekt, das die Fachhochschule Heidelberg mit Unterstützung der IBM Deutschland GmbH durchfuhrt, wird untersucht, wie eine Informatikausbildung im Fach Software-Engineering bezogen auf das Repository und die darauf aufbauenden Werkzeuge und Methoden aussehen könnte.
100 PS/2-Rechner und ein Mainframe
An unserer Fachhochschule vermitteln wir die anwendungsnahen Studieninhalte der Kerninformatik vorwiegend an IBM-Systemen. Hierzu stehen ein Großrechner von IBM, Modell 1390-190, unter MVS/ESA sowie mehr als 100 PS/2-Rechner zur Verfügung. Die PS/2-Systeme sind durch zwei -Token-Ring-Netzwerke aneinander gekoppelt. Diese Netzwerke stehen über eine Kommunikationsbrücke in Verbindung zum Großrechner. Dadurch läßt sich jedes PS/2-System sowohl als Arbeitsplatzrechner wie auch als Terminal des Großrechners einsetzen. Die Kleinrechner werden derzeit je zur Hälfte unter das und OS/2 betrieben.
Unsere Systemvoraussetzungen und unsere Erfahrung mit IBM-Produkten haben es ermöglicht, ein zweijähriges Studienprojekt durchzufahren. Dessen Ziel besteht darin, zu ergründen, ob mit den Konzepten von AD/Cycle und SAA, sowie den eingesetzten Softwareprodukten (zum Beispiel , Repository Manager, SAA-Sprachen, DB2, DBM von OS/2, CICS und ADW von Knowledgeware) eine qualifizierte, zukunftsorientierte Informatikausbildung im Bereich Wirtschaftsinformatik in der nächsten Dekade möglich ist.
In den vergangenen Monaten wurde der Repository Manager/ MVS an der Fachhochschule installiert und steht seit Anfang März dieses Jahres als Version Release 2.1, für Studienzwecke zur Verfügung. Die dem Repository zugedachte Aufgabe ist es, als umfassende Informations- und Schaltzentrale für alle Anwendungsentwickler die darin abgelegten Informationen über die gesamte Anwendungsentwicklung eines Unternehmens redundanzfrei, konsistent und zentralisiert zu verwalten. Bei Vorhandensein eines leistungsfähigen Großrechners können -die Daten des Repository im Idealfall allen Beteiligten gleichzeitig und an jedem Ort zur Verfügung gestellt werden.
Nach der offiziellen Strategie der IBM soll das Repository den Benutzern vorläufig nur unter dem Betriebssystem MVS/ESA zur Verfügung stehen. Neben diesem schon recht komplexen System benötigt das Repository für die Verwaltung eines Groß, teils der Anwendungsentwicklungsdaten das Datenbanksystem DB2, das für sich alleine betrachtet bereits als ein Großsystem bezeichnet werden muß. Die interaktive Systemkomponente auf dem Großrechner ist in ISPF/PDF eingebettet, einem ebenfalls voluminösen System, und die Dialoglogik ist hierin vornehmlich in der Programmiersprache Rexx programmiert. Mit anderen Worten: Der Einsatz des Repository erfordert einen hohen Aufwand.
Gegenüber dem Vorgänger-Release können im aktuellen. Repository neben den Modellierungsdaten für ein unternehmensweites Daten. und Prozeßmodell nun auch Daten über Cobol-Programme, Beschreibungsdaten für DL/1- und DB2-Datenbanken, Maskendaten für CICS-, DL/1-, Easel- und -ISPF-Masken sowie auch Fest Informationen für WITT und SATT verwaltet werden.
Damit sind aber nicht nur die Fähigkeiten des Repository gewachsen, auch der Umfang des Systems hat sich beträchtlich erweitert. Dies hat natürlich auch seinen Preis in erforderlichen Manpower-, CPU-Zeit- und Speicherkosten. So hat sich gezeigt, daß ein Systemprogrammierer, der im Installieren von IBM-Großsystemen versiert ist, mindestens drei Wochen Installationszeit für das Repository einkalkulieren sollte. Probleme, die hierbei in der Fachhochschule Heidelberg auftraten, hingen durchweg mit der ungewöhnlichen Größe des Systems zusammen.
Fast alle für den normalen Betrieb vorgesehenen Betriebsmittel-Zuordnungen waren für die Installation des Repository zu gering bemessen. Angefangen bei den Page-Dateien des MVS/ ESA, deren Größe auf 700 Zylinder verdoppelt werden mußte, über die Vergrößerung der DB2-Log-Dateien hinweg, bis zu den Erweiterungen der VTOCs der betroffenen Magnetplatten, mußten zur Überwindung der Installationshürden ungewöhnliche Betriebssystemmaßnahmen ergriffen werden. Der Verbrauch an CPU-Zeit belief sich dabei auf etwa sieben CPU-Stunden auf der IBM /390-190.
Die während des Installationsprozesses erzeugten Repository-Dateien, so zeigte eine Bestandsaufnahme, hatten ungefähr 39 800 Spuren auf den reservierten IBM-3380-Platten belegt. Das Repository-Zielsystem benötigt also - überschlägig gerechnet - rund zwei Gigabyte. Dieser Speicherplatz wurde von etwa 2450 Repository-spezifischen Dateien gebraucht. Eine genauere Untersuchung ergab, daß hiervon 134 Dateien vom Nicht-VSAM-Typ und 2315 Dateien vom VSAM-Typ sind.
In dieser Dateianzahl sind 41 Dateien mit einem Platzbedarf von je 515 Spuren enthalten. Sie werden jedem Repository-Benutzer vom System sofort standardmäßig zugewiesen. Nach der Installation war nur ein Benutzer für die Durchführung des Installationstests zugeordnet.
Hiermit ist natürlich noch nicht bekannt, aus wieviel Datentabellen und Indices, die von DB2 verwaltet werden und somit im DB2-Katalog vermerkt sind, das Repository derzeit besteht. Eine Analyse erbrachte hier die stattliche Zahl von 1 105 Datentabellen und 2152 Indices. Dadurch erklärt sich auch die große Anzahl von VSAM-Dateien, da jeder DB2-Index in einer eigenen VSAM-Datei realisiert wird. Die Datentabellen hingegen werden teilweise zusammengefaßt in einer gemeinsamen VSAM-Datei abgebildet.
Zusätzlicher Aufwand von 7,5 Gigabyte
Nachdem bekannt war, daß pro Repository-Benutzer 515 Spuren auf einer IBM 3380 vom Repository-Manager standardmäßig zugeordnet werden, ergab sich, daß an der Fachhochschule Heidelberg bei etwa 300 Studenten mit einem zusätzlichen Plattenaufwand von 150 000 Spuren das sind zirka 7,5 Gigabyte zu rechnen wäre.
Daß die IBM-Laboratorien bei ihren standardmäßigen Einstellungen der Dateigrößen eher großzügig verfahren wenn als Maßstab für die Größenanforderung der Speicherplatzbedarf im Ausbildungsbereich an einer Fachhochschule herangezogen würde, war uns aufgrund von Erfahrungen mit vergleichbaren Systemen für die DB2-Ausbildung bekannt. Wir konnten hier feststellen, daß sich mit zehn Prozent des standardmäßig zugeordneten Platzes anfänglich gut arbeiten läßt.
Aufgrund dieser Erkenntnis mit DB2 wurde in der Fachhochschule ein Programm geschrieben, das den primär zugeordneten Speicherplatz einer Datei freigibt, aber die Option auf die sekundäre Speicherplatz-Zuordnung offen hält. Dadurch ist der Benutzer in der Lage, allmählich in den erforderlichen Speicherplatz hineinzuwachsen. Die fixen Kosten durch die primäre Speicherplatz-Zuordnung sind minimiert. Der Einsatz dieses Programms reduziert die ursprünglich zugeordnete 515 Spuren auf ein Minimum von 53 Spuren je Repository-Benutzer,
ohne daß bis jetzt eine Beeinträchtigung der Funktionalität des Repository-Managers für den betroffenen Benutzer festgestellt werden konnte.
Als eine weitere Kenngröße für die globale Komplexität des Repository kann die Anzahl der in den Repository-Tabellen definierten Attribute angesehen werden. Im Rahmen einer diesbezüglichen Analyse wurde festgestellt, daß die derzeit 1105 Tabellen des Repository insgesamt 6512 Attribute mit 705 unterschiedlichen Namen enthalten.
Zwischenzeitlich gibt es von Release 2 einen weiteren Modifikationslevel. Dieser enthält eine noch größere Anzahl an Entitäten und Beziehungen des Informationsmodells als der Modifikationslevel 1, der an der Fachhochschule gerade installiert wurde (siehe Abbildung). Das hat zur Folge, daß die Anzahl der DB2-Tabellen und Indexe entsprechend zunehmen wird.
Derzeit bietet die IBM im Rahmen des Repository lediglich für den Werkzeugbauer und nicht für den Entwickler von Anwendungssoftware zwei Werkzeuge an, die mit dem Repository ausgeliefert werden. Mit ihnen wird auf die Metadaten des Repository, das sogenannten "Information Model" zugegriffen. Hierin ist die Struktur des Repository definiert.
Das Information Model enthält das Enterprise Model und die Technology Models. Im Enterprise Model ist festgelegt, welche Informationen über die unternehmensweite Datenmodellierung von den Werkzeugbauern im Repository abgelegt werden können. Technology Models gibt es derzeit für die Ablage von Strukturdaten über DL/l, DB2, Cobol-Datenstrukturen, Maskenstrukturdaten von CICS, DL/1, Easel etc.
Weiterhin können mit den Sprachmitteln, die im Repository Manager enthalten sind beziehungsweise unmittelbar dazugehören, Software-Entwicklungswerkzeuge gebaut werden. Das eine der mitgelieferten Werkzeuge läuft vollständig unter ISPF/PDF auf dem Großrechner. Obwohl seine Oberfläche rein textorientiert ist, spielt es derzeit für den Werkzeugbauer noch die maßgebliche Rolle. Das zweite Werkzeug mit dem Namen RM-Graph läuft auf dem PS/2-Kleinrechner unter dem Betriebssystem OS/2 EC und hier speziell unter dem Presentation Manager. RM-Graph hat eine zeitgemäße, übersichtliche und leicht zu bedienende grafische Oberfläche mit Mausunterstützung. Mit Hilfe der Kommunikations-Manager-Komponente von OS/2 werden Metadaten, die im Repository des Großrechners zentral gespeichert sind, dem Systementwickler in grafischer Form online auf dem Kleinrechner präsentiert. Dies geschieht im Rahmen eines kooperativen Datenverarbeitungsprozesses zwischen Klein- und Großrechner.
Dadurch kann man sich derzeit das Datenmodell des Repository in Form von Entitäts-Beziehungs-Diagrammen auf dem Arbeitsplatz-Computer grafisch darstellen lassen. Bei Bedarf können weitere Modellelemente zum Informationsmodell des Repository hinzugefügt werden.
Wer die Arbeitsgeschwindigkeit vom Umgang mit den dezentral auf der Enzyklopädie operierenden ADW-Workstations von Knowledgeware gewohnt ist - an der Fachhochschule Heidelberg sind derzeit 30 Lizenzen, im Einsatz -, dem fällt das schlechte Antwortzeitverhalten des Repository-Systems auf.
Es ist sowohl an der Großrechnerschnittstelle unter ISPF/PDF als auch an der Kleinrechnerschnittstelle unter RM-Graph schon bei einem einzigen Benutzer nicht zufriedenstellend. Zur Verbesserung der Performance ist deshalb noch viel Arbeit von der IBM zu leisten, sei es in der Optimierung der Repository-Manager-Software oder sei es in der Optimierung der Aufteilung der Dateien und Tabellen des Repository.