Wenn im Mainframe-Umfeld über Betriebssysteme gesprochen wird, fallen fast automatisch Namen wie z/OS, z/VM oder VSEn. Diese Systeme stehen für geschäftskritische Anwendungen, hochverfügbare Transaktionsverarbeitung und jahrzehntelange Stabilität im Enterprise-Rechenzentrum. Sie sind sichtbar, strategisch eingeplant und tief in IT-Architekturen verankert.
Und dann gibt es da noch CMS. Kein Marketing-Buzzword, kein Cloud-Label, kein Hochglanz-Prospekt. Stattdessen ein System, das seit über fünf Jahrzehnten existiert – und doch außerhalb der Mainframe-Welt nahezu unbekannt ist. Dabei ist es historisch und technisch betrachtet alles andere als unbedeutend. Ganz im Gegenteil: CMS ist einer der stillen Pioniere moderner Virtualisierungskonzepte.

Zeit also, genauer hinzuschauen!

Was ist CMS eigentlich?

CMS steht für Conversational Monitor System. Der Begriff „conversational“ ist dabei kein Zufall, sondern beschreibt den Kern des Systems: eine dialogorientierte, interaktive Arbeitsumgebung für einzelne Benutzer. Anders als klassische Batch-orientierte Großrechnersysteme der 1960er Jahre war CMS darauf ausgelegt, dass ein Nutzer direkt mit dem System „spricht“, also Kommandos eingibt und unmittelbar Ergebnisse erhält.

Entstanden ist CMS Ende der 1960er Jahre im IBM-Umfeld. Zusammen mit dem damaligen Control Program (CP) bildete es eine Kombination, die als CP/CMS bekannt wurde. Das Control Program übernahm die Virtualisierung und stellte virtuelle Maschinen bereit. In jeder dieser virtuellen Maschinen lief ein eigenes CMS-System. Was heute selbstverständlich klingt, war damals revolutionär: Mehrere vollständig isolierte Systeme auf ein und derselben physischen Maschine.

Dieses Prinzip lebt bis heute in z/VM weiter. z/VM ist der direkte Nachfahre des damaligen CP-Ansatzes. Und CMS ist – konzeptionell – immer noch die klassische interaktive Umgebung innerhalb dieser Virtualisierungswelt.

Architektur: Schlank, klar, bewusst getrennt

Um zu verstehen, warum CMS so besonders ist, lohnt sich ein Blick auf die Architektur.

In klassischen Betriebssystemen übernimmt ein Kernel sämtliche Aufgaben: Speicherverwaltung, Prozesssteuerung, Geräteansteuerung, Dateisysteme, Scheduling, Sicherheitsmechanismen und vieles mehr. CMS verfolgt einen anderen Ansatz. Die Verantwortung wird klar aufgeteilt:

• z/VM (bzw. früher CP) kümmert sich um die physische Hardware, CPU-Zuteilung, Speicherzuweisung und I/O-Virtualisierung.
• CMS stellt die Benutzerumgebung innerhalb einer virtuellen Maschine bereit.

Das bedeutet: CMS muss sich nicht um echte Hardware kümmern. Es arbeitet in einer vollständig virtualisierten Umgebung. Dadurch kann es bewusst schlank bleiben. Viele klassische Kernel-Aufgaben sind ausgelagert. CMS konzentriert sich auf das, was für den Benutzer relevant ist: Dateiverwaltung, Kommandoverarbeitung, Programmausführung und Entwicklungswerkzeuge.

In moderner Terminologie würde man sagen: CMS ist ein spezialisiertes Guest Operating System mit klar abgegrenztem Verantwortungsbereich.

Die große Frage: Ist CMS ein „richtiges“ Betriebssystem?

Diese Frage taucht immer wieder auf, gerade wenn man CMS mit Schwergewichten wie z/OS vergleicht. Die Antwort hängt stark davon ab, wie man „Betriebssystem“ definiert.

Historische Perspektive

Historisch betrachtet ist die Sache eindeutig: CMS ist ein Betriebssystem. Es stellt eine vollständige Laufzeitumgebung bereit, besitzt ein eigenes Dateisystemkonzept (Minidisks), bietet eine Kommando-Schnittstelle, unterstützt Programmausführung und stellt Werkzeuge für Entwicklung und Administration zur Verfügung. Für den Benutzer ist es das System, mit dem er arbeitet. Es gibt Login, Arbeitsumgebung, Dateien, Tools, alles, was man erwartet.

In den 1970er und 1980er Jahren war CMS für viele Anwender schlicht „das System“, auf dem sie arbeiteten.

Architektonische Perspektive

Aus architektonischer Sicht ist CMS jedoch eng an z/VM gebunden. Es läuft nicht direkt auf der Hardware. Ohne die Virtualisierungsschicht von z/VM existiert es nicht. Die tatsächliche Kontrolle über Prozessoren, reale Speicherbereiche und physische Geräte liegt vollständig beim Hypervisor.

Doch auch hier lohnt sich ein Perspektivwechsel: Wenn heute ein Linux-System in einer virtuellen Maschine unter VMware oder KVM läuft, zweifelt niemand daran, dass Linux ein echtes Betriebssystem ist. Warum also bei CMS?

Der Unterschied liegt weniger in der „Echtheit“ als in der Zielsetzung. Während z/OS als umfassendes Mehrbenutzersystem für produktive Großanwendungen konzipiert ist und z/VSE traditionell kompaktere Geschäftsanwendungen adressiert, wurde CMS bewusst als interaktive Einbenutzerumgebung innerhalb einer virtualisierten Welt entworfen.

Man könnte also sagen: CMS ist ein vollwertiges Betriebssystem – allerdings eines, das von Anfang an für den Betrieb in einer virtuellen Maschine konzipiert wurde.

Minimalismus als Stärke

Vergleicht man CMS mit modernen Betriebssystemen, fällt sofort die Reduktion auf das Wesentliche auf. Kein grafisches Interface, keine komplexe Treiberlandschaft, keine gigantischen Subsysteme. Stattdessen eine klare Kommandoorientierung und ein strukturiertes Dateikonzept.

Diese Reduktion ist kein Mangel, sondern eine bewusste Designentscheidung. Durch die Auslagerung hardwarebezogener Funktionen an z/VM bleibt CMS übersichtlich und effizient. Es ist schnell startbereit, ressourcenschonend und hervorragend kontrollierbar.

Gerade in Entwicklungs- und Administrationsszenarien ist das ein Vorteil. Wer in einer z/VM-Umgebung arbeitet, nutzt CMS häufig als Werkzeugkasten: für Tests, für Skripte, für Systemarbeiten. Es ist direkt, transparent und zuverlässig.

In einer Zeit, in der Betriebssysteme immer komplexer werden, wirkt CMS fast wie ein technischer Purismus. Und genau dieser Purismus ist Teil seines Reizes.

CMS und die frühe Virtualisierung

Ein Aspekt wird häufig unterschätzt: Die Kombination aus CP und CMS war einer der frühesten produktiven Virtualisierungsansätze weltweit.

Mehrere virtuelle Maschinen, isolierte Umgebungen, parallele Nutzung einer physischen Hardwarebasis, all das wurde hier realisiert, lange bevor Virtualisierung im x86-Umfeld populär wurde. Während andere Systeme noch stark batchorientiert arbeiteten, konnten Nutzer unter CMS interaktiv in ihrer eigenen VM agieren.

Heute sprechen wir selbstverständlich über Cloud, Mandantenfähigkeit und Infrastructure-as-a-Service. Viele dieser Konzepte haben ihre technischen Wurzeln in genau solchen Mainframe-Architekturen. CMS war damit nicht nur ein Betriebssystem, sondern Teil eines Paradigmenwechsels.

Rolle im heutigen Mainframe-Umfeld

Auch wenn CMS außerhalb der Mainframe-Welt kaum bekannt ist, hat es intern weiterhin Bedeutung. In Umgebungen mit z/VM dient es unter anderem:

• als Administrationsumgebung
• als Plattform für Entwicklungs- und Testzwecke
• als leichtgewichtige Service-VM
• als stabiles Werkzeug für Systemprogrammierer

Es konkurriert nicht mit z/OS in Bezug auf Transaktionsverarbeitung oder Großanwendungen. Es ersetzt auch keine Linux-Distributionen, die heute massenhaft unter z/VM betrieben werden. Stattdessen erfüllt es eine spezifische Rolle innerhalb des Ökosystems. Und genau darin liegt seine Daseinsberechtigung.

Einordnung im Vergleich zu z/OS und VSEⁿ

Um CMS besser einzuordnen, lohnt sich der direkte Vergleich:

• z/OS ist das strategische Enterprise-Betriebssystem für hochkritische Produktionsumgebungen. Es bietet riesige Subsysteme, Datenbankintegration, Transaktionsmonitore und umfassende Sicherheitsmechanismen.
• VSEⁿ adressiert traditionell kompaktere Workloads und spezifische Geschäftsanwendungen mit eigener Historie.
• CMS hingegen ist keine Produktionsplattform im klassischen Sinne, sondern eine interaktive, schlanke Arbeitsumgebung innerhalb einer virtuellen Maschine.

Diese Differenzierung zeigt: CMS will nicht alles sein. Es ist kein Alleskönner. Es ist ein Spezialist.

Betriebssystem mit eigenem Charakter

CMS lässt sich nicht sauber in moderne Schubladen pressen. Es ist weder ein monolithisches Großsystem wie z/OS noch ein reiner Hypervisor wie z/VM. Und doch erfüllt es zentrale Kriterien eines Betriebssystems: Es stellt eine Laufzeitumgebung bereit, verwaltet Dateien innerhalb seines Kontextes, ermöglicht Programmausführung und definiert eine klar strukturierte Benutzerinteraktion.

CMS ist damit ein echtes Betriebssystem – allerdings eines mit klar definiertem Einsatzzweck und enger Verzahnung mit der Virtualisierungsschicht von z/VM. Seine Existenz zeigt, dass Betriebssysteme nicht zwangsläufig alles selbst kontrollieren müssen, um vollwertig zu sein. Manchmal ist eine saubere Aufgabenteilung sogar die elegantere Lösung.

Vielleicht steht CMS im Schatten der großen Namen. Vielleicht taucht es in keiner Trendstudie auf. Aber wer sich ernsthaft mit Mainframe-Architekturen beschäftigt, erkennt schnell: Ohne CMS und das dahinterstehende Konzept wäre die Geschichte der Virtualisierung vermutlich anders verlaufen.

Und genau deshalb verdient dieses scheinbar unscheinbare System mehr Aufmerksamkeit – nicht als nostalgisches Relikt, sondern als technischer Klassiker mit erstaunlicher Weitsicht.

Ü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