Thought Leadership
.jpg "Erfolgreiche BS2000-Migration 1")
Die Wirkung von kühlem Bier und hochprozentigen Getränken ist bekannt. Allerdings ging es nicht um den Genuss dieser Getränke, sondern um die toolgestützte Migration eines komplexen Softwareprojektes zur Verwaltung von Alkoholika von BS2000 nach Linux.
Wie üblich, gab es dabei wieder eine Reihe neuer Herausforderungen. Bestätigt wurde erneut der toolbasierte Ansatz.
Neue Gehege für BIBER und ZEBRA
ITZBund ist der IT-Dienstleister des Bundes. Mit seinem Portfolio deckt das ITZBund das gesamte Aufgabenspektrum an Dienstleistungen für die öffentliche Verwaltung ab (Software-Entwicklung und -Beratung, Hosting und Betrieb, Service Desk,…). Im Projekt sollten zwei IT-Lösungen (sog. Verfahren) zur Festsetzung und Erhebung der Bier- bzw. Branntweinsteuer nach Linux migriert werden. Mit den Verfahren BIBER (Biersteuerberechnung) und ZEBRA (Zentralisierung des Brennens unter Abfindung) werden ca. 220.000 Bescheide jährlich mit einem Steueraufkommen von 740 Millionen Euro pro Jahr erzeugt. Die Verfahren stellten sich als typisches Legacy-Projekt dar: In COBOL entwickelt, historisch gewachsen und seit mehr als 30 Jahren im Einsatz. BIBER und ZEBRA wurden auf BS2000 betrieben und es kamen typische BS2000-Werkzeuge zum Einsatz. Technisch bestand das System aus 60 interaktiven Online-Programmen (IFG-Masken) unter der Steuerung des Transaktionsmonitors UTM und aus 300 Batchprogrammen. Zu deren Steuerung und Verwaltung wurden ca. 200 SDF-Jobs eingesetzt. Die Datenverwaltung basierte auf ca. 220 SAM-, ISAM- und LEASY-Dateien.
Was Du heute kannst besorgen…
Software-Migration ist nur mit Migrationswerkzeugen sinnvoll. pro et con verfügt über eine firmeneigene Toolbox für die Software-Migration. Mit dieser konnten alle Migrationspfade des Projektes unterstützt werden. Die folgende Abbildung 1 dokumentiert diese und die eingesetzten Migrationswerkzeuge.
Abb. 1: Migrationspfade und Softwarewerkzeuge im Projekt. Quelle: pro et con GmbH
Dass qualitativ gute Migrationswerkzeuge die Projektlaufzeit verkürzen und Budget schonen, ist nicht neu. Das Projekt konnte nur so im vorgegebenen, engen Zeitrahmen realisiert werden. Aber auch die Erfahrung: “Fertige Werkzeuge gibt es nicht!” wurde bestätigt. Konkret musste z.B. FiRe das “Rückwärtslesen” von LEASY-Dateien lernen. Bei diesen Anpassungen favorisieren wir die Erweiterung der Tools gegenüber einer manuellen Anpassung des Sourcecodes. In frühen Projektstadien kann nicht eingeschätzt werden, warum und wie häufig schon konvertierte Programme erneut konvertiert werden müssen. Die manuelle Anpassung müsste dann jedes Mal wiederholt werden. Die Toolbox enthält darüber hinaus auch Systemkomponenten für das Zielsystem. Ein Beispiel dafür ist MidaS (Middleware als Service). Dieses von pro et con entwickelte Tool ersetzt den BS2000-Transaktionsmonitor UTM im Zielsystem. Durch einen frühzeitigen Lasttest wurde nachgewiesen, dass die Performance von MidaS den praktischen Anforderungen genügt. Deshalb konnte auf den Einsatz von kostenpflichtiger Standardsoftware verzichtet werden.
Und es funktioniert doch!
COBOL ist die am weitesten verbreitete Programmiersprache in Legacy-Systemen. Eine Entscheidung in Migrationsprojekten ist, ob COBOL im Zielsystem erhalten bleiben soll. Die Praxis zeigt, dass an COBOL trotz aller Kritik meist festgehalten wird. Dies lässt sich nicht durch vernünftige Argumente, sondern nur durch „Beharrungsvermögen“ erklären. Motiviert wird das mit Skepsis gegenüber der toolbasierten Konvertierung (Kann das technisch überhaupt funktionieren? Ist der Zielcode wartbar? Wie ist im Ergebnis die Performance?) . Mehrere erfolgreiche Projekte mit Sprachkonvertierungen haben bewiesen, dass diese Skepsis unbegründet ist, wenn ein qualifiziertes Konvertierungswerkzeug existiert.
ITZBund entschied sich für den Wechsel von COBOL zu Java, nachdem die Argumente dafür überzeugt hatten: Eine Sprachkonvertierung ist nur beim Einsatz spezialisierter Konvertierungswerkzeuge, sogenannter Translatoren, erfolgreich. Die Entwicklung eines Translators gehört zu den kreativsten und anspruchsvollsten Aufgaben der Software-Migration. Translatoren arbeiten in Analogie zu einem Compiler. Es werden Quellprogramme über verschiedene Zwischenstufen in ausführbaren Zielcode übersetzt. Für die Entwicklung eines Translators ist vertieftes Wissen der Compilertechnik notwendig. Seine Neuentwicklung verursacht mehrere Mannjahre an Aufwand.
In Abbildung 2 wird die Architektur eines Translators am Beispiel einer COBOL-Java-Konvertierung dokumentiert:
Abb. 2: Translator-Architektur für COBOL-Java-Konvertierung. Quelle: pro et con GmbH
Ein sogenannter Parser liest das COBOL-Programm einschließlich der dazugehörigen Copybooks ein und erzeugt daraus einen internen Syntaxbaum, der das vollständige COBOL-Altprogramm repräsentiert. Da der Parser eine wichtige Komponente in Migrationswerkzeugen ist, spricht man auch von „parserbasierten“ Werkzeugen. Im Syntaxbaum sind z.B. auch alle Kommentare vermerkt, um sie bei Bedarf in den Zielcode wieder einfügen zu können. Hier und in weiteren Teilaufgaben unterscheidet sich der Translator vom Compiler, welcher Kommentare in seinem Übersetzungsprozess verwirft. Der nächste Konvertierungsschritt besteht in der Überführung des COBOL-Syntaxbaums in einen äquivalenten Java-Syntaxbaum durch einen Transformator. Er arbeitet auf Basis einer Abbildungsvorschrift, in der definiert ist, wie einzelne COBOL-Konstrukte (etwa Definitionen und Anweisungen) in Java abgebildet werden. Eine solche Vorschrift zu erarbeiten, ist eine der anspruchsvollsten Aufgaben in der Translatorentwicklung. Je genauer die Abbildung, desto größer ist die semantische Äquivalenz zwischen Quell- und Zielcode und umso einfacher lässt sich der Zielcode zukünftig warten.
Im dritten Schritt wird der komplexe Java-Syntaxbaum durch einen Postprozessor in einzelne Syntaxbäume zerteilt, welche die Programmstruktur (Java-Klassen und -Packages) des zukünftigen Java-Programms repräsentieren. Auch dieser Konvertierungsschritt ist neu gegenüber dem allgemeinen Compiler-Modell. In dieser Phase erfolgt auch die Integration der Kommentare, sie werden als Knoten an die entsprechenden Stellen im Java-Syntaxbaum platziert. Der letzte Konvertierungsschritt besteht in der Generierung von Java-Klassen und -Packages aus den einzelnen, internen Java-Syntaxbäumen durch einen Generator. Die eigentliche (Sprach)-Konvertierung vollzieht sich im Translator demnach auf der Ebene von Syntaxbäumen und nicht auf Quelltextniveau.
Der in Abbildung 1 aufgeführte, firmeneigene Translator „CoJaC“ (COBOL to Java Converter) basiert auf dieser Architektur. CoJaC wurde im Projekt für die COBOL zu Java-Konvertierung eingesetzt.
Wissen ist Macht
Die erste Phase eines Migrationsprojektes beinhaltet ein toolbasiertes Reverse Engineering mit dem firmeneigenen Werkzeug Flow Graph Manipulator (FGM). Dabei wird ein spezielles Augenmerk auf jene Aspekte geworfen, die Risiken für die Migration darstellen. Im vorliegenden Fall lagen diese vor allem in der Datenhaltung. Laut definiertem Migrationspfad sollten ISAM- und LEASY-Dateien durch FiRe in Oracle-Tabellen migriert werden. In der Analyse wurde z.B. folgende Besonderheit identifiziert: Die dynamischen Inhalte aus den Dateien werden bei der Programmausführung durch statische Inhalte (Konstanten) aus den Programmen angereichert. Schon vor der Migration wurde deshalb das Encoding der Daten und Quelltexte (inkl. Konstanten) vereinheitlicht. Dieser Punkt betraf also nicht nur eine Anpassung von FiRe, sondern erstreckte sich auch auf weitere Aspekte der Migration. Je früher solche vermeintlichen Kleinigkeiten im Projekt erkannt werden, desto geringer ist der Aufwand ihrer Behebung, da eventuell schon eine Konfiguration der Migrationswerkzeuge ausreicht.
Versuch macht klug
Nach einer detaillierten Analyse und ausgestattet mit einem vollen Werkzeugkasten sollte man davon ausgehen, dass die eigentliche Migration direkt in der Breite gestartet werden kann. Erfahrungen belegen etwas anderes. In der erstmaligen Kombination von Werkzeugen und Kundenanforderungen stecken unbekannte Herausforderungen. Aus diesem Grund wurde vor dem Gesamtprojekt ein Pilot migriert, welcher einen vertikalen Schnitt durch die Anwendung (Maske(n), Programm(e), Jobs, Daten) geboten hat. Dadurch werden alle Migrationspfade einmal durchlaufen und die Tools und Technologien (zumindest zum Teil) genutzt. Dieses Vorgehen erwies sich als nützlich, wurden doch wesentliche Erkenntnisse gewonnen. So erfolgte z.B. die Entscheidung, das Drucken in ein separates Tool auszulagern und nicht über die in den Werkzeugen existierenden Lösungen abzubilden. Aufgrund dieses Vorgehens wurden zusätzliche Anforderungen erkannt und vor der eigentlichen Migration implementiert. Das reduzierte das Risiko, Werkzeuganpassungen neben den Aufgaben der Migration vornehmen zu müssen.
Divide et impera
Bei einem Migrationsprojekt, welches alle Facetten von Legacy-Systemen widerspiegelt, besteht die Herausforderung, die Komplexität der Migrations- und Testprozesse zu reduzieren. Im vorliegenden Projekt wurde dem Rechnung getragen, indem ITZBund die Anwendung in einzelne Pakete aufteilte. Die Basis für die Aufteilung waren die (Geschäfts-)Prozesse, welche sinnvoll in Pakete zusammengefasst wurden. Die dadurch mögliche Parallelisierung von Migration und Test zeigte im Projekt viele Vorteile. Ein wesentlicher Punkt war auch die Kommunikation zu den Fachleuten vom ITZBund. Diese kennen die Prozesse und konnten valide Testdaten bereitstellen. Diese Daten und die definierten Prozesse boten auch die Möglichkeit der Testautomatisierung. Dazu wurden die Prozesse und die passenden Daten normiert und in Testfälle überführt. Im Laufe des Projektes entstand eine komplexe Testdatenbank. Vor Auslieferung einer neuen Version wurden die Testfälle jedes Mal automatisch durchlaufen, was den Aufwand für den Test enorm verminderte. Durch die Aufteilung in einzelne Pakete blieben Migration und Test beherrschbar und es existierte stets ein Überblick über den Projektfortschritt.
Man lernt nie aus
Am 12.09.2016 wurde das Projekt produktiv geschaltet. Erneut wurde mit diesem Projekt bewiesen, dass der von pro et con verfolgte, toolbasierte Ansatz funktioniert. Technologien und Werkzeuge können noch so erprobt und ausgereift sein, jedes neue Migrationsprojekt bietet neue Herausforderungen. Dabei entfällt auch immer ein nicht unwesentlicher Aufwand auf unsere Projektpartner. Diesen hat ITZBund durch Fachwissen und aktive Mitarbeit vorbildlich geleistet. Nur durch eine so enge Zusammenarbeit können Migrationsprojekte erfolgreich verlaufen.
Die Autoren:
Dr.-Ing. habil. Uwe Kaiser forschte und lehrte von 1977 – 1994 an der TU Karl-Marx-Stadt/Chemnitz zu compilergenerierenden Werkzeugen und Meta-Werkzeugen. Seit 1994 ist er geschäftsführender Gesellschafter der pro et con GmbH. Dipl.-Ing (BA) Denis Uhlig arbeitet seit 2006 als Softwareentwickler bei der pro et con GmbH. Sein Spezialgebiet sind parserbasierte Werkzeuge für die Software-Migration.
