In vielen Unternehmen gibt es eine über viele Jahrzehnte entstandene Anwendungs-Landschaft. Viele Kernbereiche wurden zu einer Zeit entwickelt, als nur ein Mainframe die notwendige Leistung und Sicherheit lieferte.
Die Mainframe Anwendungen laufen seit Jahrzehnten stabil, aber die Anzahl der Spezialisten, die den Betrieb und die notwendigen Anpassungen benötigt werden, nimmt ab.
Also ist eine Umstellung auf Techniken, die heute an Hochschulen vermittelt werden, mittelfristig zu planen.
Vielfach wurde versucht, einen Unix Server zu kaufen, darauf eine Oracle Datenbank zu betrieben und in einem BigBang die gesamte Anwendungs-Landschaft umzustellen. Die meisten dieser Versuche führten zum Weiterbetrieb des Mainframes auf unbestimmte Zeit.
Die Begründung ist einfach, die Business Analysten, die vor 30 Jahren die fachlichen Konzepte für die Mainframe Anwendungen erstellt haben, sind schon lange in Rente. Die fachlichen Änderungen, die seitdem umzusetzen waren, sind nicht vollständig dokumentiert. Ein aktuelles Fachkonzept für das gesamte Anwendungssystem, das für die komplette Neuimplementierung benötigt würde, existiert also nicht.
In der Zeit, in der dieses Fachkonzept durch Analyse der alten Programm Sourcen und intensiven Gesprächen mit dem jeweils zuständigen Fachbereichen entsteht, ergeben sich neue gesetzliche Anforderungen oder die alten Programme müssen an geänderte betrieblichen Anforderungen angepasst werden.
Es ist also unmöglich, den fachlichen Ist-Zustand der Anwendungs-Landschaft zu beschreiben und anschliessend in der neuen Technik umzusetzen, zu testen und in Betrieb zu nehmen.
Für Teilbereiche, die innerhalb einiger Wochen zu analysieren, umzusetzen, zu testen und in Betrieb zu nehmen sind, wäre es möglich. Aber dazu muss die neue Technik auf die Datenquellen des Mainframe zugreifen können, oder der Mainframe muss auf die neue Datenbank zugreifen.
Auch wenn es in der neuen Java Welt die beste Middleware als Open Source gibt, wenn von der alten Welt darauf nicht zugreifen werden kann, eine Umstellung würde den nicht durchführbaren Big-Bang bedeuten.
Aber aus der Java Welt kann man die Middleware, die der Mainframe beherrscht, nutzen.
Middleware sind zum einen die Datenbank und zum anderen ein asynchroner Transaktionsmonitor, also für einem IBM Mainframe IBM DB2 und IBM MQS.
Beides kostet Geld, ja viel Geld. Dieses Geld wird aber schon seit Jahren ausgegeben, und der Betrag ändert sich nicht (oder kaum), wenn statt eines COBOL Programmes ein Java Programm die Datenbankoperation auslöst.
Viele Entwickler in der Java Welt meinen, eine DB2 ist keine „Oracle Datenbank“, es gibt nichts besseres und sicheres als Oracle.
Dass die Backend Systeme der grossen Banken und Bank-Organisationen nutzen DB2, wird leider auch im Informatikstudium nicht vermittelt.
Weiterhin sind viele Java Entwickler der Meinung, dass DB2 ja kaum genutzt wird (siehe „2 Takt Diesel“, davon gibt auch nur wenige, aber 70% des Welthandels werden damit abgewickelt, denn sie treiben die Hochseeschiffe an) und das SQL von DB2 läuft nicht auf Oracle.
Beide können ANSI-SQL und fast alle Erweiterungen sind kompatible.
Wobei, alles, was über den ANSI Standard hinausgeht, sollte gut begründet sein. Es gibt ja auch andere Datenbanksysteme, die weit weniger kosten, und auf die später umgestiegen werden könnte.
Und ein IBM MQS kann von Java auch als JMS angesprochen werden. IBM WebSphere, also der Java Applicatioin Server von IBM, hat als technische Basis auch MQS, deshalb hat IBM das Produkt zu „WebSphere MQ“ umbenannt.
Sollten doch später eine Middleware um Einsatz kommen, die nicht Syntax-kompatible ist, sind die Zugriffe auf die Middleware so zu kapseln, dass später nur einige wenige Module schnell angepasst werden müssen.
Es gibt auch Vorgehensweisen, bei denen Java auf vorhandene Mainframe Module zugreifen kann, aber unser Ziel ist es ja, die Mainframe Technik abzulösen.
Also, von der Java Seite ist alles technisch möglich, nur muss auch auf der Mainframe Seite administrativ die Zugriffe zugelassen werden.
Und es gibt noch ein weiteres Problem, den Mainframe gibt es seit über 50 Jahren, DB2 erst seit knapp 40 Jahren und MQS gute 20 Jahre.
Es gibt also Technik, die heute noch genutzt wird, die älter ist.
Ein Beispiel ist IMS DB, eine hierarchische Datenbank. Hier ist die Zugriffslogik und damit auch die Transaktionslogik anders. Am besten stellt man sich IMS DB als eine Art XML oder ein daraus abgeleitetes DOM vor. Es gibt eine Kunden, zu diesem Kunden gehört ein Konto. Wechselt dieses Konto den Inhaber, wird nicht die Rollentabelle geändert, sondern das Konto wird innerhalb einer Transaktion bei alten Inhaber physikalisch gelöscht und beim neuen Inhaber eingefügt, also umgehängt.
Hier macht es Sinn, noch auf dem Mainframe die Zugriffsmodule und vor allem die Zugriffslogik auf das Relationale Modell, also DB2, umzustellen.
Eine andere Technik zum Speichern ist VSAM. Dieses ist ein Index Sequentielle transaktionsorientierte Systemdienst. Diese Basis nutzt auch DB2 auf dem Mainframe. Die Zugriffslogik ist identisch, es ist also einfach möglich, bestehende VSAM Zugriffsmodule auf DB2 umzustellen. Es ist zu prüfen, ob ggf. durch den zusätzlichen DB2 Workload Lizenzkosten entstehen.
Eine „normale“ Sequentielle Datei gibt es auch in Java, diese anzusprechen ist einfach.
Aber hier gibt es vielleicht ein Problem bei Zahlen. Auf dem Mainframe werden gerne BCD Zahlen (COMP-3) genutzt. Hier wird jede Ziffer in einem Halb-Byte (4 Bit) gespeichert und das letzte Halb-Byte ist das Vorzeichen.
Binärzahlen, also Integer oder Long sind auf dem Mainframe eher unüblich, bereiten aber auch Probleme.
Weiterhin gibt die Zahlen, bei denen jede Ziffer in einem Byte gespeichert wird. Ist die Zahl vorzeichenbehaftet, wird das Minus-Zeichen im vorletzten Halb-Byte gespeichert.
Schickt man solche Zahlenwerte durch eine Zeichensatz-Umwandlung, entsteht Chaos. Also zuerst alle numerischen Variablen auf dem Mainframe als druckbare Zeichen definieren, bei denen das Vorzeichen der führende Trenner ist, also “ -123.45″.
Gerne wird auch in einem ersten Schritt versucht, die bisherigen COBOL Sourcen auf einen Unix Rechner laufen zu lassen. Es gibt einen Hersteller, der eine entsprechende Umgebung seit Jahrzehnten bereitstellt. Ob es sinnvoll ist, eine Anwendung auf eine andere Plattform zu portieren, hierbei aber auch in Zukunft auf die alten Knowhow Träger angewiesen zu sein, ist zu hinterfragen. Und es lauern noch einige Fallstricke, sei es nur der andere Zeichensatz, so dass auf einmal „A > 1“ wahr ist (EBCDIC versus ASCII) oder das Format eines Timestamp Strings.
Die Umstellung erfordert also mehrere Schritte und sollte die komplette Ablösung zum Ziel haben.
Im ersten Schritt ist technisch zu analysieren, wo noch „Vor DB2 Technik“, also IMS DB, VSAM oder anderen Nicht DB2 Datenhaltung genutzt wird.
Diese Anwendungen sind dann umzustellen, entweder weiterhin als Mainframe Anwendung, die jetzt DB2 nutzt, oder falls möglich und sinnvoll, gleich als Java Anwendung.
Im zweiten Schritt, möglichst zeitgleich mit dem ersten Schritt, sind auf dem Host alle Schnittstellen, insbesondere die Zwischendateien, zu prüfen. Alle binär kodierten Inhalte (COMP-3 Zahlen und ähnliches) sind auf druckbare Zeichen umzustellen.
Jetzt können die weiteren Schritte geplant werden. Einzelne Anwendungen, ja sogar einzelne Module können umgestellt werden.
Die noch 3270 Terminals nutzenden Dialoganwendungen sind sicher ein guter Anfang.
Sollte in den Präsentation Modulen, die die Bildschirmsteuerung durchführen, auch Fachlogik enthalten sein, ist diese natürlich zuerst auszulagern, sprich statt eines „PERFORM“ wird ein „CALL“ durchgeführt.
Die Fachlogik der Anwendungen kann noch auf dem Mainframe liegen. Hier ist eine Kapsel über MQS zu erstellen. Statt des „CALL“ aus dem COBOL Programm wird vom Java Programm eine MQS Message mit Namen und Schnittstellen-Parameter gesendet, die auf dem Host empfangen wird. Das zentrale Modul erkennt am Namen, welchen Call es durchzuführen hat, ruft das Fachmodul auf und sendet das Ergebnis per MQS zurück.
Häufig werden die Schnittstellen Parameter in XML (SOAP) verpackt oder es wird eine REST Schnittstelle genutzt. Die Umwandung ist jedoch aufwendig, insbesondere auf dem Mainframe. Besser ist es, dem Mainframe als Parameter einen String mit einer festen Länge zu senden. Wie in Java ein String aus verschiedenen Parametern aufzubauen und später wieder zu zerlegen ist, weiss jeder Programmierer, hierfür gibt es String.format(). Auf dem Mainframe gibt es eine entsprechende Copystrecke. Ein Tool, das auf Basis einer COBOL Copystrecke die passende Java Formatanweisung, auf Basis einer Java Formatanweisung eine COBOL Copystrecke oder auf Basis einer fachlichen Schnittstellenbeschreibung beides erzeugt, ist für einen erfahrenen Programmierer eine Fingerübung.
Im Zweifel sollte eine aktuell genutzte fachliche Logik nur an einer Stelle, sprich in einer Sprache, implementiert werden. Wenn also alle Dialog Module auf Java umgestellt sind (jetzt kann auch der bisherige Transaktion Monitor CICS oder IMS DC auf dem Mainframe abgeschaltet werden), kann mit der Umstellung der Fachmodule von COBOL auf Java begonnen werden.
Neue Fachmodule, die nur von Java Anwendungen genutzt werden, wurden natürlich sofort in Java erstellt.
Jetzt bleibt nur noch das „Batch-Geschäft“. Also die Batch-Anwendungen, die meist nachts laufen und die grossen Datenmengen bearbeiten. Vielfach nutzen die Batch-Programme auch Fachmodule, die auch in Dialog Anwendungen genutzt werden, die per CALL aufgerufen werden.
Eine Umstellung auf Java ist leicht zu programmieren, aber die Anforderungen an die Performance sind schwer zu erfüllen. Das Problem ist nicht die Rechenleistung auf dem Java Application Server, sondern die Datenbankanbindung.
Auf dem Host schreibt DB2 seine Ergebnisse auf eine Speicherstelle, kurz gesagt einen Speicher Chip, und das COBOL Programm liest seine Daten genau von diesem Speicher Chip, verarbeitet die Daten und schreibt die Ergebnisse auf einen Speicher Chip, von dem anschließend DB2 die zu schreibenden Daten liest.
Bei einer JDBC Anbindung schreibt die Datenbank ihre Ergebnisse auf eine Speicherstelle, der serverseitige Teil der JDBC Verbindung liest die Daten, konvertiert eventuell den Zeichensatz, packt die Daten in einen „JDBC Umschlag“ und übergibt seinen Umschlag an den Netzwerktreiber im Betriebssystem, dieser packt den Umschlag in den „logischen Netzwerk Umschlag“ ein und übergibt seinen Umschlag an die Netzwerk Hardware. Dort werden dann Pakete gepackt und auf die Reise geschickt. Sicher gibt auf der Reise noch einige „Zollkontrollen“, sprich Firewalls, wo die Pakete ausgepackt und auf den zulässigen Inhalt geprüft werden. Auf dem Java Server angekommen, werden die Pakete auf Vollständigkeit geprüft. Dort werden die vollständigen Pakete, dann die Umschläge ausgepackt und endlich kann der JDBC Treiber die Daten empfangen und ausliefern.
Bei einer Dialoganwendung, wo viele Benutzer jeweils einen Datensatz aus der Datenbank holen, bearbeiten und wieder auf die Datenbank, fällt der im Hintergrund ablaufende Aufwand nicht auf, aber bei einem Batchprogramm, das Millionen von Datensätzen in kürzester Zeit lesen und schreiben muss, fällt der Aufwand durch eine deutlich längere Laufzeit auf.
Am Besten liegen der Datenbank und der Java Server im Netz dicht bei einander, also möglich nur wenige Router, Load Balancer und vor allem Firewalls dazwischen. Aber auch dieses kann eventuell nicht reichen, die geforderte Laufzeit zu erreichen.
Dann sollten der Netzwerk Verkehr vermindert werden. Hierbei kommt es nicht auf die Menge an Daten, also Kilobytes, sondern auf die Anzahl an Paketen an. Ein Pakete mit 1000 Bytes Daten dürfte im Vergleich zu 10 Paketen mit jeweils 10 Bytes Daten schneller übertragen werden.
Eine gute Idee die Verlagerung der Logik auf den Datenbank Server. Über Scalar Functions, Common Expression Tables und ähnlichen Dingen kann viel Logik direkt abgebildet werden und mittels eine Updates oder eines „Insert from Select“ vom Java Server auf dem Datenbank Server ausgelöst werden.
Stored Procedures sind eine weiter Möglichkeit, dieser Vorteil wird jedoch durch die Einführung einer weiteren Programmiersprache erkauft.
Ein weitere Weg ist, auf dem Datenbank Server (Teile) der Tabellen zu entladen, der FTP auf einen Anwendungsserver zu senden. Hier wird dann die Datei als sequentielle Datei verarbeitet, eine Ausgabedatei geschrieben, diese per FTP auf den Datenbank Server geschickt, in eine temporäre Tabelle geladen und schliesslich ersetzt der Inhalt der temporären Tabelle Teile der Datenbank Tabelle. Das Vorgehen ist sehr schnell, ein ähnliches Vorgehen habe ich mehrfach bei sehr grossen Migrationen auf dem Mainframe genutzt, aber der Ablauf ist sehr komplex und fehleranfällig, bedarf also eines genauen Tests und einer ständigen Überwachung.
Soll Logik auf dem Datenbank Server ausgeführt werden, ist sicherzustellen, dass auch ein für den späteren Einsatz geplante Datenbank diese Logik versteht.
Wie Sie sehen, ist die Umstellung nicht trivial, wird mehrere Jahre dauern und erfordert in der Anfangsphase viele Mainframe Spezialisten, wobei der Bedarf im Laufe der Umstellung abnimmt. Und es braucht Spezialisten, die die Mainframe und die Java Welt kennen, einerseits als Dolmetscher zwischen den Mainframe und den Java Spezialisten und auch als Übersetzer der Mainframe Logik auf die Java Logik.