Was ist z/OS eigentlich?

Status: dokumentiert, nicht live verifizierbar — reiner Grundlagen-/Orientierungstext. Kein Anspruch auf Mainframe-Operator-Tiefe, sondern genug, um im Gespräch mit dem DB2-for-z/OS-/Mainframe-Team nicht bei null anzufangen. Baut auf 01-db2-fuer-zos-und-mainframe-grundlagen.md auf bzw. geht diesem inhaltlich voraus.

Einordnung: ein eigenes Betriebssystem, keine "größere Linux-Maschine"

z/OS ist IBMs Betriebssystem für System z-Mainframe-Hardware — kein Linux, kein Unix im klassischen Sinn, auch wenn es POSIX-Schnittstellen (USS, siehe unten) mitbringt. Wer aus der Linux-/Windows-Welt kommt, stolpert typischerweise über vier Dinge:

Adressräume statt Prozesse. z/OS organisiert laufende Arbeit in Address Spaces — konzeptionell ähnlich zu Prozessen, aber mit einer viel stärkeren Isolations- und Verwaltungsphilosophie (jede Subsystem-Instanz, z. B. ein DB2-Subsystem, läuft in eigenen, klar benannten Address Spaces).
Datasets statt Dateisystem-Pfaden. Es gibt kein /home/user/datei.txt. Stattdessen Datasets mit eigener Namenskonvention (HLQ.MITTLERE.QUALIFIER.ENDUNG, alles in Großbuchstaben, Punkte als Trenner) und festen Organisationsformen — sequenziell (PS), partitioniert (PDS/PDSE, ähnlich einem Ordner mit "Members" darin) oder VSAM (indexbasierter Zugriff, u. a. die Grundlage für viele Kernbanksysteme). Ein WAS-Admin muss diese nicht selbst verwalten, sollte aber verstehen, warum ein Mainframe-Kollege von "Datasets" statt "Dateien" spricht.
EBCDIC statt ASCII/UTF-8. z/OS-Anwendungen arbeiten intern traditionell mit EBCDIC (eine andere Zeichenkodierung als das in der Web-/Java-Welt übliche ASCII/UTF-8). Bei jeder Datenübertragung zwischen Liberty (Java, intern UTF-16/UTF-8) und z/OS-Anwendungen können Kodierungsprobleme auftreten — moderne Zugriffswege wie DDF/JDBC (siehe 01-db2-fuer-zos-und-mainframe-grundlagen.md) übernehmen die Konvertierung automatisch, aber bei Datei-/Batch-basiertem Datenaustausch (siehe Punkt 4) ist EBCDIC-vs-ASCII ein sehr realer Fehlerquell, den man kennen sollte.
Batch- statt (nur) interaktive Verarbeitung. Viel Kernbank-Logik läuft nicht als dauerhaft laufender Server-Prozess, sondern als Batch-Jobs, gesteuert über JCL (Job Control Language) und verwaltet vom JES2/JES3 (Job Entry Subsystem) — z. B. der nächtliche Tagesabschluss. Eine Liberty-Anwendung, die auf "frische" Kerndaten wartet, wartet in Wahrheit oft auf das Ende eines solchen Batch-Fensters.

Wie man mit z/OS interagiert (zum Wiedererkennen)

Zugang	Wofür	Relevanz für WAS-Admin
TSO/ISPF	Interaktiver, menübasierter Terminal-Zugang für Mainframe-Personal	Selten selbst genutzt, aber der Ort, an dem das DB2-/Mainframe-Team arbeitet — hilfreich zu wissen, wenn man Screenshots/Log-Auszüge von dort bekommt
DDF (Distributed Data Facility)	TCP/IP-JDBC-/ODBC-Zugriff auf DB2 for z/OS	Der Weg, den `concordia-portal` nutzt, siehe `01-db2-fuer-zos-und-mainframe-grundlagen.md`
z/OS Connect EE	Moderner, REST/JSON-basierter API-Zugang zu z/OS-Programmen (CICS, IMS, Batch) — Alternative zu direktem JDBC	Relevant, falls die Kernbank-Anbindung nicht nur über DB2, sondern auch über CICS-Transaktionen läuft — dann ist z/OS Connect EE oft der modernere Integrationsweg statt eigener Legacy-Protokolle
USS (Unix System Services)	POSIX-kompatible Schicht innerhalb z/OS	Erlaubt z. B. das Ausführen von Shell-Skripten auf z/OS — die "Brücke" zwischen klassischem Mainframe-Denken und der Unix-/Linux-Welt
FTP/Connect:Direct	Datei-/Dataset-basierter Massendatenaustausch	Klassischer Weg für große Batch-Datenlieferungen zwischen dezentral und zentral — hier potenziell die EBCDIC-Falle aus Punkt 3 oben

CICS/IMS: die anderen z/OS-Transaktionssysteme

Nicht jede Kernbank-Logik steckt in DB2-Tabellen — CICS (Customer Information Control System) und IMS (Information Management System) sind eigene z/OS-Transaktionsmonitore, unter denen viel gewachsene Kernbank-Logik als eigenständige Programme läuft (nicht nur als Datenbanktabellen). Falls concordia-portal künftig nicht nur Daten lesen, sondern eine Geschäftstransaktion auf dem Kernbanksystem auslösen müsste, wäre nicht JDBC/DDF der richtige Weg, sondern eher z/OS Connect EE (siehe Tabelle oben) oder eine CICS-Web-Services-Anbindung — ein wichtiger Unterschied, den man als WAS-Admin kennen sollte, um nicht reflexhaft "dann bauen wir eine JDBC-Verbindung" vorzuschlagen, wenn eigentlich eine Transaktion ausgelöst werden soll.

Sysplex: mehr als nur "DB2 hat mehrere Instanzen"

01-db2-fuer-zos-und-mainframe-grundlagen.md erwähnt den Sysplex im DB2-Kontext (Data Sharing Group) — der Sysplex selbst ist aber ein allgemeines z/OS-Konzept: mehrere gekoppelte z/OS-Systeme (Parallel Sysplex), die sich Workload, Daten und Verfügbarkeit teilen, verbunden über eine Coupling Facility (spezialisierte Hardware/Firmware für gemeinsam genutzte Datenstrukturen zwischen den Sysplex-Mitgliedern). Das ist die Mainframe-Antwort auf dieselbe Grundfrage wie die Liberty-HA-Demo in docs/70-high-availability/ — "mehr als eine Instanz, damit ein einzelner Ausfall nicht alles lahmlegt" — nur auf einer ganz anderen technologischen Ebene und mit jahrzehntelang gewachsener, sehr ausgereifter Umsetzung.

Was das für den WAS-Admin-Alltag konkret bedeutet

Diese Grundlagen sind kein Selbstzweck — sie erklären, warum die in 02-der-bindeglied-prozess.md beschriebenen Abläufe so formell/langsamer wirken als im eigenen dezentralen Umfeld: andere Betriebskultur (Change Control historisch sehr strikt, da eine einzelne z/OS-Instanz oft geschäftskritische Workloads vieler Anwendungen gleichzeitig trägt), andere Fehlerbilder (EBCDIC-Konvertierung, Batch-Fenster-Abhängigkeiten), andere Ansprechpartner-Struktur (TSO/ISPF-Nutzer statt Linux-Shell-Nutzer). Wer diesen kulturellen/technischen Unterschied versteht, wirkt im Gespräch mit dem Mainframe-Team nicht wie jemand, der "nur Java kennt".

⌂ Cockpit