GitOps til mainframe: Moderne versionskontrol til z/OS

IN-COM September 16, 2026 Applikationer, Kode gennemgang, Udviklere, Effektanalyse

Den nye udvikler slutter sig til mainframe-teamet. Hun har brugt fem år på at skrive Java-mikroservices med Git, GitHub, pull requests, kodegennemgange og CI/CD-pipelines. Hun ved, hvordan man opretter en feature-branch, indsender en PR, ser de automatiserede tests køre, får feedback fra kolleger og merger, når kontrollerne består. På dag ét i mainframe-teamet lærer hun arbejdsgangen: åbn ISPF, naviger til kilde-PDS'en, rediger medlemmet direkte, gem det, indsend compile JCL'en, tjek SYSOUT for fejl. Der er ingen branch. Der er ingen historik ud over, hvad sekvensnumrene i kolonne 1-6 angiver. Der er ingen pull request. Der er ingen automatiseret testgate. Hvis hun og en kollega begge redigerer det samme medlem samtidigt, overskriver den anden gemte kode den første uden merge, ingen advarsel, ingen konflikt, kun lydløst datatab.

Dette er den arbejdsgang, som GitOps til mainframe er designet til at erstatte. Ikke z/OS-platformen, ikke COBOL-sproget, ikke den dokumenterede transaktionsbehandling, som mainframen leverer med en tilgængelighed på fem-ni-niveauer, kun den arbejdsgang til kildekodehåndtering, der er ældre end distribueret versionskontrol og ikke har holdt trit med, hvordan softwareteams fungerer. Business casen bliver mere og mere konkret: Mainframe-teams, der anvender Git-baserede arbejdsgange, rapporterer hurtigere onboarding for nye udviklere (inklusive den voksende gruppe med kun moderne værktøjserfaring), bedre overblik over ændringshistorik for compliance og revision, forbedret samarbejde mellem mainframe- og distribuerede udviklingsteams og reduceret risiko fra problemet med dobbelt redigeringsoverskrivning, som ISPF-biblioteksadministration altid har haft.

Byg kun berørte programmer

SMART TS XL identificerer ethvert program, der indeholder en modificeret kopibog, før CI-pipelinen beslutter, hvad der skal kompileres.

FÅ MERE AT VIDE…

Indholdsfortegnelse

Hvad GitOps til mainframe egentlig betyder

GitOps er en operationel model, hvor Git er den eneste sandhedskilde for både applikationskode og infrastrukturkonfiguration. Enhver ændring af systemet, koden, konfigurationen og implementeringsdefinitionen foretages via en Git-commit. Git-arkivet er den autoritative post; det kørende system afstemmes, så det matcher det, Git siger, det skal indeholde.

For mainframe-systemer betyder dette et specifikt sæt af forpligtelser:

Git er den autoritative kilde til COBOL-kildekode. PDS-biblioteket på z/OS er en implementeringsartefakt, det der kompileres og kører i produktion, ikke sandhedens kilde. Sandhedens kilde er Git-arkivet. Hvis PDS og Git-arkivet er uenige, har Git ret.

Enhver ændring går gennem en pull request. Ingen direkte PDS-redigeringer. Ingen nødkompilering og -promovering uden for Git-arbejdsgangen. En ændring, der er nødvendig med det samme, går gennem en fremskyndet PR, potentielt med reducerede gennemgangskrav i tilfælde af en reel nødsituation, men den går gennem Git.

Automatiserede pipelines håndterer build og promovering. En udvikler fletter deres PR; pipelinen kompilerer de berørte programmer, kører automatiserede tests og promoverer de kompilerede indlæsningsmoduler til det relevante bibliotek. Udvikleren indsender ikke kompilerings-JCL manuelt.

Git-commithistorikken er revisionssporet. Enhver ændring i produktionen kan spores til en specifik commit, en specifik forfatter, en specifik PR og, hvis pull request-arbejdsgangen følges, et specifikt sæt af korrekturlæsere og testresultater.

Dette er en betydelig ændring i arbejdsgangen for teams, der er vant til ISPF-baseret udvikling. Det er også i stigende grad den arbejdsgang, som organisationer har brug for for at bygge bro over talentkløften: nye udviklere, der kender Git og intet andet, kan deltage i COBOL-udvikling uden at lære ISPF-biblioteksstyringskonventioner.

De tekniske udfordringer: Hvad ingen anden artikel forklarer

Det er ikke så ligetil at flytte COBOL-kildekode til Git som at oprette et repository og kopiere filer ind. Fire specifikke tekniske udfordringer ved z/OS komplicerer migreringen:

1. EBCDIC vs. UTF-8-kodning

z/OS gemmer tegndata i EBCDIC (Extended Binary Coded Decimal Interchange Code), mens Git gemmer filer i UTF-8. Enhver fil, der flyttes mellem mainframen og et Git-arkiv, skal transkodes. Hvis transkodningen ikke håndteres korrekt, hvis den forkerte kodeside antages, hvis konverteringen udføres inkonsekvent, eller hvis filer overføres uden konvertering, bliver COBOL-kildekoden lydløst beskadiget.

z/OS Unix System Services (USS) er broen: COBOL-kildekoden i et PDS transkodes til UTF-8, når den skrives til USS-filsystemet, hvor Git kan operere på den. Når Git-arkivet klones til USS, tagges filer med deres kodning, så z/OS-værktøjer ved, hvordan de skal fortolkes.

bash

# z/OS USS: correctly tag a Git-managed COBOL source file
chtag -t -c IBM-1047 CUSTPROC.cbl

# Verify the tag
ls -T CUSTPROC.cbl
# Output: t IBM-1047   T=on  CUSTPROC.cbl

# The Git checkout hook should apply this automatically
# so developers don't have to tag files manually

2. Kilde i fast format og kolonnesemantik

COBOL-kildefiler bruger en fastformatstruktur med kolonnespecifik semantik:

Columns 1-6:   Sequence numbers (optional; ISPF editors fill these automatically)
Column 7:      Indicator (* = comment, - = continuation, D = debug line)
Columns 8-11:  Area A (division/section/paragraph names, level numbers 01/77)
Columns 12-72: Area B (executable statements, clauses)
Columns 73-80: Identification (program name, historically used for card identification)

En Git-diff af COBOL-kildekoden, der viser ændringer i kolonne 73-80, viser typisk ændringer i sekvensnummer eller identifikationsfelt, ikke funktionelle ændringer i koden. Et diff-værktøj, der ikke forstår disse kolonnesemantikker, producerer støj, der skjuler reelle ændringer. Git-konfigurationen for et COBOL-repository bør indeholde en .gitattributes der forbinder COBOL-filer med en diff-driver, der fjerner eller ignorerer identifikationsfeltet:

ini

# .gitattributes: configure COBOL-aware diff
*.cbl  diff=cobol
*.cob  diff=cobol
*.cpy  diff=cobol

# .gitconfig (or repo-level config): define the cobol diff driver
[diff "cobol"]
    xfuncname = "^[0-9A-Z][0-9A-Z -]+"
    wordRegex = "[A-Z][A-Z0-9-]+"

3. Begrænsninger for PDS-medlemsnavne

PDS-medlemsnavne er begrænset til 8 tegn, store bogstaver, alfanumeriske bogstaver plus $, #, @I Git er filnavnet PDS-medlemsnavnet (uden filtypenavn eller med en standardfiltypenavn) .cbl (udvidelse tilføjet efter konvention). Grænsen på 8 tegn skaber navngivningsbegrænsning: CUSTUPDT knyttes tydeligt til et PDS-medlem; customer-account-update-processor gør ikke.

Konventionen der fungerer i praksis: behold medlemsnavne som basisfilnavn (8 tegn), tilføj en .cbl udvidelse i Git til kildeidentifikation, og brug mappestruktur i Git til at levere det navneområde, som PDS-navngivning ikke kan:

repository/
├── CUSTMGMT/          # Logical application group (no PDS equivalent)
│   ├── CUSTUPDT.cbl   # Maps to PDS member CUSTUPDT
│   ├── CUSTINQ.cbl
│   └── CUSTSRCH.cbl
├── COPYBOOKS/
│   ├── CUSTMSTR.cpy   # Maps to PDS member CUSTMSTR
│   └── TRANREC.cpy
└── JCL/
    ├── CUSTNITE.jcl
    └── CUSTMON.jcl

4. Problemet med den autoritative kilde

Under overgangen fra PDS-baseret til Git-baseret udvikling indeholder både PDS og Git kopier af kildekoden. Hvilken er autoritativ? Svaret skal være entydigt, før der foretages nogen produktionsændringer via den nye arbejdsgang.

(cite index="42-1">Hvilket system indeholder den autoritative kilde: Git, biblioteksadministratoren eller outputtet genereret af synkroniseringsprocessen? Når svaret er uklart, bruger teams tid på at løse forskelle mellem systemer i stedet for at levere værdi. En Git-first-model giver et klarere svar. Git indeholder den autoritative kilde og registrerer dens historik. Pipeline bruger denne kilde til at oprette testede, sporbare artefakter til implementering.

Overgangssekvensen, der løser denne tvetydighed: etabler Git-arkivet som den autoritative kilde på en bestemt dato; efter denne dato er enhver PDS-redigering en politikovertrædelse, der skal eskaleres og backporteres til Git inden udgangen af arbejdsdagen; nød-hotfixes får en dedikeret hurtig PR-arbejdsgang, ikke en PDS-redigeringsundtagelse. Overgangsperioden, hvor begge systemer vedligeholdes, bør være så kort som operationelt muligt, fordi hver dag med vedligeholdelse af to kilder er en dag med potentiel divergens.

Mainframe GitOps-værktøjskæden

Fire værktøjskategorier forbinder Git med z/OS-leveringspipelinen:

Kildestyring og IDE: IBM Developer for z/OS (IDz) leverer en traditionel Eclipse-baseret IDE med ISPF-lignende redigering og inkluderer Git-integration. Alternativt tilbyder VS Code med Zowe Explorer-udvidelsen en moderne IDE, der opretter forbindelse til z/OS via Zowe API-frameworket uden at kræve IDz. Teams, der ønsker at tiltrække udviklere, der er bekendte med moderne værktøjer, foretrækker typisk VS Code.

Zowe-frameworket: Zowe er et open source-framework, der leverer REST API'er til z/OS, og som eksponerer datasætoperationer, jobannsendelse og USS-filadgang via standardiserede HTTP-grænseflader, som standard CI/CD-værktøjer kan kalde. Uden Zowe (eller en kommerciel ækvivalent) er der ingen standardiseret måde for en GitHub Actions-runner eller Jenkins-agent at interagere med z/OS.

IBM Dependency Based Build (DBB): DBB er det byggeværktøj, som IBM leverer specifikt til mainframe GitOps. Det forstår COBOL-kompileringsafhængigheder, hvilke kopibøger hvert program indeholder, hvilke DBD'er og PSB'er der kræves til IMS-programmer, hvilke BIND'er der er nødvendige til Db2, og bruger denne afhængighedsforståelse til at bestemme, hvad der skal kompileres, når et givet sæt filer ændres.

Ændringsstyring og implementering: ISPW (CA Brightside), UrbanCode Deploy og Rocket Software ISPW leverer den promoveringsstyring, der flytter kompilerede indlæsningsmoduler fra udviklingsbiblioteker via testmiljøer til produktion med de godkendelsesworkflows og revisionsspor, som regulerede miljøer kræver.

Værktøjskædelag	Open Source / IBM-mulighed	Kommercielt alternativ
IDE	VS-kode + Zowe Explorer	IBM IDz, Broadcom IDz
z/OS API-bro	Zowe CLI + API-lag	Rocket ConnectZen, Californien Brightside
Byg orkestrering	IBM DBB	BMC Compuware Topaz arbejdsbord
CI/CD-løber	Jenkins, GitHub-handlinger	Azure DevOps, GitLab CI
Forandringsledelse	Zowe + DBB-implementering	ISPW, UrbanCode Implementering
Kildepromovering	Git-fletning til hovedgrenen	ISPW-promoveringsarbejdsgang

Pipeline: Fra PR til produktion

End-to-end GitOps-pipelinen for en COBOL-ændring spænder over den distribuerede CI/CD-platform og z/OS-udførelsesmiljøet:

yaml

# GitHub Actions: COBOL GitOps pipeline
name: Mainframe COBOL Pipeline

on:
  pull_request:
    paths:
      - '**/*.cbl'
      - '**/*.cpy'
      - '**/*.jcl'

jobs:
  impact-analysis:
    runs-on: ubuntu-latest
    outputs:
      affected: ${{ steps.analyze.outputs.affected_programs }}
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Identify changed files
        id: changes
        run: |
          CHANGED=$(git diff --name-only origin/main...HEAD \
                    | grep -E '\.(cbl|cpy|jcl)$')
          echo "changed=$CHANGED" >> $GITHUB_OUTPUT

      - name: Analyze dependency scope
        id: analyze
        # SMART TS XL or DBB dependency analysis determines
        # which programs are affected by the changed files
        run: |
          echo "Resolving dependency scope for: ${{ steps.changes.outputs.changed }}"
          # Output: the specific programs that must be compiled/tested

  compile-and-test:
    needs: impact-analysis
    runs-on: [self-hosted, zos-runner]  # Runner with z/OS connectivity
    steps:
      - uses: actions/checkout@v4

      - name: Compile affected COBOL programs (via Zowe + DBB)
        run: |
          zowe dbb build \
            --sourceDir ./CUSTMGMT \
            --affected "${{ needs.impact-analysis.outputs.affected }}" \
            --workDir /u/devops/builds/${{ github.run_id }}

      - name: Run unit tests
        run: |
          zowe zunit run \
            --programs "${{ needs.impact-analysis.outputs.affected }}" \
            --results-dir /u/devops/results/${{ github.run_id }}

      - name: Static compliance check (before promotion)
        run: |
          # Hardcoded credential check, FILE STATUS validation,
          # naming convention compliance
          zowe smart-ts-xl analyze \
            --scope "${{ needs.impact-analysis.outputs.affected }}"

  promote-to-test:
    needs: compile-and-test
    if: github.event_name == 'pull_request' && github.base_ref == 'main'
    runs-on: [self-hosted, zos-runner]
    steps:
      - name: Promote to TEST library (via ISPW)
        run: |
          zowe ispw promote \
            --programs "${{ needs.compile-and-test.outputs.compiled }}" \
            --from DEV --to TEST \
            --change-request ${{ github.event.pull_request.number }}

Det kritiske element i denne pipeline er konsekvensanalysetrinnet: bestemmelse af hvilke COBOL-programmer, der skal kompileres og testes, når en PR ændrer et specifikt sæt kildefiler. Uden dette trin kompilerer pipelinen enten alt (langsomt og dyrt) eller kompilerer kun de eksplicit ændrede filer (manglende programmer, der afhænger af ændrede kopibøger).

Afhængighedskløften: Hvorfor konsekvensanalyse er den sværeste del

Git ved præcis hvilke filer der blev ændret i en pull request. Hvad Git ikke ved, er hvilke andre programmer der er påvirket af disse ændringer.

En PR, der ændrer CUSTMSTR.cpy, den kopibog, der definerer layoutet for kundens stamdata, ændrer intet med hensyn til filantal: én fil blev redigeret. Men CUSTMSTR.cpy er inkluderet i 47 COBOL-programmer. Alle 47 skal rekompileres. Hvis kun den eksplicit ændrede fil kompileres, forbliver 46 programmer i produktion med en kopibogsdefinition, der ikke længere matcher deres kompilerede binære fil. Uoverensstemmelsen er tavs, indtil programmet kører og forsøger at læse en post ved hjælp af det gamle layout mod data skrevet med det nye layout.

Dette er afhængighedsgabet i mainframe GitOps: byggesystemet skal kende afhængighedsgrafen for at bestemme det korrekte kompileringsomfang. IBM DBB adresserer dette for nyetablerede repositories ved at opbygge et eksplicit afhængighedskort som en del af sin byggeproces. For ældre miljøer, hvor tusindvis af programmer eksisterer før DBB, skal det indledende afhængighedskort konstrueres ud fra statisk analyse af den eksisterende kildekode.

De fire afhængighedstyper, der er vigtige for COBOL-build-scoping:

COPY-sætninger , den hyppigste afhængighed. En ændring af en hvilken som helst kopibog inkluderet via COPY kræver rekompilering af alle programmer, der inkluderer den.

CALL-sætninger , statiske kald til underprogrammer. Hvis det kaldte programs grænseflade ændres (parametre, returkoder), skal kaldere muligvis opdateres og rekompileres.

SQL INCLUDE , indlejrede SQL-programmer, der inkluderer DCLGEN-medlemmer (dataklassegeneratorer til Db2-tabeller). En Db2-skemaændring, der genererer en ny DCLGEN, kræver rekompilering af alle programmer, der inkluderer den.

JCL DD-datasætreferencer , JCL-ændringer, der refererer til forskellige datasæt eller bruger forskellige programnavne, påvirker den operationelle pipeline, ikke kun programkompileringen.

Den gamle arbejdsgang vs. Git-arbejdsgangen

Aspect	ISPF PDS-baseret arbejdsgang	Git-baseret GitOps-arbejdsgang
Sandhedens kilde	PDS-bibliotek på z/OS	Git-arkiv
Redigeringsmekanisme	ISPF-editor, direkte redigering af PDS-medlemmer	VS-kode / IDz med Git-integration
Ændringssporing	Sekvensnumre i kolonne 1-6	Git commit-historik med forfatter, tidsstempel og besked
Samtidig redigering	Anden gemning overskrives først (lydløs tab)	Grenbaseret udvikling; detektion af fusionskonflikter
Kode anmeldelse	Uformelt, lige ved skrivebordet	Pull request med struktureret gennemgang og godkendelse
Byggeudløser	Manuel JCL-indsendelse	Automatiseret via pipeline på PR eller merge
Beregning af berørt omfang	Manuel viden; genopbyg alt som standard	Afhængighedsanalyse bestemmer berørte programmer
Revisionsspor	Manuel ændringslog; ufuldstændig	Git-log + PR-metadata; komplet og forespørgbar
Onboarding af nye udviklere	ISPF-uddannelse påkrævet	Git-standard onboarding; moderne IDE
Nødændringer	Direkte PDS-redigering; ofte ikke sporet	Fremskyndet PR-workflow; fuldt sporet

Den nederste række er der, hvor den operationelle risiko ved ISPF-arbejdsgangen koncentreres: Nødændringer foretaget direkte i produktions-PDS'er, der omgår ændringsstyringsprocessen, er den hyppigste kilde til usporede produktionsændringer og det hyppigste revisionsresultat i mainframe-ændringskontrolgennemgange.

Hvordan SMART TS XL Muliggør præcis mainframe GitOps

Afhængighedsgabet i mainframe GitOps, gabet mellem "Git ved, hvad der er ændret" og "pipeline ved, hvad der skal kompileres", adresseres ved statisk analyse af COBOL-kildekoden, der producerer afhængighedsgrafen.

SMART TS XL's kortlægning af applikationsafhængighed producerer den komplette COPY-afhængighedsgraf: hver kopibog, hvert program, der inkluderer den, hver indlejret COPY-relation og hver CALL-afhængighed på tværs af hele porteføljen. Når en PR ændrer CUSTMSTR.cpy, producerer afhængighedskortet straks listen over 47 programmer, der inkluderer det, og leverer det input til byggeområdet, som CI-pipelinen skal bruge for at kompilere det korrekte sæt af programmer, hverken mere eller mindre.

Dette afhængighedskort er også det, der gør migreringen til Git-first-udvikling sikker: før Git-repositoryet etableres som den autoritative kilde, skal den fulde afhængighedsgraf være kendt, så den indledende repositorystruktur afspejler de faktiske afhængighedsrelationer mellem programmer og kopibøger. En repositorystruktur, der adskiller kopibøger fra de programmer, der inkluderer dem, uden de dokumenterede afhængighedsrelationer, skaber et repository, der kun bygger korrekt, hvis man tilfældigvis ved, hvad der afhænger af hvad, hvilket modvirker formålet med versionskontrol.

Funktionen til statisk kodeanalyse leverer pre-commit gate-logikken: kontrol af ændrede programmer for hardcodede legitimationsoplysninger, manglende FILE STATUS-erklæringer, overholdelse af navngivningskonventioner og andre statiske kvalitetskontroller, der i en Git-arbejdsgang kører som PR-gates i stedet for som resultater efter implementering.

Effektanalysefunktionen besvarer PR-gennemgangsspørgsmålet: "Hvad er det fulde omfang af denne ændring?" En PR, der ændrer en kopibog , har et effektomfang, der strækker sig til alle programmer, der inkluderer den, og alle JCL-job, der kører disse programmer. Ved at gøre dette omfang synligt i PR-gennemgangskonteksten, før ændringen integreres, er de oplysninger, der muliggør informerede beslutninger om gennemgang, passende testomfang og passende godkendelsesniveauer fra det rådgivende udvalg for ændringer.

virksomhedssøgning Funktionen understøtter kravet om revisionsspor: find alle ændringer i et specifikt program inden for et datointerval (kan forespørges fra Git-loggen), alle programmer, der inkluderer en specifik kopibog (kan forespørges fra afhængighedskortet), alle programmer, der er ændret af en specifik forfatter (kan forespørges fra Git). Kombinationen af Gits commit-historik og SMART TS XL's strukturelle analyse producerer det komplette, forespørgbare revisionsspor, som compliance-teams og forandringsrådgivningsudvalg har brug for.

Arkivet bør vide, hvad koden ved

Udvikleren, der slutter sig til mainframe-teamet med fem års Git-erfaring, beder ikke mainframen om at blive en cloud-native platform. Hun beder den om at understøtte de arbejdsgange, som alle moderne udviklingsteams bruger, versionskontrol, kodegennemgang, automatiseret testning, sporbarhed. Disse arbejdsgange eksisterer af grunde, der gælder lige så meget for COBOL som for Java: at forhindre dobbeltredigeringsoverskrivning, at oprette en auditerbar historik over hver produktionsændring, at muliggøre kodegennemgang før implementering og at automatisere det mekaniske arbejde, så udviklere kan fokusere på det væsentlige arbejde.

De tekniske udfordringer er reelle: EBCDIC-kodning, konventioner for fastformaterede kildekoder, begrænsninger i PDS-navngivningen og spørgsmålet om autoritativ kildekode. Ingen af dem er uløselige. Værktøjskæden, Zowe, DBB, VS Code med Zowe Explorer, platformene til ændringsstyring, adresserer de fleste af dem. Det resterende hul er den afhængighedsanalyse, der sikrer, at pipelinen bygger det rigtige omfang, når en delt komponent ændres.

Mainframen, der administrerer sin kildekode i Git, bygger via en CI/CD-pipeline og implementerer via en automatiseret promoveringsworkflow, er ikke en anden mainframe. Det er den samme mainframe, der kører de samme dokumenterede COBOL-programmer med den samme 5-9-graders pålidelighed, og det er nu en mainframe, som en udvikler med fem års erfaring med moderne værktøjer kan tilslutte sig og være produktiv i inden udgangen af den første uge.