Wechsel von IMS nach Adabas

Sanierung der SW-Bestände durch Datenbank-Migration

12.04.1991

Die Instandsetzung von Altsoftware auf der Basis einer Datenbank-Migration ist ein komplexen Vorgang. Im folgenden Artikel stellt Thomas Schwab* anhand eines Wechsels vom hierarchischen Datenbank-System IMS zum relational-orientierten Adabas die allgemeine Problematik solcher Umstellungen und ein Lösungskonzept dar.

Gründe für eine Umstellung vorhandener Programmsysteme beziehungsweise von Individualsoftware können unterschiedlicher Art sein:

- Wechsel des Betriebssystems,

-auslaufende Produktlinien von Hard- und Software-Anbietern,

-Überalterung funktionaler Teilsysteme,

-Wechsel des Datenbank-Management-Systems (DBMS),

-veränderte Anforderungen und

-fehlendes Fachpersonal.

Modernes Informations-Management verlangt den Einsatz von DV-Systemen für strategische und dispositive Unternehmensaufgaben. Flexible, schnelle und zeitpunktbezogene Auswertungen sind dabei ein entscheidendes Kriterium. Diesen Anspruch an Anwendungssysteme können relationale beziehungsweise relational-orientierte Datenbank-Systeme Ó la Adabas erfüllen. Vordergründig scheint sich die Modernisierung der Anwendungen damit, auf die Umstellung von hierarchischen nach relationalen Datenbank-Systemen zu reduzieren.

Dabei gehen die betroffenen Unternehmen nach unseren Erfahrungen verschiedene Wege, die von der radikalen Umstellung auf die relationale DB-Technologie bis hin zur parallelen Installation eines zusätzlichen Datenbanksystems reichen. Beide Wege werfen neue Fragen auf, doch gerade der zweite Weg scheint besonders problematisch.

Neuentwicklungen werden nur noch auf dem neuen DB-System durchgeführt, während gleichzeitig bewährte Software von der Weiterentwicklung immer mehr abgekoppelt wird und in einer künstlich gehaltenen Umgebung arbeitet. Zur Sicherstellung der Datenkonsistenz weiden spezielle Transferprozeduren eingerichtet. Typischerweise entstehen vermeidbare Kosten, vom doppelten Speicherplatz über doppelte Lizenzgebühren bis hin zur doppelten Vorhaltung von Fachwissen und Personal.

Die Aufgabenstellung läuft demnach auf die Erhaltung bewährter Softwaresysteme bei gleichzeitigen, Sanierung hinaus. Warum?

- Aus Anwendersicht bestehen die Anforderungen, die der alten Software zugrundeliegen, weiter.

- In die alte Software will in aller Regel wegen ihres Umfangs, ihrer Komplexität und ihrer strukturellen Mängel niemand eingreifen.

- Eine Neuprogrammierung scheidet wegen der damit verbundenen Kosten und Unwägbarkeiten (fehlende Spezifikationen) aus.

Sobald die Entscheidung zugunsten eines Datenbank-Systemwechsels gefallen ist, stellt sich die Frage: Wie kann die vorhandene Software saniert werden und wer besitzt dafür professionelles Know-how? Ausgangspunkt für ein von uns durchgeführtes Projekt war die Ablösung von IMS-Datenbanken, wobei die betroffenen Cobol-Programmsysteme nach Adabas migriert werden sollten (siehe Abbildung 1).

Das Projekt begann mit einer Machbarkeitsstudie, in der am Beispiel einer IMS-Datenbank die technische Möglichkeit einer Umstellung untersucht wurde. Die an die Datenbank gekoppelten Anwendungssysteme stellten einen ungefähren Querschnitt der Anforderungen dar. In der sich anschließenden Implementierungsphase wurden die Programme analog zu den "alten" IMS-Versionen umgestellt.

Die neuen Zugriffe auf das relational-orientierte Adabas erfolgten über generierte, zentrale Zugriffsmodule. Der jeweils vom Programm angeforderte Retrieval-Befehl wurde über Parametrisierung an das Zugriffsprogramm weitergereicht und über Direktaufrufe (Adabas-Direct-Calls) realisiert. Die Tests erfolgten in einer separaten Umgebung, wodurch das Tagesgeschäft nicht beeinträchtigt wurde und die volle Funktionalität überprüft werden konnte.

Die beiden Programmversionen (IMS versus Adabas) durchliefen einen Paralleltest. Voraussetzung war ein Datentransfer von Adabas nach IMS zur Vereinheitlichung der Ausgangsdaten. Nach den jeweiligen Programmläufen wurden die Ergebnisse (zum Beispiel Listen, Auswertungen, Statistiken) verglichen. Trotz sehr geringer Fehlerquote in der Produktionsumgebung wurden weiterreichende Überlegungen angestellt:

- Kein restriktives Festhalten an einer Eins-zu-eins-Migration

- ein Abweichen von der alten Zugriffslogik zugunsten des anderen Datenbank-Systems sollte ermöglicht werden. Auf systemspezifische Unterschiede möchte ich hier nicht weiter eingehen.

- Die einheitliche Cobol-Umgebung sollte prinzipiell durch Natural-Programme ergänzt werden können. Ausschlaggebend hierfür waren Performance-Überlegungen.

Die überaus positive Gesamtbewertung der ersten Migrationsphase unterstützte die Entscheidung zur Generalablösung von IMS-Datenbanken innerhalb der kommerziellen Datenverarbeitung des Unternehmens.

Die zweite Phase begann wiederum mit einer Analyse, in der die Datenbank- und Programmsysteme untersucht wurden. Unter Berücksichtigung der Abhängigkeiten der Anwendungssysteme untereinander und ihrer kritischen Zeitpunkte wurde neben der Betrachtung technischer Aspekte eine Aufwandschätzung durchgeführt und ein Zeitrahmen ermittelt. Das neue Umstellungskonzept ging von Zugriffen auf die Adabas-Files über eine SQL-Schnittstelle aus.

Die Machbarkeit wurde über einen Prototypen getestet und mit den generierten Zugriffsmodul-Versionen verglichen. Die für die SQL-Lösung notwendigen zusätzlichen technischen, fachlichen sowie konzeptionellen Voraussetzungen haben wir in die Planung einbezogen.

Wesentlicher Vorteile der SQL-Schnittstelle liegen in dem geringen Programmieraufwand des Zugriffs gegenüber dem Direct-Call und in der relativen Unabhängigkeit der Datenhaltung. In notwendigen Fällen wichen wir von der alten Ablauflogik ab.

Einige Cobol-Programme ließ sich durch Natural-Versionen ersetzen oder der weiteren Verarbeitung voranstellen. Die physischen Datenbank-Zugriffe erfolgten wie im ersten Migrationsabschnitt über zentrale Zugriffsprogramme.

Diese Zugriffsprogramme haben wir systemübergreifend eingerichtet: Aller Zugriffe auf einen File wurden zu einem Programm gebündelt. Den erhöhten Koordinierungsaufwand rechtfertigte eine Vereinheitlichung der Gesamtumlgebung und der Wartungsaufgaben.

Innerhalb der Zugriffsprogramme erfolgte neben dem Zugriff auf den Adabas-File die Anpassung an bestehende Strukturen und spezifischer Parameter. Eingriffe innerhalb der Programmsysteme sollten auf ein Minimum beschränkt und das Risiko, welches durch ein Geflecht weiterer Programmaufrufe unter Verwendung derselben Parameter gegeben war, begrenzt werden.

Während der gesamten Projektdauer wurden die Ergebnisse ständig analysiert und mit der Zielvorgabe in Einklang gebracht. Bei wichtigen Neuerkenntnissen mußten wir das nach den jeweiligen Analysephasen erstellte Umstellungskonzept überarbeiten und gegebenenfalls durch eine neue Spezifizierung verändern. Besonders positiv machte sich die mittelbare Nähe und produktive Zusammenarbeit mit dem Auftraggeber bemerkbar. In turnusmäßigen Review-Meetings wurden Erfahrungen ausgetauscht und die weitere Vorgehensweise abgestimmt.

Im Kern bedeutet Sanierung von Software den Austausch Datenbank-spezifischer Teile der Anwendungsprogramme, verbunden mit einem umfassenden Re-Design. Aus der konkreten Projektabwicklung haben wir eine Methode entwickelt, die an unterschiedliche Anforderungen angepaßt werden kann. Unsere Gesamtkonzeption schließt alle Migrationsphasen ein und ergänzt die Grundanforderung um wichtige Bereiche der Softwaresanierung.

Teilkomponenten sind miteinander verzahnt

Hintergrund war die Überlegung, daß man mit dem Festhalten an der sogenannten Altsoftware die vielleicht letzte und einmalige Chance hat, neben der Umstellung auf ein neues, modernes DBMS in einem Verfahren zusätzliche Vorteile zu nutzen. Das dem Prinzip der evolutionären Software-Entwicklung angepaßte Konzept zur "Sanierung von Altsoftware auf der Basis der Datenbank-Migration" ist unter anderem um die Komponenten Reverse-Engineering, Re-Engineering, Recycling und Re-Design ergänzt worden (siehe Abbildung 2).

Alle Teilkomponenten sind miteinander verzahnt und lassen sich in ihren Aufgaben nicht streng voneinander trennen. Der Anteil der manuellen Tätigkeit ist durch weitgehende Tool-Unterstützung auf das Notwendigste begrenzt worden. Das Kernstück ist geprägt durch die unmittelbare Auseinandersetzung mit der Zielanforderung: Ablösen des veralteten Datenbank-Systems und Umsetzen der daran gekoppelten Programme.

Im Analysemodul werden die Altprogramme systematisch gecheckt. Neben Auswertungslisten erhält man eine umfassende Befehlstabelle. Sie kann durch Parametrisierung individuell zusammengestellt werden. Zusätzlich können die Ergebnisse in ein vorhandenes Datenlexikon überspielt werden.

In einem weiteren Schritt wird die Befehlstabelle überarbeitet und in eine Umsetzungstabelle überführt. Die Altprogramme können dann in der Umsetzungsphase zu einem großen feil maschinell umgestellt werden. Re-Design befaßt sich mit der gesamten Systemumgebung. Inhaltliche Schwerpunkte sind die Überarbeitung des Ist-Zustandes und eine Spezifizierung des zukünftigen Soll-Systems. Ein wesentlicher Bestandteil dieser Phase ist die Datenmodellierung.

Bei der Spezifizierung werden die wirklichen, nicht die im Ist-Zustand implementierten Anforderungen der Unternehmensbereiche berücksichtigt. Auf der konzeptionellen Ebene wird das Re-Design durch die Komponente des Reverse-Engineerings unterstützt. Auf der Anwendungs- beziehungsweise Programmebene erfolgt eine Wiedergewinnung des implementierten Entwurfs. Man erhält zum Beispiel eine verlorengegangene Spezifikation zurück.

In der Phase des Re-Engineerings werden die Programme in eine strukturierte Form überführt. Dieser Teil der Sanierung soll die weitere Bearbeitung erleichtern und die künftige Wartbarkeit verbessern.

Konzept läßt sich individuell anpassen

Das Recycling befaßt sich mit Teilbereichen der Altsoftware. Hier werden der veraltete Code auf die neuen Anforderungen umgesetzt und somit teilweise wiederverwendbare Module gewonnen.

Obwohl sich einige Komponenten stark bedingen, ist unser Konzept aufgrund seines modularen Charakters variabel einsetzbar. Es kann durch eine individuelle Gewichtung an die jeweiligen Bedürfnisse angepaßt werden.

Eine Begrenzung des Sanierungsvorhabens auf das Kernstück schließt zum Beispiel die anderen Komponenten nicht aus. Sie sind dabei nur integrierte Hilfsfunktionen und beziehen sich lediglich auf die unmittelbar umzustellenden Teile des Sourcecodes.

Bei einem zusätzlichen Schwerpunkt auf Re-Engineering würden die Programme der gesamten Systemumgebung mit berücksichtigt werden.

Die Sanierung von Altsoftware auf der Basis einer Migration von Datenbanken ist ein komplexer Vorgang, der die unterschiedlichsten Bereiche eines Unternehmens berührt. Sie erfordert ein fundiertes Fachwissen. Die Vorteile liegen unter anderem in einer Modernisierung der Basissysteme, in einer Vereinheitlichung der Programmsysteme, in der Konzentration des Fachpersonals auf ein Datenbank-System, in einem teilweise deutlich verbessertem Laufzeit-verhalten, im Abbau von Datenredundanzen und nicht mehr benötigter Prozeduren, in einer Reduzierung des Speicherplatzes sowie in einer optimierten Wartung, also sowohl im monetären als auch im konzeptionell-strategischen Bereich.