DB2 for z/OS und Mainframe-Grundlagen für WAS-Administratoren

Setzt 00-was-ist-zos.md voraus, falls z/OS selbst (Adressräume, Datasets, EBCDIC, Batch/JCL, Sysplex) noch nicht vertraut ist — dieses Dokument konzentriert sich bewusst nur auf den DB2-/Verbindungs-Teil.

Status: dokumentiert, nicht live verifizierbar. Echtes z/OS/DB2-for-z/OS-Zugriff ist in dieser Lernumgebung nicht verfügbar (Mainframe-Zeitmiete/-Lizenz). Ausbaustufe 5 verifiziert stattdessen JDBC-Konnektivität gegen einen DB2-Community-Edition-Container als Stand-in für das reine Treiber-/Konfigurationsverhalten (jdbcDriver, dataSource, Connection Pool in server.xml) — die hier beschriebenen z/OS-spezifischen Eigenheiten (DDF, RACF, WLM, Sysplex) lassen sich damit NICHT nachstellen und bleiben bewusst reine Konzept-Doku.

Warum das überhaupt zum WAS-Admin-Job gehört

Die Anzeige nennt explizit "Bindeglied zwischen Java-Entwicklung und Administration von WebSphere Application Server sowie DB2 für z/OS, Netzwerk". Das bedeutet nicht, DBA für den Mainframe zu sein — aber genug über die andere Seite der Verbindung zu wissen, um mit dem DB2-for-z/OS-Team auf Augenhöhe zu reden, Verbindungsprobleme grob einzuordnen, und zu verstehen, warum manche Änderungen (Poolgröße, neue Verbindung, Zertifikat) auf der Mainframe-Seite ganz anders ablaufen als "einfach einen neuen Container hochfahren".

DB2 for z/OS ist NICHT DB2 LUW

Wer nur DB2 auf Linux/Unix/Windows (LUW) kennt, unterschätzt leicht, wie anders die z/OS-Variante betrieben wird:

Wie die Verbindung technisch zustande kommt (DDF)

Liberty verbindet sich nicht "in den Mainframe hinein", sondern gegen die DDF (Distributed Data Facility) — die Komponente von DB2 for z/OS, die TCP/IP-JDBC-/ODBC-Verbindungen von verteilten Systemen entgegennimmt:

• Treiber: JDBC Type 4 (db2jcc4.jar / db2jcc_license_cisuz.jar), rein Java, keine native Client-Installation nötig — genau das, was in server.xml als <jdbcDriver> referenziert wird (siehe 02-der-bindeglied-prozess.md für das konkrete Beispiel).
• Ports: klassisch 446 (unverschlüsselt) und 447 (SSL) — welcher Port erreichbar ist, entscheidet i. d. R. eine Firewall-Freigabe, die das Netzwerk-Team einrichtet, nicht der WAS-Admin selbst. Siehe 03-netzwerksegmentierung.md.
• Hochverfügbarkeit auf DB2-Seite: ein Sysplex kann mehrere DB2-Mitglieder ("Data Sharing Group") anbieten; die Verteilung auf ein konkretes Mitglied läuft oft über eine DVIPA (Dynamic Virtual IP Address) bzw. den Sysplex Distributor — aus Sicht des JDBC-Treibers eine einzige, stabile IP, dahinter steckt aber ggf. mehr als eine physische DB2-Instanz. Für den WAS-Admin heißt das: die "eine Connection-URL" ist oft schon selbst ein HA-Mechanismus, nicht nur ein einzelner Server.

RACF statt (oder zusätzlich zu) LDAP

Wichtiger gedanklicher Stolperstein: die Zugriffskontrolle auf DB2 for z/OS läuft nicht über das LDAP-Verzeichnis, das in docs/60-security-lifecycle/ für Liberty/Portal-Logins beschrieben ist, sondern über RACF (Resource Access Control Facility), das mainframe-eigene Sicherheitssystem:

• Eine JDBC-Verbindung zu DB2 for z/OS braucht eine RACF-Technical-User-ID (kein Mensch, ein Service-Account) mit den passenden DB2-Berechtigungen (GRANT auf Tabellen/Views bzw. RACF-Klassen wie DSNR, je nach Berechtigungsmodell der Bank).
• Diese RACF-ID zu beantragen ist ein eigener Prozess über das DB2-for-z/OS-/Mainframe-Team — typischerweise Formular-/Ticket-basiert, mit längerem Vorlauf als "im eigenen LDAP schnell eine Gruppe anlegen".
• Bei SSL-Verbindungen (Port 447) muss zusätzlich das Zertifikat des Liberty-Keystores im RACF-Keyring (bzw. dem äquivalenten Trust Store) auf z/OS-Seite als vertrauenswürdig hinterlegt werden — ein Zertifikatswechsel auf Liberty-Seite (siehe docs/60-security-lifecycle/) hat also potenziell eine Mainframe-seitige Nebenwirkung, die koordiniert werden muss.
• Ergebnis für den Alltag: ein WAS-Admin in so einer Bank kennt zwei parallele Identity-/Access-Welten (LDAP für Web-Logins, RACF für Mainframe-Ressourcen) und weiß, welche für welche Verbindung greift.

Warum Verbindungs-/Pool-Größe hier ein "Politikum" ist

Auf einem gewöhnlichen Linux-DB-Server kostet eine zusätzliche Connection praktisch nichts. Auf DB2 for z/OS wird CPU-Verbrauch traditionell in MSU (Million Service Units) gemessen und oft direkt in die Softwarelizenzkosten der gesamten Mainframe-Kapazität eingerechnet (z. B. über Tailored Fit Pricing / Sub-Capacity Pricing bei IBM). Praktisch bedeutet das:

• Der connectionManager-/Pool-Sizing-Wert in server.xml (siehe docs/20-monitoring-tuning/) ist auf der DB2-for-z/OS-Seite nicht nur eine Performance-Stellschraube, sondern potenziell eine Kostenfrage — ein zu groß gewählter Pool kann in einer echten Umgebung Rückfragen vom Mainframe-Kapazitätsmanagement auslösen, bevor er einfach genehmigt wird.
• WLM (Workload Manager) auf z/OS-Seite klassifiziert eingehende DDF-Verbindungen (z. B. nach RACF-ID oder Client-Kennung) in Service-Klassen mit unterschiedlicher Priorität — ein WAS-Admin, der weiß, dass es diese Klassifizierung gibt, kann bei Performance-Problemen die richtige Frage an das Mainframe-Team stellen ("in welcher WLM-Service-Klasse läuft unsere Verbindung?") statt nur auf der eigenen Seite zu suchen.

Fehlerbilder, die ein WAS-Admin grob einordnen können sollte

Kein Anspruch auf DB2-DBA-Tiefe, aber diese Grundmuster sind typisch und sollten im Troubleshooting (siehe docs/30-troubleshooting-runbooks/) wiedererkannt werden:

Weiter mit 02-der-bindeglied-prozess.md für den konkreten Ablauf zwischen den vier Teams (Java-Dev, WAS-Admin, DB2-for-z/OS, Netzwerk) und ein server.xml-Beispiel.