IMS-databaseafhængighedsanalyse: Hvad moderniseringsteams skal vide, før de flytter noget

IMS er ikke et ældre system i den forstand, at det er forældet. Det er databasemotoren bag debitorer hos større banker, policeadministration hos forsikringsselskaber og skadebehandling af sundhedsforsikringsselskaber. IBM fortsætter med at udvikle det. Problemet er ikke, at IMS er holdt op med at virke, problemet er, at alle udviklere, der vidste, hvordan man navigerede i dets hierarkiske segmenttræer, går på pension, enhver ændring af et IMS-baseret system kræver forståelse af en datamodel, der ikke har SQL, og enhver migreringsplan, der behandler IMS som en relationel database, opdager forskellen på den hårde måde.

Den hårde måde er at opdage midt under migreringen, at et COBOL-program tilgår IMS ikke via et simpelt nøgleopslag, men via en hierarkisk gennemgang, der skal replikeres i målsystemet med tilsvarende navigationslogik. Eller at opdage, at en logisk relation mellem to fysiske IMS-databaser skaber en afhængighed, som ingen af ​​databasernes DBD'er dokumenterer fuldt ud, og at migreringen konverterede begge databaser uafhængigt, mens den lydløst brød alle programmer, der brugte den logiske relation. Eller at opdage, at en sekundær indeksdatabase, en struktur, som de fleste migreringsplaner aldrig oplister, var den eneste vej, hvorigennem et kritisk rapporteringsprogram nåede sine data.

Ingen af ​​disse overraskelser overlever kontakt med grundig afhængighedsanalyse før migration. De overlever kontakt med antagelser.

Hvad gør IMS-afhængighedsanalyse anderledes

Afhængighedsanalyse for et relationsdatabasemiljø, DB2, Oracle, SQL Server, følger en velforstået sti. Analyser SQL'en i applikationskoden, identificer tabel- og kolonnereferencerne, opbyg et kort over, hvilke programmer der tilgår hvilke tabeller, og brug dette kort til at bestemme migreringsomfang og -rækkefølge. Strukturen er eksplicit. Afhængighederne er synlige i SQL-teksten.

IMS-afhængighedsanalyse er mere kompleks i alle dimensioner.

Strukturen er hierarkisk, ikke relationel. En IMS-database er organiseret som et træ af segmenttyper, hvor hver segmenttype har en defineret overordnet-underordnet relation. Et COBOL-program, der læser patientjournaler fra en IMS-database, udføres ikke SELECT * FROM PATIENTS WHERE ID = ?Den udfører et Get Unique-kald (GU) for at navigere i hierarkiet til rodsegmentet og derefter Get Next Within Parent-kald (GNP) for at gennemgå de underordnede segmenter. Programmets afhængighed er ikke på en tabel, men på en bestemt sti gennem en hierarkisk struktur, og ændring af denne struktur kan ødelægge programmer, der navigerer i den på måder, som ingen SQL-niveauanalyse ville registrere.

Afhængighederne er fordelt på tværs af tre separate strukturer. Det fulde billede af, hvad et COBOL-program gør med IMS, kræver analyse:

• DBD (databasebeskrivelse): definerer det fysiske segmenthierarki, nøglefelterne, adgangsmetoderne (HDAM, HIDAM, HISAM, HSAM) og eventuelle sekundære indeks eller logiske relationer
• PSB (Programspecifikationsblok): definerer hvilke databaser et program har adgang til, gennem hvilke printkort, med hvilke følsomheds- og intentionsspecifikationer
• COBOL-kildekoden: indeholder de faktiske DL/I-kald, der bestemmer, hvilke segmenter der tilgås, med hvilke kaldsfunktioner, i hvilken rækkefølge, med hvilke SSA'er

Ingen enkelt kilde indeholder det komplette billede. Analyse, der kun læser COBOL-kilden, ser kaldstyperne og segmentnavnene, men ikke den fysiske databasestruktur. Analyse, der kun læser DBD og PSB, ser, hvad programmet har tilladelse til at gøre, men ikke hvad det rent faktisk gør.

Navigation er positionsafhængig. I en relationsdatabase kan hver række adresseres uafhængigt med en nøgle. I IMS påvirker et programs aktuelle position i hierarkiet, hvad efterfølgende kald returnerer. Et GN (Get Next)-kald returnerer det næste segment i hierarkisk rækkefølge, uanset hvor programmet befinder sig i øjeblikket. Afhængigheden er ikke kun af segmenttypen, men også af den traversalsti, der førte til den aktuelle position. Programmer, der er afhængige af IMS' implicitte hierarkiske rækkefølge, har en afhængighed, der forsvinder, når dataene migreres til en relationsdatabase, hvor ingen tilsvarende rækkefølge er garanteret.

DL/I-kaldsinventaret: Hvad COBOL-kildekoden afslører

Den mest direkte nyttige analyse før migrering er en komplet oversigt over alle DL/I-kald i alle COBOL-programmer, der tilgår IMS. Denne oversigt fortæller migreringsteamet, hvad hvert program gør med IMS, ikke hvad det har tilladelse til at gøre (hvilket PSB definerer), men hvad det rent faktisk gør.

DL/I-kald i COBOL forekommer i to 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

Begge formularer indeholder de samme analytiske oplysninger: funktionskoden, det anvendte PCB, det segment, der er målet, og eventuelt SSA (Segment Search Argument), der kvalificerer kaldet. En komplet DL/I-kaldsopgørelse udtrækker alt dette fra hvert program.

Funktionskodens taksonomi og dens migrationsimplikationer

DL/I-funktionskoden er det mest migrationsbetydende element i hvert kald. Hver funktionskode antyder et forskelligt dataadgangsmønster, der skal replikeres i den ønskede relationelle database:

Skrivebeskyttede funktioner: GU, Get Unique: naviger direkte til et segment ved hjælp af kvalificerede SSA'er. Svarende til en SELECT med WHERE-klausul i relationelle termer. Nem at migrere, hvis segmentnøglen knyttes tydeligt til en relationel primærnøgle.

GN, Hent næste: Går videre til det næste segment i hierarkisk rækkefølge. Dette er funktionskoden, der ikke har nogen direkte relationel ækvivalent, den er afhængig af IMS' positionstilstand og implicitte rækkefølge. Programmer, der bruger GN i vid udstrækning, kræver omhyggelig analyse af, hvilken rækkefølge de er afhængige af.

GNP, Hent næste inden for forælder: hent efterfølgende underordnede segmenter af det aktuelle forældersegment. Svarende til at hente alle rækker i en fremmednøgle-relation. Generelt knyttes det tydeligt til en SELECT med en fremmednøgle WHERE-klausul.

Hold-funktioner (forudsætninger for opdatering): GHU, GHN, GHNP, Hent Hold-ækvivalenter til GU, GN, GNP. "Hold"-flaget angiver, at der vil følge en opdaterings- (REPL) eller sletnings- (DLET) handling. Programmer, der bruger hold-kald, er læse-ændre-skrive-programmer; migreringen skal bevare transaktionsintegriteten på tværs af hold'en og den efterfølgende opdatering.

Opdateringsfunktioner: ISRT, Indsæt: tilføjer en ny segmentforekomst. Svarende til INSERT. DLET, Slet: fjerner det aktuelle holdte segment og alle dets afhængige. Adfærden "alle afhængige" er en IMS-specifik kaskade, der skal implementeres eksplicit i målsystemet. REPL, Erstat: opdaterer det aktuelle lagrede segment med nye data. Svarende til UPDATE.

Hvorfor dette er vigtigt for migreringsomfanget: Et program med kun GU- og GNP-kald er en skrivebeskyttet forbruger af IMS-data, lavere risiko for migrering og enklere at validere. Et program, der bruger GHU, REPL og DLET, er et transaktionsbehandlingsprogram, der ændrer hierarkiske strukturer; dets migrering kræver bevarelse af transaktionel integritet på tværs af operationer, som IMS i øjeblikket håndhæver atomart.

De tre afhængighedstyper, der udløser enhver migration

Logiske forhold

Logiske IMS-relationer forbinder segmenter på tværs af to fysisk separate databaser. Et logisk undersegment i database A har et logisk overordnet segment i database B. Når et COBOL-program navigerer gennem en logisk relation, krydser det en sti, der fysisk krydser databasegrænser, en gennemgang, som IMS administrerer transparent, men som forsvinder, når databaserne migreres uafhængigt.

Logiske relationer er den afhængighedstype med højest risiko i IMS-migrering af én grund: de er usynlige i COBOL-kildekoden. COBOL-programmet kalder GNP for at hente underordnede segmenter. Om dette GNP krydser en fysisk overordnet-underordnet relation eller en logisk relation, bestemmes af PSB og DBD, ikke af COBOL-koden. Et migreringsteam, der kun analyserer COBOL-kilden, har ingen måde at vide, at et GNP-kald krydser en logisk relationsgrænse uden separat at analysere PSB og DBD.

Programmer, der bruger logiske relationer, kræver migreringen for at replikere den logiske relations semantik i målsystemet, typisk en JOIN i den relationelle model, og for at validere, at hvert program, der bruger relationen, modtager tilsvarende resultater fra JOIN'en, som det modtog fra den logiske IMS-gennemgang.

Sekundære indeksdatabaser

IMS sekundære indeksdatabaser giver en alternativ adgangssti til en primær database, der giver programmer mulighed for at hente segmenter via et andet felt end rodnøglen. En sekundær indeksdatabase er en separat IMS-database med sin egen DBD, men dens data er afledt af den primære database.

Migrationsteams opdager ofte sekundære indeksdatabaser under analyse snarere end under planlægning, fordi:

• De er defineret i DBD'er, der ikke altid er grupperet med de primære database-DBD'er.
• Programmer, der bruger sekundære indekser, navngiver indeksdatabasen i deres PSB'er, men programmer, der navigerer til den primære database via et sekundært indeks, gør dette muligvis ikke tydeligt i COBOL-kildekoden.
• Dokumentationen kan beskrive den primære database uden at nævne dens sekundære indekser.

Et program, der tilgår IMS via et sekundært indeks, har en adgangsmønsterafhængighed, der skal replikeres i målet som et ikke-primærnøgleindeks eller en anden forespørgselsstrategi. Hvis dette mangler under migreringen, kører programmet uden fejl, men kan ikke finde de poster, det leder efter.

GSAM-databaser

GSAM-databaser (Generalized Sequential Access Method) er IMS' grænseflade til sekventiel batchbehandling, hvilket i bund og grund tillader COBOL-batchprogrammer at bruge DL/I-kald til, hvad der funktionelt er sekventiel fil-I/O. GSAM-databaser har ikke segmenthierarkier; de er flade sekventielle strukturer, der tilgås via IMS for at drage fordel af IMS' gendannelses- og genstartsfunktioner.

Programmer, der bruger GSAM-databaser, er batchprogrammer, der er afhængige af IMS's checkpoint-/genstartsunderstøttelse for deres gendannelsesadfærd. Migrering skal bevare denne gendannelsesadfærd eller erstatte den med en tilsvarende mekanisme på målplatformen.

Opbygning af afhængighedsopgørelsen før migration

En komplet IMS-afhængighedsanalyse producerer seks leverancer, der tilsammen definerer migreringens omfang, risiko og rækkefølge.

Leverance 1: PCB-til-database-kortlægning

Hvert printkort i hver PSB er knyttet til en specifik DBD (en specifik IMS-database). Ved at liste hvert printkort på tværs af alle PSB'er og knytte hvert enkelt til dets DBD, produceres den autoritative liste over, hvilke programmer der har adgang til hvilke databaser. Dette er udgangspunktet for at forstå omfanget, men det overdriver de faktiske afhængigheder, fordi programmer kan have PSB'er, der inkluderer flere databaser, end de rent faktisk bruger.

Leverance 2: Faktisk opkaldsbeholdning pr. program

Parsing af hvert COBOL-programs DL/I-kald producerer den faktiske brugsliste: hvilke PCB'er hvert program rent faktisk kalder, hvilke funktionskoder det bruger, hvilke segmenttyper det tilgår, og om det bruger kvalificerede SSA'er (segmentnøgleadgang) eller ukvalificeret navigation (positionel gennemgang). Dette indsnævrer omfanget fra PSB-definerede tilladelser til den faktiske programadfærd.

Leverance 3: Brugskort over logiske relationer

Krydsreferencer af kaldinventaret mod DBD'erne identificerer, hvilke programmers GNP- eller GN-kald krydser logiske relationer. Dette kræver analyse af ikke blot COBOL-kilden og PSB'en, men også de DBD-strukturer, der definerer, hvilke forældre-barn-relationer der er fysiske, og hvilke der er logiske.

Leverance 4: Brugskort for sekundært indeks

Programmer, der navngiver sekundære indeksdatabaser i deres PSB'er eller udfører kald med SSA'er, der refererer til ikke-rodnøglefelter, identificeres som sekundære indeksbrugere. Kortet dokumenterer, hvilke sekundære indeks der findes, hvilke primære databaser de understøtter, og hvilke programmer der er afhængige af dem.

Leverance 5: Fordeling af kaldstyper pr. database

For hver IMS-database i omfanget angiver fordelingen af ​​opkaldstyper på tværs af alle programmer, der tilgår den, kompleksiteten af ​​dens migrering:

• Databaser, der kun tilgås via læsefunktioner (GU, GN, GNP), er enklere at migrere
• Databaser, der tilgås via hold-funktioner og opdateringer (GHU + REPL, GHN + DLET), kræver replikering af transaktionel integritet
• Databaser med høj GN-brug indikerer positionsnavigationsafhængigheder, der kræver rækkefølgeanalyse
• Databaser med logiske relationer kræver JOIN-semantik på tværs af databaser i målet

Leverance 6: Programrisikoklassificering

Ved hjælp af opkaldstypefordelingen og afhængighedstypeopgørelsen klassificeres hvert program efter migreringsrisiko:

Programmer, der kun bruger GU og GNP med kvalificerede SSA'er, tilgår en enkelt database uden logiske relationer og ikke har hold/update-kald, er de kandidater med den laveste risiko til tidlige migreringsbølger. Programmer, der bruger GN i vid udstrækning, tilgår flere databaser via logiske relationer eller udfører komplekse hold/update-sekvenser, er de programmer med den højeste risiko, der kræver den mest grundige analyse og validering før migrering.

Hvad analysen ændrer ved migrationsplanlægning

Afhængighedsanalysen dokumenterer ikke blot, hvad der eksisterer, den ændrer de efterfølgende beslutninger.

Sekvensbeslutninger. Programmer, der deler IMS-databaser gennem logiske relationer, kan ikke migreres uafhængigt. Hvis Program A læser et logisk undersegment, der har en logisk forælder i den samme database som Program B's rodsegment, vil migrering af A uden at migrere B (eller oprette en bro) ødelægge A. Afhængighedsgrafen bestemmer, hvilke programmer der skal flyttes sammen.

Beslutninger om måldesign. Fordelingen af ​​kaldstyper informerer, hvordan målets relationsskema skal struktureres. En hierarkisk forældre-barn-relation, der udelukkende tilgås via nøglekvalificerede GU- og GNP-kald, oversættes tydeligt til en fremmednøgle-relation i målet. Den samme relation, der tilgås via GN-kald med positionsafhængigheder, kræver, at målskemaet bevarer en tilsvarende rækkefølge, enten gennem eksplicit ORDER BY, et sekvensfelt eller et andet adgangsmønster, der opnår det samme resultat.

Valideringsbeslutninger om omfang. Analysen identificerer, hvilke programmer der er skrivebeskyttede forbrugere af IMS-data, og hvilke der er transaktionsprocessorer. Skrivebeskyttede programmer kan valideres ved at sammenligne outputresultater mellem det originale IMS-system og det migrerede system. Transaktionsprocessorer kræver transaktionel ækvivalenstestning, der sikrer, at den samme rækkefølge af operationer mod målet producerer tilsvarende ændringer i datatilstanden som originalen.

Risikoklassificering. Den logiske sammenhæng og sekundære indeksresultater er de primære input til risikoklassificering. Hvert migreringsprogram har et risikoregister. IMS-afhængighedsanalysen fortæller teamet, hvilke poster der skal indsættes i det.

Hvordan SMART TS XL Udfører IMS-afhængighedsanalyse

SMART TS XL's statisk kodeanalyse analyserer alle COBOL-programmers DL/I-kald, både EXEC DLI- og xxxTDLI-kaldsgrænsefladeformularer, og udtrækker funktionskoden, PCB-referencen, segmentnavnet og SSA-strukturen fra hvert kald. Dette producerer den faktiske kaldinventar på programniveau, på tværs af hele COBOL-porteføljen, uden at kræve et kørende IMS-system eller manuel kodegennemgang.

Applikationsafhængighedskortlægningen udvider denne opgørelse til en afhængighedsgraf på tværs af programmer: hvilke programmer deler adgang til hvilke IMS-databaser, hvilke programmer bruger de samme PCB'er, hvilke programmers adgangsmønstre overlapper hinanden på måder, der kræver koordineret migrering. Når en logisk relation forbinder segmenter på tværs af databaser, repræsenterer afhængighedskortet denne forbindelse på tværs af databaser som en eksplicit relation, der skal bevares i målsystemet.

Effektanalysefunktionen besvarer det spørgsmål, som alle migreringsteams skal besvare , før en database konverteres: Hvis denne IMS-database migreres, hvilke programmer er så berørt, hvilke adgangsmønstre skal replikeres, og hvilke testtilfælde skal valideres for at bekræfte ækvivalens. Svaret er ikke et estimat, det er en opregnet liste udledt af den faktiske DL/I-kaldsinventar.

JCL -udvidelsesfunktionen tilføjer den operationelle kontekst: hvilke JCL-jobtrin der aktiverer hvilke programmer der tilgår IMS, i hvilken rækkefølge, med hvilke PSB-specifikationer. Den operationelle afhængighedskæde, batchjobsekvensen der behandler IMS-data gennem flere programmer, er lige så vigtig for migreringsplanlægning som adgangsmønstrene på programniveau. Migrering af databasen uden at migrere den batchjoborkestrering, der omgiver den, producerer et system, der behandler poster korrekt isoleret og fejler i produktionen, når jobsekvensen kører.

For hold, der udfører arvemodernisering af IMS-baserede systemer, den strukturelle dokumentation produceret af SMART TS XL er inputtet til enhver efterfølgende migreringsbeslutning: hvilke programmer migrerer i hvilken bølge, hvilke databaser kan konverteres uafhængigt, og hvilke kræver koordineret konvertering, hvilke adgangsmønstre kræver omarkitektur snarere end direkte oversættelse. Som beskrevet i forbindelse med migrering af IMS- og VSAM-strukturer sideløbende med COBOL-programmer, sammenkoblingen mellem COBOL-programmer og ældre datastrukturer betyder, at datamigrering og kodeanalyse skal foregå parallelt, og afhængighedsopgørelsen er den mekanisme, der muliggør parallel planlægning.

Inventaret er ikke migrationen

IMS-afhængighedsanalyse producerer viden. Migreringen kræver stadig beslutninger, engineering og validering. Det, analysen ændrer, er kvaliteten af ​​beslutningerne, fuldstændigheden af ​​det tekniske omfang og valideringens sikkerhed.

De organisationer, der migrerer IMS-databaser med succes, er ikke dem med de mest aggressive tidslinjer eller de største migreringsbudgetter. Det er dem, der vidste, hvad de havde, før de begyndte at flytte den, hvert program, der tilgik hver database, hver funktionskode, der afslørede hvert programs adgangsmønster, hver logisk relation, der skabte afhængigheder på tværs af databaser, hvert sekundært indeks, der gav en adgangssti, der ikke ville overleve konvertering uden eksplicit replikering.

Den viden kommer ikke fra dokumentation. Den kommer fra at parse koden.