IMS-databasberoendeanalys: Vad moderniseringsteam måste veta innan de flyttar något

IMS är inte ett äldre system i den meningen att det är föråldrat. Det är databasmotorn bakom storbankernas kundfordringar, försäkringsbolagens policyadministration och vårdbetalarnas skadehantering. IBM fortsätter att utveckla det. Problemet är inte att IMS slutat fungera, problemet är att varje utvecklare som visste hur man navigerar i dess hierarkiska segmentträd går i pension, varje förändring av ett IMS-baserat system kräver förståelse för en datamodell som saknar SQL, och varje migreringsplan som behandlar IMS som en relationsdatabas upptäcker skillnaden den hårda vägen.

Den svåra vägen är att upptäcka mitt under migreringen att ett COBOL-program kommer åt IMS inte genom en enkel nyckelsökning utan genom en hierarkisk genomgång som måste replikeras i målsystemet med motsvarande navigeringslogik. Eller att upptäcka att en logisk relation mellan två fysiska IMS-databaser skapar ett beroende som ingen av databasernas DBD dokumenterar helt och hållet, och att migreringen konverterade båda databaserna oberoende av varandra samtidigt som varje program som använde den logiska relationen bröts i tysthet. Eller att upptäcka att en sekundär indexdatabas, en struktur som de flesta migreringsplaner aldrig inventerar, var den enda vägen genom vilken ett kritiskt rapporteringsprogram nådde sina data.

Inga av dessa överraskningar överlever kontakt med rigorös beroendeanalys före migrationen. De överlever kontakt med antaganden.

Vad som gör IMS-beroendeanalys annorlunda

Beroendeanalys för en relationsdatabasmiljö, DB2, Oracle, SQL Server, följer en välförstådd sökväg. Parsa SQL-koden i applikationskoden, identifiera tabell- och kolumnreferenser, skapa en karta över vilka program som har åtkomst till vilka tabeller och använd den kartan för att bestämma migreringens omfattning och sekvens. Strukturen är explicit. Beroendena är synliga i SQL-texten.

IMS-beroendeanalys är mer komplex längs varje dimension.

Strukturen är hierarkisk, inte relationell. En IMS-databas är organiserad som ett träd av segmenttyper, där varje segmenttyp har en definierad förälder-barn-relation. Ett COBOL-program som läser patientjournaler från en IMS-databas körs inte SELECT * FROM PATIENTS WHERE ID = ?Den utfärdar ett Get Unique-anrop (GU) för att navigera hierarkin till rotsegmentet, och sedan Get Next Within Parent-anrop (GNP) för att gå igenom de underordnade segmenten. Programmets beroende är inte på en tabell, det är på en specifik sökväg genom en hierarkisk struktur, och att ändra den strukturen kan orsaka att program som navigerar i den på sätt som ingen SQL-nivåanalys skulle upptäcka inte fungerar.

Beroendena är fördelade över tre separata strukturer. För att få en fullständig bild av vad ett COBOL-program gör med IMS krävs analys av:

• DBD (databasdeskriptor): definierar den fysiska segmenthierarkin, nyckelfälten, åtkomstmetoderna (HDAM, HIDAM, HISAM, HSAM) och eventuella sekundära index eller logiska relationer.
• PSB (Programspecifikationsblock): definierar vilka databaser ett program har åtkomst till, genom vilka PCB:er, med vilka känslighets- och avsiktsspecifikationer
• COBOL-källkoden: innehåller de faktiska DL/I-anropen som avgör vilka segment som nås, med vilka anropsfunktioner, i vilken sekvens, med vilka SSA:er

Ingen enskild källa innehåller hela bilden. Analys som bara läser COBOL-källan ser anropstyperna och segmentnamnen men inte den fysiska databasstrukturen. Analys som bara läser DBD och PSB ser vad programmet har tillåtelse att göra men inte vad det faktiskt gör.

Navigeringen är positionsberoende. I en relationsdatabas är varje rad oberoende adresserbar med nyckel. I IMS påverkar ett programs aktuella position i hierarkin vad efterföljande anrop returnerar. Ett GN (Get Next)-anrop returnerar nästa segment i hierarkisk sekvens från var programmet för närvarande befinner sig. Beroendet är inte bara på segmenttypen utan på den traversalväg som ledde till den aktuella positionen. Program som förlitar sig på IMS implicita hierarkiska ordning har ett beroende som försvinner när data migreras till en relationsdatabas där ingen motsvarande ordning garanteras.

DL/I-anropsinventeringen: Vad COBOL-källkoden avslöjar

Den mest direkt användbara analysen före migrering är en komplett inventering av varje DL/I-anrop i varje COBOL-program som använder IMS. Denna inventering berättar för migreringsteamet vad varje program gör med IMS, inte vad det är tillåtet att göra (vilket PSB definierar) utan vad det faktiskt gör.

DL/I-anrop i COBOL förekommer i två former:

cobol

* Form 1: EXEC DLI interface (CICS-compatible, high-level syntax)
       EXEC DLI
           GU DB2PCB
           SEGMENT(CUSTROOT)
           WHERE(CUSTID = WS-CUST-ID)
       END-EXEC

* Form 2: xxxTDLI call interface (batch programs, assembler-compatible)
       CALL 'CBLTDLI' USING WS-FUNCTION-CODE
                            PCB-CUSTOMER
                            WS-CUSTOMER-SEGMENT
                            WS-SSA-CUSTOMER

Båda formulären innehåller samma analytiska information: funktionskoden, det PCB som används, det segment som är målet och eventuellt SSA (Segment Search Argument) som kvalificerar anropet. En komplett DL/I-anropsinventering extraherar allt detta från varje program.

Funktionskodens taxonomi och dess migreringskonsekvenser

DL/I-funktionskoden är det mest migrationsmässigt betydelsefulla elementet i varje anrop. Varje funktionskod innebär ett annat dataåtkomstmönster som måste replikeras i målrelationsdatabasen:

Skrivskyddade funktioner: GU, Get Unique: navigera direkt till ett segment med hjälp av kvalificerade SSA:er. Motsvarar en SELECT with WHERE-klausul i relationella termer. Enkelt att migrera om segmentnyckeln mappas tydligt till en relationell primärnyckel.

GN, Hämta nästa: flyttar till nästa segment i hierarkisk sekvens. Detta är funktionskoden som inte har någon direkt relationell motsvarighet, den förlitar sig på IMS positionstillstånd och implicita ordning. Program som använder GN i stor utsträckning kräver noggrann analys av vilken ordning de är beroende av.

GNP, Hämta nästa inom föräldersegmentet: hämta efterföljande underordnade rader till det aktuella föräldersegmentet. Motsvarar att hämta alla rader i en främmande nyckelrelation. Mappas generellt sett tydligt till en SELECT med en främmande nyckel WHERE-klausul.

Hold-funktioner (förutsättningar för uppdatering): GHU, GHN, GHNP, Get Hold-ekvivalenter till GU, GN, GNP. Flaggan "hold" indikerar att en uppdaterings- (REPL) eller borttagnings- (DLET) åtgärd kommer att följa. Program som använder hold-anrop är läs-modifiera-skriv-program; migreringen måste bevara transaktionell integritet över hela hold-processen och den efterföljande uppdateringen.

Uppdateringsfunktioner: ISRT, Infoga: lägger till en ny segmentförekomst. Motsvarar INSERT. DLET, Ta bort: tar bort det aktuella lagrade segmentet och alla dess beroenden. Beteendet "alla beroenden" är en IMS-specifik kaskad som måste implementeras explicit i målsystemet. REPL, Ersätt: uppdaterar det aktuella lagrade segmentet med ny data. Motsvarar UPDATE.

Varför detta är viktigt för migreringens omfattning: Ett program med endast GU- och GNP-anrop är en skrivskyddad konsument av IMS-data, lägre risk att migrera, enklare att validera. Ett program som använder GHU, REPL och DLET är ett transaktionsbehandlingsprogram som modifierar hierarkiska strukturer; dess migrering kräver att transaktionell integritet bevaras över operationer som IMS för närvarande tillämpar atomärt.

De tre beroendetyperna som sätter stopp för varje migrering

Logiska relationer

IMS logiska relationer kopplar samman segment över två fysiskt separata databaser. Ett logiskt undersegment i databas A har ett logiskt föräldersegment i databas B. När ett COBOL-program navigerar genom en logisk relation, korsar det en väg som fysiskt korsar databasgränser, en genomgång som IMS hanterar transparent men som försvinner när databaserna migreras oberoende av varandra.

Logiska relationer är den beroendetypen med högst risk i IMS-migrering av en anledning: de är osynliga i COBOL-källkoden. COBOL-programmet anropar GNP för att hämta underordnade segment. Huruvida GNP:n korsar en fysisk överordnad-underordnad relation eller en logisk relation avgörs av PSB och DBD, inte av COBOL-koden. Ett migreringsteam som bara analyserar COBOL-källkoden har inget sätt att veta att ett GNP-anrop korsar en logisk relationsgräns utan att separat analysera PSB och DBD.

Program som använder logiska relationer kräver att migreringen replikerar den logiska relationens semantik i målsystemet, vanligtvis en JOIN i relationsmodellen, och för att validera att varje program som använder relationen får motsvarande resultat från JOIN:en som det fick från den logiska IMS-genomgången.

Sekundära indexdatabaser

IMS sekundära indexdatabaser tillhandahåller en alternativ åtkomstväg till en primärdatabas, vilket gör det möjligt för program att hämta segment via ett annat fält än rotnyckeln. En sekundär indexdatabas är en separat IMS-databas med sin egen databasdatabase (DBD), men dess data härleds från den primära databasen.

Migreringsteam upptäcker ofta sekundära indexdatabaser under analys snarare än under planering, eftersom:

• De definieras i databasdatabaser som inte alltid grupperas med de primära databasens databasdatabaser.
• Program som använder sekundära index namnger indexdatabasen i sina PSB:er, men program som navigerar till den primära databasen via ett sekundärt index kanske inte gör detta uppenbart i COBOL-källkoden.
• Dokumentationen kan beskriva den primära databasen utan att nämna dess sekundära index.

Ett program som ansluter till IMS via ett sekundärt index har ett beroende av åtkomstmönster som måste replikeras i målet som ett icke-primärnyckelindex eller en annan frågestrategi. Om detta saknas under migreringen produceras ett program som körs utan fel men inte hittar de poster det söker efter.

GSAM-databaser

GSAM-databaser (Generalized Sequential Access Method) är IMS gränssnitt för sekventiell batchbehandling, vilket i huvudsak tillåter COBOL-batchprogram att använda DL/I-anrop för vad som är funktionellt sekventiell fil-I/O. GSAM-databaser har inga segmenthierarkier; de är platta sekventiella strukturer som nås via IMS för att dra nytta av IMS återställnings- och omstartsfunktioner.

Program som använder GSAM-databaser är batchprogram som är beroende av IMS kontrollpunkts-/omstartsstöd för sitt återställningsbeteende. Migreringen måste bevara detta återställningsbeteende eller ersätta det med en motsvarande mekanism i målplattformen.

Bygga beroendeinventeringen före migration

En fullständig IMS-beroendeanalys producerar sex leveranser som tillsammans definierar migreringens omfattning, risk och sekvens.

Leverans 1: Mappning av kretskort till databas

Varje PCB i varje PSB mappas till en specifik DBD (en specifik IMS-databas). Att lista varje PCB över alla PSB:er och mappa var och en till sin DBD ger en auktoritativ lista över vilka program som har åtkomst till vilka databaser. Detta är utgångspunkten för att förstå omfattningen, men det överdriver faktiska beroenden eftersom program kan ha PSB:er som inkluderar fler databaser än de faktiskt använder.

Leverans 2: Faktisk samtalsinventering per program

Genom att analysera varje COBOL-programs DL/I-anrop skapas den faktiska användningslistan: vilka PCB:er varje program faktiskt anropar, vilka funktionskoder det använder, vilka segmenttyper det kommer åt och om det använder kvalificerade SSA:er (segmentnyckelåtkomst) eller okvalificerad navigering (positionell traversering). Detta begränsar omfattningen från PSB-definierade behörigheter till faktiskt programbeteende.

Leverans 3: Användningskarta för logiska relationer

Genom att korsreferera anropsinventariet mot databasdatabaserna identifieras vilka programs GNP- eller GN-anrop som korsar logiska relationer. Detta kräver att man analyserar inte bara COBOL-källan och PSB, utan även de databasstrukturer som definierar vilka förälder-underordnade relationer som är fysiska och vilka som är logiska.

Leverans 4: Användningskarta för sekundärt index

Program som namnger sekundära indexdatabaser i sina PSB:er eller utfärdar anrop med SSA:er som refererar till nyckelfält som inte är rotdatabaser identifieras som sekundära indexanvändare. Kartan dokumenterar vilka sekundära index som finns, vilka primärdatabaser de stöder och vilka program som är beroende av dem.

Leverans 5: Anropstypsfördelning per databas

För varje IMS-databas inom räckvidden indikerar fördelningen av anropstyper över alla program som har åtkomst till den komplexiteten i migreringen:

• Databaser som endast nås via läsfunktioner (GU, GN, GNP) är enklare att migrera
• Databaser som nås via hold-funktioner och uppdateringar (GHU + REPL, GHN + DLET) kräver replikering av transaktionell integritet
• Databaser med hög GN-användning indikerar positionsnavigeringsberoenden som kräver ordningsanalys
• Databaser med logiska relationer kräver JOIN-semantik mellan databaser i målet

Resultat 6: Programriskklassificering

Med hjälp av anropstypsfördelningen och beroendetypsinventeringen klassificeras varje program efter migreringsrisk:

Program som endast använder GU och GNP med kvalificerade SSA:er, har åtkomst till en enda databas utan logiska relationer och inte har några hold/update-anrop är de kandidater med lägst risk för tidiga migreringsvågor. Program som använder GN i stor utsträckning, har åtkomst till flera databaser genom logiska relationer eller utför komplexa hold/update-sekvenser är de program med högst risk som kräver den mest grundliga analysen och valideringen före migrering.

Vad analysen förändrar gällande migrationsplanering

Beroendeanalysen dokumenterar inte bara vad som existerar, den förändrar de beslut som följer.

Sekvensbeslut. Program som delar IMS-databaser genom logiska relationer kan inte migreras oberoende. Om program A läser ett logiskt undersegment som har ett logiskt föräldersegment i samma databas som program B:s rotsegment, bryts A om man migrerar A utan att migrera B (eller skapar en brygga). Beroendegrafen avgör vilka program som måste flyttas tillsammans.

Beslut om måldesign. Anropstypsfördelningen avgör hur målets relationsschema ska struktureras. En hierarkisk förälder-barn-relation som åtkoms exklusivt via nyckelkvalificerade GU- och GNP-anrop översätts tydligt till en främmande nyckel-relation i målet. Samma relation som åtkoms via GN-anrop med positionsberoenden kräver att målschemat bevarar motsvarande ordning, antingen genom explicit ORDER BY, ett sekvensfält eller ett annat åtkomstmönster som uppnår samma resultat.

Beslut om valideringsomfattning. Analysen identifierar vilka program som är skrivskyddade konsumenter av IMS-data och vilka som är transaktionsprocessorer. Skrivskyddade program kan valideras genom att jämföra utdataresultat mellan det ursprungliga IMS-systemet och det migrerade systemet. Transaktionsprocessorer kräver transaktionell ekvivalenstestning, vilket säkerställer att samma sekvens av operationer mot målet producerar motsvarande datatillståndsändringar som originalet.

Riskklassificering. Det logiska sambandet och sekundära indexresultat är de primära indata för riskklassificering. Varje migreringsprogram har ett riskregister. IMS-beroendeanalysen talar om för teamet vilka poster som ska läggas in i det.

Hur SMART TS XL Utför IMS-beroendeanalys

SMART TS XLÄr statisk kodanalys analyserar varje COBOL-programs DL/I-anrop, både EXEC DLI- och xxxTDLI-anropsgränssnittsformulär, och extraherar funktionskoden, PCB-referensen, segmentnamnet och SSA-strukturen från varje anrop. Detta producerar den faktiska anropsinventeringen på programnivå, över hela COBOL-portföljen, utan att kräva ett pågående IMS-system eller manuell kodgranskning.

Mappningen av applikationsberoenden utökar denna inventering till ett beroendediagram över flera program: vilka program delar åtkomst till vilka IMS-databaser, vilka program använder samma PCB:er, vilka programs åtkomstmönster överlappar varandra på sätt som kräver samordnad migrering. När en logisk relation kopplar samman segment över databaser representerar beroendekartan denna koppling mellan databaser som en explicit relation som måste bevaras i målsystemet.

Effektanalysfunktionen besvarar frågan som varje migreringsteam måste besvara innan någon databas konverteras: om denna IMS - databas migreras, vilka program påverkas, vilka åtkomstmönster måste replikeras och vilka testfall måste valideras för att bekräfta likvärdighet. Svaret är inte en uppskattning, det är en uppräknad lista härledd från den faktiska DL/I-anropsinventeringen.

JCL -expansionsfunktionen lägger till det operativa sammanhanget: vilka JCL-jobbsteg anropar vilka program som har åtkomst till IMS, i vilken sekvens, med vilka PSB-specifikationer. Den operativa beroendekedjan, batchjobbsekvensen som bearbetar IMS-data genom flera program, är lika viktig för migreringsplaneringen som åtkomstmönstren på programnivå. Att migrera databasen utan att migrera batchjobborkestreringen som omger den producerar ett system som bearbetar poster korrekt isolerat och misslyckas i produktion när jobbsekvensen körs.

För lag som genomför äldre modernisering av IMS-stödda system, de strukturella bevis som producerats av SMART TS XL är inputen till varje efterföljande migreringsbeslut: vilka program migrerar i vilken våg, vilka databaser kan konverteras oberoende och vilka kräver samordnad konvertering, vilka åtkomstmönster kräver omarkitektur snarare än direkt översättning. Som beskrivs i samband med migrera IMS- och VSAM-strukturer tillsammans med COBOL-program, sammankopplingen mellan COBOL-program och äldre datastrukturer innebär att datamigrering och kodanalys måste ske parallellt, beroendeinventeringen är den mekanism som möjliggör parallell planering.

Inventeringen är inte migreringen

IMS-beroendeanalys producerar kunskap. Migreringen kräver fortfarande beslut, ingenjörskonst och validering. Det som analysen förändrar är beslutens kvalitet, fullständigheten i den tekniska omfattningen och valideringens tillförlitlighet.

De organisationer som framgångsrikt migrerar IMS-databaser är inte de med de mest aggressiva tidslinjerna eller de största migreringsbudgetarna. Det är de som visste vad de hade innan de började flytta den, varje program som åtkom varje databas, varje funktionskod som avslöjade varje programs åtkomstmönster, varje logisk relation som skapade beroenden mellan databaser, varje sekundärt index som tillhandahöll en åtkomstväg som inte skulle överleva konvertering utan explicit replikering.

Den kunskapen kommer inte från dokumentation. Den kommer från att analysera koden.