Erst einmal: Herzlichen Glückwunsch zum 60. Geburtstag des IBM Mainframes! Wusstest du, dass der Mainframe ein wesentlicher Bestandteil des Mondlande-Projektes war, das 1961 von Präsident John F. Kennedy initiiert wurde? – Die Plattform wurde ursprünglich genau zu diesem Zweck entwickelt. IBM investierte damals beeindruckende 5 Milliarden Dollar in das Projekt, eine enorme Summe zu dieser Zeit.

In den letzten 60 Jahren (seit 1964) hat sich die Plattform kontinuierlich weiterentwickelt, bekannt als S/370, S/390 und jetzt IBM Z. Sie hat sich an Branchentrends und Marktanforderungen angepasst und unterstützt moderne Codes wie Java, C, GO und Python, neben den traditionellen Cobol und PL/1. Heute treibt sie Technologien für Hybrid Cloud, KI, Analytik, DevOps, Container, Linux und Open Source an, während sie ihre Kernprinzipien der Datenintegrität, Zuverlässigkeit, Verfügbarkeit und Wartbarkeit beibehält. Als die langlebigste Technologie in der Branche ist die Beständigkeit des IBM Mainframes ein Beweis für seine kontinuierliche Modernisierung und seinen erheblichen Einfluss auf die Weltwirtschaft.

Entgegen der Wahrnehmung von Mainframes als „Legacy-Technologie“ sind diese Systeme keineswegs obsolet. Der Mainframe, der erstmals 1964 eingeführt wurde, hat sich ständig weiterentwickelt. Die heutigen Modelle verfügen über hochmoderne 7-nm-Chip-Technologie, mit einer Roadmap, die bald 5-nm-Chips und bis 2030 2-nm-Chips anvisiert.

Der Vergleich von Mainframes mit der Mercedes-Benz S-Klasse verdeutlicht diese Evolution. Genau wie die S-Klasse, die erstmals 1972 auf den Markt kam und ein Höhepunkt moderner Ingenieurskunst bleibt, repräsentieren auch Mainframes Spitzentechnologie.

Mainframes haben noch immer Hochkonjunktur in bestimmten Bereichen, insbesondere in Branchen wie dem Bankwesen. Beispielsweise verlassen sich die meisten der weltweit größten Banken, einschließlich der größten Bank Chinas und der profitabelsten Privatbank Indiens, HDFC, auf Mainframes für ihre Kernsysteme. HDFC hat die Mainframe-Technologie erst vor etwa zehn Jahren übernommen.

Was macht die Mainframe-Architektur so einzigartig und unverzichtbar?

Die Mainframe-Architektur zeichnet sich durch eine Fähigkeit zur „vertikalen Skalierung“ aus, d.h. das Skalieren der IT-Produktion innerhalb eines hochintegrierten Hardware/Software-Stacks. Zum Beispiel kann ein vollständig ausgestatteter Mainframe mit 200 Verarbeitungseinheiten (sogenannten: „PUs“) 215.089 MIPS (Millionen Anweisungen pro Sekunde) erreichen und bis zu 25 Milliarden verschlüsselte Transaktionen täglich verarbeiten!! Um dies in Perspektive zu setzen: Die weltweit größte Bank verarbeitet täglich 1,5 Milliarden CICS-Transaktionen, mit einem Spitzenwert von 14.000 Transaktionen pro Sekunde [!!!], auf einem einzelnen Mainframe mit 160.000 MIPS in einer hochverfügbaren Umgebung.

Vertikales Skalieren bietet mehrere Vorteile. Betrachten wir eine Transaktion mit mehreren Arbeitseinheiten („Unit of Work“) wie einen Verkauf, was Einnahmenbuchungen, Forderungseinträge, Lagerbestandsanpassungen usw. in verschiedenen Datenbanken erfordert. Wenn ein einzelner Schritt fehlschlägt, entsteht eine Daten-Inkonsistenz. Auf einem Mainframe jedoch sind diese Schritte (=CICS-Transaktion) eng innerhalb einer einzigen Maschine koordiniert, was sowohl hohe Effizienz als auch Zuverlässigkeit gewährleistet.

Sicherheit ist ein weiterer wichtiger Vorteil: Bis zu 25 Milliarden verschlüsselte Transaktionen pro Tag können in einer hochsicheren Maschine verarbeitet werden, was für Compliance und Datensicherheit entscheidend ist.

Übrigens: Während sich das vertikale Skalieren auf dem Mainframe auf Effizienz und Zuverlässigkeit konzentriert, erfolgt das horizontale Skalieren typischerweise innerhalb eines Netzwerks, hauptsächlich in der Cloud.

Mainframe-Modernisierung: Was ist das? Und wie wird es richtig gemacht?

Zunächst, was bedeutet „Mainframe-Modernisierung“?

Der Begriff „Legacy-Technologie“ wird oft wahllos auf das gesamte Mainframe-Ökosystem angewendet. Hardware und Betriebssysteme sind jedoch nicht „veraltet“, sondern hochmodern. Das Label „Legacy“ bezieht sich genauer gesagt auf die Anwendungsebene: Dies sind Programme in nicht mehr gängigen Programmiersprachen (z.B. COBOL, PL/1), die oft schlecht dokumentiert und stark von Middleware (z.B. CICS, JES) abhängig sind. Genau hier sollte ein Modernisierungsprojekt ansetzen: den Legacy-Code in moderne Programmiersprachen zu überführen, einschließlich ordnungsgemäßer Dokumentation. In einigen Fällen kann die Verwendung von LinuxONE (Mainframe-Architektur mit Linux als Betriebssystem) ratsam sein. Die typische Zielsprache für solche Modernisierungsprojekte ist oft Java – mehr dazu weiter unten. Zum Einstieg: Java läuft kostenlos auf Z.

Im Hype um Cloud-Strategien wird „Modernisierung“ manchmal missverstanden und falsch umgesetzt: Fälschlicherweise wird zunächst die hochmoderne Hardware (d.h. der Mainframe) infrage gestellt – und dann komplexe Anwendungslandschaften, die für vertikal skalierende Hardware konzipiert sind, werden in Cloud-Umgebungen migriert, die für horizontales Skalieren ausgelegt sind. Eine solche Migration bringt viele Herausforderungen (bis hin zum völligen Scheitern) mit sich, da diese Anwendungslandschaften (und die zugrunde liegenden Geschäftsprozesse) nicht für das horizontale Skalieren in der Cloud ausgelegt sind.

Was du über Java wissen solltest: In der Java Virtual Machine (JVM) wird der Java-Programmcode immer auf die aktuelle Hardware übersetzt. Der Optimierer oder Compiler weiß sehr genau, was am besten funktioniert, und übersetzt den Programmcode immer in Maschinensprache, sodass der Code mit maximaler Effizienz ausgeführt wird. Im Allgemeinen laufen Java-Programme daher schneller als COBOL-Programme. Diese Tatsache überrascht manche „Mainframer“ immer wieder, da angenommen wird, dass nativer Code (z.B. COBOL) schneller laufen sollte. Ein vor 20 Jahren kompiliertes COBOL-Programm nutzt jedoch keine neuen Hardware-Befehle; und es ist eine Tatsache, dass insbesondere in regulierten Umgebungen Updates durch Neukompilierung auf der neuen Hardware nicht (so häufig wie nötig) stattfinden.

Fun Fact: Heute ist die z-Plattform die schnellste und leistungsstärkste Java-Plattform, teilweise aufgrund der „parallel garbage collection“. Der Z Garbage Collector (ZGC) ist ein skalierbarer Garbage Collector mit niedriger Latenz. ZGC führt alle intensiven Aufgaben gleichzeitig aus, ohne die Programmausführung zu unterbrechen.

Ich hatte diesen Überblick zur Mainframe-Modernisierung auf LinkedIn gepostet, und das löste eine leidenschaftliche Debatte mit vielen Beiträgen von IT-Profis und interessanten Beobachtungen aus der Praxis aus. Du kannst diese Debatte auf LinkedIn (HIER klicken) verfolgen; weiter unten habe ich auch einige dieser Kommentare/Beiträge (ohne Namensnennung) einkopiert:

  • ”It’s a legendary system not a legacy system!”
  • ” Java was a fad, a craze. Enthusiasm for it appears short-lived. I got hook once but got bored eventually. Over the years they added OO to Cobol & PL/I. To modernize just exploit the OO enhancements. That appears more feasible than uprooting all Cobol & PL/I code. Also, OO databases never took over SQL relational databases. Even if java is free, I dont think installations will save by converting to java as the conversion effort will be costly & that cost includes introducing bugs to a mission critical system that has been doing its job with lesser or no problems. Training staff to learn Cobol & PL/I is modernization to me. I would recommend that path instead. To me, It is a lot easier to read & understand Cobol & PL/I. A programmer who knows other languages can easily adapt to Cobol & PL/I.”
  • ”the advantage of Java, apart from being a tool to make great coffee, is that developers can learn it on a workstation or a PC, so you can attract a young audience. But they will not learn to develop with a large system with hundreds of thousands of parallel users in mind, using systems for databases and transaction handling. They will always think PC and single system.
    Mainframe development is less an issue of the language used, but a way to understand the entire infrastructure of a mainframe. And that is ingrained in z/OS or z/VM COBOL and PL/1. Plus, there is still the issue of having to use JVM and JIT virtual systems for running Java which is a performance killer. And performance, stability and security is the main thing on any large system. There is a reason why mainframes don’t even know the traditional Blue Screen of Death…”
  • Not designed for horizontal scaling in the cloud. This sums it up. A large part of my last 12 years has been moving and modernising things to go to cloud but too many organisations miss this point. You can’t move something to cloud that cannot take advantage of the way cloud works and expect a great outcome. As with all things, the right tool for the job.
  • ”the days when up scaling and horizontally scaling on a mainframe in both directions, up and down, on a mainframe were a drag have gone away a long time ago with all kinds of flexibility in terms of additional processor cores and data storage. That used to be a great argument for the cloud. These days mainframes often run the cloud by proving the resources needed in a VM that can be scaled up and down.”
  • ” I think it’s served certain folks with a vested interest to brand mainframe as obsolete when it is not. Cloud and mainframe are different tools suitable for different circumstances. Yes that certainly is one of many arguments for cloud. I don’t feel this need been a cloud v mainframe situation at all. Early in my cloud career (which came after years doing on premises infrastructure) I was guilty of thinking that the cloud was the ‚be all, end all‘. I’ve learned a lot since then, and would offer the same caution that naturally the mainframe cannot be the answer to every problem either.”
  • Zum Weiterlesen

  • Die Zukunft des Mainframe (Teil I)
  • Die Zukunft des Mainframe (Teil II): Hörtipps zu Mainframe Podcasts
  • Die Zukunft des Mainframe (Teil III): Weltweite KYNDRYL-Umfrage zur IT Strategie für den Mainframe
  • Author

    Der Autor ist Manager in der Softwareindustrie mit internationaler Expertise: Prokurist bei einem der großen Beratungshäuser - Verantwortung für den Aufbau eines IT Entwicklungszentrums am Offshore-Standort Bangalore - Director M&A bei einem Softwarehaus in Berlin.