Wer die Vorteile seines relationalen Systems von nutzen will, wird früher oder später auf das Problem stoßen, seine alten Daten und Programme in die neue Welt zu transferieren. Hierbei ergeben sich Migrationsszenarien, die frühzeitig erkannt und unterschiedlich behandelt werden müssen. Dieser Erfahrungsbericht nicht schildert einige der Szenarien und wie man damit umgeht beziehungsweise umgehen sollte.

Die glatte Ablösung: DB2, Version 1.3, war gerade installiert, da hörte man einen Softwareleiter orakeln: "Bis in vier Jahren haben wir kein einziges IMS-Programm mehr." Es ging um zirka 2,5 GB Sourcecode.

Inzwischen, fünf Jahre später, ist zwar ein Dutzend DB2-Anwendungen in Produktion gegangen, aber keine einzige IMS-Datenbank und somit auch kein IMS-Programm ist abgelöst worden.

Alles neu macht DB2. Es mag ironisch klingen, aber auf die Frage nach ihrer Migrationsstrategie war die Antwort vieler DV-Führungskräfte: "Wozu? Alles Neue wird bei uns ganz einfach in DB2 gemacht!"

Paarlauf der Systeme: Einige wenige IMS/DB2-Anwender verfolgen jedoch eine konsequente Ablösungsstrategie, bei der die temporäre Spiegelung bestimmter Bestände und der synchrone IMS/DB2-IO eine wichtige Rolle spielen.

Folgendes Bild soll diese drei Auffassungen einer IMS/DB2-Koexistenz verdeutlichen.

Situation A: Nach 20 Jahren IMS und fünf Jahren Koexistenz mit DB2 sind alle IMS-Anwendungen auf DB2 umgestellt. Die Illusion, daß es so gehen könnte, wurde in den letzten Jahren manchem geraubt. Dennoch erfreuen sich Pläne für größere Zeitpunkt-Umstellungen stetiger Beliebtheit.

Situation B: IMS-Anwendungen werden über viele fahre gewartet und weiterentwickelt. DB2-Anwendungen koexistieren über mehrere DB2-Versionen hinweg mit IMS. Diese Situation paßt zu "Alles neu macht DB2".

Situation C: IMS- und DB2-Anwendungen koexistieren wie bei B über viele Jahre, doch werden alte Anwendungen schrittweise auf eine gemeinsame Datenbasis gestellt. Es sind eben diese "Schritte", die C von A unterscheiden: Durch eine gleitende Migration, bei der dank der Spiegelung der kritischen Bestände jederzeit ein Wechsel der Datenbasis möglich ist vermeidet man eine Zeitpunkt-Umstellung. C unterscheidet sich von B durch die Fähigkeit, die alte IMS-Welt in die neue DB2-Welt zu integrieren.

Nachfolgend soll gezeigt werden, daß man sich, obwohl A oder B angestrebt ist, plötzlich zu C gezwungen sieht. Unvorbereitet kann dies zu einer Situation führen, die ich den "Migrations-Deadlock" nenne - das alte System verhindert die Realisierung des neuen. DB2 schießt bei einem Deadlock eine oder mehrere der ineinander verkeilten Zugriffs-Anforderungen ab, um ihn aufzulösen.

Beim Migrations-Deadlock kann man (wenn man kann) entweder auf die Weiterentwicklung des Systems verzichten, bis die Umstellung geschafft ist oder auf die Umstellung verzichten.

Abhängigkeiten sind sinnvoll und gewollt

In einer größeren Anwendung lassen sich viele Migrationsszenarien aufzeigen. Am folgenden Beispiel sollen nur die grundsätzlichen Abhängigkeiten dargelegt werden:

Ein Engineering-Konzern betreibt mit zirka 15 000 IMS-Programmen ein hochintegriertes System, das alle wichtigen kaufmännischen und technischen Bereiche umfaßt. Viele Programme greifen auch auf VSAM- und OS-Files zu. Die zentrale Serviceabteilung erbringt Leistungen sowohl konzernintern wie auch extern. Man will eine relationale Datenbasis haben, um die Kommunikation mit den unterschiedlichsten Benutzern via SQL rationell und flexibel zu gestalten. Ein in zahlreichen Varianten vorkommen. der Ausschnitt zeigt sowohl auf System-, wie auch auf Programm- und Modulebene folgendes Bild:

Es gibt Programm- und, Datenkomponenten, die gemeinsam und oft gleichzeitig genutzt werden. Schließlich ist es eines der Ziele industrieller (Software-) Produktion, durch die Konstruktion wiederverwendbarer Teile die Stückkosten zu senken.

Dementsprechend zielt die Datenmodellierung auf ein konsistentes, redundanzarmes Datenmodell.

Der hohe Anteil an gemeinsam genutzten Daten- und Programmteilen ist somit sinnvoll und gewollt.

Das bedeutet, daß die Umstellung einer oder mehrerer Datenbanken oder die Umstellung eines oder mehrerer Programme immer andere Datenbanken oder Programme tangieren muß.

Alles auf einmal anzupacken wäre vergleichbar mit der Renovierung der Kanalisation einer Stadt über die Feiertage (das geht auch in fünf Jahren nicht, siehe Situation A).

Aller Anfang ist schwer: Das Einfachste zuerst?

Man könnte in Anbetracht der immensen Komplexität dazu neigen, die einfachen Dinge zuerst zu machen. Das wären beispielsweise:

- die Modellierung der neuen Welt;

- ein periodisches Copy-Management für Read-Only-DBs;

- neue DB2-Programme für Read-Only-DBs.

Vor 13 Jahren staunte ich nicht schlecht, als ich mit zwei Seiten "Easytrieve" -Statements (statt 50 Seiten Cobol) mehrere sequentielle, VSAM-KSDS- und DL1-Bestände zu einem Multilevel-Report zusammenzog. Wie geht das heute? Durch den Aufbau von Sekundärbeständen? Welch ein Fortschritt!

Man könnte annehmen, daß die Umstellung - aufgrund der systemimmanenten Abhängigkeiten - um so problembeladener wird, je perfekter im Altsystem das Design für die Wiederverwendbarkeit der Komponenten gelungen ist. Genau das Gegenteil kann der Fall sein.

Um die Migrationsfähigkeit eines Systems zu beurteilen, braucht man neben Programm/ Datei- und Datei/Programm-Verwendungsnachweisen zusätzlich Kenntnisse über die Programmstrukturen und ihre internen Call-Schnittstellen.

Ein Maß für die Güte der Modularisierung

Bei der Untersuchung großer Mengen von Cobol- und PL1-Quellcode wurde deutlich, daß nicht der Modularisierungsgrad an sich, sondern die Güte der Modularisierung für die Migrationsfähigkeit entscheidend ist.

Ein einfaches Maß hierfür ist "die Austauschbarkeit einer Realisierungsform durch eine andere ohne Nebenwirkungen". Oder - negativ gefragt: "Ist die Anwendungslogik durchsetzt mit Realisierungsformen des IO-Codes zur File-, DBMS- und Monitor-Kommunikation?" Ich habe 15 Jahre alte Software vorgefunden, die in der gesamten Organisation nur eine einzige IO-Schnittstelle zu File und DBMS enthielt!

Bei anderen wiederum war fast jedes Programm mit IO-Code übersät.

Hierbei sind die unterschiedlichen Codemuster zum Beispiel SSA-Muster (Segment Search Argument) beim DLI-Call - von Bedeutung. Spätestens hier wird eine maschinelle Quellcode-Analyse notwendig.

Doch es ist nicht nur der alte Quellcode, der die Migrationsstrategen das Fürchten lehrt. Der naive Optimismus der "global, total Modeller" macht oft mehr Probleme. Die Nutzbarkeit vieler Datenmodelle ist durch die Migrationsfähigkeit der Altsysteme limitiert. Es gibt zahlreiche Modelle, die nie operationell wurden, da die Spezifikation der Transformationsregeln zunehmend babylonischer wurde. Es folgt ein Beispiel, bei dem die Modellierer die Datenherkunft aus der alten Welt immer mitberücksichtigt haben:

20 IMS-Datenbanken mit maximal fünf Stufen und zirka 100 Segmenttypen sollen einmalig in 150 Tables geladen werden. Dann sollen nur noch die IMS-Bewegungen, erst im Batch und später Realtime, eingespielt werden, das heißt, IMS und DB2 laufen synchron. Obwohl die Herkunft und Transformation der Daten einer jeden Column aus den IMS-Feldern und alle nicht zu übernehmenden Daten geklärt waren und alle neu hinzukommenden Daten Defaultwerte hatten, ergab sich dennoch eine Situation, die der später geplanten Realtime-Einspeisung von IMS und DB2 den Garaus machen wird. Denn folgende IMS/DB2-Mappings entstanden unter anderem:

- Ein IMS-Insert führte zu zwölf DB2-Inserts in vier Tables und in bestimmten Situationen zu Updates.

- Zwei IMS-Segmente aus verschiedenen DBs waren nötig, um die Key-Columns zweier Tables zu bilden.

Im Batch läßt sich mit genügend Speicher viel lösen. Doch im MPP (Message Processing Program) geschieht in zwei Sekunden wenig, mit synchronen IMS/DB2-IOs noch weniger. Man stelle sich vor, das obige Beispiel wäre nicht in Anlehnung an die IMS-Welt, sondern auf der Basis eines Welt-, Branchen-, Firmen-, oder Projekt-Modells entstanden. Das Projekt wäre vermutlich bereits bei der Spezifikation der Transformationsregeln zum Scheitern verurteilt gewesen.

Modellierer müssen auch die alten Daten kennen

Deshalb die Forderung: "Modellierer müssen ihre Modelle frühzeitig mit vorhandenen Altdaten testen können." Das geht nur, wenn das Mapping-Schema gleichzeitig spezifiziert wird. Auf diese Weise erhält erstens der Endbenutzer frühzeitig ein gutes und für ihn verstellbares Bild seiner neuen Welt mit realen Daten, zweitens wird ein drohender "Migrations-Gap" vermieden (die Kluft zwischen den schönen neuen Strukturen und der vorhandenen Datenwirklichkeit). Neue und alte Daten können dann mit Standardwerkzeugen wie QMF ergänzt und ausgewertet werden.

Abgesehen von dem Sonderfall, daß jemand völlig neu beginnen kann, brauchen die Daten-, System- und Programmdesigner einen ständigen Migrationsservice, um Systeme zu bauen, die wirklich in der Lage sind, die alte Welt zu modernisieren und schrittweise zu ersetzen. Unabhängig von den Werkzeugen zur Erstellung der neuen Welt und deren Automationsgrad sind zuerst folgende Analyseschritte notwendig:

1. Metadatenanalyse:

- maschinelle Erstellung eines 1:1-Modells der alten Datenstrukturen;

- maschinelle Übernahme des neuen Datenmodells;

- maschineller oder manueller Abgleich (Mapping-Schema).

2. Grobanalyse:

- Schnittstellenanalyse der alten Source-Programme;

- Codemuster-Erkennung für die IOs zu File, DBMS und Monitor.

3. Feinanalyse:

- Strategie für zu migrierende Objekte;

- SQL-Äqivalent für IOs zu File und DBMS.

Für diejenigen, die wie die meisten alte Quellen meiden wie der Teufel das Weihwasser, zum Abschluß ein kleiner Trost:

- Eine Analyse produziert noch keinen DUMP, sie kann ihn höchstens vorhersagen.

- Die Werkzeuge zur aktiven Wartung werden immer integrierter und "honoriger" (SAA), denn

- die Reenineering- und Reverse-Techniken weiden immer "repositoriger".