Großrechner im Container
Von Dale Vecchio, LzLabs
Mainframe-Anwendern stehen gleich in mehrerlei Hinsicht Probleme ins Haus. Zunächst einmal sieht die Verfügbarkeit von Spezialisten in Zukunft düster aus. Im Gegensatz zu heute gehörte vor 20 Jahren die Vermittlung von Mainframe-Kenntnissen, in der Systemprogrammierung und in Entwicklungssprachen wie COBOL und PL/1 oft zum Lehrplan an Hochschulen und Fortbildungseinrichtungen. Jedoch gehen die meisten dieser Experten entweder bald in den Ruhestand oder sind bereits in Rente. Diese Entwicklung war schon lange absehbar. Bereits 1999 wurden etliche Entwickler aus dem Ruhestand geholt, um die Codes fit für das Jahr 2000 zu machen.
Die Experten fehlen
Heute erscheint der Bereich Mainframe für den Nachwuchs immer weniger attraktiv. Gegenüber beliebten Programmiersprachen wie Java ziehen COBOL und PL/1 den Kürzeren. Vereinzelt gibt es Weiterbildungsmaßnahmen, die Unternehmen gemeinsam mit Hochschulen anbieten. Diese richten sich aber an eine jüngere Zielgruppe, wohingegen Unternehmen erfahrene Experten vorziehen. Wobei bei der Auswahl nicht nur die IT-Eignung maßgeblich ist, sondern auch die Erfahrung im Fachbereich, in dem sich die Entwickler bewegen. Quereinsteiger spielen in diesem Segment kaum eine Rolle.
Ein weiteres Problem für den Mainframe ist die Verfügbarkeit alternativer Lösungen – vergleichbare x86-Server sind wesentlich kostengünstiger. Eine Loslösung vom Mainframe hätte auch den Vorteil, dass der Anwender sich aus der vielschichtigen Nutzung von Mainframe-Systemsoftware lösen könnte. Aber eine Migration ist schwierig. Es gibt zu viel alten Code, und die Routinen sind vielfach miteinander verknüpft. Die Mainframe-Anwendungen sind zu sehr in die Funktion des Unternehmens eingewoben, als dass sie im Rahmen einer IT-Umstellung abgeschafft werden könnten.
Schwarz auf Weiß
Dieser Beitrag erschien zuerst in unserer Magazinreihe „Rechenzentren und Infrastruktur“. Einen Überblick mit freien Download-Links zu sämtlichen Einzelheften bekommen Sie online im Pressezentrum des MittelstandsWiki.
Rekodierung möglich, aber schwierig
Mittlerweile gibt es einige Möglichkeiten, mit der eine Mainframe-Migration machbar ist. Einige IT-Dienstleister bieten eine Rekodierung an. Dort arbeiten Entwickler an der Portierung des Codes auf eine x86-Plattform. Dieser neue Code läuft dann nativ auf dem dort verwendeten Betriebssystem und bildet die Funktionsweise des alten Codes ab. Diese Methode ist zwar der grundlegendste Bruch und eine gute Gelegenheit, sein IT-System neu zu konzipieren und sich von alten, ungenutzten Routinen zu verabschieden, birgt aber einige Gefahren.
Zunächst können durch die Rekodierung Fehler entstehen, deren Beseitigung zusätzliche Ressourcen bindet. Eine manuelle Anpassung eines komplexen Systems ist auch sehr zeitaufwendig und eignet sich eher für Projekte mit einem kleineren Umfang. Nicht zuletzt erfordert eine Rekodierung auch organisatorische Anpassungen in der IT-Struktur. Mit einem Nicht-Mainframe-basierten System müssen außerdem bisherige Mainframe-Experten eine neue Rolle finden.
Rekompilierung erübrigt sich: Der LzLabs Software Defined Mainframe übernimmt Legacy Code bruchlos vom alten Mainframe in Container auf preisgünstigen Linux-Plattformen. (Bild: LzLabs)
Doch es gibt auch handfeste technische Gründe für Schwierigkeiten bei der Rekodierung. Ein Life Cycle Management, das Sourcecode, Compiler Reports und Lademodule durchgehend dokumentiert, ist selten vorhanden. Oft existieren nicht dokumentierte Routinen. Ebenso stellt sich die Frage, auf welchem Code die Anwendung tatsächlich basiert und welcher nicht mehr relevant ist. Die Analyse hierfür umfasst daher nicht nur die eigentliche Routine, sondern auch die Umgebung, in die sie eingebunden ist. Eine Dependency Map, die die Abhängigkeit der einzelnen Routinen zueinander auflistet, gibt es in aller Regel nicht. Betrachtet man bei der Rekodierung nicht nur die im laufenden Betrieb verwendeten Programmteile, sondern auch „toten Code“, so könnte das Migrationsteam versuchen, Probleme, die in nicht mehr verwendeten Modulen bestehen, zu lösen – ohne dass dies überhaupt notwendig wäre.
Das Problem liegt im Detail
Bei Rekodierung oder auch nur Rekompilierung kommen auch grundliegende Probleme zum Vorschein. Mainframes und herkömmliche offene Betriebssysteme wie Linux nutzen unterschiedliche Code-Tabellen. Während in der x86-Welt Unicode beziehungsweise ASCII zum Tragen kommt, nutzt der Mainframe mit EBCDIC seine eigene, proprietäre Code-Tabelle. Dies hat umfangreiche Anpassungen zur Folge. Falls die Migrationsbeauftragten diesem Umstand nicht ausreichend beachten, sind Inkompatibilitäten wortwörtlich vorprogrammiert. ASCII beziehungsweise Unicode sortieren aufsteigend: Zahlen vor Großbuchstaben vor Kleinbuchstaben; EBCDIC nutzt die umgekehrte Reihenfolge. Bei sämtlichen Routinen, deren Code unangepasst übernommen wird, verändert sich bei Sortierfolgen das Ergebnis. Damit ändert sich die Business-Logik, und das Resultat wird unbrauchbar.
Ein anderes Beispiel sind abweichende numerische Formate. Das bei Mainframes oft verwendete Format Packed Decimal findet außerhalb der Mainframe-Welt keine Entsprechung. Auch die Adressierung bei Binärformaten ist unterschiedlich. Mainframes nutzen dafür Big Endian und speichern das höchstwertige Byte an der kleinsten Speicheradresse. Anders bei x86-Systemen: Hier kommt Little Endian zum Tragen. Das kleinste Byte erhält die kleinste Adresse. Obwohl ganze Zahlen syntaktisch gültig bleiben, ändern sich ihre Werte vollkommen. Auch führen Mainframes und x86-Server Gleitkommaoperationen unterschiedlich aus, was besonders bei finanzmathematischen Anwendungen schwer wiegt, falls der zu migrierende Code nicht aufwendig angepasst wird.
Dale Vecchio arbeitet als Chief Marketing Officer bei LzLabs. Davor war er 18 Jahre als Research Vice President bei Gartner tätig, wo er sich auf Strategien zur Modernisierung von Anwendungsportfolios spezialisierte. Bevor er einer der weltweit führenden Analysten im Bereich der Anwendungsmodernisierung wurde, begann Dale seine Karriere als Mainframe-Anwendungsentwickler und wurde später zum Systemprogrammierer und Direktor und Vice President of Marketing bei einer Reihe von Technologieunternehmen, darunter Cincom Systems, Systems Center und Viasoft.
LzLabs GmbH, Richtiarkade 16, 8304 Wallisellen, Tel. +41 44-5159876, info@lzlabs.com, www.lzlabs.com
Anwendung im Container
Doch welchen Weg könnten Unternehmen gehen, um unabhängig von ihrer Mainframe-Infrastruktur zu werden? Ein gangbarer Weg wäre die Nutzung von Mainframes in Containern, die – wie zum Beispiel ein Software-defined Mainframe (SDM) – eine entsprechende Laufzeitumgebung bieten, sodass die Applikationssoftware ohne Transformation von Datenformaten und ohne eine Neukompilierung die unterliegende offene Betriebssystemumgebung nutzen kann. Hier versieht ein quasi virtueller Mainframe-Container um die eigentliche Applikation seinen Dienst wie ein physischer, nur unter direkter Verwendung von Linux. Anwendungen müssen nicht neu kompiliert werden, sondern lediglich, wie bei Containern üblich, in das unterliegende Betriebssystem integriert werden. Das kann besonders dann von Vorteil sein, wenn einige Routinen bereits so lange im Unternehmen in Einsatz sind, dass der Zugriff auf die ursprünglichen Entwickler nicht mehr erfolgen kann. Oft sind das die Module, die noch „mit viel Glück“ modifikationsfrei funktionieren.
Um eine Portierung überhaupt zu ermöglichen, sollte der Software-defined Mainframe über adäquate Transaktionsmonitore, Datenbanken und Batch-Verarbeitungsmodule verfügen, die den Systemen auf einem Mainframe entsprechen. So können IT-Verantwortliche Legacy-Code ohne Rekompilierung in einem Container laufen lassen. Da der Container eine abgeschlossene Einheit bildet und über definierte Schnittstellen verfügt, kann Legacy Code beispielsweise mit Java-Anwendungen interagieren, die auf dem Betriebssystem der x86-Server laufen. Damit entfällt auch der Zwang, das gesamte Mainframesystem zu migrieren. Eine schrittweise Entwicklung vom Mainframe hin zur x86-Architektur ist so möglich und risikoarm zu bewerkstelligen.
Damit verändert sich auch die Struktur eines Rechenzentrums. Die Verwendung von x86-Servern ermöglicht flexiblere Planung. Und weil SDMs in Containern arbeiten, sind sie prinzipiell in die Cloud verschiebbar. Einige Anbieter wie Microsoft mit Azure oder Amazon mit AWS können entsprechende virtuelle Mainframes bereits hosten.
