Omformning eller omstrukturering? Hur man väljer rätt moderniseringsväg för äldre COBOL

Två organisationer med COBOL-portföljer av liknande storlek fattar olika moderniseringsbeslut. Den ena omplattformar: flyttar COBOL-program till molninfrastruktur med hjälp av AWS Mainframe Modernization eller ett COBOL-emuleringslager, vilket bevarar koden samtidigt som den fysiska stordatorn elimineras. Inom arton månader sänker de infrastrukturkostnaderna med 40 % och programmet anses vara en framgång. Den andra organisationen försöker samma tillvägagångssätt, stöter på väggen efter tolv månader och ställs om till omstrukturering och ombyggnad av de mest kritiska programmen som Java-mikrotjänster. Omvandlingen kostar dubbelt så mycket som den ursprungliga budgeten och tar ytterligare tre år.

Samma utgångspunkt. Radikalt olika resultat. Skillnaden låg inte i verktygen, leverantörerna eller teamen. Det var att den andra organisationen valde omplattformning för system som hade arkitektoniska begränsningar som den nya plattformen inte kunde hantera, CICS-transaktionsberoenden, VSAM-filstrukturer och realtidskrav som den omplattformade koden inte kunde uppfylla utan en grundläggande omdesign. Beslutet fattades innan någon förstod systemen tillräckligt väl för att göra det korrekt.

Vad varje sökväg faktiskt betyder för COBOL

De generiska definitionerna är välkända. Det som spelar roll är vad varje sökväg betyder specifikt för COBOL-program, där arkitekturen, exekveringsmodellen och datastrukturerna skiljer sig från moderna applikationer på sätt som direkt påverkar vilken sökväg som är gångbar.

Omplattformning av COBOL

Omplattformning flyttar COBOL-program till en ny operativ miljö, vanligtvis molninfrastruktur, samtidigt som koden i stort sett bevaras oförändrad. COBOL kompilerar och körs på den nya plattformen, antingen direkt (med IBMs COBOL-kompilator på Linux) eller genom ett emuleringslager som fångar upp stordatorspecifika anrop (CICS, VSAM, JES) och översätter dem till molnbaserade motsvarigheter.

Vad omplattformning behåller:

• COBOL-källkoden
• Programmets logik, beräkningar och affärsregler
• Batchexekveringsmodellen (PERFORM-loopar, sekventiell filbehandling)
• Datastrukturerna (postlayouter, kopieboksdefinitioner)
• JCL-jobbstrukturen (omskriven för den nya schemaläggaren, men logiskt likvärdig)

Vilka förändringar vid omplattformning:

• Den fysiska infrastrukturen (z/OS → Linux i molnet)
• I/O-delsystemet (VSAM → hanterad fillagring eller databas, beroende på verktyg)
• Jobbschemaläggaren (JES2/JES3 → AWS Batch, Azure Logic Apps eller motsvarande)
• Kostnadsmodellen (MIPS-baserad fakturering → konsumtionsbaserad molnfakturering)

Viktig slutsats: Omplattformning är korrekt när problemet är plattformen, kostnaden för att köra z/OS, infrastrukturberoendet eller MIPS-faktureringsmodellen. Det är fel väg att gå när problemet är koden eller arkitekturen.

Omstrukturering av COBOL

Omstrukturering förändrar systemets grundläggande design. Affärslogiken bevaras, eller härleds på nytt från COBOL-källan, men den implementeras i ett nytt språk, med en ny exekveringsmodell, mot ett nytt datalager. Resultatet är ett system som gör vad COBOL gjorde men inte liknar COBOL i struktur.

Vilka förändringar vid omstrukturering:

• Programmeringsspråket (COBOL → Java, Python, Go, C#)
• Exekveringsmodellen (batch → händelsedriven, streaming eller API-baserad)
• Datalagret (VSAM-filer → relationsdatabas, NoSQL, molnbaserad lagring)
• Transaktionsmodellen (CICS pseudo-konversationsbaserad → RESTful tillståndslösa tjänster)
• Integrationsmönstret (delade datamängder → API-kontrakt, meddelandeköer)

Vad omstrukturering måste bevara:

• Varje affärsregel som COBOL implementerar, inklusive odokumenterade edge-fall
• Varje beräkning, inklusive de numeriska precisionsegenskaperna hos packad decimalaritmetik
• Varje datatransformation, inklusive implicita konverteringar i MOVE-satser
• Varje feltillstånd, inklusive de specifika FILSTATUS-koder och abend-beteenden som nedströmssystem kan vara beroende av.

Se upp: Det vanligaste felläget vid omarkitektur är att upptäcka att COBOL-systemet innehåller affärsregler som aldrig skrivits ner någon annanstans. Det nya systemet beter sig annorlunda än det gamla i specifika edge-fall, inte på grund av implementeringsfel, utan för att specifikationen var ofullständig. Affärslogik måste extraheras och dokumenteras från COBOL-källan innan omarkitekturen påbörjas.

De COBOL-specifika faktorerna som förändrar detta beslut

Generiska moderniseringsramverk behandlar omplattformning och omstrukturering som beslut främst om kostnad, tidslinje och risk. För COBOL driver flera tekniska faktorer specifika för språket och dess körmiljö beslutet starkt i ena eller andra riktningen.

CICS-transaktionsberoenden

CICS (Customer Information Control System) är den mellanprogramvara för transaktionsbehandling som många COBOL-program använder för interaktiva arbetsbelastningar. Ett COBOL-program som gör EXEC CICS-anrop har ett implicit beroende av CICS-transaktionsservern för skärmhantering, terminalkommunikation, uppgiftsdispatching och programkontroll.

Implikation för omplattformning: Verktyg som Micro Focus CICS-emulering, OpenFrame och vissa funktioner i AWS Mainframe Modernization emulerar CICS-semantik. Om CICS-användningen är standard och välfungerande kan emulering fungera. Om programmet förlitar sig på CICS-interna funktioner, försämras emuleringskvaliteten på grund av commarea-manipulation, syncpoint-kontroll och lagring på uppgiftsnivå.

Implikation av omstrukturering: Ett CICS-program som konverterats till ett REST API måste få sin pseudokonversationstransaktionsmodell omdesignad till tillståndslösa interaktioner. Detta är en arkitekturförändring, inte en kodöversättning.

Signal som driver mot omstrukturering: Tung CICS-användning med komplex commarea-hantering, backend-transaktionskedjor eller syncpoint-logik.

VSAM-filarkitektur

VSAM (Virtual Storage Access Method) är det indexerade filsystem som används av de flesta COBOL-produktionsprogram. VSAM-filer har specifika åtkomstmönster, KSDS-nyckelrad sekventiell, ESDS-postsekvenserad, RRDS-relativ post, som inte har några direkta motsvarigheter i molnbaserad lagring.

Implikationer för omplattformning: Emuleringslager översätter VSAM-läsningar och -skrivningar till underliggande fil- eller databasoperationer. För enkel sekventiell eller nyckelbaserad åtkomst fungerar detta. För komplex alternativ nyckelåtkomst, VSAM-kluster som delas över flera program eller prestandakänsliga slumpmässiga åtkomstmönster ökar emuleringen latens och komplexitet.

Implikation av omstrukturering: Att ersätta VSAM med en relationsdatabas kräver mappning av postlayouter till tabellscheman, hantering av implicita datatypkonverteringar och omskrivning av varje filåtkomst för att använda SQL eller en ORM.

Signal som driver mot omstrukturering: VSAM-filer som delas mellan många program, alternativa indexåtkomstmönster eller prestandakrav i realtid som emulering inte kan uppfylla.

Batch- kontra realtidskrav

COBOL-batchprogram är utformade för att bearbeta stora volymer poster sekventiellt i schemalagda fönster. Många bank-, försäkrings- och myndighetssystem kör fortfarande batchjobb över natten som bearbetar miljontals transaktioner, producerar rapporter och uppdaterar huvudfiler.

Implikationer för omplattformning: Batchsemantik översätts väl till molnbatchkörning (AWS Batch, Azure Batch). Den sekventiella bearbetningsmodellen överlever plattformsbytet. Om kravet helt enkelt är att köra samma batchjobb på billigare infrastruktur, åtgärdar omplattformning det direkt.

Implikation av omstrukturering: Om affärskraven har förändrats, från batchkörningar över natten till nära realtidsbehandling, från filbaserat utbyte till API-integration, från monolitiska batchkörningar till individuellt utlösta mikrotjänster, kan omplattformning inte uppfylla det nya kravet. Arkitekturen måste förändras.

Signal som driver mot omstrukturering: Intressenternas krav på realtidsbehandling, API-baserad integration, händelsedriven arkitektur eller svarstider på under en sekund som batchsemantik inte kan ge.

Inbäddad affärslogik utan extern specifikation

Detta är den mest underskattade COBOL-specifika faktorn. De primära riskerna inkluderar förlust av kritiska affärsregler inbäddade i årtionden gammal kod och otillräcklig dokumentation av systembeteende. COBOL-program innehåller ofta den enda bevarade specifikationen av en affärsregel. Regeln som krävde en specifik beräkning skrevs 1983. Affärsanalytikern som förstod den gick i pension 2001. COBOL-koden är inte bara en implementering, det är dokumentationen.

Implikationer för omplattformning: Affärsreglerna förblir intakta eftersom koden bevaras. Detta är ett av omplattformningens starkaste argument.

Implikation för omstrukturering: Affärsreglerna måste extraheras från COBOL-källan innan de implementeras på nytt. <cite index="28-1">Odokumenterad, tätt kopplad kod multiplicerar ansträngningen i varje fas.</cite> Om denna extrahering är ofullständig har det nya systemet en annan specifikation än det gamla, och dessa skillnader kommer till ytan i produktionen.

Ett beslutsramverk: Åtta frågor

Innan man väljer en väg tar dessa åtta frågor fram de bevis som behövs för att fatta beslutet med säkerhet snarare än antaganden.

1. Vad är den främsta drivkraften bakom denna modernisering?

• Infrastrukturkostnad → omplattformning är tillräcklig
• Plattformsberoende (z/OS) → omplattformning är tillräckligt
• Realtidskrav → omstrukturering krävs
• Integrationskrav (API) → omstrukturering krävs sannolikt
• Underhållbarhet / tillgänglighet av talanger → omstrukturera eller refaktorera

2. Vad är CICS-kopplingsnivån? Räkna upp alla EXEC CICS-anrop. Räkna program med mer än tjugo distinkta CICS-kommandon. Program med kraftig CICS-koppling är dåliga kandidater för omplattformning om emuleringskvaliteten är osäker.

3. Vilka är VSAM-åtkomstmönstren? Identifiera program som åtkommer VSAM-filer med alternativa nycklar, delade kluster eller prestandakänslig slumpmässig åtkomst. Dessa är riskindikatorer för replatforming.

4. Har affärslogiken dokumenterats externt? Om COBOL-källan är den enda auktoritativa specifikationen kräver omstrukturering extrahering av affärslogik som ett nödvändigt steg, inte en parallell arbetsbelastning.

5. Vad är toleransen för batchfönstret? Om verksamheten kräver samma batchbearbetningsmodell till lägre kostnad, omformulera. Om verksamheten kräver att samma bearbetning ska vara tillgänglig i realtid, omstrukturera.

6. Vad är beroendets komplexitet? Ett program med femtio nedströms beroenden, dataset, kallade underprogram, JCL-anropare, medför högre omstruktureringsrisk än ett fristående verktyg. Beroendestrukturen avgör migreringssekvensering och testomfattning.

7. Hur stor andel av koden är död? Död kod som exkluderas från omfånget innan någon konvertering minskar ansträngningen för båda sökvägarna. För omstrukturerade program konverteras död kod som inte exkluderas till full kostnad och kasseras sedan.

8. Vad är komplexitetsfördelningen? En cyklomatisk komplexitet över 50 per program, eller fler än tjugo inkluderade kopior, indikerar program som är dyra att omstrukturera och riskabla med avseende på plattformsomvandling. Dessa kräver individuell uppmärksamhet snarare än masstilldelning av sökvägar.

Tillämpa ramverket: Fyra COBOL-systemprofiler

Profil	Egenskaper	Rekommenderad väg	Bakgrund
Stabil batch-verktyg	Sekventiell fil-I/O, ingen CICS, väl dokumenterad logik, låg komplexitet	Omplattforma	Plattformskostnaden är problemet; kod är inte begränsningen
CICS-tunga onlinetransaktioner	Tung EXEC CICS-användning, kommaområdeberoenden, pseudokonversationsmodell	Omarkitekt	CICS-emuleringsrisken är hög; realtidskrav sannolikt
VSAM-masterfilprocessor	Komplexa VSAM-åtkomstmönster, delade mellan många program, hög läsvolym	Utvärdera emuleringskvaliteten först; omforma om emuleringen håller	VSAM-emulering är beslutsvariabeln
Affärslogik Treasury	Odokumenterade regler, ingen extern specifikation, hög regulatorisk betydelse	Extrahera logik först, välj sedan	Omstruktureringsrisk är oacceptabel utan föregående extrahering av affärslogik

Viktig slutsats: <cite index="30-1">I praktiken blandar stora system tillvägagångssätt: omplattformar de stabila delarna, omstrukturerar koden som är svår att underhålla, skriver om de få system som behöver ny kapacitet och tar bort det som inte längre används.</cite> Beslutet är inte på portföljnivå, utan på arbetsbelastningsnivå, och tillämpas individuellt på varje program eller programgrupp baserat på bevisen.

Hybridmetoden: Omforma först, omstrukturera där det behövs

En praktisk regel: byt värdskap eller plattform för att snabbt stoppa blödningen, och omstrukturera eller omstrukturera sedan de system som är verkliga konkurrensfördelar.

För de flesta organisationer med stora COBOL-portföljer är den praktiska sekvensen:

Fas 1, Omplattforma de tydliga kandidaterna. Program utan CICS, enkel sekventiell I/O, dokumenterad logik och låg komplexitet kan omplattformas med förutsägbar ansträngning och risk. Detta ger snabba minskningar av infrastrukturkostnader och bygger upp organisationens förtroende.

Fas 2, Utvärdera de komplexa programmen. Program med CICS-koppling, komplexa VSAM-mönster eller odokumenterad affärslogik kräver individuell analys innan en väg väljs. Det är här affärslogikutvinning och strukturell analys avgör om omstrukturering är nödvändig och vad omfattningen skulle vara.

Fas 3, Omstrukturera programmen med arkitektoniska blockerare. Program som inte kan uppfylla affärskraven på den omplattformade infrastrukturen, realtidskrav, API-integration, händelsedriven bearbetning, omstruktureras med hjälp av Strangler Fig-mönstret: den nya tjänsten bygger bredvid det omplattformade programmet, trafik dirigeras progressivt till den nya implementeringen allt eftersom varje komponent valideras och det gamla programmet avvecklas när all trafik har migrerat.

Fas 4, Avveckla död kod. Program som identifierats som döda under strukturell analys exkluderas från båda sökvägarna och tas ur drift, vilket minskar löpande underhållskostnader utan någon konverteringsansträngning.

---

Vad analysen måste ge innan något beslut fattas

Beslutsramverket ovan ger bättre svar när indata är bevis snarare än uppskattningar. Den strukturella analysen som ger dessa indata kräver att man analyserar den faktiska COBOL-källkoden snarare än att förlita sig på dokumentation eller utvecklarens kunskap.

Vad analysen måste fastställa för varje program:

En komplett programinventering inklusive program som dokumentationen inte tar hänsyn till. I stora COBOL-miljöer överstiger antalet odokumenterade program ofta 20 % av det totala antalet. Ett beroendediagram som visar vilka program som anropar vilka andra, vilka datamängder som delas, vilka JCL-jobb som anropar vilka program. CICS-kommandoinventering för varje program, antalet, typerna och komplexiteten hos anropen. VSAM-åtkomstmönsteranalys, vilka åtkomstmetoder, vilka filer som delas mellan program, vilka filer som har alternativa index. Cyklomatisk komplexitetsfördelning, vilka program som är strukturellt enkla och vilka är högriskkandidater för konvertering. Identifiering av död kod, vilka program och stycken som inte har några inkommande exekveringsvägar. Extraktion av affärslogik, vilka regler varje program implementerar, i en form som kan användas för att validera utdata från endera vägen.

Utan denna inventering fattas beslutet om sökvägen baserat på ofullständig information. Program tilldelas omplattformning baserat på antaganden som visar sig vara felaktiga när emuleringen avslöjar arkitektoniska begränsningar som inte var synliga under planeringen.

Hur SMART TS XL Producerar bevis före beslut

SMART TS XLÄr äldre modernisering Analys automatiserar den strukturella inventeringen som beskrivs ovan och analyserar varje COBOL-program, kopiebok, JCL-jobb och VSAM-filreferens samtidigt för att bygga den enhetliga beroendemodellen som gör sökvägsbeslutet evidensbaserat.

Mappningen av applikationsberoenden producerar anropsgrafen mellan program och delningskartan för dataset som avgör beroendets komplexitet, den faktor som mest direkt påverkar både risken för omplattformsemulering och omarkitekturens omfattning och sekvensering.

Den statiska kodanalysen producerar komplexitetsmått, CICS-anropsinventeringar och identifiering av död kod för varje program i portföljen. Program över den cyklomatiska komplexitetströskeln och med kraftig CICS-koppling dyker automatiskt upp som kandidater för omstrukturering eller utvärdering snarare än att masstilldelas till omplattformning.

JCL -expansionen löser symboliska parametrar och bygger den kompletta beroendekedjan för batchexekvering, vilka JCL-jobb anropar vilka program, i vilken sekvens, med vilka datamängder, vilket tillhandahåller det operativa sammanhang som avgör hur utdata från båda sökvägarna måste bete sig för att uppfylla batchschemat.

Effektanalysfunktionen konkretiserar varje sökvägs omfattning innan programmet börjar: för alla program som valts för omstrukturering räknar effektanalysen upp alla beroende program som måste uppdateras, testas om eller koordineras med den omstrukturerade komponenten. För kandidater med omstrukturering identifierar samma analys vilka delade datamängder och delade delprogram som skapar beroenden mellan program som måste hanteras konsekvent.

Företagssökningen gör hela inventeringen sökbar i hela programmet: hitta alla program som använder ett specifikt CICS-kommando, alla program som använder ett specifikt VSAM - kluster, alla kopieböcker som definierar en specifik datastruktur, på några sekunder, över miljontals rader COBOL.

De organisationer som fattar detta beslut korrekt är de som fattar det utifrån strukturella bevis snarare än utifrån antaganden i projektplanen. De strukturella bevisen är vad SMART TS XL producerar.