Dort finden sich heute unter anderem ein /proc-Dateisystem, flock und shlock, Namespace-Werkzeuge, OpenTelemetry-Unterstützung, Java 25, REST-Schnittstellen und ein erweitertes Secrets Management in SAF und RACF. IBM fasst viele dieser Erweiterungen in der Übersicht zu z/OS 3.2 zusammen.
Natürlich wird z/OS dadurch nicht zu Linux, und genau diese Schlussfolgerung wäre auch wenig hilfreich. Interessanter ist vielmehr, dass IBM zunehmend Konzepte und Schnittstellen in die Plattform integriert, die Entwickler und Administratoren aus anderen Systemwelten bereits kennen. Dadurch wird die technische Distanz zwischen Mainframe und Distributed Computing kleiner, ohne dass z/OS seine eigenen Stärken oder seine Architektur aufgeben müsste.
Vielleicht sollten wir deshalb bei der Mainframe-Modernisierung nicht nur darüber sprechen, wie sich Anwendungen verändern lassen. Ebenso sinnvoll wäre es, gelegentlich zu überprüfen, ob unser eigenes Bild von der Plattform überhaupt noch dem entspricht, was technisch inzwischen möglich ist.
UNIX auf z/OS ist keine neue Erfindung
Bevor man /proc, Namespaces oder flock als Zeichen dafür interpretiert, dass z/OS plötzlich „unixiger“ geworden sei, lohnt sich zunächst ein Blick auf die Geschichte der Plattform. UNIX-Funktionalität ist auf z/OS keineswegs neu.
Die z/OS UNIX System Services, meist kurz USS genannt, gehören schon lange zum Betriebssystem. IBM beschreibt diese Umgebung als Bestandteil von z/OS mit API- und Shell-Schnittstellen, die sich an offenen Standards wie POSIX und XPG4 orientieren. Eine Einführung dazu findet sich hier.
Damit verbindet z/OS seit vielen Jahren zwei technische Welten. Auf der einen Seite stehen klassische Mainframe-Konzepte wie Data Sets, TSO, JES und die bekannten Systemdienste. Gleichzeitig existieren Filesysteme, Prozesse, Pipes, Sockets, Shells und zahlreiche UNIX-Werkzeuge. Für langjährige Mainframe-Spezialisten ist das selbstverständlich, außerhalb dieser Welt ist es jedoch erstaunlich wenig bekannt.
Neu ist deshalb nicht die grundsätzliche Idee, UNIX-Konzepte auf z/OS bereitzustellen. Interessanter ist, wie konsequent IBM diese Umgebung weiterentwickelt und dabei Funktionen ergänzt, die aus anderen Plattformen bereits vertraut sind. Gerade z/OS 3.2 liefert dafür einige anschauliche Beispiele.
/proc zeigt sehr gut, wie sich z/OS weiterentwickelt
Wer regelmäßig mit Linux oder anderen UNIX-Systemen arbeitet, kennt /proc als selbstverständlichen Bestandteil der Umgebung. Darüber lassen sich Informationen über Prozesse und Systemzustände auf eine Weise zugänglich machen, die für Administratoren und Entwickler sehr vertraut ist.
Dass /proc inzwischen auch in der z/OS-Welt eine Rolle spielt, ist deshalb fast symbolischer als technisch spektakulär. IBM führt das PROC File System in der Funktionsübersicht von z/OS 3.2 auf. Interessant ist dabei, dass die Funktion nicht ausschließlich an dieses Release gebunden ist. IBM dokumentiert, dass entsprechende Unterstützung über APAR OA62757 auch für z/OS 2.5 und 3.1 verfügbar gemacht wurde.
Gerade dieses Detail zeigt sehr gut, wie Modernisierung auf z/OS häufig funktioniert. Es gibt nicht den einen großen Schnitt, nach dem plötzlich alles neu ist. Viele Funktionen entstehen schrittweise, werden über Service auch für bestehende Releases bereitgestellt und fließen später selbstverständlich in neue Versionen ein.
Für geschäftskritische Systeme ist diese evolutionäre Vorgehensweise durchaus sinnvoll. Unternehmen müssen nicht bei jeder technischen Weiterentwicklung ihre gesamte Plattform neu aufbauen, sondern können neue Funktionen kontrolliert in bestehende Umgebungen integrieren.
Vertraute Werkzeuge machen den Einstieg leichter
Ähnlich verhält es sich mit flock und shlock. Wer Shell-Skripte entwickelt, kennt das Problem, dass mehrere Prozesse nicht gleichzeitig dieselbe Ressource bearbeiten sollen. Dafür braucht man Mechanismen, mit denen sich konkurrierende Abläufe koordinieren lassen.
Mit flock kann auf z/OS innerhalb von Shell-Skripten ein gemeinsamer oder exklusiver Lock auf Dateien und Verzeichnisse gesetzt werden, so die Funktionsbeschreibung von IBM. shlock verfolgt einen verwandten Ansatz mit Lock-Dateien und Prozess-IDs; die Dokumentation dazu findet sich ebenfalls bei IBM.
Das sind keine Funktionen, wegen derer ein Unternehmen seine Plattformstrategie ändern würde. Trotzdem sind sie wichtig, weil sie zeigen, wie sich Arbeitsweisen angleichen. Ein Entwickler, der solche Mechanismen aus einer UNIX- oder Linux-Umgebung kennt, muss auf z/OS nicht zwangsläufig ein völlig fremdes Konzept erlernen, um ein vergleichbares Problem zu lösen.
Gerade solche kleinen Gemeinsamkeiten können die Einstiegshürde erheblich senken. In der täglichen Arbeit sind sie häufig wichtiger als die großen Schlagworte, mit denen Modernisierung sonst gerne beschrieben wird.
Namespaces auf z/OS bedeuten nicht, dass z/OS zu Linux wird
Noch deutlicher wird diese Annäherung bei Namespaces. IBM stellt unter z/OS UNIX inzwischen Werkzeuge wie lsns, nsenter und unshare bereit. Damit lassen sich vorhandene Namespaces untersuchen, Programme in einem anderen Namespace ausführen oder Prozesse innerhalb eines neu erzeugten Namespace starten. IBM beschreibt diese Funktionen in seiner Dokumentation.
Auch hier lohnt sich der Blick auf die Details. IBM hat entsprechende Utilities über APAR OA62870 ebenfalls für frühere z/OS-Versionen verfügbar gemacht. Es handelt sich also nicht um eine einzelne Funktion, die plötzlich mit z/OS 3.2 erschienen ist, sondern um eine Entwicklung, die über mehrere Releases hinweg vorangetrieben wird.
Wer aus der Linux-Welt kommt, denkt beim Begriff Namespace natürlich schnell an Container. Trotzdem wäre es falsch, daraus abzuleiten, dass z/OS nun einfach nach demselben Modell funktioniert wie Linux. Viel spannender ist, dass vertraute Abstraktionen auf unterschiedlichen Plattformen verfügbar werden und damit auch die Kommunikation zwischen Spezialisten leichter wird.
Wenn ein Linux-Administrator und ein z/OS-Spezialist über ähnliche Konzepte sprechen können, wird Integration einfacher. Modernisierung bedeutet in diesem Fall also nicht, dass eine Plattform die andere kopiert. Sie schafft vielmehr gemeinsame technische Bezugspunkte.
OpenTelemetry macht den Mainframe sichtbarer als Teil des gesamten Geschäftsprozesses
Ein besonders interessantes Beispiel dafür ist OpenTelemetry. Moderne Anwendungen bestehen heute oft aus mehreren Plattformen und Technologien. Eine einzelne Geschäftstransaktion kann beispielsweise in einer Webanwendung beginnen, einen Java-Service durchlaufen, über MQ auf den Mainframe gelangen, in CICS verarbeitet werden und anschließend Db2 verwenden.
Aus Sicht des Anwenders ist das ein zusammenhängender Vorgang. Aus Sicht des Monitorings entstehen daraus jedoch schnell verschiedene technische Welten.
Genau an dieser Stelle wird der z/OS OpenTelemetry Emitter interessant. IBM beschreibt ihn als native z/OS-Schnittstelle, mit der OpenTelemetry-konforme Tracing-Daten an entsprechende Collector- und Observability-Lösungen weitergegeben werden können. Damit lassen sich unter anderem CICS, Db2, IMS, MQ und andere kompatible Anwendungen besser in eine gemeinsame Observability-Landschaft einbinden. Informationen dazu finden sich beispielsweise in der IBM-Dokumentation zum z/OS OpenTelemetry Emitter.
Das bedeutet nicht, dass etablierte Mainframe-Werkzeuge dadurch überflüssig werden. SMF, CICS Statistics, Db2 Accounting und andere Datenquellen bleiben unverzichtbar, wenn es darum geht, tief im System zu verstehen, warum sich eine Anwendung auf eine bestimmte Weise verhält.
OpenTelemetry ergänzt diese Werkzeuge um eine andere Perspektive. Es hilft dabei, den Mainframe-Teil wieder als Bestandteil derselben Geschäftstransaktion sichtbar zu machen, statt ihn beim Monitoring künstlich von der restlichen Anwendung zu trennen.
Für mich ist das eines der besten Beispiele dafür, wie moderne Mainframe-Integration heute aussehen kann. Die vorhandenen Mechanismen werden nicht ersetzt. Sie werden in einen größeren Zusammenhang gestellt.
Java 25 auf z/OS ist inzwischen kein exotischer Sonderfall mehr
Auch Java gehört mittlerweile so selbstverständlich zum z/OS-Umfeld, dass die Gegenüberstellung „Java oder Mainframe“ technisch eigentlich nicht mehr sinnvoll ist.
Seit 2026 unterstützt z/OS die IBM Semeru Runtime Certified Edition for z/OS 25. IBM beschreibt z/OS 3.1 und 3.2 inzwischen ausdrücklich als für Java 25 und spätere Versionen ausgelegt. Ältere unterstützte Versionen können weiterhin verwendet werden, neue Funktionen können jedoch Java 25 voraussetzen. Weitere Hinweise dazu finden sich bei IBM.
Das ist deshalb relevant, weil Java auf z/OS außerhalb der Mainframe-Welt gelegentlich noch immer wie eine exotische Zusatztechnologie betrachtet wird. Tatsächlich gehört es längst zur Plattformstrategie und wird unter anderem für moderne Anwendungen, Services und Integrationsszenarien genutzt.
Noch interessanter wird es im Zusammenspiel mit der z/OS Container Platform. IBM stellt inzwischen auch ein Semeru-25-Container-Image für z/OS bereit. Die Details dazu beschreibt IBM in seiner Dokumentation.
Auch hier liegt der eigentliche Fortschritt weniger in einer einzelnen Versionsnummer. Entwickler können zunehmend Werkzeuge und Deployment-Modelle einsetzen, die sie bereits aus anderen Umgebungen kennen, während die Anwendung weiterhin auf z/OS betrieben wird.
Damit verändert sich vor allem der Einstieg in die Plattform.
Der Mainframe besteht längst nicht mehr nur aus 3270
Eines der hartnäckigsten Mainframe-Klischees lautet, dass nahezu jede administrative oder programmatische Aufgabe über einen 3270-Bildschirm erledigt werden müsse.
ISPF und 3270 sind weiterhin wichtige Werkzeuge und werden das auch bleiben. Sie sind aber längst nicht mehr die einzige Möglichkeit, mit z/OS zu arbeiten.
z/OSMF stellt seit Jahren REST-Schnittstellen bereit, über die Anwendungen unter anderem mit Data Sets, UNIX-Dateien, Jobs und Workflows interagieren können. IBM beschreibt diese REST Services als plattform- und sprachunabhängige HTTP-Schnittstellen. Die Data-Set- und File-Schnittstellen sind ebenfalls bei IBM dokumentiert.
Das ist keine Neuerung, die erst mit z/OS 3.2 entstanden ist. Genau deshalb ist sie aber wichtig für das Gesamtbild. Die moderne Plattform entsteht nicht durch eine einzelne große Funktion, sondern durch viele Entwicklungen, die sich über mehrere Releases hinweg zu einer neuen Arbeitsweise verbinden.
REST APIs, Git-basierte Entwicklung, Zowe, moderne IDEs, Java, UNIX-Werkzeuge und Observability ergänzen die klassischen Werkzeuge. ISPF verliert dadurch keineswegs seinen Wert. Es ist nur nicht mehr das einzige sichtbare Gesicht des Mainframes.
Secrets Management zeigt besonders gut, wie Modernisierung ohne Rewrite funktionieren kann
Eine der aus meiner Sicht interessantesten neueren Erweiterungen betrifft das Secrets Management in SAF und RACF.
In modernen Anwendungen müssen Programme häufig auf externe Services, APIs, Datenbanken oder andere geschützte Ressourcen zugreifen. Dafür werden Passwörter, Tokens, API Keys, Zertifikate oder andere Credentials benötigt. Solche Informationen fest im Sourcecode oder in ungeschützten Konfigurationsdateien zu hinterlegen, ist aus heutiger Sicht kaum noch vertretbar.
Mit z/OS 3.2 stellt IBM dafür unter anderem den neuen SAF Callable Service R_Secret (IRRSSCR0) bereit. Anwendungen können damit Secrets abrufen und verwalten, die zentral über RACF beziehungsweise entsprechende Secret-Management-Komponenten bereitgestellt werden. IBM beschreibt die Funktion in seiner Dokumentation.
Besonders interessant ist dabei, dass dieser Zugriff nicht nur für Java gedacht ist. Auch COBOL, PL/I, Assembler und C können entsprechende Services verwenden. Zusätzlich gibt es Java-Schnittstellen und mit irrsadmin auch eine UNIX-Kommandozeilenmöglichkeit.
Gerade für Legacy-Modernisierung ist das ein wichtiger Punkt, weil ein bestehendes COBOL-Programm dadurch ein modernes Sicherheitsprinzip nutzen kann, ohne vorher vollständig neu geschrieben werden zu müssen.
Modernisierung bedeutet hier also nicht, dass das alte Programm verschwindet. Die Anwendung kann weiterbestehen, während sich ihre technische Umgebung und ihr Sicherheitsmodell verbessern.
Genau solche Veränderungen werden in vielen Diskussionen unterschätzt, weil sie weniger spektakulär wirken als ein kompletter Rewrite. In der Praxis können sie jedoch deutlich schneller einen konkreten Nutzen bringen.
Damit wird der Begriff „Legacy“ deutlich komplizierter
Die übliche Gleichung „alte Sprache gleich Legacy, neue Sprache gleich modern“ funktioniert spätestens an dieser Stelle nur noch sehr eingeschränkt.
Ein COBOL-Programm kann über eine moderne Secrets-Infrastruktur auf Credentials zugreifen. Eine CICS-Transaktion kann Teil eines OpenTelemetry-Traces sein. Auf derselben Plattform läuft Java 25, REST APIs sind verfügbar und UNIX-Werkzeuge werden weiter ausgebaut.
COBOL wird dadurch natürlich nicht zu einer neuen Sprache, JCL nicht zu einem modernen Skriptformat und z/OS nicht zu Linux. Das muss es aber auch gar nicht.
Entscheidend ist vielmehr, ob eine Plattform neue Anforderungen aufnehmen kann, ob Anwendungen sicher betrieben werden können, ob Schnittstellen vorhanden sind und ob sich Veränderungen mit vertretbarem Aufwand durchführen lassen.
Unter diesem Blickwinkel ist das Alter einer Technologie nur noch ein Teil der Bewertung.
Ein System kann alt sein und trotzdem gut wartbar bleiben. Eine wesentlich jüngere Anwendung kann dagegen längst problematisch sein, wenn Frameworks nicht mehr unterstützt werden, Abhängigkeiten unbekannt sind oder niemand mehr in der Lage ist, sie zuverlässig zu verändern.
Vielleicht sollten wir den Begriff Legacy deshalb weniger als Altersangabe und stärker als Beschreibung eines Zustands verstehen.
Auch für den Nachwuchs verändert sich dadurch einiges
Diese technische Entwicklung wirkt sich außerdem darauf aus, wie neue Mitarbeiter mit dem Mainframe in Kontakt kommen.
Wer bislang keinerlei z/OS-Erfahrung hat und sofort ausschließlich mit unbekannten Werkzeugen konfrontiert wird, hat verständlicherweise eine hohe Einstiegshürde. Natürlich bleibt tiefes Plattformwissen notwendig, wenn jemand später mit WLM, Sysplex, RACF, CICS oder Db2 auf Systemebene arbeiten möchte.
Der Einstieg kann heute aber wesentlich vertrauter aussehen.
Ein Java-Entwickler findet Java. Wer REST APIs kennt, kann dieses Wissen nutzen. OpenTelemetry ist aus anderen Plattformen bekannt, ebenso /proc, Namespaces oder Shell-Locking. Ein Entwickler aus einer DevSecOps-Umgebung versteht sofort, warum Secrets nicht fest im Sourcecode stehen sollten.
Damit wird aus dem Mainframe nicht automatisch eine vertraute Plattform. Es entstehen aber Anknüpfungspunkte, und genau diese sind für Wissenstransfer ausgesprochen wertvoll.
Lernen funktioniert nun einmal leichter, wenn nicht alles gleichzeitig neu ist.
Gerade für Banken und Versicherungen ist diese Form der Modernisierung interessant
Für Banken, Versicherungen und große öffentliche Organisationen ist diese evolutionäre Entwicklung besonders relevant. Dort laufen häufig Anwendungen, die über Jahrzehnte gewachsen sind und zentrale Geschäftsprozesse abbilden. Bei solchen Systemen kann Modernisierung nicht allein danach beurteilt werden, ob eine Zieltechnologie jünger oder populärer wirkt.
Verfügbarkeit, Sicherheit, Auditierbarkeit, Performance und das Risiko einer Veränderung spielen mindestens dieselbe Rolle.
Wenn ein bestehender Geschäftsprozess über OpenTelemetry besser in eine unternehmensweite Observability-Landschaft eingebunden werden kann, muss er dafür nicht zwangsläufig die Plattform verlassen. Wenn ein COBOL-Programm über RACF ein Secret sicher beziehen kann, ist dafür kein Rewrite erforderlich. Wenn Anwendungen über REST-Schnittstellen erreichbar werden, kann eine bestehende Plattform trotzdem Bestandteil moderner Entwicklungs- und Integrationsprozesse sein.
Damit wird Modernisierung weniger zu einer simplen Frage danach, wie man vom Mainframe wegkommt. Viel sinnvoller ist die Frage, welche Teile verändert werden sollten, welche weiterhin sinnvoll sind und wie beide Seiten miteinander verbunden werden können.
Diese Betrachtung ist anspruchsvoller, aber meistens näher an der Realität.
z/OS-Modernisierung verläuft eher evolutionär als revolutionär
Bei aller Begeisterung für die neuen Funktionen sollte man allerdings vermeiden, sämtliche genannten Technologien als Neuerfindungen von z/OS 3.2 darzustellen.
Gerade /proc und Namespace-Werkzeuge zeigen, dass IBM Funktionen teilweise auch über APARs und PTFs in ältere Releases zurückbringt. REST Services und UNIX System Services existieren ohnehin schon lange. OpenTelemetry entwickelt sich parallel in mehreren Produkten und Subsystemen weiter.
Das macht die Entwicklung aber nicht weniger interessant. Im Gegenteil, es zeigt sehr gut, wie Innovation auf einer geschäftskritischen Plattform funktionieren kann.
Neue Funktionen werden ergänzt, bestehende Releases werden erweitert und neue Technologien Schritt für Schritt mit vorhandenen Mechanismen verbunden. Dadurch können Unternehmen ihre Umgebung weiterentwickeln, ohne bei jeder Neuerung ein komplettes technisches Fundament austauschen zu müssen.
Für hochverfügbare produktive Systeme ist dieser Weg oft deutlich sinnvoller als permanente Revolution.
Vielleicht liegt das eigentliche Legacy-Problem manchmal in unserem Kopf
Technologien verändern sich häufig schneller als die Vorstellungen, die wir von ihnen haben. Beim Mainframe fällt dieser Unterschied besonders auf, weil viele sichtbare Symbole seit Jahrzehnten nahezu unverändert geblieben sind.
Ein 3270-Bildschirm sieht auch heute noch aus wie ein 3270-Bildschirm. JCL wirkt nicht plötzlich moderner, nur weil das zugrunde liegende System neue Schnittstellen bekommen hat. RACF ist ebenfalls kein neuer Markenname, der nach Cloud oder DevSecOps klingt.
Dadurch lässt sich leicht übersehen, was sich unterhalb dieser bekannten Oberfläche verändert.
Das moderne z/OS ersetzt seine traditionellen Konzepte nicht einfach. Es ergänzt sie. 3270 und REST können nebeneinander existieren, ebenso JCL und Container. Ein COBOL-Programm kann moderne Secrets Services verwenden, während SMF und OpenTelemetry unterschiedliche Perspektiven auf denselben Geschäftsprozess liefern.
Gerade diese Mischung macht z/OS für Außenstehende manchmal schwer verständlich. Die Plattform ist weder einfach ein historisches System noch eine Kopie moderner Distributed-Plattformen. Sie verbindet sehr alte und sehr neue Konzepte miteinander.
Und vielleicht ist genau das eine ihrer interessantesten Eigenschaften.
Modernisierung sollte deshalb anders gemessen werden
Wenn Modernisierung ausschließlich daran gemessen wird, wie viele Programme in eine neue Sprache übersetzt oder auf eine andere Plattform verschoben wurden, bleibt ein großer Teil der tatsächlichen Weiterentwicklung unsichtbar.
Modernisierung kann genauso bedeuten, eine bestehende Anwendung über APIs zugänglich zu machen, Credentials aus dem Sourcecode zu entfernen, Observability zu verbessern oder Entwickler mit moderneren Werkzeugen arbeiten zu lassen. Ebenso kann sie darin bestehen, vorhandene Anwendungen an neue Laufzeiten und Services anzubinden.
Solche Schritte sind weniger spektakulär als ein kompletter Rewrite, können im Alltag aber erheblich schneller Nutzen bringen und deutlich weniger Risiko verursachen.
z/OS 3.2 ist deshalb nicht interessant, weil nun auch /proc, flock oder OpenTelemetry auf einer Mainframe-Plattform auftauchen. Entscheidend ist das Muster dahinter. Die Plattform übernimmt zunehmend Konzepte, Schnittstellen und Arbeitsweisen, die außerhalb des Mainframes längst selbstverständlich sind, und verbindet sie mit den Eigenschaften, die Unternehmen von z/OS erwarten.
Damit wird die Frage, ob der Mainframe „modern“ oder „Legacy“ sei, eigentlich immer weniger hilfreich.
Viel sinnvoller wäre es zu fragen, ob sich moderne Anforderungen auf der Plattform vernünftig, sicher und wirtschaftlich umsetzen lassen.
Bei Observability lautet die Antwort inzwischen häufiger ja. Bei APIs ebenfalls. Java und Container gehören längst zum Gesamtbild, und beim Secrets Management zeigt sich dieselbe Entwicklung.
Das bedeutet nicht, dass jede Anwendung auf dem Mainframe bleiben sollte. Es bedeutet genauso wenig, dass eine alte Technologie automatisch modern ist, nur weil sie weiterhin unterstützt wird. Es bedeutet lediglich, dass Entscheidungen auf Grundlage des heutigen technischen Zustands getroffen werden sollten und nicht anhand eines Bildes, das vielleicht vor 15 oder 20 Jahren entstanden ist.
Vielleicht ist deshalb manchmal gar nicht z/OS das eigentliche Legacy-Problem.
Vielleicht ist es unser Bild davon, was z/OS heute noch ist.
Über den Autor: Uwe Graf ist Head of Consulting bei der EasiRun Europa GmbH und gilt auf LinkedIn als eine der profiliertesten Stimmen in Sachen Mainframe-Modernisierung. Seine Beiträge sind fachlich präzise, pointiert – und unverkennbar durch den kleinen Dino, der als Symbol für den Brückenschlag zwischen Tradition und Innovation steht. Für sein Engagement in der Mainframe-Community wurde er 2025 sowohl als IBM Champion als auch als „Influential Mainframer“ von planetmainframe.com ausgezeichnet
