Im Idealfall werden zwei Werkzeuge parallel eingesetzt, denn:

Ein einziger Monitor kann nicht das Optimum für alle sein

21.07.1989

Systemgruppe und Anwendungsentwicklung stellen oft unterschiedliche Anforderungen an einen Performance-Monitor. Diese Erfahrung machte Peer Gribbohm* als Projektleiter bei der Christlich-Sozialen Krankenversicherung der Schweiz (CSS) in Luzern. Anlaß war die Umstellung des Datenbank-Management-Systems auf DB2.

1984 war bei der CSS das Limit der alten IBM-DOS-Strukturen mit Assembler, CICS und Datacom-DB erreicht. Nach Vorgaben der Geschäftsleitung sollte eine neue DV-Lösung kein Zwischenschritt - zum Beispiel über IMS-DB/DC - sein, sondern ganzheitlich moderner Softwaretechnologie entsprechen. Man entschied sich im Sommer desselben Jahres für das IBM-Produkt DB2.

Es wurde dem Unternehmen sehr schnell klar, daß es eine Vorreiterrolle in Europa übernehmen würde, da DB2 gerade mit dem ersten Release verfügbar war. Im Frühjahr 1985 begann man, die bestehenden Datenstrukturen aus dem Jahre 1964 im Hinblick darauf zu untersuchen, wie daraus ein relationales Modell entstehen könne. Für die Funktionskonzepte wurden applikationsverantwortliche Mitarbeiter ausgebildet und direkt der Informatikleitung unterstellt. Die Fortschritte in der Datenmodellierung überprüfte der IBM-Wissenschaftler und ETH-Professor Max Vetter.

Anfang 1986 wurde ein Projektteam gegründet, das anhand des erstellten Funktionskonzeptes und der Detailstudie mit der Realisierung begann. Ein MVS-Rechner des Typs 4381 diente als Testmaschine, DB2 war mit dem ersten Release verfügbar, für das Transaktionsmonitoring kam CICS zum Einsatz, programmiert wurde in COBOL II.

Nach Erfolgen beim Realisieren von Teilapplikationen mit mächtigen DB2-Zugriffen wurde das Projektteam auf allen Ebenen aufgestockt. Auf dem Markt waren zu diesem Zeitpunkt kaum Tools zu finden, so daß sich die Mitarbeiter ihre eigenen Standards entwickelten (DB2-Dictionary und Online-Schnittstelle CICS/ DB2).

Mit wachsender Komplexität während der Projektlaufzeit (Einbindung des Rechenzentrums in die neuen Abläufe, Schaffung einer kontinuierlichen DBA-Gruppe) bekam man mehr Mut zur Ausnutzung von SQL-Befehlen (union, join, order by). Es wurde vorgegeben, daß in den Programmen diese Konstrukte benutzt werden müßten. Das brachte die ersten Performance-Probleme.

Zunächst wurde also der batchorientierte Performance-Monitor der IBM eingesetzt, dessen Grenzen jedoch aufgrund der zeitlichen Dauer bis zur Information zu eng waren. Daraufhin untersuchte die CSS den Online-Monitor Insight/DB2 von Plenum Systems und das Candle-Produkt Omegamon/DB2.

In der Anwendungsentwicklung stieß Insight/DB2 auf großes Interesse, weil es dem Programmierer die Möglichkeit gibt, seine eigenen SQLs online zu verfolgen und zu prüfen, ob zeitkritische Operationen vorliegen. Auch die Option, sich eigene "Spezifische Traces" zu schaffen (mit einer Cliste-ähnlichen Sprache), fand dort Anklang. Für die Projektleitung war ein Programm fortan erst dann produktionsreif, wenn der Programmierer mit Insight/DB2 den Nachweis der Qualität erbracht hatte.

Das Candle-Produkt wurde von der Projektleitung kritischer betrachtet, da es Informationen nur zum Ausführungszeitpunkt liefert. Die Systemgruppe war allerdings anderer Meinung; denn Omegamon/DB2 kommuniziert perfekt mit der gesamten Candle-Produktpalette.

Durch die Verschiedenartigkeit der Tools waren wir in der Lage, sowohl der Anwendungsentwicklung als auch der Systemgruppe gute Werkzeuge zur Arbeitsunterstützung an die Hand zu geben. Diese Werkzeuge haben der Projektleitung aufgrund einfacher Qualitätssicherungsmechanismen geholfen, den 1986 geplanten Einführungstermin am 3. Oktober 1988 einzuhalten.