Kernsystem · Prio 10 · Version 4

Mainframe / Host-Kernsystem

Zentrale Transaktionslogik, Buchungen, Vertragsfuehrung, Policenverwaltung oder Kundenstammdaten mit sehr hoher Stabilitaet.

← Startseite
0 Treffer
Kurzverständnis und Systemgrenze

Mainframe-Systeme sind in vielen Unternehmen keine technischen Altlasten, sondern betriebliche Rueckgrate. Sie verarbeiten hohe Transaktionsmengen, sind stark kontrolliert und enthalten Fachlogik, die in keinem aktuellen Wiki vollstaendig dokumentiert ist.

Typische Modernisierungsfehler entstehen, wenn Teams Copybooks wie simple DTOs behandeln oder Host-Transaktionen ueber neue APIs exponieren, ohne Commit-Verhalten, Sperren, Tagesabschluss und Fehlercodes zu verstehen.

Das Ziel ist nicht zwingend, den Host sofort abzuwerfen. Ziel ist zuerst eine kontrollierte Kapselung: stabile Facades, fachliche Testfaelle, Golden-Master-Vergleiche, beobachtbare Integrationen und klare Grenzen fuer neue Funktionen.

Daten- und Verantwortungsgrenze: Der Mainframe ist oft das System of Record. Er besitzt die finale Wahrheit fuer Kernobjekte und darf nicht nur als alte Datenbank betrachtet werden. Viele Regeln liegen in COBOL-Programmen, Copybooks, Jobketten und jahrzehntelang stabilisierten Sonderfaellen.
Fachliche und technische Darstellung
Fachliche Sicht Mainframe / Host-Kernsystem
Fachliche Sicht: Prozess, Verantwortung, Nachweis.
Technische Sicht Mainframe / Host-Kernsystem
Technische Sicht: Komponenten, Protokolle, Betriebsbezug.
Wichtige Begriffe und Artefakte

Copybook

Gemeinsame Felddefinition fuer COBOL-Programme und externe Adapter.

CICS-Transaktion

Online-Transaktion mit definiertem Programmnamen, Eingabemaske, Antwortcode und Commit-Verhalten.

VSAM/DB2

Datenhaltung fuer sequenzielle, indexierte oder relationale Kernbestände.

JCL

Beschreibung fuer Batchjobs, Step-Folgen, Dateien, Ressourcen und Rueckgabecodes.

Typischer Ablauf Schritt für Schritt
  1. Sachbearbeiter oder Portal loest eine Vertragsaenderung aus.
  2. Java- oder ESB-Adapter uebersetzt Fachrequest in Copybook-Struktur.
  3. CICS-Transaktion validiert Status, Sperren und fachliche Sonderregeln.
  4. Host schreibt Kernbestand und erzeugt technische/fachliche Rueckgabecodes.
  5. Batchjobs synchronisieren Folgeinformationen fuer DWH, Archiv oder Partnerdateien.
Ausführliche Praxisbeispiele mit Code und Konfiguration

Die Beispiele sind bewusst nicht minimalistisch. Sie zeigen typische Artefakte, die man in echten Legacy-Analysen findet: Schnittstellenverträge, Containerkonfiguration, SQL/PL-SQL, Jobdefinitionen, Queue-Regeln oder Adaptercode.

COBOL Copybook fuer Vertragsaenderung
       01  POLICY-CHANGE-REQUEST.
           05  POLICY-NO            PIC X(12).
           05  CUSTOMER-ID          PIC X(10).
           05  EFFECTIVE-DATE       PIC 9(8).
           05  CHANGE-TYPE          PIC X(03).
           05  PREMIUM-AMOUNT       PIC S9(7)V99 COMP-3.
           05  REQUEST-CHANNEL      PIC X(02).
           05  AUDIT-USER           PIC X(20).
           05  RESPONSE-CODE        PIC X(04).
           05  RESPONSE-TEXT        PIC X(80).
Java Adapter als Anti-Corruption Layer
public final class PolicyHostAdapter {
    private final CicsGateway gateway;
    private final PolicyCopybookMapper mapper;

    public PolicyChangeResult changePolicy(PolicyChangeCommand command) {
        HostPolicyChangeRequest request = mapper.toHost(command);
        HostResponse response = gateway.execute("POLC", request.toBytes());

        if (response.isTechnicalFailure()) {
            throw new HostUnavailableException(response.technicalCode());
        }
        if (response.isBusinessRejection()) {
            return PolicyChangeResult.rejected(mapper.toDomainReason(response));
        }
        return PolicyChangeResult.accepted(response.correlationId());
    }
}
JCL Batch-Step mit Returncode-Auswertung
//POLBATCH JOB (FIN),'POLICY CLOSE',CLASS=A,MSGCLASS=X
//STEP010  EXEC PGM=POLCLOSE
//INFILE   DD DSN=PROD.POLICY.CHANGES,DISP=SHR
//OUTFILE  DD DSN=PROD.POLICY.CLOSE.REPORT,DISP=(NEW,CATLG)
//SYSOUT   DD SYSOUT=*
//CONDCHK  EXEC PGM=RCHECK,COND=(4,LT,STEP010)
//SYSOUT   DD SYSOUT=*
Risiken, Fehlerbilder und Diagnose
AspektBeschreibung
Fachliches RisikoUnklare Verantwortung fuer Vertrag/Konto/Police fuehrt zu widerspruechlichen Entscheidungen zwischen Alt- und Neusystem.
Technisches RisikoCOBOL und angrenzende Komponenten werden isoliert betrachtet; Laufzeitkopplung bleibt verborgen.
BetriebsrisikoFehlerkanal, Monitoring, Restart oder manuelle Klaerung sind nicht ausreichend dokumentiert.
MigrationsrisikoNeue Architektur uebernimmt Daten oder Schnittstellen, ohne fachliche Invarianten und historische Sonderfaelle abzusichern.
Typische Fallen:
  • EBCDIC/ASCII, Dezimalformate und gepackte Zahlen falsch interpretieren.
  • Host-Returncodes nur technisch behandeln und fachliche Ablehnungen uebersehen.
  • Online-Transaktion modernisieren, aber Nachtbatch, Tagesabschluss und Storno-/Korrekturlogik ignorieren.
  • Mehrere neue Services direkt gegen dieselbe Host-Transaktion bauen und dadurch unkontrollierte Kopplung erzeugen.
Modernisierungspfad und geeignete Entwurfsmuster
PatternEinsatz in diesem System
Strangler Fig PatternNeue Funktionalitaet vor das Altsystem setzen und Altanteile schrittweise herausloesen.
Anti-Corruption LayerAltbegriffe, technische Codes und Datenformate vom neuen Domänenmodell trennen.
FacadeKomplexe Legacy-Operationen hinter klaren fachlichen Use-Case-Methoden kapseln.
AdapterProtokolle und Formate wie SOAP, MQ, Copybook, SQL oder File in Ports uebersetzen.
Golden Master TestBestehendes Verhalten mit Referenzdaten erfassen und gegen neue Implementierung vergleichen.
Empfohlene Schritte:
  • Baue eine Host-Facade mit fachlichen Methoden statt direkter Transaktionsweitergabe.
  • Nutze Contract Tests fuer Copybook-Felder, Wertebereiche, Encoding und Returncodes.
  • Lege Anti-Corruption Layer an, der Host-Begriffe in modernes Domänenmodell uebersetzt.
  • Beginne mit lesenden Use Cases oder Nebenfunktionen, bevor schreibende Kerntransaktionen ersetzt werden.
Analysefragen für echte Projekte
  • Wer besitzt fachlich die Wahrheit fuer Vertrag/Konto/Police?
  • Welche technische Komponente ist kritisch: COBOL, CICS/IMS, DB2/VSAM?
  • Welche Daten werden veraendert, gelesen, abgeleitet oder nur transportiert?
  • Welche Fehler sind fachlich erwartbar und welche sind technische Stoerungen?
  • Welche Protokolle, Dateien, Tabellen, Queues oder Reports bilden den offiziellen Vertrag?
  • Wie wird ein Fehler heute erkannt, korrigiert und gegenueber dem Fachbereich nachgewiesen?
  • Welche Teile lassen sich lesend modernisieren und welche sind schreibend hochkritisch?
  • Welche Tests sichern aktuelles Verhalten, bevor Refactoring oder Migration beginnt?
Übung

Nimm eine Host-Transaktion wie Vertragsaenderung. Dokumentiere Eingabefelder, Pflichtfelder, Encoding, Returncodes, fachliche Ablehnungen, technische Fehler, Batch-Nachwirkungen und Testdaten. Entwerfe danach eine moderne Facade-Schnittstelle.

⌂ Cockpit