21st Century Software wird am akzeptierten Mainframe-Änderungsprotokoll gemessen

Zusammenfassung

• 21st Century Software wird am besten anhand des akzeptierten Mainframe-Änderungsprotokolls bewertet: dem Nachweis, dass eine z/OS- oder VSE-Änderung autorisiert, angewendet, beobachtet, wiederherstellbar und ohne Schaffung einer neuen fragilen Abhängigkeit an den Betrieb zurückgegeben wurde.
• Sein stärkstes öffentliches Argument ist die Änderungsverfolgung, Back-up- und Wiederherstellungsnachweise, Migrationskontrollen, VSE-Kontinuität und spezialisierte Unterstützung. Das schwächste Argument ist das übliche Käuferrisiko bei proprietärer Mainframe-Software: Lizenzkosten, Integrationsaufwand, Personalabhängigkeit und die Schwierigkeit, Kundenergebnisse ohne direkte Tests auf Systemebene nachzuweisen.

Das akzeptierte Änderungsprotokoll ist die eigentliche Werteinheit

Für einen modernen Softwarekäufer ist es einfach, den Großrechner als kulturelles Argument darzustellen. Er ist alt, also muss er entweder eine Belastung oder ein Zeichen der Widerstandsfähigkeit sein. Diese Sichtweise übersieht die Arbeit, die Enterprise-Mainframe-Teams tatsächlich leisten. Ihr wiederkehrendes Problem ist nicht, ob die Plattform modern ist. Es geht darum, ob eine geplante Änderung, eine Notfallkorrektur, eine Speicherverschiebung, eine Sicherheitsanpassung oder eine Wiederherstellungsmaßnahme zu einer akzeptierten betrieblichen Tatsache werden kann, ohne dass die Infrastruktur das nächste Mal schwerer zu verstehen ist.

Das ist der richtige Ansatz, um 21st Century Software (oft als 21CS abgekürzt) zu betrachten. Das Unternehmen versucht nicht, ein neues Anwendungsteam durch die Geschichte der grünen Bildschirme zu inspirieren. Es verkauft in Umgebungen, in denen ein Fehler in einem Library-Member, einem JCL-Stream, bei der Speichermigration, in einem Backup-Set oder in der VSE-Betriebsumgebung Batch-Fenster verzögern, die Wiederherstellung erschweren, Audit-Befunde verursachen oder die knappe Aufmerksamkeit erfahrener Systemprogrammierer beanspruchen kann. In dieser Welt ist das akzeptierte Änderungsprotokoll die entscheidende Produktabgrenzung.

Eine Änderung ist nicht abgeschlossen, nur weil ein Werkzeug meldet, dass sie ausgeführt wurde. Sie ist abgeschlossen, wenn das Team eine Reihe schwierigerer Fragen beantworten kann: Was hat sich geändert? Wer hat es geändert? Wurde das geänderte Objekt geschützt? Existiert das richtige Backup? Wurde der Job-Stream validiert? Gibt es einen Rollback-Pfad? Ist der neue Zustand mit dem Rest der Umgebung kompatibel? Und ist das Runbook noch korrekt?

21CS hat sein öffentliches Portfolio um diese Kontrollfläche herum aufgebaut. Die Website beschreibt Produkte für das z/OS-Änderungsmanagement, den Datenschutz, die unterbrechungsfreie Speichermigration, die Anbindung an Cloud-Objektspeicher, den Dataset-Transfer, die Leistungs- und Kapazitätsanalyse, die JCL-Validierung und VSEn – den Fortsetzungspfad für Organisationen, die nach dem End-of-Service von IBM z/VSE 6.2 eine unterstützte VSE-Betriebsumgebung benötigen.

IBMs eigene Partnerliste beschreibt 21CS als IBM-Z-Mainframe-Softwarepartner mit Arbeiten in den Bereichen Resilienz, Verschlüsselung, Performance- und Kapazitätsmanagement, Cloud-Enablement und Entwicklerproduktivität und verweist auf globale Niederlassungen und die Unterstützung kritischer Infrastrukturen. Die 21CS-Story hängt daher weniger von allgemeinen Modernisierungsversprechen ab, sondern vielmehr von einem präzisen betrieblichen Versprechen: Reduzieren Sie die Unsicherheit bei Änderungen, ohne dem Mainframe-Team die Kontrolle zu entziehen.

Dieses Versprechen ist plausibel, weil die Arbeit real ist. Es ist jedoch teuer, es zu validieren. Die Zuverlässigkeit eines Mainframes entsteht nicht durch eine Produktseite, eine Demo, ein Partnerabzeichen oder eine einzige erfolgreiche Migrationsbehauptung. Sie entsteht durch monotone Wiederholung unter Richtliniendruck. Jede akzeptierte Änderung muss die Mischung aus LPARs, RACF-Regeln, JES-Verhalten, SMF-Daten, Scheduler-Konventionen, Bandrichtlinien, Dataset-Benennungsgewohnheiten, Unterschieden bei Speichercontrollern, Wiederherstellungszielen und menschlichen Genehmigungen überstehen.

Ein Werkzeug, das das Risiko an einer Stelle senkt, kann es an anderer Stelle erhöhen, wenn es spröde Ausstiege, schlecht dokumentierte Verfahren, nicht unterstützte Releases, einen seltenen Spezialisten oder einen neuen Servicepfad erfordert, den an einem Sonntagmorgen niemand bedienen kann. 21CS verdient eine Analyse auf dieser Ebene, denn dort erzielen Kunden entweder den Wert, den sie kaufen, oder stellen fest, dass sie eine weitere Abhängigkeit erworben haben.

Die stärkste Investitionsthese für 21CS ist nicht, dass Mainframes noch am Leben sind. Jüngste Branchenumfragen und IBM-Kommentare machen bereits deutlich, dass viele große Organisationen weiterhin kritische Workloads auf IBM Z betreiben, während sie mit Fachkräften, Modernisierung und komplexen Umgebungen kämpfen. Die stärkere These ist enger gefasst: Wenn diese Umgebungen sich weiter verändern, benötigen sie Tools und Unterstützung, die Änderungen in wiederherstellbare Nachweise umwandeln. Das akzeptierte Änderungsprotokoll ist die Anzeigetafel.

Was 21CS tatsächlich zur Änderungsoberfläche beiträgt

21CS sollte von den Systemen getrennt werden, die es umgibt. Es handelt sich nicht um IBM-Z-Hardware. Es ist nicht die Bank, Versicherung, Behörde oder der Betreiber öffentlicher Infrastruktur, dessen Anwendungen auf der Plattform laufen. Es handelt sich nicht um eine generische Jahr-2000-Software-Referenz. Die relevante Einheit ist ein Mainframe-Software- und Support-Unternehmen, dessen Angebote sich um z/OS-Operationen, VSE-Kontinuität, Speicherbewegung, Batch-Wiederherstellbarkeit, JCL-Validierung, Cloud-Datenbewegung und Performance-Einblicke drehen.

Das Portfolio ist breit, aber sein Schwerpunkt ist eng genug, um beschrieben zu werden. SENTINELn wird als z/OS-Änderungsmanagement-Produkt präsentiert, das Datasets überwacht, verfolgt und wiederherstellt, mit Sicherungen auf Member-Ebene, Audit-Trails, Vergleichsfunktionen, kontrolliertem Zugriff und Befehlszeilenintegration.

Das ist wichtig, weil viele schädliche Mainframe-Vorfälle als gewöhnliche Bearbeitungen beginnen: Ein Library-Member wird aktualisiert, eine Produktions-Load-Library unterscheidet sich von einer bekannten Baseline, ein Konfigurations-Dataset ändert sich während der Wartung, oder ein global verteiltes Team kann nicht feststellen, welche Änderung ein späteres Symptom verursacht hat. In diesen Fällen ist das wertvolle Artefakt nicht das Marketing-Label „Änderungsmanagement“.

Es ist die Fähigkeit, das geänderte Member zu identifizieren, frühere Versionen zu bewahren, zu dokumentieren, warum die Bearbeitung stattfand, Zustände zu vergleichen und die richtige Version wiederherzustellen, ohne die Wiederherstellung in eine forensische Jagd zu verwandeln.

Die IBM-gebrandete Seite des 21CS-Portfolios verstärkt dieses Muster. IBM Z Backup Resiliency ist auf die kontinuierliche Erfassung von Dataset-Aktivitäten, SMF-Analysen, Backup-Status, automatisierte Wiederherstellungs-JCL-Generierung und Berichte ausgerichtet, die Wiederherstellungslücken aufdecken. IBM z/OS Change Tracker umfasst Echtzeitüberwachung, Sicherungen auf Member-Ebene, Dokumentation der Bearbeitungsgründe, Überwachung von Produktions-Load-Libraries und Umgebungsvergleiche.

IBM Z JCL Expert zielt darauf ab, JCL und Parameter vor oder während Terminänderungen zu validieren, einschließlich Fällen wie Massen-JCL-Updates, Produktionskontrollprüfungen, REST-API-Validierung und Pipeline-Nutzung. Diese Produkte ersetzen nicht die eigene Steuerungstafel, den Scheduler oder die Speicherrichtlinien der Umgebung. Sie sind nur dann wertvoll, wenn sie die Nachweise liefern, die ein Team akzeptieren muss: Dieser Job wurde geprüft, dieses Member wurde geändert, dieses Backup deckt das Dataset ab, diese Umgebung unterscheidet sich oder stimmt überein, dieser Wiederherstellungspfad ist bekannt.

Weitere 21CS-Produkte adressieren angrenzende Teile derselben Kette. TRANSVERSEn wird als z/OS-basierte, herstellerunabhängige, unterbrechungsfreie Festplattenspeicher-Migrationslösung mit dynamischen Swap- und Switchback-Funktionen beschrieben. VECTORn zielt auf den aktiven Dataset-Transport zwischen Speichersystemen ab, während Anwendungen online bleiben. Tape/Assist unterstützt die Bandmigration und die Metadatenkontinuität über Bandverwaltungsumgebungen wie CA-1 und RMM hinweg. STRATUSn verbindet z/OS-Daten mit S3-kompatiblem Objektspeicher ohne zwischengeschaltete Server, mit bidirektionalem Transport und Code-Page-Übersetzung.

OPTIMAn wird als Mainframe-Performance- und Kapazitätsanalyseprodukt beschrieben, das große Mengen an SMF-Daten verarbeitet und Prognosen, Workload-Simulation und Finanzberichterstattung unterstützt. VSEn ist das Element für die Betriebssystemkontinuität und spiegelt die Quellcode-Lizenzvereinbarung von 21CS mit IBM für z/VSE und den Anspruch wider, neuere IBM-Z-Hardware zu unterstützen.

Eine nützliche Sichtweise ist die als Karte wiederkehrender betrieblicher Aufgaben. Ein Enterprise-Team ändert Code und Konfiguration, validiert Jobs, sichert Nicht-Datenbank-Daten, migriert Speicher, bewahrt Bandmetadaten, verschiebt ausgewählte Daten in hybride Umgebungen, überwacht die Leistung und schützt eine kleinere VSE-Umgebung davor, aus dem unterstützten Pfad zu fallen. 21CS ist nicht deshalb glaubwürdig, weil jede Behauptung für bare Münze genommen werden kann. Es ist glaubwürdig, soweit diese Angebote die tatsächlichen Punkte angreifen, an denen Änderungen normalerweise Nachweise verlieren.

Das Portfolio wirft auch eine kommerzielle Frage auf. Ein Käufer lizenziert nicht einfach eine Komfortfunktion. Er erwirbt möglicherweise eine langfristige Support-Beziehung, Produktschulungen, Integrationsarbeit, Verlängerungsverpflichtungen und eine Abhängigkeit von der Kontinuität eines spezialisierten Anbieters. Dieser Handel ist rational, wenn manueller Aufwand, Ausfallrisiko, Audit-Exposition oder verzögerte Modernisierung teurer sind als der Anbieter-Stack.

Er ist nicht rational, wenn die Umgebung bereits denselben akzeptierten Änderungsnachweis mit IBM-nativen Werkzeugen, bestehenden Scheduler-Kontrollen, disziplinierter SMP/E-Praxis, Dienstprogrammen von Speicheranbietern und interner Expertise erbringen kann.

Wiederholte Produktionsaufgaben, nicht einmalige Transformation

Der betriebliche Wert von 21CS hängt von wiederholten Aufgaben ab. Mainframe-Umgebungen werden oft durch außergewöhnliche Momente beschrieben: eine Migration, eine Katastrophe, ein Modernisierungsprogramm, eine regulatorische Frist. Diese Momente sind wichtig, aber die Kostenbasis entsteht durch Wiederholung. Nächtliche und wöchentliche Batch-Fenster laufen weiter. Datasets werden geöffnet, geschlossen, kopiert, gesichert, zurückgerufen, gelöscht und wiederhergestellt. Scheduler-Definitionen ändern sich. JCL-Streams verändern sich nach Anwendungsupdates, Fusionen oder Workload-Verschiebungen. Speicherhardware erreicht Aktualisierungspunkte.

Sicherheitsrichtlinien werden verschärft. Neue Mitarbeiter müssen alte Konventionen verstehen. Ein VSE-Kunde sieht sich einem weiteren Hardwarezyklus gegenüber. Jede Aktion stellt dieselbe stille Frage: Kann das Team beweisen, was passiert ist?

In diesem Licht ist SENTINELn nicht nur ein Wiederherstellungsprodukt. Es ist ein Versuch, die Überwachungskosten gewöhnlicher Änderungen zu senken. Wenn ein geschütztes Dataset den Benutzer, den Job, das Programm, das Datum, die Uhrzeit und die Aktion auf Member-Ebene aufzeichnet, muss der leitende Systemprogrammierer nicht mehr jede kleine Bearbeitung aus dem Gedächtnis, verstreuten Änderungstickets und Job-Protokollen rekonstruieren. Wenn Sicherungen zum Zeitpunkt der Änderung erstellt und nebeneinander verglichen werden können, erhält das Team einen schnelleren Pfad vom Symptom zur vermuteten Ursache.

Wenn Kommentare mit der Aktualisierung erfasst werden, hat der nächste Prüfer Kontext statt nur eines Zeitstempels. Wenn der Befehlszeilenzugriff in eine Pipeline integriert werden kann, hat der Änderungsnachweis die Chance, mit modernen Bereitstellungspraktiken zu reisen, anstatt in einer separaten Konsole zu verweilen.

Derselbe Blickwinkel der wiederholten Aufgaben gilt auch für die JCL-Validierung. JCL-Fehler sind selten intellektuell interessant, aber sie sind operativ teuer, wenn sie zur falschen Zeit auftreten. Ein fehlendes Dataset, ein Syntaxfehler, eine nicht aufgelöste Scheduler-Variable, ein inaktiver Db2-Plan oder ein Berechtigungsproblem können einen Batch-Lauf ruinieren und die Produktionssteuerung durch Warteschlangen vermeidbarer Prüfungen schicken.

IBM Z JCL Expert und VERIFIn von 21CS adressieren diese Problemklasse, indem sie die Validierung vorverlagern und Schnittstellen unterstützen, die Entwickler und Produktionsanalysten nutzen können, bevor Jobs den kritischen Pfad erreichen. Der Punkt ist nicht, dass die Validierung schlechte Anwendungslogik gut macht. Das tut sie nicht. Der Punkt ist, dass sie verhindern kann, dass mechanische Fehler ein knappes Batch-Fenster verbrauchen oder erst nach der Terminierung entdeckt werden.

Backup- und Wiederherstellungsnachweise sind eine weitere wiederholte Aufgabe. IBM Z Backup Resiliency ist um nicht-datenbankverwaltete Daten wie sequenzielle Dateien und VSAM-Dateien herum konzipiert, bei denen das Wiederherstellungswissen manueller sein kann als bei datenbankverwalteten Ressourcen. Öffentliches Material beschreibt die kontinuierliche Erfassung von Dataset-Aktivitäten, Backup-Analysen, Dashboard-Indikatoren, Berichte und generierte Wiederherstellungs-JCL. Dies ist direkt relevant für das akzeptierte Änderungsprotokoll, denn viele reale Vorfälle sind keine plattformweiten Katastrophen.

Es handelt sich um selektive Beschädigungen, versehentliche Überschreibungen, falsche Versionen oder Batch-Kaskaden, bei denen das Team wissen muss, welches Backup verwendbar ist und welche nachgelagerten Auswirkungen folgen. Ein Wiederherstellungsprodukt ist am wertvollsten, wenn es „wir haben wahrscheinlich ein Backup“ in „dieses Dataset kann mit dieser Methode wiederhergestellt werden, hier ist die generierte JCL, und hier ist der Nachweis der damit verbundenen Aktivität“ verwandelt.

Die Speichermigration folgt demselben Muster in größerem Maßstab. Festplatten- und Bandmigrationen werden gefährlich, wenn sie als isolierte Projekte und nicht als wiederkehrende betriebliche Verpflichtungen behandelt werden. Hardware-Aktualisierung, Anbieterwechsel, Verschlüsselungsarbeiten, Tiering und Konsolidierung erfordern alle Bewegung, während die Anwendungen weiterlaufen. TRANSVERSEn, VECTORn und Tape/Assist werden daher nicht danach beurteilt, ob das Bewegen von Daten modern klingt.

Sie werden danach beurteilt, ob die Bewegung die Metadaten, die Katalogintegrität, die Anwendungsverfügbarkeit, die Ausweichoptionen und die Fortschrittstransparenz bewahrt. Die Behauptung einer unterbrechungsfreien dynamischen Swap-Funktion ist nur dann aussagekräftig, wenn die Operatoren den Fortschritt beobachten, Konsistenzgruppen überprüfen, bei Bedarf zurückfallen und nachweisen können, dass sich Katalog- und Ablaufattribute nicht verändert haben.

Deshalb ist der Blickwinkel des Artikels das akzeptierte Änderungsprotokoll und nicht die Produktliste. Mainframe-Teams kaufen keine Sammlung attraktiver Verben. Sie kaufen weniger unklare Nächte. Die wiederholten Aufgaben sind der Ort, an dem sich dieses Versprechen entweder bewährt oder scheitert.

Überwachungskosten sind das versteckte Mainframe-Budget

Lizenz- und Wartungsausgaben sind sichtbar. Die Überwachungskosten sind schwerer zu beziffern, könnten aber der größere Grund sein, warum ein Unternehmen einen Anbieter wie 21CS in Betracht zieht. Eine Mainframe-Umgebung kann mit beeindruckender Stabilität laufen und dennoch kostspielige menschliche Aufmerksamkeit erfordern, weil die Expertise spezialisiert ist, die Fehlerfolgen hoch sind und sich im Laufe der Jahre durch lokale Anpassungen viele Verfahren angesammelt haben. Erfahrene Mitarbeiter führen nicht nur Befehle aus. Sie tragen das Gedächtnis der Umgebung.

Öffentliche Marktdaten deuten auf den Druck hin. Kyndryls Mainframe-Modernisierungsumfrage 2025 ergab, dass sieben von zehn Organisationen Schwierigkeiten hatten, qualifizierte Talente für die Modernisierung von Mainframes zu finden. IBMs eigene Diskussion über Mainframe-Trends hebt Verfügbarkeit, Talentabwanderung und komplexe Umgebungen als anhaltende Probleme hervor. Ein Fachkräftemangel beweist nicht automatisch, dass ein bestimmtes Softwareprodukt den Kauf wert ist, aber er verändert die Rechnung des Käufers.

Wenn ein Tool die richtigen Nachweise für weniger erfahrene Mitarbeiter verfügbar machen kann, ohne das zugrunde liegende System zu verschleiern, kann es die Abhängigkeit von den wenigen Personen verringern, die jede historische Konvention kennen.

21CS hat dies eindeutig erkannt. Die Website betont Investitionen in neue IBM-Z-Talente, globale Entwicklungslabore, Schulungen und eine Partnerschaft mit Interskill Learning im Jahr 2026 zur Unterstützung der Mainframe-Ausbildung. Die Partnerschaft ist kommerziell sinnvoll, denn Tools senken die Überwachungskosten nicht, wenn die Mitarbeiter sie nicht korrekt nutzen können. Ein Produkt, das für jede Konfigurationswahl denselben seltenen Experten erfordert, verlagert lediglich die Last.

Ein Produkt, das den Änderungskontext erfasst, geführte Berichte anbietet, Routinefehler validiert und neuen Mitarbeitern einen sichereren Weg bietet, aktuelle und frühere Zustände zu überprüfen, kann die Überwachung skalierbarer machen.

Der Käufer sollte dennoch skeptisch bleiben. „Einfach“ ist ein gefährliches Wort in der Systemprogrammierung. Die eigentliche Frage ist, welche Art von Überwachung sich ändert. Ein Tool könnte den manuellen Vergleich von Library-Members reduzieren, aber die Notwendigkeit erhöhen, die Produktkonfiguration zu pflegen. Es könnte das Erstellen von Wiederherstellungs-JCL reduzieren, aber eine sorgfältige Einarbeitung in die Backup-Methoden erfordern. Es könnte Entwicklern eine REST-Schnittstelle für die Validierung bieten, aber Sicherheitsteams zwingen, zu definieren, wer welche Ressourcen validieren darf.

Es könnte neuen Mitarbeitern helfen, Nachweise einzusehen, während erfahrene Mitarbeiter weiterhin die Ausnahmebehandlung und das Richtliniendesign besitzen. Dies ist kein Versagen; es liegt in der Natur von Infrastrukturwerkzeugen. Aber es bedeutet, dass der Business Case die Überwachung auf Workflow-Ebene modellieren sollte und nicht als generische Personalreduzierung.

Das beste Szenario für 21CS ist ein mehrschichtiges. Erfahrene Spezialisten definieren Richtlinien, geschützte Ressourcen, Backup-Methoden, Migrationsbeschränkungen und Akzeptanzkriterien. Die Tools sammeln Nachweise, setzen einige Grenzen durch und decken Routineprobleme früher auf. Weniger erfahrene Mitarbeiter erledigen mehr gewöhnliche Prüfungen, ohne zu improvisieren. Audit- und Wiederherstellungsgespräche beginnen mit strukturierten Daten und nicht mit Erinnerungen. Das spart Zeit, nicht indem Menschen aus dem Prozess entfernt werden, sondern indem menschliches Urteilsvermögen für die Ausnahmen vorbehalten bleibt, die es verdienen.

Das schlechteste Szenario ist ebenfalls klar. Wenn die Umgebung ein Produkt einführt, weil die erfahrenen Mitarbeiter in den Ruhestand gehen, es aber versäumt, lokale Regeln zu dokumentieren, Operatoren zu schulen, Rollbacks zu testen und Änderungstickets mit den Tool-Nachweisen abzugleichen, wird die Software zu einer weiteren Konsole, die nur wenige verstehen. Die Überwachungskosten steigen dann. Der Großrechner wird nicht weniger fragil, sondern undurchsichtiger, weil das Team anbieterspezifisches Verhalten hinzugefügt hat, ohne Stammeswissen in akzeptierte Betriebsaufzeichnungen umzuwandeln.

Integrations- und Wartungslast entscheiden, ob der Stack hilft

Die Mainframe-Umgebung ist bei der Integration unerbittlich, weil ihre Zuverlässigkeit auf Disziplinsschichten beruht. Das z/OS-Softwaremanagement kann SMP/E-Inventare, paketierte Bereitstellungen und Berichte umfassen. z/OSMF kann browserbasiertes Management, REST-APIs, Workflows und Zugriff auf Datasets, Jobs und Konsolen bieten. Sicherheit ist in SAF- und RACF-Richtlinien eingebunden. Das Batch-Verhalten hängt von JES, Schedulern, JCL-Standards, Exit-Routinen, Namenskonventionen und lokalen Betriebsverfahren ab. Speicherwerkzeuge interagieren mit Katalogen, Volumes, SMS-Richtlinien, Bandmanagern und Backup-Repositories.

In dieser Landschaft ist ein Tool nur so gut wie seine Fähigkeit, sich in die Umgebung einzufügen, ohne blinde Flecken zu schaffen.

Das öffentliche Material von 21CS verwendet oft Wörter wie nativ, direkt, automatisiert, transparent und unterbrechungsfrei. Diese Wörter zählen erst nach dem Integrationsnachweis. Eine native z/OS-Anwendung wie STRATUSn mag eine zwischengeschaltete Serverinfrastruktur vermeiden, muss aber dennoch mit Anmeldeinformationen, S3-kompatiblem Provider-Verhalten, Code-Page-Konvertierung, Batch-Planung, Abrufsemantik, Sicherheitsgenehmigungen, Datenklassifizierung und Netzwerkkontrollen umgehen.

Ein Migrationstool wie TRANSVERSEn mag dynamischen Swap und Switchback unterstützen, aber die Umgebung muss dennoch Konsistenzgruppen, Fallback-Zeitpläne, Anwendungssensitivität, Remote-Netzwerkverhalten und den Katalogzustand nach der Bewegung testen. Ein Change Tracker mag ein Member wiederherstellen, aber das Change Board muss immer noch entscheiden, ob die Wiederherstellung dieses Members ausreicht oder ob abhängige Jobs, Load Libraries oder Konfigurationsreferenzen mit verschoben werden müssen.

Deshalb muss das akzeptierte Änderungsprotokoll Integrationsnachweise enthalten. Für einen 21CS-Einsatz würde ein starkes Protokoll nicht einfach „SENTINELn installiert“ oder „Migration abgeschlossen“ vermerken. Es würde zeigen, welche Datasets geschützt sind, welche Ereignisse erfasst werden, welche Backup-Richtlinie gilt, welche Kommentare erforderlich sind, wer Members auschecken kann, wie Vergleiche überprüft werden, wie Befehlszeilenaktionen authentifiziert werden, wie Berichte aufbewahrt werden, wie das Produkt selbst aktualisiert wird und wie seine Protokolle den bestehenden Audit- und Vorfallsverfahren zugeordnet werden.

Für Migrationsprodukte würde es Quell- und Zieldefinitionen, Leistungsfenster, Fallback-Regeln, Anwendungsverfügbarkeitsprüfungen, Metadatenabgleich, Katalogverifizierung und Überwachung nach der Bewegung zeigen.

Die Wartungslast ist die zweite Hälfte. Mainframe-Tools können zu dauerhaften Vermögenswerten werden, aber sie können auch zu einem weiteren Release-Stream werden, der mit z/OS-Ständen, IBM-Z-Hardware, Speicher-Firmware, Sicherheitsregeln und internen Prozessen kompatibel gehalten werden muss. Das Portfolio von 21CS umfasst Produkte mit Dokumentation aus dem Jahr 2026 sowie neuere Angebote wie SENTINELn, STRATUSn und OPTIMAn. Diese Frische ist positiv, denn sie signalisiert Investitionen. Sie bedeutet aber auch, dass Käufer Release-Disziplin benötigen. Neue Produkte sind möglicherweise weniger kampferprobt als ältere Dienstprogramme.

Kompatibilitätsansprüche müssen unter den kundeneigenen Exits, Schedulern und Sicherheitsmodellen getestet werden. Support-SLAs müssen die Zeiten abdecken, in denen sich die Umgebung tatsächlich ändert, nicht nur die normalen Geschäftszeiten.

Der VSEn-Teil des Portfolios macht die Wartungslast besonders greifbar. IBM hat erklärt, dass z/VSE 6.2 am 30. September 2023 das Ende des Supports erreicht hat und dass es kein Nachfolge-Release von IBM gibt. Es wird auch angegeben, dass IBM den z/VSE-Quellcode und die meisten Stack-Komponenten an 21st Century Software lizenziert hat, und es wird empfohlen, dass Kunden, die eine wartungsfähige Umgebung benötigen, auf eine Alternative wie die von 21CS abgeleiteten VSE-Produkte umsteigen. Dies schafft einen echten Kontinuitätspfad für VSE-Kunden, überträgt aber auch das Vertrauen auf einen kleineren Spezialanbieter.

Kunden müssen nicht nur die funktionale Kompatibilität testen, sondern auch Hardware-Unterstützung, die Bereitschaft des Drittanbieter-Ökosystems, das Lizenzierungsverhalten, TCP/IP-Stack-Optionen, Verschlüsselungsanforderungen, Backup-Verfahren und die Fähigkeiten der Mitarbeiter.

Die Integrationslast ist daher kein Einwand gegen 21CS. Sie ist die Bedingung für den Wert. In diesen Umgebungen gibt es keine reibungsarme Abkürzung am Nachweis vorbei.

Fehlerarten, die mehr zählen als Funktionslisten

Die wichtigsten Risiken für 21CS-Kunden sind nicht abstrakt. Sie ergeben sich direkt aus dem akzeptierten Änderungsprotokoll.

Das erste ist das Risiko nicht unterstützter Releases. Ein Kunde kann einen z/OS-, z/VSE- oder Produktstand betreiben, der außerhalb der aktuellen Support-Matrix liegt, oder er kann von einer Komponente abhängen, deren IBM-Servicepfad beendet ist. VSEn ist eine Antwort auf genau dieses Problem für VSE-Umgebungen, aber das Risiko verschwindet nicht. Es verlagert sich auf die Frage, ob 21CS mit der IBM-Z-Hardware, den zugehörigen Stack-Komponenten und den Drittanbieterprodukten Schritt halten kann, die VSE-Kunden weiterhin benötigen.

Das zweite ist die Verschlechterung des Batch-Fensters. Ein Produkt, das Änderungen überwacht, JCL validiert, SMF scannt, Dataset-Aktivitäten erfasst, Daten migriert oder in Objektspeicher schreibt, verbraucht Ressourcen und berührt das Betriebszeitverhalten. Selbst wenn der Overhead in normalen Fällen gering ist, muss der Käufer die schlimmsten Momente testen: Monatsende, Quartalsende, ungewöhnlich hohe Rückrufe, Notfallwiederherstellungen, Massen-JCL-Updates, Speicheraktualisierungsfenster und Cyber-Recovery-Übungen.

Der Wert einer früheren Validierung kann zunichte gemacht werden, wenn das Tool unvorhersehbare Verzögerungen in Bereichen hinzufügt, in denen die Umgebung wenig Spielraum hat.

Das dritte ist ein schwacher Rollback. Mainframe-Teams haben oft ausgezeichnete Backup-Gewohnheiten auf Plattformebene, kämpfen aber dennoch mit der selektiven Anwendungswiederherstellung. Ein Change-Tracking- oder Migrationstool sollte nach seiner Fähigkeit beurteilt werden, das richtige Objekt wiederherzustellen, nicht irgendein Objekt.

Wenn eine Member-Wiederherstellung abhängige Module inkonsistent lässt, wenn ein Storage-Switchback-Pfad nicht geübt ist, wenn eine Cloud-Kopie nicht in dem von den Anwendungen benötigten Format abrufbar ist oder wenn die generierte Wiederherstellungs-JCL nicht an lokale Methoden angepasst ist, ist das akzeptierte Änderungsprotokoll unvollständig.

Das vierte ist das Risiko veralteter Runbooks. Tools können starke Nachweise liefern und dennoch operativ versagen, wenn die Verfahren nicht aktualisiert werden. Wenn ein Team SENTINELn einführt, die Incident-Responder aber weiterhin einem alten manuellen Vergleichsprozess folgen, werden die Nachweise des Tools unter Druck möglicherweise ignoriert. Wenn ein Team STRATUSn für Cloud-Objektspeicher einsetzt, aber die Datenklassifizierungs- und Abrufverfahren nicht aktualisiert, kann dies Governance-Probleme schaffen.

Wenn VSEn übernommen wird, der Betrieb aber IBM z/VSE-Annahmen im Runbook beibehält, kann das nächste Hardware- oder Lizenzereignis die Lücke aufdecken.

Das fünfte sind Integrationskonflikte. Mainframe-Umgebungen sind voll von ausgereiften Kontrollen. Ein Produkt kann sich mit bestehenden Änderungsmanagement-Datenbanken, Speicherreplikation, Scheduler-Validierung, Überwachung privilegierter Zugriffe, Sicherheitsinformationssystemen und Audit-Aufbewahrungstools überschneiden. Überlappung kann vorteilhaft sein, wenn sie eine mehrschichtige Verteidigung schafft. Sie kann aber auch widersprüchliche Aufzeichnungen produzieren.

Wenn das Änderungsticket das eine sagt, der Library-Tracker etwas anderes und das Backup-Dashboard anzeigt, dass ein Dataset gefährdet war, benötigt das Team eine Abstimmungsregel, bevor ein Regulierer oder ein Incident-Kommandant nach der Wahrheit fragt.

Das sechste ist der Mangel an Spezialisten. 21CS kann einen Teil der Wissenslast reduzieren, insbesondere wenn es Kontext erfasst und Schulungen unterstützt, aber seine Produkte leben immer noch im Spezialistengebiet. Wenn nur eine Person die Konfiguration geschützter Datasets oder die VSEn-Upgrade-Mechanik versteht, hat der Käufer die Kontinuität nicht gelöst. Er hat sie nur verlagert.

Die letzte Fehlerart ist die Diskontinuität des Anbieter-Supports. 21CS ist ein Spezialunternehmen, keine Hyperscale-Plattform. Diese Fokussierung ist Teil seines Wertes, aber auch der Grund, warum Kunden die Support-Abdeckung, die Produkt-Roadmaps, die Aktualität der Dokumentation, gegebenenfalls Treuhand- oder Quellcode-Vereinbarungen sowie Notfallpläne für den Fall von Produktlinienänderungen genau prüfen sollten. Ein regulierter Mainframe-Betrieb kann die Support-Kontinuität nicht als nebensächlichen Beschaffungspunkt behandeln.

Kundenergebnisse sind durch die Umgebung begrenzt

Die öffentlichen Nachweise für 21CS stützen eine plausible betriebliche Hypothese: Seine Tools können die Unsicherheit bei Änderungen, Wiederherstellung und Migration verringern, wenn sie in Umgebungen eingesetzt werden, die bereit sind, sie aufzunehmen. Sie beweisen kein universelles Kundenergebnis. Diese Unterscheidung ist wichtig.

Die öffentliche Seite von TRANSVERSEn besagt, dass 21CS Expertise aus Tausenden von unterbrechungsfreien lokalen und globalen Migrationen in mehr als 850 Organisationen einbringt. Tape/Assist gibt an, dass 21CS mehr als 102.000 TB in über 160 erfolgreichen Migrationen bewegt hat. Dies sind aussagekräftige Kontinuitätssignale für einen Spezialanbieter. Sie deuten auf einen Erfahrungsschatz mit Migrationen hin, nicht auf ein Produkt, das nur für eine Präsentation erfunden wurde. Doch die Anzahl der Migrationen sagt einem neuen Käufer nicht, ob seine eigene Umgebung ohne Zwischenfälle migrieren kann.

Sie offenbart nicht die Komplexität des Quellspeichers, des Ziels, der Netzwerkpfade, der Anwendungssensitivität, der Personalausstattung, der Wartungsfenster oder der Ausnahmebehandlung in jedem Einzelfall.

Dieselbe Grenze gilt für die Änderungsverfolgung und die Backup-Resilienz. Ein Produkt, das Sicherungen auf Member-Ebene und Audit-Trails erfasst, kann ein Team, das sich derzeit auf manuelle Notizen verlässt, erheblich verbessern. Es kann weniger Mehrwert für ein Team mit ausgereiften Library-Kontrollen, strenger RACF-Disziplin, gut integrierten Änderungstickets, starken Backup-Analysen und geübten Wiederherstellungstests bieten.

Das Versprechen von IBM Z Backup Resiliency, geeignete Backups zu identifizieren und Wiederherstellungs-JCL zu generieren, ist nur dann relevant, wenn das Tool auf die Backup-Methoden und kritischen Dateien konfiguriert ist, die in dieser Umgebung zählen. JCL-Validierung ist leistungsstark, wenn sie Fehler vor der Terminierung abfängt, aber sie beweist nicht die Geschäftslogik, die Datenqualität oder die nachgelagerte Anwendungsbereitschaft.

Deshalb sollte 21CS nicht anhand allgemeiner Kundenlogos bewertet werden. Die bessere Bewertung ist eine Stichprobe der eigenen Änderungsprotokolle des Käufers. Nehmen Sie aktuelle Vorfälle und geplante Änderungen: eine Korrektur einer Produktionsbibliothek, eine Speicherverschiebung, ein fehlgeschlagener Batch-Job aufgrund von JCL, eine Wiederherstellung von nicht-datenbankverwalteten Daten, eine Bandmigrationsausnahme, ein Problem bei der VSE-Hardwareplanung. Fragen Sie, wie jedes Szenario mit dem 21CS-Tool aussehen würde. Welcher Schritt entfällt? Welche Aufzeichnung wird klarer? Welche manuelle Überprüfung bleibt?

Welcher Fehler würde immer noch auftreten? Welche neue Abhängigkeit entsteht? Welche Person muss geschult werden?

Ein Anbieter erzielt Wert, wenn sich die Antworten in wiederholten Fällen verbessern. Er erzielt keinen Wert, indem er abstrakt Mainframe-Modernisierung beansprucht. Für 21CS wäre ein starkes Kundenergebnis sichtbar als kürzere Diagnosezeiten, weniger vermeidbare Wiederholungsläufe, schnellere Wiederherstellungsauswahl, bessere Audit-Nachweise, saubereres Storage-Migrations-Fallback, einfachere Einarbeitung neuer Mitarbeiter und ein Support-Pfad für VSE-Workloads, die andernfalls nicht unterstützte IBM-Releases hätten.

Ein schwaches Ergebnis wäre sichtbar als doppelte Konsolen, nicht gepflegte Richtlinien, teure Shelfware und Mitarbeiter, die das Tool immer noch umgehen, weil es die Arbeit, die sie tatsächlich tun, verlangsamt.

Die Grenze schützt 21CS auch vor unfairen Erwartungen. Kein Anbieter kann eine schlecht verstandene Umgebung einfach machen. Kein Change Tracker kann jahrelange fehlende Zuständigkeiten reparieren. Kein Migrationstool kann die Notwendigkeit von Testfenstern beseitigen. Keine Schulungspartnerschaft kann über Nacht erfahrene Systemprogrammierer schaffen. Die realistische Behauptung ist enger und nützlicher: 21CS kann helfen, bestimmte Klassen von Mainframe-Änderungen in bessere betriebliche Nachweise umzuwandeln, wenn der Kunde in Konfiguration, Prozesse und Übungen investiert.

Stückkostenökonomie: Wann sich die Kosten lohnen

Die kommerzielle Frage ist, ob die Vorteile in Bezug auf Zuverlässigkeit und Support die Kosten für Lizenzen, Wartung, Spezialistenarbeit, Migrationsverzögerung und Anbieterkontinuität überwiegen. Diese Frage kann nicht anhand öffentlicher Preislisten beantwortet werden, da die relevante Preisgestaltung umgebungsspezifisch ist. Sie kann jedoch strukturiert werden.

Der Vorteil für den Käufer beginnt mit vermiedenen Vorfällen. Ein einziges fehlgeschlagenes Batch-Fenster bei einer Bank, einer Versicherung oder einem öffentlichen Betreiber kann nachgelagerte manuelle Arbeit, verpasste Berichterstattung, Serviceverzögerungen und Aufmerksamkeit der Geschäftsleitung verursachen. Wenn die JCL-Validierung wiederkehrende mechanische Ausfälle verhindert, kann ihr Wert leicht zu rechtfertigen sein. Wenn die Änderungsverfolgung die Diagnose nach einer fehlerhaften Member-Aktualisierung verkürzt, kann die Einsparung in wiederhergestellter Servicezeit und reduzierten Überstunden gemessen werden.

Wenn die Backup-Resilienz während eines Beschädigungsereignisses verwendbare Nicht-Datenbank-Backups identifiziert, kann sie mehr als nur Arbeitszeit schützen. Wenn ein Speichermigrationstool einen Wochenendausfall vermeidet oder die Abhängigkeit von veralteter Hardware verringert, kann das wirtschaftliche Argument stark sein.

Der zweite Vorteil ist die Verringerung von Reibung bei Audit und Compliance. Regulierte Infrastrukturbetreiber benötigen Nachweise. Ein Tool, das dokumentiert, wer was geändert hat, warum eine Ressource ausgecheckt wurde, welches Backup existiert, welche Datasets geöffnet waren, welche Umgebung abweicht oder wie eine Wiederherstellung generiert wurde, kann den Aufwand für die Audit-Vorbereitung und die Vorfallsüberprüfung reduzieren. Das bedeutet nicht, dass das Produkt selbst Compliance schafft. Es bedeutet, dass es die Evidenzmaschine füttern kann.

Der dritte Vorteil ist die Kontinuität. VSEn ist das klarste Beispiel. Ein Kunde, der noch VSE-Workloads benötigt, muss zwischen Migration von VSE weg, nicht unterstütztem Betrieb, erweiterten oder alternativen Support-Pfaden oder der Einführung der von 21CS abgeleiteten VSE-Produkte wählen. Eine vollständige Migration mag strategisch attraktiv, aber langsam und riskant sein. Der nicht unterstützte Betrieb mag billig erscheinen, bis Hardware-, Lizenz-, Sicherheits- oder Personalereignisse eintreten.

VSEn kann wirtschaftlich rational sein, wenn es Zeit, Hardware-Kompatibilität und einen unterstützbaren Pfad erkauft, während der Kunde Änderungen auf Anwendungsebene plant.

Die Kosten sind ebenso real. Lizenzierung und Wartung sind nur die sichtbare Schicht. Der Kunde muss Implementierung, Tests, Design geschützter Ressourcen, Rollenzuordnung, Integration der Backup-Methoden, Speichermigrationsübungen, Dokumentationsaktualisierungen, Schulungen, Support-Eskalationsübungen und Produkt-Upgrades einplanen. Wenn die Umgebung bereits unterbesetzt ist, konkurrieren diese Aufgaben mit anderen dringenden Arbeiten. Wenn das Unternehmen mehrere 21CS-Tools auf einmal einführt, kann die Integrations- und Schulungskurve steil sein, selbst wenn jedes Produkt ein echtes Problem löst.

Die Abhängigkeit vom Anbieter ist ein weiterer Kostenfaktor. Für einige Kunden reduziert die Hinzufügung von 21CS die Abhängigkeit von einer nicht mehr fortgeführten Produktlinie eines größeren Anbieters, insbesondere bei VSE. Für andere fügt sie einem bereits komplexen Stack eine Spezialistenabhängigkeit hinzu. Das richtige Wirtschaftsmodell sollte Abhängigkeiten vergleichen und nicht so tun, als sei eine Seite frei von Abhängigkeiten. IBM-native Werkzeuge, Broadcom-Tools, BMC-Tools, Dienstprogramme von Speicheranbietern, Open-Source-Modernisierungsschichten, Runbooks von Dienstleistern und interne Skripte haben alle ihre eigene Bindung.

Die Frage ist, welche Bindung das zuverlässigste akzeptierte Änderungsprotokoll zu den niedrigsten Gesamtkosten über den Planungshorizont liefert.

Ein nützlicher Kauftest ist das „Drei-Änderungen-Amortisations“-Modell. Bevor der Käufer umfassend lizenziert, sollte er drei echte, wiederkehrende Änderungen auswählen und die aktuellen Kosten schätzen: Arbeitsstunden, Verzögerungsrisiko, Audit-Aufwand, Wiederholungslauf-Exposition, Wiederherstellungsunsicherheit und Spezialistenbeteiligung. Dann schätzen Sie die zukünftigen Kosten mit dem 21CS-Tool, einschließlich des Produktbetriebs. Wenn das Tool mindestens zwei dieser Änderungen nicht wesentlich verbessern kann, ist der Business Case wahrscheinlich nur ein Modernisierungsslogan.

Wenn es das kann, hat der Käufer eine vertretbare stückkostenökonomische Geschichte.

Realistische Alternativen und warum sie ausreichen könnten

21CS arbeitet nicht im luftleeren Raum. Mainframe-Teams haben bereits Alternativen, einige technischer, einige organisatorischer Natur.

IBM-native Werkzeuge sind die erste Alternative. z/OSMF bietet browserbasiertes Management, Workflows, REST-APIs und Software-Management-Dienste. SMP/E bleibt zentral für das installierte Software-Inventar und die Wartung. IBM-Produkte wie z/OS Change Tracker, Z Backup Resiliency und Z JCL Expert können je nach Kundenverträgen über IBM-Kanäle bezogen und direkt genutzt werden. Eine ausgereifte IBM-Werkzeugumgebung kann bereits einen Teil der Evidenzkette abdecken, die 21CS betont.

Bestehende Enterprise-Anbieter sind eine weitere Alternative. Große Mainframe-Häuser betreiben oft Broadcom, BMC, Rocket Software, Precisely, Speicheranbieter- und Scheduler-spezifische Werkzeuge. Diese Produkte können bereits Bibliotheksverwaltung, Job-Scheduling, Output-Management, Backup-Berichterstattung, Speicherreplikation, Leistungsanalyse, Sicherheitsüberwachung und Änderungstickets übernehmen. Sie durch 21CS zu ersetzen oder zu ergänzen, ist nur dann sinnvoll, wenn das neue Tool eine definierte Lücke schließt, anstatt eine funktionierende Kontrolle zu duplizieren.

Interne Skripte und Runbooks sind die auf den ersten Blick billigste Alternative. Viele Mainframe-Teams haben über Jahre lokale Automatisierungen rund um REXX, JCL, ISPF-Panels, Scheduler-Jobs, SMF-Berichte und Speicherdienstprogramme aufgebaut. Diese können sehr effektiv sein, weil sie den lokalen Konventionen entsprechen. Ihre Schwäche liegt in der Kontinuität. Wenn der Autor in den Ruhestand geht, die Dokumentation dürftig ist oder die Skripte keine audittauglichen Nachweise liefern, können die scheinbaren Einsparungen vorübergehend sein.

21CS wird attraktiver, wenn die interne Alternative nur funktioniert, weil ein Experte sie am Leben erhält.

Dienstleister sind eine weitere Option. Ein Kunde kann Migration, VSE-Support, Wiederherstellungsplanung oder Modernisierungsarbeiten an Mainframe-Berater auslagern, anstatt ein neues Tool zu lizenzieren. Das kann für einmalige Ereignisse oder wenn die internen Mitarbeiter zu stark ausgelastet sind, rational sein. Für wiederkehrende akzeptierte Änderungsnachweise ist es weniger geeignet, da der Kunde weiterhin die tägliche Betriebskontrolle benötigt. Ein Dienstleister kann das Ereignis durchführen, aber die Umgebung muss mit dem Ergebnis leben.

Anwendungsmigration ist die strategische Alternative. Wenn eine Workload den Großrechner sicher verlassen kann, kann der Käufer beschließen, nicht weiter in mainframespezifische Werkzeuge zu investieren. Aber das ist oft langsamer, als es Planungsfolien vermuten lassen. Kyndryls Fachkräftedaten und Branchenumfragen zur Modernisierung zeigen, warum: Modernisierung erfordert multidisziplinäre Teams, Cloud-Integration, Anwendungswissen und Risikomanagement.

Für langlebige Workloads im Finanz-, Versicherungs- und öffentlichen Sektor kann die Mainframe-Änderungskontrolle noch jahrelang notwendig bleiben, selbst wenn die Migration der gewünschte Endzustand ist. In diesem Zeitraum kann eine Unterinvestition in wiederherstellbare Änderungen die letztendliche Migration erschweren, nicht erleichtern.

Die beste Alternative könnte ein hybrider Ansatz sein: Behalten Sie die IBM-nativen Grundlagen bei, bewahren Sie ausgereifte vorhandene Tools, fügen Sie 21CS nur dort hinzu, wo es das akzeptierte Änderungsprotokoll stärkt, und nutzen Sie Dienstleistungen für außergewöhnliche Übergänge. Das ist weniger spektakulär als eine Plattformtransformations-Erzählung, aber so funktioniert ernsthafte Infrastrukturbeschaffung normalerweise.

Was ein Käufer fordern sollte, bevor er dem Versprechen vertraut

Ein Mainframe-Käufer sollte von 21CS Nachweise auf demselben Niveau verlangen, das das Produkt zu verbessern vorgibt.

Für SENTINELn sollte der Nachweis die Einrichtung überwachter Ressourcen, das Backup-Verhalten auf Member-Ebene, Wiederherstellungspfade, Vergleichsausgaben, Zugriffskontrollabbildung, Beispiele für Audit-Berichte, Befehlszeilenintegration, Leistungsauswirkungen und Produkt-Upgrade-Verfahren umfassen.

Der Käufer sollte eine harmlose, aber realistische Bibliotheksänderung testen: Führen Sie eine autorisierte Bearbeitung durch, erfassen Sie den Grund, vergleichen Sie davor und danach, stellen Sie einen bekannten guten Zustand wieder her, erstellen Sie einen Audit-Bericht und prüfen Sie, ob bestehende Änderungsticket- und Sicherheitsaufzeichnungen übereinstimmen.

Für die JCL-Validierung sollte der Nachweis die tatsächlichen Scheduler-Konventionen, Variablen, Sicherheitsregeln, Datasets, Db2-Pläne und Pipeline-Gewohnheiten der Umgebung umfassen. Es reicht nicht aus, saubere Beispiel-JCL zu validieren. Das Produkt muss die Klassen vermeidbarer Fehler abfangen, die in der Vergangenheit zu Wiederholungsläufen oder Produktionssteuerungs-Eskalationen geführt haben. Es sollte auch zeigen, wie falsch positive Ergebnisse behandelt werden, denn ein Tool, das jede harmlose Änderung verlangsamt, wird umgangen werden.

Für die Backup-Resilienz sollte der Nachweis ein Nicht-Datenbank-Dataset umfassen, dessen Wiederherstellung zuvor schwierig war. Das Team sollte die Backup-Identifizierung, die generierte Wiederherstellungs-JCL, die Health-Check- oder Dashboard-Nachweise und die nachgelagerte Auswirkungsberichterstattung überprüfen. Das Produkt sollte nicht danach beurteilt werden, ob es eine beruhigende Punktzahl anzeigen kann, sondern danach, ob es den Operatoren hilft, unter Zeitdruck eine korrekte Wiederherstellungsentscheidung zu treffen.

Für TRANSVERSEn, VECTORn und Tape/Assist sollte der Nachweis eine kontrollierte Migrationsübung sein. Der Käufer sollte Quell- und Zielgeräte, Prüfungen der Anwendungsverfügbarkeit, Katalogabgleich, Fallback-Zeitpläne, Bewahrung von Bandmetadaten, Fortschrittsberichterstattung und Ausnahmebehandlung definieren. Ein Migrationstool, das keine verständliche Ausnahmebehandlung bietet, ist gefährlich, selbst wenn sein Erfolgspfad schnell ist.

Für STRATUSn sollte der Nachweis das Berechtigungsmanagement, das Verhalten des S3-kompatiblen Providers, die Code-Page-Übersetzung, den bidirektionalen Transport, die Batch-Planung, die Abruftests, die Datenklassifizierung und die Annahmen zur Notfallwiederherstellung umfassen. Das Verschieben kalter Daten in den Objektspeicher mag attraktiv sein, aber das akzeptierte Protokoll muss beweisen, dass die Daten in der von der Geschäftsseite benötigten Form und innerhalb des benötigten Zeitrahmens abgerufen werden können.

Für VSEn sollte der Nachweis noch strenger sein, da die Betriebssystemkontinuität eine tiefgreifende Abhängigkeit darstellt. Der Käufer sollte Hardware-Unterstützung, Kompatibilität mit Drittanbieterprodukten, Netzwerkstack-Optionen, Sicherheits- und Verschlüsselungsanforderungen, Lizenzierungsverhalten, Backup- und Wiederherstellungsverfahren, Bedienerschulung, Support-Eskalation und eine Exit-Strategie validieren. VSEn mag für einige Kunden der richtige Kontinuitätspfad sein, gerade weil der z/VSE-Servicepfad von IBM beendet wurde, aber das macht die Due Diligence wichtiger, nicht weniger.

Diese Tests sind nicht feindselig. Sie sind der richtige Weg, um Mainframe-Software zu kaufen. Das Wertversprechen von 21CS selbst weist auf Nachweise, Wiederherstellbarkeit und Support hin. Ein Käufer sollte diese Einladung annehmen und die Nachweise operationalisieren.

Das Urteil

21st Century Software ist interessant, weil es nicht versucht, den Großrechner verschwinden zu lassen. Es versucht, Teile der verbleibenden Mainframe-Umgebung beobachtbarer, wiederherstellbarer, migrierbarer und unterstützbarer zu machen. Das ist eine kommerziell sinnvolle Position im Jahr 2026. Mainframe-Workloads bleiben in Branchen wichtig, in denen Ausfallzeiten, Datenverluste und Audit-Lücken teuer sind. Gleichzeitig steht die Fachkräftebasis unter Druck, die Umgebung ist hybrider und einige Plattformlinien, insbesondere IBM z/VSE, haben Kunden zu Kontinuitätsentscheidungen gezwungen.

Das Unternehmen sollte nicht nach Nostalgie oder pauschaler Anti-Legacy-Stimmung beurteilt werden. Es sollte nach dem akzeptierten Mainframe-Änderungsprotokoll beurteilt werden. Kann ein Team nachweisen, was sich geändert hat? Kann es das verantwortliche Ereignis finden? Kann es das richtige Dataset oder Member wiederherstellen? Kann es den Job validieren, bevor er ein Fenster verschwendet? Kann es Speicher bewegen, ohne Verfügbarkeit oder Metadaten zu verlieren? Kann es VSE-Workloads auf einem wartbaren Pfad halten, während größere Anwendungsentscheidungen anstehen?

Kann es all dies, ohne eine Abhängigkeit hinzuzufügen, die nur ein Spezialist bedienen kann?

Nach öffentlichen Nachweisen hat 21CS glaubwürdige Vermögenswerte für diesen Test. SENTINELn adressiert das Problem der Änderungsverfolgung und -wiederherstellung direkt. Die IBM-gebrandeten Resilienz-, Änderungsverfolgungs- und JCL-Produkte im Portfolio entsprechen den realen betrieblichen Schmerzen in z/OS. TRANSVERSEn, VECTORn und Tape/Assist adressieren Speicher- und Bandbewegungen, bei denen Metadaten und Fallback wichtig sind. STRATUSn zielt auf hybride Datenbewegungen ohne verteilte Middleware-Schicht ab. VSEn bietet VSE-Kunden nach IBM z/VSE 6.2 einen Support-Pfad.

Das Unternehmen scheint auch in Talente, Dokumentation und Partnerschaften zu investieren, anstatt nur alte Wartungsströme abzuernten.

Die Vorsicht ist, dass öffentliche Nachweise nicht gleichbedeutend mit nachgewiesener Eignung für die eigene Umgebung sind. Kein externer Leser kann Overhead, Support-Qualität, Reduzierung von Kundenvorfällen, Migrationssicherheit oder Wiederherstellungsverhalten ohne direkten Zugang zu lizenzierter Software und einer repräsentativen Mainframe-Umgebung überprüfen. Die Produkte sind zudem mit den üblichen Risiken proprietärer Software behaftet: Kosten, Integrationsarbeit, Schulung, Verlängerungsabhängigkeit, überlappende Kontrollen und Anbieterkontinuität. In einigen Häusern werden ausgereifte vorhandene Werkzeuge ausreichen.

In anderen wird die Kosten manueller Unsicherheit 21CS weniger wie optionale Software und mehr wie einen Weg zur Erhaltung der Betriebskontrolle erscheinen lassen.

Das ist die praktische Schlussfolgerung. Der Wert von 21CS ist am höchsten, wenn ein Kunde wiederkehrende z/OS- oder VSE-Änderungen, eine geringe Spezialistenkapazität, schwache Wiederherstellungsnachweise, Druck durch Speichertransformationen oder ein VSE-Kontinuitätsproblem hat, das nicht auf eine vollständige Anwendungsmigration warten kann. Sein Wert ist am niedrigsten, wenn die Umgebung bereits saubere akzeptierte Änderungsprotokolle produziert und nur ein Modernisierungslabel wünscht. Der Mainframe-Käufer sollte nicht fragen, ob 21CS die Plattform modern macht.

Der Käufer sollte fragen, ob die nächste riskante Änderung mit einem klareren, schnelleren und besser wiederherstellbaren Protokoll endet als heute.