Die Datenorganisation in Tabellenform ist theoretisch schon lange kein Thema mehr. Trotzdem werden noch 80 Prozent der weltweiten Mainframe-Datenbestaende hierarchisch, zumeist mit VSAM oder IMS, gehalten. Eine Migration ist teuer - es sei denn, sie laesst sich automatisch unterstuetzen. Rainer Gerkens* stellt drei unterschiedliche Konzepte vor.

Datenbankdinosaurier sind zaeh. Sie lassen sich nicht wie ihre zoologischen Vorgaenger durch ein singulaeres Ereignis, eine DV- technische Naturkatastrophe etwa, beiseite schaffen. Der Zeit- und Kostendruck, unter dem DV-Abteilungen arbeiten muessen, laesst es im Normalfall nicht zu, dass eine komplette Datenbanklandschaft oder auch nur ein Teil davon ausstirbt und auf der gruenen Wiese neu entwickelt wird.

Doch allein die Pflege hierarchischer Datenbankanwendungen bindet im Regelfall so viele Programmierkraefte, dass kaum noch Ressourcen fuer Neuentwicklungen uebrigbleiben. Zudem muesste ein DV-Chef es der Fachabteilung und dem Controlling erst einmal plausibel machen, dass durch Arbeiten am Datenbankneubau die weiterlaufenden alten Anwendungen unter Umstaenden schlechtere Performance zeigen, ausserdem der Support leidet und - last, but not least - die Investitionen in die Neuentwicklungen vielleicht erst in ein oder zwei Jahren Wirkung zeigen.

Migration von Hand ist

teuer und dauert lange

Beispiele fuer Datenbankmigrationen von Hand existieren zwar, teuer und arbeitsintensiv sind sie jedoch allemal. So musste Ende der 80er Jahre ein schwaebischer Mittelstaendler zu Spitzenzeiten 70 Kraefte fuer eine haendische Migration abstellen. Sieben Millionen Mark, so heisst es - allerdings von Unternehmensseite unbestaetigt - in der Branche, habe die Umstellung gekostet. Ohne massive Unterstuetzung des Hardware- und Systemlieferanten fuer den Vorzeigekunden waere das Projekt kaum durchfuehrbar gewesen.

Zu welchen Kosten auch immer: Kaum ein Unternehmen kann auf den Umstieg in die relationale Welt verzichten. Zwei Loesungsansaetze fuer dieses Dilemma haben sich als Kruecken erwiesen - unter oekonomischen wie unter technischen Gesichtspunkten: Die Emulation hierarchischer Modelle auf einem relationalen Datenbanksystem und das Aufsetzen einer SQL-Schnittstelle auf die hierarchische Datenbank. Nicht erreicht wird in beiden Faellen der ueblicherweise mit einem RDBMS angestrebte Zweck: die hoehere Produktivitaet. Die historisch gewachsenen hierarchischen Datenmodelle verhindern, dass die Benefits relationaler Datenhaltung zum Tragen kommen. Was kommt ueberhaupt mit DB2 auf uns zu? Um diese Frage zu beantworten, testete die Deutsche Bank Bauspar AG in Frankfurt vor der eigentlichen Umstellung - 900 Batch- und Online-Programme in Cobol und Assembler bilden den Anwendungsbestand - die Vorteile von DB2 mittels

einer Migration von Hand. Etwa 15 IMS-Programme und eine VSAM- Anwendung wurden umgestellt. Ausserdem lag ein Neuprojekt an, das die Deutsche Bank Bauspar AG gleich auf DB2 realisierte.

Laut DV/Org.-Leiter Frank-Michael Rogowski ging das Bauspar- Unternehmen davon aus, dass die einzelnen DB2-Anwendungen fuer sich genommen teurer sein wuerden als ihre hierarchischen Vorgaengerinnen. "Das liegt aber nicht an DB2 und auch nicht am Migrationswerkzeug", erlaeutert Rogowski, "sondern daran, dass man mit DB2 adaequat umgehen koennen muss." IMS-Programmierer daechten auch nach einer Umstellung zuerst noch in IMS statt in DB2.

Die Erfahrung habe jedoch gezeigt, dass die Leute schnell lernen. Rogowski: "Man muss einmal da durch - mit allen Fehlerquellen, die daran haengen." Auf der gruenen Wiese entwickelt, so vermutet der DV-Spezialist, liessen sich DB2-Anwendungen kostenguenstiger gestalten als IMS-Applikationen. Der Programmieraufwand falle durch SQL geringer aus.

Neben diesem Argument spreche fuer eine Umstellung auf DB2 oft auch die Erwartung, dass sich der hohe Wartungsaufwand fuer IMS- oder VSAM-Anwendungen zurueckfahren lasse. Nicht zuletzt sei der Umstieg von hierarchischer auf relationale Datenhaltung selbstverstaendlich auch als ein Schritt in Richtung angestrebter Client-Server- Architektur zu verstehen.

Eine akzeptable Loesung fuer einen homogenen relationalen Datenbestand mit entsprechenden Anwendungen muss mit vertretbarem Aufwand realisierbar sein. Der investive Wert alter Programme darf sich nicht verfluechtigen. Gleichzeitig sollte die Datenorganisation den Moeglichkeiten der relationalen Welt angepasst werden. Darum bemuehen sich die unterschiedlichen Ansaetze von drei Anbietern.

Die Koexistenz von

Daten und Anwendungen

Zu IBMs Information-Warehouse-Architektur gehoert neben "Enterprise Data" und "Applications and Decision Support Systems" der Komplex "Data Delivery". Ein Bestandteil davon ist das IBM-Angebot zum Anschluss an relationale Datenbanken, speziell an DB2. Es traegt die Bezeichnung "Data Propagator" (Dprop).

Das Produkt ermoeglicht die Koexistenz von hierarchisch und relational gehaltenen Daten samt entsprechenden Anwendungen. Dabei gewaehrleistet es die Konsistenz von Daten zwischen dem IMS/ESA- Datenbank-Manager und DB2 unter MVS. Applikationen fuer den IMS/ESA-Datenbank-Manager greifen ueber ein

"Call-Interface" auf IMS/ESA-Daten zu, und DB2/MVS-Anwendungen nutzen das SQL-Interface der relationalen IBM-Datenbank zum Zugriff auf die DB2-Kopie derselben Daten.

Auf eine Migration von Daten und Anwendungen kann nach diesem Konzept also verzichtet werden: Aenderungen an der IMS-Kopie des Datenbestands werden automatisch in DB2 repraesentiert, und seit der Verfuegbarkeit von Dprop, Version 1, Release 2, im Oktober 1993 funktioniert die Propagierung auch umgekehrt.

Die damit ermoeglichte relative Sorglosigkeit bezahlt der Anwender indes mit hoeherem Verbrauch an Plattenplatz und CPU-Ressourcen, die sich aus der doppelten Datenhaltung ergeben. Dennoch macht der User laut IBM mit der Dprop-Loesung seinen Schnitt: Existierende IMS-Daten wuerden geschuetzt, und der (Nutz-)Wert der relationalen Tools erhoehe sich.

Ebenfalls in den Information-Warehouse-Bereich Data Delivery faellt auch die Produktfamilie "EDA/SQL" von Information Builders Inc. OS/2-Workstations mit OS/2, DOS oder Windows erhalten damit Zugang zu nichtrelationalen Daten auf Mainframes und anderen Workstations sowie im Netz.

Der Ende vergangenen Jahres angekuendigte "Extender for OS/2" versetzt EDA/SQL zudem in die Lage, von Workstations abgesetzte SQL-Anfragen so anzupassen, dass sie den Formatanforderungen anderer Datenbank- und Dateisysteme auf fremden Hardwareplattformen entsprechen. Nuetzlich zum Verbinden dezentraler relationaler Datenbanksysteme, bringt EDA/SQL jedoch eine wesentliche Limitierung mit sich: In IMS-Datenbanken kann nur gelesen werden. Das zweite Konzept stammt von Computer Associates(CA). Beim Uebergang von hierarchischen Datenbanken zum hauseigenen relationalen "Datacom/DB-System" setzt der Anbieter auf seine "Transparency"-Werkzeugfamilie. Auch zur Koexistenz zwischen DB2 und Datacom findet sich ein entsprechendes Transparency-Angebot im Katalog des Softwareriesen.

"CA-Datacom/DL1 Transparency" und "CA-Datacom/VSAM Transparency" zielen auf die MVS- und VSE-Welten ab. Ihnen gemeinsam ist, dass eine Ueberarbeitung der Datenbankdesigns und eine Neuprogrammierung der Applikationen nicht erforderlich sind, um einen existierenden Anwendungsbestand in einer Datacom-Umgebung einsatzfaehig zu machen.

Vielmehr schaffen die Werkzeuge Anwendungstransparenz, indem sie mit Hilfe von "Intercept"-Softwarekomponenten VSAM- oder DL1-Calls automatisch in Datacom-Requests transferieren und die Antworten in das von VSAM oder DL1 gewohnte Format uebersetzen. Ausserdem konvertieren die Transparency-Tools hierarchisch gehaltene Daten in das relationale Datacom-Format.

Dadurch sind, so heisst es bei CA, alle Daten - unabhaengig von ihrer urspruenglichen Speicherungsform - nicht nur mit den gewohnten VSAM- oder DL1-Calls, sondern auch mit SQL abfragbar. Neue, fuer die relationale Umgebung geschriebene Applikationen koennen damit auf denselben Datenbestand zugreifen wie alte Anwendungen. In verteilten Umgebungen steht die Datenbasis zudem auch fuer Client-Workstations, -PCs oder -VAXen zur Verfuegung.

Die Transparency-Werkzeuge erlauben einen weichen Uebergang auf relationale Datenorganisation - im Unterschied zu IBMs Dprop jedoch ohne doppelte Datenhaltung. Eine wesentliche Einschraenkung des Konzepts gibt es indes: Die Produktivitaetsvorteile der relationalen gegenueber der hierarchischen Datenhaltung lassen sich nur mit einer Neuentwicklung der Applikationen vollstaendig ausnutzen. Solange die dafuer erforderlichen Mannjahre nicht investiert werden, besteht zwar eine Option auf die relationale Zukunft, sie ist aber noch nicht eingeloest.

Ein Produkt, mit dem eine Migration weitgehend zu automatisieren ist, ohne den laufenden Systembetrieb zu unterbrechen, vertreibt die System Performance GmbH, Gruenwald, unter der Bezeichnung "Hirel". Fuer diese Loesung entschied sich die Deutsche Bank Bauspar AG - laut DV-Chef Rogowski deshalb, weil sich damit unmittelbar lauffaehiger Code erzeugen laesst.

Nach dem automatischen Migrationslauf gab es zunaechst Durchsatzprobleme. Nach Rogowskis Worten handelte es sich um "eine Konsolidierungsphase, in der wir die Performance der migrierten Programme optimiert haben". So lag ein Programm, das im alten Zustand einen CPU-Verbrauch im Minutenbereich hatte, nach der Migration bei einer halben Stunde, weil Hirel die IMS-Logik eins zu eins auf DB2 nachgebildet hatte. Nach der Ueberarbeitung sank der CPU-Verbrauch auf 20 bis 30 Sekunden.

Kosten wieder auf

dem alten Niveau

Diese Optimierungsmarge hat, so Rogowski, mittlerweile dazu gefuehrt, dass die Kosten der migrierten Programme wieder auf den Stand vom Juni 1993, dem Zeitpunkt unmittelbar vor dem Hirel- Einsatz, zurueckgeschraubt werden konnten. Bis auf zwei Mitarbeiter, die auch jetzt noch mit der Optimierung einiger Programme beschaeftigt sind, ging die Abteilung danach zum Tagesgeschaeft ueber.

Schmerzhaft, weil arbeitsaufwendig, aber trotzdem lohnend war ein Problem, das sich aus der unterschiedlichen Definition der Bauspar-Vertragsnummern ergab. Dieses Rueckgrat des Datenmodells ist, so erlaeuterte Rogowski, inhaltlich immer numerisch, war im System aber als Character-Feld ausgelegt. Bei der Migration entschloss sich das Unternehmen, sie auch im System numerisch zu fuehren.

Wurden diese Felder nun unter alphanumerische Cobol-Datengruppen gefasst, so sah die Programmiersprache sie als Character-Felder an. Dazu Rogowski: "Eine gepackte Zahl bleibt also gepackt, und Datenvergleiche gehen nicht mehr auf. Eins ist nicht gleich eins." Nach der Migration zeigte der erste Programmlauf solche Schwachstellen jedoch auf, und die Fallgruben liessen sich zuschuetten.

Mit PL/1-Migration

Neuland betreten

Waehrend die meisten Hirel-Kunden das Werkzeug fuer die Migration von Cobol-Progammen einsetzen, betrat Juergen Burmann, Abteilungsdirektor bei der Lebensversicherungs-Gesellschaft der Agrippina-Versicherung, Neuland: Er setzte das Tool fuer die Umstellung von PL/1-Anwendungen ein - mit dem Ziel, die Bestandsfuehrung flexibler zu gestalten und damit die Integration neuer Versicherungsprodukte zu erleichtern.

Bis alles wie geplant lief, musste die Agrippina zusaetzlich ein Viertel der eigentlichen Migrationszeit in die Anpassung und das Tuning von Programmen investieren.

Doch einschliesslich der Nachbearbeitung der umgestellten Programme dauerte das Projekt nur knapp acht Monate, wobei waehrend der gesamten Zeit auch an der Erweiterung des Systems gearbeitet wurde.

Dr. Rainer Gerkens ist Marketing-Manager bei der SWS Software Services GmbH, Pforzheim.