Den nya utvecklaren ansluter sig till stordatorteamet. Hon har tillbringat fem år med att skriva Java-mikrotjänster med Git, GitHub, pull requests, kodgranskningar och CI/CD-pipelines. Hon vet hur man skapar en funktionsbranch, skickar in en PR, tittar på de automatiserade testerna som körs, får feedback från kollegor och slår samman data när kontrollerna godkänns. På dag ett i stordatorteamet lär hon sig arbetsflödet: öppna ISPF, navigera till käll-PDS:en, redigera medlemmen direkt, spara den, skicka in kompilerings-JCL:en, kontrollera SYSOUT för fel. Det finns ingen branch. Det finns ingen historik utöver vad sekvensnumren i kolumnerna 1-6 anger. Det finns ingen pull request. Det finns ingen automatiserad testgate. Om hon och en kollega båda redigerar samma medlem samtidigt, skriver den andra sparningen över den första utan sammanslagning, ingen varning, ingen konflikt, bara tyst dataförlust.
Det här är arbetsflödet som GitOps för stordatorer är utformat för att ersätta. Inte z/OS-plattformen, inte COBOL-språket, inte den beprövade transaktionsbehandlingen som stordatorn levererar med en tillgänglighet på fem-nior, bara arbetsflödet för källkodshantering som föregår distribuerad versionskontroll och inte har hållit jämna steg med hur programvaruteam arbetar. Affärsargumentet blir alltmer konkret: stordatorteam som använder Git-baserade arbetsflöden rapporterar snabbare onboarding för nya utvecklare (inklusive den växande kohorten med endast modern verktygserfarenhet), bättre insyn i ändringshistorik för efterlevnad och revision, förbättrat samarbete mellan stordator- och distribuerade utvecklingsteam och minskad risk från problemet med dubbel redigeringsöverskrivning som ISPF-bibliotekshantering alltid har haft.
Bygg endast berörda program
SMART TS XL identifierar varje program som innehåller en modifierad copybook innan CI-pipelinen bestämmer vad som ska kompileras.
TA REDA PÅ MER…Vad GitOps för stordatorer egentligen betyder
GitOps är en operativ modell där Git är den enda sanningskällan för både applikationskod och infrastrukturkonfiguration. Varje ändring av systemet, koden, konfigurationen och distributionsdefinitionen görs via en Git-commit. Git-arkivet är den auktoritativa posten; det körande systemet avstäms för att matcha vad Git säger att det ska innehålla.
För stordatorsystem innebär detta en specifik uppsättning åtaganden:
Git är den auktoritativa källan för COBOL-källkod. PDS-biblioteket på z/OS är en distributionsartefakt, det som kompileras och körs i produktion, inte sanningskällan. Sanningskällan är Git-arkivet. Om PDS och Git-arkivet inte överensstämmer har Git rätt.
Varje ändring går igenom en pull request. Inga direkta PDS-redigeringar. Ingen akut kompilering och promotering utanför Git-arbetsflödet. En ändring som behövs omedelbart går igenom en snabbare PR, eventuellt med minskade granskningskrav för en verklig nödsituation, men den går via Git.
Automatiserade pipelines hanterar byggande och marknadsföring. En utvecklare sammanfogar sin PR; pipelinen kompilerar de berörda programmen, kör automatiserade tester och marknadsför de kompilerade laddningsmodulerna till lämpligt bibliotek. Utvecklaren skickar inte in kompilerings-JCL manuellt.
Git-commithistoriken är revisionsspåret. Varje ändring i produktionen kan spåras till en specifik commit, en specifik författare, en specifik PR och, om arbetsflödet för pull requests följs, en specifik uppsättning granskare och testresultat.
Detta är en betydande förändring i arbetsflödet för team som är vana vid ISPF-baserad utveckling. Det är också i allt högre grad det arbetsflöde som organisationer behöver för att överbrygga talanggapet: nya utvecklare som känner till Git och inget annat kan delta i COBOL-utveckling utan att lära sig ISPF:s konventioner för bibliotekshantering.
De tekniska utmaningarna: Vad ingen annan artikel förklarar
Att flytta COBOL-källkod till Git är inte lika enkelt som att skapa ett repository och kopiera in filer. Fyra specifika tekniska utmaningar med z/OS komplicerar migreringen:
1. EBCDIC vs. UTF-8-kodning
z/OS lagrar teckendata i EBCDIC (Extended Binary Coded Decimal Interchange Code), medan Git lagrar filer i UTF-8. Varje fil som flyttas mellan stordatorn och ett Git-arkiv måste transkodas. Om transkodningen inte hanteras korrekt, om fel kodsida antas, om konverteringen görs inkonsekvent eller om filer överförs utan konvertering, blir COBOL-källkoden tyst korrupt.
z/OS Unix System Services (USS) är bryggan: COBOL-källkoden i ett PDS transkodas till UTF-8 när den skrivs till USS-filsystemet, där Git kan arbeta på den. När Git-arkivet klonas till USS taggas filer med sin kodning så att z/OS-verktyg vet hur de ska tolka dem.
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 manually2. Semantik för källor och kolumner i fast format
COBOL-källfiler använder en struktur med fast format och kolumnspecifik 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 av COBOL-källkod som visar ändringar i kolumn 73-80 visar vanligtvis ändringar i sekvensnummer eller identifieringsfält, inte funktionella ändringar i koden. Ett diff-verktyg som inte förstår denna kolumnsemantik producerar brus som döljer verkliga ändringar. Git-konfigurationen för ett COBOL-arkiv bör inkludera en .gitattributes som associerar COBOL-filer med en diff-drivrutin som tar bort eller ignorerar identifieringsfältet:
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änsningar för PDS-medlemsnamn
PDS-medlemsnamn är begränsade till 8 tecken, versaler, alfanumeriska plus $, #, @I Git är filnamnet PDS-medlemsnamnet (utan filändelse, eller med en standardfiländelse .cbl tillägg tillagt enligt konvention). 8-teckensgränsen skapar namngivningsbegränsning: CUSTUPDT mappas tydligt till en PDS-medlem; customer-account-update-processor gör inte.
Konventionen som fungerar i praktiken: behåll medlemsnamnen som basfilnamn (8 tecken), lägg till en .cbl tillägg i Git för källidentifiering, och använd katalogstruktur i Git för att tillhandahålla namnrymden som PDS-namngivning inte 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.jcl4. Problemet med auktoritativa källor
Under övergången från PDS-baserad till Git-baserad utveckling innehåller både PDS och Git kopior av källkoden. Vilken är auktoritativ? Svaret måste vara entydigt innan någon produktionsändring görs genom det nya arbetsflödet.
Vilket system innehåller den auktoritativa källan: Git, bibliotekshanteraren eller utdata som genereras av synkroniseringsprocessen? När det svaret är oklart lägger team tid på att lösa skillnader mellan system snarare än att leverera värde. En Git-first-modell ger ett tydligare svar. Git innehåller den auktoritativa källan och registrerar dess historik. Pipelinen använder den källan för att skapa testade, spårbara artefakter för distribution.
Övergångssekvensen som löser denna tvetydighet: etablera Git-arkivet som auktoritativ källa på ett specifikt datum; efter det datumet är alla PDS-redigeringar ett policybrott som måste eskaleras och backportas till Git före slutet av arbetsdagen; akuta snabbkorrigeringar får ett dedikerat snabbkorrigeringsarbetsflöde för PR, inte ett undantag för PDS-redigering. Övergångsperioden, när båda systemen underhålls, bör vara så kort som operativt möjligt, eftersom varje dag med underhåll med dubbla källor är en dag med potentiell divergens.
GitOps-verktygskedjan för stordatorer
Fyra verktygskategorier kopplar Git till z/OS-leveranspipelinen:
Källhantering och IDE: IBM Developer for z/OS (IDz) tillhandahåller en traditionell Eclipse-baserad IDE med ISPF-liknande redigering och inkluderar Git-integration. Alternativt tillhandahåller VS Code med Zowe Explorer-tillägget en modern IDE som ansluter till z/OS via Zowe API-ramverket utan att kräva IDz. Team som vill attrahera utvecklare som är bekanta med moderna verktyg föredrar vanligtvis VS Code.
Zowe-ramverket: Zowe är ett ramverk med öppen källkod som tillhandahåller REST API:er för z/OS, vilket exponerar datauppsättningsoperationer, jobbinlämning och USS-filåtkomst via standardiserade HTTP-gränssnitt som standard CI/CD-verktyg kan anropa. Utan Zowe (eller en kommersiell motsvarighet) finns det inget standardiserat sätt för en GitHub Actions-runner eller Jenkins-agent att interagera med z/OS.
IBM Dependency Based Build (DBB): DBB är det byggverktyg som IBM tillhandahåller specifikt för stordator-GitOps. Det förstår COBOL-kompileringsberoenden, vilka kopieböcker varje program inkluderar, vilka DBD:er och PSB:er som krävs för IMS-program, vilka BIND:er som behövs för Db2, och använder den beroendeförståelsen för att avgöra vad som måste kompileras när en given uppsättning filer ändras.
Ändringshantering och driftsättning: ISPW (CA Brightside), UrbanCode Deploy och Rocket Software ISPW tillhandahåller den befordringshantering som flyttar kompilerade laddningsmoduler från utvecklingsbibliotek via testmiljöer till produktion, med de godkännandearbetsflöden och revisionsspår som reglerade miljöer kräver.
| Verktygskedjelager | Öppen källkod / IBM-alternativ | Kommersiellt alternativ |
|---|---|---|
| IDE | VS-kod + Zowe Explorer | IBM IDz, Broadcom IDz |
| z/OS API-brygga | Zowe CLI + API-lager | Rocket ConnectZen, Kalifornien Brightside |
| Bygg orkestrering | IBM DBB | BMC Compuware Topaz arbetsbänk |
| CI/CD-löpare | Jenkins, GitHub-åtgärder | Azure DevOps, GitLab CI |
| Ändra hanteringen | Zowe + DBB-distribution | ISPW, UrbanCode Deploy |
| Källkampanj | Git-sammanslagning till huvudgrenen | ISPW-kampanjens arbetsflöde |
Rörledningen: Från PR till produktion
Den kompletta GitOps-pipelinen för en COBOL-ändring sträcker sig över den distribuerade CI/CD-plattformen och z/OS-exekveringsmiljön:
jaml
# 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 kritiska elementet i denna pipeline är konsekvensanalyssteget: att bestämma vilka COBOL-program som måste kompileras och testas när en PR modifierar en specifik uppsättning källfiler. Utan detta steg kompilerar pipelinen antingen allt (långsamt och dyrt) eller kompilerar endast de explicit ändrade filerna (saknade program som är beroende av ändrade kopior).
Beroendegapet: Varför konsekvensanalys är den svåraste delen
Git vet exakt vilka filer som ändrades i en pull request. Vad Git inte vet är vilka andra program som påverkas av dessa ändringar.
En PR som modifierar CUSTMSTR.cpy, kopieboken som definierar layouten för kundens huvudregister, ändrar ingenting vad gäller filantal: en fil redigerades. Men CUSTMSTR.cpy ingår i 47 COBOL-program. Alla 47 måste kompileras om. Om bara den explicit ändrade filen kompileras, förblir 46 program i produktion med en copybook-definition som inte längre matchar deras kompilerade binärfil. Avvikelsen är tyst tills programmet körs och försöker läsa en post med den gamla layouten mot data skrivna med den nya layouten.
Detta är beroendegapet i stordator-GitOps: byggsystemet måste känna till beroendegrafen för att bestämma rätt kompileringsomfång. IBM DBB åtgärdar detta för nyetablerade arkiv genom att bygga en explicit beroendekarta som en del av sin byggprocess. För äldre miljöer där tusentals program föregår DBB måste den initiala beroendekartan konstrueras från statisk analys av den befintliga källkoden.
De fyra beroendetyperna som är viktiga för COBOL-byggomfång:
COPY-satser , det vanligaste beroendet. En ändring av en copybook som inkluderas via COPY kräver omkompilering av varje program som inkluderar den.
CALL-satser , statiska anrop till delprogram. Om det anropade programmets gränssnitt ändras (parametrar, returkoder) kan anroparna behöva uppdateras och kompileras om.
SQL INCLUDE , inbäddade SQL-program som inkluderar DCLGEN-medlemmar (dataklassgeneratorer för Db2-tabeller). En Db2-schemaändring som genererar en ny DCLGEN kräver omkompilering av varje program som inkluderar den.
JCL DD-datauppsättningsreferenser , JCL-ändringar som refererar till olika datauppsättningar eller använder olika programnamn påverkar den operativa pipelinen, inte bara programkompileringen.
Det gamla arbetsflödet kontra Git-arbetsflödet
| Aspect | ISPF PDS-baserat arbetsflöde | Git-baserat GitOps-arbetsflöde |
|---|---|---|
| Sanningens källa | PDS-bibliotek på z/OS | Git-arkiv |
| Redigeringsmekanism | ISPF-redigerare, direkt PDS-medlemsredigering | VS-kod / IDz med Git-integration |
| Ändringsspårning | Sekvensnummer i kolumnerna 1–6 | Git commit-historik med författare, tidsstämpel, meddelande |
| Samtidig redigering | Andra sparfunktionen överskrivs först (tyst förlust) | Grenbaserad utveckling; detektering av sammanslagningskonflikter |
| Kodgranskning | Informellt, direkt till skrivbordet | Hämtningsförfrågan med strukturerad granskning och godkännande |
| Bygg utlösare | Manuell JCL-inlämning | Automatiserad via pipeline vid PR eller sammanslagning |
| Beräkning av påverkat omfattning | Manuell kunskap; återskapa allt som standard | Beroendeanalys fastställer berörda program |
| Verifieringskedja | Manuell ändringslogg; ofullständig | Git-logg + PR-metadata; komplett och frågabar |
| Onboarding av nya utvecklare | ISPF-utbildning krävs | Git-standard onboarding; modern IDE |
| Nödförändringar | Direkt PDS-redigering; ofta ospårad | Snabbt PR-arbetsflöde; fullständig spårning |
Den nedersta raden är där den operativa risken i ISPF-arbetsflödet koncentreras: nödändringar som görs direkt i produktions-PDS:er, och som kringgår ändringshanteringsprocessen, är den vanligaste källan till ospårade produktionsändringar och det vanligaste granskningsfyndet i granskningar av ändringskontroll i stordatorer.
Hur SMART TS XL Möjliggör korrekta GitOps för stordatorer
Beroendegapet i stordator-GitOps, gapet mellan "Git vet vad som ändrats" och "pipelinen vet vad som ska kompileras", åtgärdas genom statisk analys av COBOL-källkoden som producerar beroendegrafen.
SMART TS XLÄr mappning av applikationsberoenden producerar den kompletta COPY-beroendegrafen: varje kopiebok, varje program som inkluderar den, varje kapslad COPY-relation och varje CALL-beroende över hela portföljen. När en PR modifierar CUSTMSTR.cpy, producerar beroendekartan omedelbart en lista med 47 program som inkluderar den, och tillhandahåller den indata för byggomfånget som CI-pipelinen behöver för att kompilera rätt uppsättning program, varken mer eller mindre.
Denna beroendekarta är också det som gör migreringen till Git-first-utveckling säker: innan Git-repositoriet etableras som den auktoritativa källan måste hela beroendegrafen vara känd så att den initiala repositorystrukturen återspeglar de faktiska beroendeförhållandena mellan program och kopior. En repositorystruktur som separerar kopior från de program som inkluderar dem utan att de beroendeförhållandena dokumenteras skapar ett repository som byggs korrekt bara om man råkar veta vad som beror på vad, vilket motverkar syftet med versionskontroll.
Funktionen för statisk kodanalys tillhandahåller logiken för pre-commit-grindar: kontroll av ändrade program för hårdkodade autentiseringsuppgifter, saknade FILE STATUS-deklarationer, efterlevnad av namngivningskonventioner och andra statiska kvalitetskontroller som i ett Git-arbetsflöde körs som PR-grindar snarare än som resultat efter distribution.
Effektanalysfunktionen besvarar PR - granskningsfrågan: ”Vad är den fullständiga omfattningen av denna ändring?” En PR som modifierar en kopiabok har en omfattning som sträcker sig till alla program som inkluderar den och varje JCL-jobb som kör dessa program. Att synliggöra denna omfattning i PR-granskningssammanhanget, innan ändringen slås samman, är den information som möjliggör välgrundade granskningsbeslut, lämplig testomfattning och lämpliga godkännandenivåer för ändringsrådgivningsnämnden.
Ocuco-landskapet företagssökning Funktionen stöder kravet på revisionsspår: hitta varje ändring av ett specifikt program inom ett datumintervall (frågabar från Git-loggen), varje program som innehåller en specifik kopia (frågabar från beroendekartan), varje program som modifierats av en specifik författare (frågabar från Git). Kombinationen av Gits commit-historik och SMART TS XLs strukturella analys producerar den kompletta, efterfrågade revisionsloggen som efterlevnadsteam och förändringsrådgivande nämnder kräver.
Förvaret borde veta vad koden vet
Utvecklaren som går med i stordatorteamet med fem års Git-erfarenhet ber inte stordatorn att bli en molnbaserad plattform. Hon ber den att stödja de arbetsflöden som alla moderna utvecklingsteam använder, versionskontroll, kodgranskning, automatiserad testning, spårbarhet. Dessa arbetsflöden existerar av skäl som gäller lika mycket för COBOL som för Java: förhindra dubbelredigeringsöverskrivning, skapa en granskningsbar historik över varje produktionsändring, möjliggöra kodgranskning före driftsättning och automatisera det mekaniska arbetet så att utvecklare kan fokusera på det väsentliga arbetet.
De tekniska utmaningarna är verkliga, EBCDIC-kodning, konventioner för fast format, namnbegränsningar för PDS, frågan om auktoritativa källor. Ingen av dem är olöslig. Verktygskedjan, Zowe, DBB, VS Code med Zowe Explorer, ändringshanteringsplattformarna, adresserar de flesta av dem. Den återstående luckan är beroendeanalysen som gör att pipelinen bygger rätt omfattning när en delad komponent ändras.
Stordatorn som hanterar sin källkod i Git, bygger via en CI/CD-pipeline och driftsätts via ett automatiserat arbetsflöde för marknadsföring är inte en annan stordator. Det är samma stordator, som kör samma beprövade COBOL-program, med samma fem-nio-gradiga tillförlitlighet, och det är nu en stordator som en utvecklare med fem års erfarenhet av moderna verktyg kan ansluta sig till och vara produktiv i i slutet av den första veckan.
