.shock - Fotolia

Problematisches Re-Hosting von Mainframe-Applikationen

Sollen Mainframe-Anwendungen auf eine neue Umgebung portiert werden, kann sich dies nahezu beliebig komplex gestalten. Beim Re-Hosting ist das Re-Coding eine große Herausforderung.

Bei der Erstellung der ersten Mainframe-Anwendungen haben die Entwickler kaum angenommen, dass sich ihre Routinen auch fünfzig Jahre später im Einsatz befinden werden oder gar das Jahr 2000 erleben.

Modernes Software-Lifecycle-Management, das Sourcecode, Compiler-Reports und Lademodule miteinander dokumentierte und archivierte, gab es noch nicht. Das Ergebnis: Code der nicht immer zur real genutzten Anwendung passt, undurchsichtige, oftmals undokumentierte Programmroutinen und ein generell schwer zu wartender Code.

Auf welchem Code basiert meine Applikation?

Bei einem klassischen Re-Hosting einer Mainframe-Applikation stellt sich nun die Frage, auf welchem Code basiert meine Anwendung nun eigentlich und welche Code-Teile oder Unterprogramme sind nicht mehr relevant? Dazu kommt, dass es nicht nur wichtig ist, den Code selbst zu verstehen, sondern auch die Umgebung, in die er gebettet ist.

Auf Basis des Sourcecode allein lässt sich dies nicht ermitteln. Oft steht eine Dependency Map, eine Auflistung der von einer einzelnen Routine abhängigen anderen Modulen, nicht zur Verfügung. Niemand möchte bei einem Re-Hosting Probleme lösen, die sich auf „toten Progammcode“ beziehen.

Unterschiedliche Basis

Angenommen, diese Hürde ist überwunden, ergeben sich weitere Anforderungen an ein herkömmliches Mainframe-Re-Hosting von Applikationen, wenn die Applikation neu geschrieben oder auch nur re-compiliert werden muss. Aufgrund der unterschiedlichen Zeichensatztabellen für die Daten zwischen dem Mainframe und die herkömmlichen offenen Rechnersysteme ist mit durchaus umfangreicheren Anpassungen zu rechnen. Bei geringem Kenntnisstand über die Programmierung der Applikation und mangelnder Dokumentation eine wahrhaft unlösbare Aufgabe.

Während auf allen herkömmlichen Rechnersystemen – seien sie Windows-, Linux- oder Unix-basiert – für die Zeichensatztabellen und damit die Darstellung von Zeichen ASCII oder das modernere Unicode zum Einsatz kommen, verwenden Mainframes das völlig davon abweichende EBCDIC-Format.

Falls diese Abweichungen nicht im Applikationscode reflektiert werden, ergeben sich Probleme bei Sortierreihenfolgen und eben auch schon bei einfachen Vergleichen, wie sie häufig in Programmen zum Einsatz kommen. Bei ASCII setzt beispielsweise eine aufsteigende Reihenfolge Zahlen vor Großbuchstaben und diese wiederum vor Kleinbuchstaben. Bei EBCDIC ist es umgekehrt.

Thilo Rockmann, Izlabs

 „Beim Ansatz des Software-defined Mainframe bleibt die ursprüngliche Business-Logik erhalten, denn der Code läuft so wie er ist in einem Container auf den nativen Datenformaten ab.“

Thilo Rockmann, LzLabs 

Dieser Unterschied wirkt sich auf viele Aspekte der Programmverarbeitung aus, nicht zuletzt auf sehr häufige programmatische Entscheidungspunkte. Bei dem einfachen Vergleich von zwei Variablen, beispielsweise „if a‘ > A‘ then“ kann das einen tiefgreifenden Effekt haben. Die Businesslogik ist damit komplett verfälscht und Routinen müssen auch unter diesem Aspekt umfangreich angepasst werden.

Zahlendreher

Bei Mainframes werden zudem abweichende numerische Formate verwendet. So besitzt „Packed Decimal“, das häufig bei Dezimalzahlen auf dem Mainframe verwendet wird, keine Entsprechung außerhalb der Mainframe-Welt. So müsste jede einzelne Datenstruktur und jedes Programm auf dieses Format hin überprüft werden. Auch die Adressierung bei Binärformaten ist unterschiedlich: Bei Mainframes kommt Big Endian zum Tragen. Das höchstwertige Byte wird an der kleinsten Adresse gespeichert. Bei x86-Systemen wird Little Endian genutzt. Das kleinstwertige Byte wird zuerst abgelegt. Ganze Zahlen bleiben vielleicht syntaktisch gültig, ihre Werte sind allerdings völlig verändert.

Doch Kodierungsprobleme sind nur die Spitze des Eisbergs. Auch Gleitkommaoperationen werden unterschiedlich ausgeführt, was insbesondere bei finanzmathematischen Applikationen zu erheblichen Unterschieden führen kann, wenn hier nicht aufwendige Anpassungen im Code vorgenommen werden.

Herausforderung Datenbank

Auch die Datenbanken selber bieten eine weitere Herausforderung, denn diese werden auf den unterschiedlichen Systemen unterschiedlich implementiert – Standard SQL (Structured Query Language) auf Mainframe-Datenbanken nutzt einen anderen Dialekt als SQL-Datenbanken auf Nicht-Mainframe-Systemen. Alle SQL-Aufrufe müssen somit umfangreich geprüft und getestet werden.

Auch nutzt die weiterverbreitete Mainframe-Datenbank DB2 eingebettetes statisches SQL. Praktisch alle relationalen Datenbanken verfügen über einen sogenannten Optimizer, der die Datenzugriffe bei Suchanfragen möglichst effizient gestaltet. Bei statischem SQL wird lediglich der Optimizer zum Zeitpunkt der Kompilierung verwendet (oder zu einem anderen Zeitpunkt vor der Programm-Ausführung), während bei fast allen relationalen Datenbanken auf herkömmlichen Rechnersystemen der Optimizer zur Laufzeit ausgeführt wird.

Das bedeutet, dass bei statischem SQL der Zugriffspfad auf die Daten vorberechnet, im Datenbankkatalog gespeichert und der Aufruf zur Laufzeit unverändert ausgeführt wird. Das ist zwar inflexibel, spart aber CPU-Zyklen. Mithin müssen bei einem klassischen Re-Hosting alle SQL-Aufrufe aus dem Katalog wieder im Code integriert werden. Falls die auf ein statisches SQL bezogenen Codeteile im Umfeld einer dynamischen SQL-Datenbank stehen bleiben, ruft dies Fehler hervor. Auch hier müssten Codeanpassungen vorgenommen werden, die aufgrund der grundlegenden Verankerung der Anweisungen des Codes sehr aufwändig sind.

Software-defined Mainframe

Dies sind nur einige Beispiele, warum neu kompilierter, beziehungsweise angepasster Mainframe-Code im Migrationsprozess eine große Hürde darstellen kann. Beim Ansatz des Software-defined Mainframe bleibt die ursprüngliche Business-Logik erhalten, denn der Code läuft so wie er ist in einem Container auf den nativen Datenformaten ab. Damit wird das Risiko beim Re-Hosting von Applikationen und der damit verbundene Testaufwand reduziert, was zu einer besseren Planbarkeit des Projektes führt.

Über den Autor:
Thilo Rockmann ist Chairman and COO bei LzLabs.

Folgen Sie SearchDataCenter.de auch auf Twitter, Google+, Xing und Facebook!

Nächste Schritte

Ist für alle virtuelle Maschinen das gleiche Lifecycle-Management sinnvoll?

Container sicher einsetzen

Best Practices für den sicheren Einsatz von Containern

Artikel wurde zuletzt im Dezember 2017 aktualisiert

Erfahren Sie mehr über Data-Center-Systems-Management

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchNetworking.de

SearchEnterpriseSoftware.de

Close