Der Bindeglied-Prozess: Java-Entwicklung ↔ WAS-Admin ↔ DB2-for-z/OS-Team ↔ Netzwerk

Status: Ablauf dokumentiert/vorbereitet (organisatorisches Muster, wie es in Mainframe-nahen Bankumgebungen üblich ist). Der server.xml-Ausschnitt unten ist syntaktisch korrekt und nach demselben Muster wie die verifizierte Oracle-/DB2-Konfiguration im Novaris-Referenzprojekt aufgebaut, aber nicht gegen echtes DB2 for z/OS gestartet — echtes DB2 for z/OS ist nicht verfügbar (siehe 01-db2-fuer-zos-und-mainframe-grundlagen.md). Ausbaustufe 5 verifiziert dieselbe Konfigurationsform gegen einen DB2-Community-Container.

Warum es überhaupt vier Parteien braucht

Eine neue Datenbankverbindung von concordia-portal zu einer Kerndaten-Tabelle auf DB2 for z/OS berührt vier unterschiedliche Verantwortungsbereiche, die keine einzelne Person/Rolle gleichzeitig innehat:

1. Java-Entwicklung: weiß, welche Query/welches Datenmodell fachlich gebraucht wird.
2. WAS-Administration (diese Rolle): konfiguriert dataSource/jdbcDriver/Connection-Pool in server.xml, sorgt für JNDI-Bindung, überwacht Pool-Auslastung.
3. DB2-for-z/OS-Team: legt die Technical-User-ID + RACF-Berechtigungen an, vergibt ggf. Tabellen-Grants, stellt Kapazität/WLM-Klassifizierung sicher.
4. Netzwerk-Team: schaltet die Firewall-Verbindung zwischen dem Liberty-Subnetz ("dezentral") und dem DDF-Endpunkt ("zentral") frei — siehe 03-netzwerksegmentierung.md.

Typischer Ablauf (Change-Request-Muster)

Java-Dev                WAS-Admin                DB2-for-z/OS-Team          Netzwerk-Team
   |                        |                            |                        |
   |--- Anforderung: ------>|                            |                        |
   |  "neue DataSource      |                            |                        |
   |   fuer Tabelle X"      |                            |                        |
   |                        |--- RACF-ID + Grants ------->|                        |
   |                        |    anfordern (Ticket)       |                        |
   |                        |                            |--- Firewall-Freigabe -->|
   |                        |                            |    Liberty-Subnetz      |
   |                        |                            |    -> DDF-Port 447      |
   |                        |<---------- RACF-ID + -------|                        |
   |                        |            Zertifikats-     |                        |
   |                        |            Trust bestaetigt |                        |
   |                        |<----------------------------------------- Freigabe --|
   |                        |         bestaetigt                                   |
   |                        |
   |                        |--- server.xml: dataSource + jdbcDriver ergaenzen
   |                        |--- Connection-Pool-Groesse MIT DB2-Team abstimmen
   |                        |    (siehe "Politikum"-Abschnitt in Doc 01)
   |                        |--- Deploy + Verifikation (Testverbindung)
   |                        |
   |<--- DataSource JNDI ---|
   |     Name mitteilen     |

Der WAS-Admin ist hier klar die koordinierende Mitte: er/sie muss weder DB2-DBA noch Netzwerk-Spezialist sein, aber genug Kontext aus Doc 01 haben, um die richtigen Tickets an die richtigen Teams zu stellen und die Antworten technisch korrekt umzusetzen.

server.xml-Beispiel: DataSource gegen DB2 for z/OS

Selbes Strukturmuster wie im Referenzprojekt (novaris-policy-ear/src/main/liberty/config/ server.xml, dort gegen DB2 LUW dokumentiert, hier auf DB2-for-z/OS-typische Properties angepasst — sslConnection für Port 447, currentSchema weil auf z/OS Schema-Namenskonventionen oft strikter sind):

<featureManager>
    <feature>jdbc-4.3</feature>
    <!-- ... weitere Features, siehe docs/10-installation-konfiguration/ -->
</featureManager>

<dataSource jndiName="jdbc/concordia/coreBankingDS" id="coreBankingDS">
    <jdbcDriver libraryRef="db2JdbcLib"/>
    <properties.db2.jcc
            serverName="${env.CONCORDIA_DB2_HOST}"
            portNumber="${env.CONCORDIA_DB2_PORT}"
            databaseName="${env.CONCORDIA_DB2_DATABASE}"
            currentSchema="${env.CONCORDIA_DB2_SCHEMA}"
            sslConnection="true"
            user="${env.CONCORDIA_DB2_USER}"
            password="${env.CONCORDIA_DB2_PASSWORD}"/>
    <!-- Poolgroesse bewusst klein und MIT dem DB2-for-z/OS-Team abgestimmt,
         siehe "Politikum"-Abschnitt in 01-db2-fuer-zos-und-mainframe-grundlagen.md. -->
    <connectionManager id="coreBankingConnMgr" maxPoolSize="10" minPoolSize="2"/>
</dataSource>

<library id="db2JdbcLib">
    <fileset dir="${shared.resource.dir}/db2" includes="db2jcc4.jar db2jcc_license_cisuz.jar"/>
</library>

Bewusste Details:

• ${env.CONCORDIA_DB2_*} statt hartcodierter Werte: Zugangsdaten/Hostnamen gehören nicht in eine eingecheckte server.xml — Liberty löst ${env.X} direkt aus Umgebungsvariablen auf (kein zusätzliches Bootstrap-Mapping nötig).
• db2jcc_license_cisuz.jar: die separate Lizenzdatei, die für DB2 for z/OS (anders als für DB2 LUW) zusätzlich zum reinen Treiber-JAR gebraucht wird — ein Detail, das leicht übersehen wird, wenn man nur DB2-LUW-Setups kennt.
• sslConnection="true": Port 447 statt 446, siehe 03-netzwerksegmentierung.md für die Portfreigabe.

Was das für die Übergabe an Betrieb/Support bedeutet

Sobald diese DataSource läuft, gehört sie zum operativen Alltag (siehe docs/50-automatisierung-deployment/ für die Betriebsübergabe-Checkliste). Wichtig für die Übergabe-Doku speziell bei DB2-for-z/OS-Anbindungen:

• Welche RACF-ID wird verwendet, wer ist deren fachlicher Owner (für Passwortrotation/-ablauf)?
• Welche WLM-Service-Klasse ist zugeordnet (für Performance-Eskalationen)?
• Wer beim DB2-for-z/OS-Team ist der Eskalationskontakt bei -30081-Fehlern?

Weiter mit 03-netzwerksegmentierung.md für die Netzwerkzonen und die konkrete Firewall-/Port-Tabelle.