Datamigrering kan ikke ske isoleret, den skal udvikle sig parallelt med de COBOL-applikationer, der læser og skriver disse datasæt. Denne begrænsning definerer hele udfordringen ved VSAM-modernisering. VSAM (Virtual Storage Access Method) er ikke blot et filformat. Det er datakontrakten mellem programmer, den implicitte specifikation, der ikke er defineret nogen steder undtagen i FD-poster og SELECT-klausuler, der styrer, hvordan hvert program i et virksomhedssystem producerer og forbruger sine mest kritiske forretningsdata. En enkelt ændring af postlayoutet, der ikke afspejles i hvert program, der læser den pågældende post, producerer datakorruption, der muligvis ikke dukker op, før en lovgivningsmæssig rapport kører på data, der ikke længere betyder, hvad det forbrugerprogram forventede.
De organisationer, der har succes med VSAM-datamodernisering, er ikke dem, der starter med målskemaet. Det er dem, der starter med en komplet, evidensbaseret forståelse af, hvad VSAM-filerne indeholder, hvordan de er struktureret, hvilke programmer der tilgår dem, i hvilke mønstre, og hvilke implicitte kontrakter der findes mellem producenter og forbrugere. Denne forståelse, analysen af VSAM-filstrukturen, er forudsætningen for enhver efterfølgende beslutning: hvilke VSAM-datasæt der knyttes til relationelle tabeller, hvilke der kræver forskellige målarkitekturer, hvilke postlayouts der kræver præcisionsbevarende datatypekonverteringer, og hvilke delte datasæt der skal migreres som koordinerede enheder snarere end uafhængigt.
Delte datasæt kræver koordineret migrering
SMART TS XL udtrækker automatisk alle postlayoutdetaljer, som målskemadesignet kræver.
FÅ MERE AT VIDE…De fire VSAM-organisationer og hvad hver især kræver
VSAM-datasæt findes i fire forskellige organisationer. Hver især har en forskellig strukturel egenskab, et forskelligt typisk adgangsmønster og en forskellig naturlig kortlægning i forhold til moderne målarkitekturer. Ved at behandle alle VSAM-datasæt identisk og massekonvertere hvert enkelt til en relationel tabel, produceres mål, der fungerer for nogle datasæt og fungerer dårligt eller fejler funktionelt for andre.
KSDS, Key-Sequenced Data Set, er den mest almindelige VSAM-organisation. Poster er fysisk ordnet efter en primærnøgle (primærnøglen), hvilket muliggør både direkte adgang efter nøgle og sekventiel adgang i nøgleorden. KSDS-filer har valgfrit alternative indeks, sekundære nøglestier, der tillader hentning via andre felter end primærnøglen. Det naturlige mål for et KSDS er en relationel tabel, hvor primærnøglen bliver primærnøgle, og alternative indeks bliver til SQL-indeks.
ESDS, Entry-Sequenced Data Set, gemmer poster i den rækkefølge, de blev skrevet. Der er ingen nøgle, poster adresseres af deres fysiske byte-offset (RBA: Relative Byte Address). ESDS-filer bruges typisk til loglignende data: revisionsspor, transaktionsjournaler, hændelsesstrømme. Det naturlige mål for en ESDS er en relationel tabel med kun tilføjelser, en hændelsesstrøm (Kafka-emne) eller en tidsseriedatabase, afhængigt af hvordan de forbrugerprogrammer tilgår dataene.
RRDS, Relative Record Data Set, lagrer poster med fast længde, der er adresseret efter et relativt postnummer. Hvert slot i filen svarer til et postnummer; slots kan være tomme (slettede). RRDS-filer bruges til scenarier med direkte adgang, hvor postnummeret er meningsfuldt for applikationen, ofte brugt som simple opslagstabeller eller hashbaseret lagring. Det naturlige mål er en relationel tabel med en numerisk sekvensidentifikator eller en opslagsstruktur i hukommelsen, hvis datasættet er lille og ofte tilgås.
LDS, Linear Data Set, er en byte-adresserbar lagring uden nogen synlig poststruktur for VSAM. Den bruges af applikationer (typisk DB2, Java-arbejdsbelastninger eller brugerdefinerede programmer), der administrerer deres eget interne format inden for VSAM-byteområdet. LDS-filer kan ikke analyseres via standard COBOL FD-poster, deres struktur findes kun i det applikationslag, der skriver til dem.
Analyseresultatet for hvert datasæt skal identificere, hvilken organisation det bruger, fordi organisationen bestemmer alt downstream: målarkitektur, adgangsmønster og den specifikke analyse, der kræves for at forstå dens struktur.
Problemet med analyse af postlayout
Postlayoutet er den analytisk mest komplekse dimension af VSAM-strukturanalyse. I modsætning til et relationsskema, hvor hver kolonne har en defineret type, navn og begrænsning, der håndhæves af databasemotoren, har VSAM-poster ingen selvbeskrivende struktur. Layoutet findes udelukkende i COBOL FD-posten, og FD-poster er sjældent simple.
FD-indlæg og COPY-medlemmer
Poststrukturen for et VSAM-datasæt er defineret i FILE DESCRIPTION (FD)-posten i COBOL DATA DIVISION. I velholdte kodebaser refererer FD-posten til et COPY-medlem, en delt kopibog, der definerer postlayoutet og er inkluderet i hvert program, der tilgår datasættet:
COBOL
FILE SECTION.
FD CUSTOMER-FILE
LABEL RECORDS ARE STANDARD
RECORD CONTAINS 250 CHARACTERS.
01 CUSTOMER-RECORD.
COPY CUSTMSTR.COPY-medlemmet CUSTMSTR definerer det faktiske feltlayout. Hvis 47 programmer inkluderer CUSTMSTR, så deler 47 programmer en afhængighed af det postlayout, det definerer. Et feltomdøbning i CUSTMSTR påvirker alle 47. Dette er kopbogskoblingsproblemet anvendt på data: VSAM-postlayoutet er en delt afhængighed, der ikke kan ændres uden at koordinere hvert program, der bruger det.
Til migreringsanalyse skal hver FD-post spores til dens kopibog, og hver kopibog skal knyttes til hvert program, der inkluderer den. Grafen for afhængighed af delt layout er grundlaget for at forstå migreringsomfanget.
REDEFINERER: Flere layouts, én post
REDEFINES klausulen er, hvor VSAM-postanalyse bliver virkelig kompleks. REDEFINES tillader forskellige feltfortolkninger at overlejre den samme fysiske lagring. En VSAM-post, der indeholder en transaktionstypekode, kan bruge REDEFINES til at fortolke de resterende bytes forskelligt afhængigt af den pågældende kode:
COBOL
01 TRANSACTION-RECORD.
05 TXN-TYPE PIC X(2).
05 TXN-COMMON-DATA PIC X(48).
05 TXN-DETAIL REDEFINES TXN-COMMON-DATA.
10 TXN-PAYMENT.
15 PAY-AMOUNT PIC S9(11)V99 COMP-3.
15 PAY-CURRENCY PIC X(3).
15 PAY-METHOD PIC X(2).
15 FILLER PIC X(28).
05 TXN-WITHDRAWAL REDEFINES TXN-COMMON-DATA.
10 WDR-AMOUNT PIC S9(11)V99 COMP-3.
10 WDR-ACCOUNT PIC 9(12).
10 WDR-BRANCH PIC 9(5).
10 FILLER PIC X(18).Denne post har ikke ét layout, men tre, afhængigt af TXN-TYPEI det relationelle målskema kræver dette typisk enten et polymorf tabeldesign (enkelt bred tabel med nullable kolonner for hver variant), et normaliseret design (forælderække plus typespecifikke underrækker) eller en JSON-kolonne, der indeholder variantdataene. Ingen af disse beslutninger kan træffes uden at analysere, hvad TXN-TYPE værdier findes i dataene, og hvilke REDEFINES-varianter der rent faktisk anvendes.
En komplet analyse af postlayout skal:
- Identificer hvert REDEFINES-hierarki i hver FD-post
- Bestem hvilken REDEFINES-variant der er aktiv under hvilke betingelser (kræver programlogisk analyse, ikke kun FD-analyse)
- Dokumentér felttyper, længder og præcision for pakket decimal for hver variant.
- Anbefal den passende normaliseringsstrategi for målskemaet
COMP-3 og numerisk præcision
COBOL'er PIC S9(11)V99 COMP-3 (pakket decimal) har specifikke præcisions- og skalakarakteristika, der ikke har nogen direkte ækvivalent i SQL-standarddatatyper. V angiver et implicit decimalpunkt, gemmes værdien som et heltal med en implicit skala på 2 decimaler. COMP-3 pakker to decimalcifre pr. byte, hvor den sidste halve byte indeholder fortegnet.
Når dette felt migreres til en relationsdatabase, er det korrekte SQL-mål DECIMAL(13, 2), Ikke FLOAT, hvilket ville introducere afrundingsfejl, og ikke INTEGER, hvilket ville miste decimalerne. For finansielle systemer, hvor COMP-3-felter indeholder monetære beløb, er præcisionskravet ikke til forhandling. En migration, der konverterer PIC S9(11)V99 COMP-3 til en flydende komma-type i målskemaet introducerer afrundingsfejl, der akkumuleres på tværs af batchkørsler og kan påvirke den lovgivningsmæssige rapportering.
Hvert COMP-3-felt i hver FD-post skal dokumenteres med dets nøjagtige præcision, skala og fortegnskonvention, før designet af målskemaet begynder.
Analyse af VSAM-adgangsmønstre i COBOL-kildekode
FD-posten beskriver, hvad der er i posten. COBOL PROCEDURE DIVISION beskriver, hvordan programmet bruger den. Begge er nødvendige for en komplet strukturel analyse. Adgangsmønsteranalysen undersøger alle filadgangsverber i hvert program, der berører datasættet.
SELECT-klausulen: Første signal
SELECT-klausulen i ENVIRONMENT DIVISION fastlægger, hvordan COBOL-programmet tilgår VSAM-filen:
COBOL
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT CUSTOMER-FILE
ASSIGN TO CUSTFILE
ORGANIZATION IS INDEXED
ACCESS MODE IS DYNAMIC
RECORD KEY IS CUST-PRIME-KEY
ALTERNATE RECORD KEY IS CUST-ALT-KEY
WITH DUPLICATES
FILE STATUS IS WS-CUST-STATUS.Denne SELECT-klausul afslører:
ORGANIZATION IS INDEXED→ KSDSACCESS MODE IS DYNAMIC→ Programmet bruger både sekventiel og tilfældig adgangALTERNATE RECORD KEY IS CUST-ALT-KEY WITH DUPLICATES→ der findes et alternativt indeks, og dette program bruger det
Dynamisk adgangstilstand er særlig vigtig: et program, der tilgår et KSDS i DYNAMISK tilstand, kan bruge READ med en nøgle til direkte adgang og READ NEXT til sekventiel scanning fra et positioneret punkt. Begge adgangsmønstre skal replikeres i målet, hvilket kan kræve understøttelse af både direkte opslag (primær nøgleforespørgsel) og intervalscanning (ordnet gennemgang) i det relationelle skema.
Adgangsverber og deres migrationsimplikationer
Hvert filadgangsverbum afslører en forskellig dimension af, hvordan programmet interagerer med VSAM-datasættet:
LÆS (direkte): READ CUSTOMER-FILE KEY IS WS-CUST-KEY, direkte nøgleopslag. Kortlægger til SELECT ... WHERE primary_key = ?De fleste KSDS-programmer bruger dette mønster; det oversættes direkte til et relationelt indekseret opslag.
LÆS (sekventiel): READ CUSTOMER-FILE NEXT RECORD, sekventiel scanning fra den aktuelle position. Kortlægger til SELECT ... ORDER BY primary_key med markørpositionering. Den implicitte rækkefølgeafhængighed, programmer der er afhængige af VSAM's naturlige nøgleorden til sekventiel behandling, skal eksplicit bevares i målet.
START: START CUSTOMER-FILE KEY >= WS-SEARCH-KEY efterfulgt af READ NEXT, områdescanning fra en delvis nøgleposition. Kortlægger til en områdeforespørgsel: SELECT ... WHERE primary_key >= ? ORDER BY primary_keyProgrammer, der bruger START, etablerer en nedre grænse for sekventiel scanning; dette er et kritisk adgangsmønster for KSDS-filer, der ikke har nogen simpel ækvivalent, medmindre måltabellen har samme nøglerækkefølge.
SKRIVE: Indsætter en ny post efter nøgle. Knytter til INSERT INTOHvis VSAM-filen har alternative indekser, skal skrivningen opretholde konsistens med disse indekser. I VSAM er dette automatisk; i en relationsdatabase kræver det enten en databasetrigger eller kode på applikationsniveau for at vedligeholde tilsvarende sekundære indekstabeller.
OMSKRIV: Opdaterer en post på stedet. Posten skal være i øjeblikket tilbageholdt (efter en LÆSNING med tilbageholdelsesintention). Knytter til UPDATE ... WHERE primary_key = ?REWRITE er et læse-ændre-skrive-mønster; migreringen skal bevare transaktionel integritet på tværs af læsning og skrivning.
SLET: Fjerner en post efter nøgle. I KSDS-filer er DELETE en fysisk sletning. Programmer, der forventer, at den slettede plads ikke er tilgængelig til fremtidige sekventielle scanninger, afhænger af denne fysiske sletningsadfærd. En soft-delete (logisk sletningsflag) i målet producerer ikke tilsvarende adfærd, medmindre alle forbrugerprogrammer opdateres for at filtrere logisk slettede poster.
Alternativ indeksbrug: Den skjulte afhængighed
Alternative indekser på KSDS-filer er en af de oftest oversete afhængigheder i VSAM-migrering. Et alternativt indeks giver et program adgang til et KSDS via et andet felt end primnøglen. Det alternative indeks er i sig selv et separat VSAM-datasæt (en PATH), der skal vedligeholdes synkroniseret med basisklyngen.
Et program, der tilgår CUSTOMER-FILE gennem sin alternative nøgle CUST-ALT-KEY har en afhængighed, der er usynlig, hvis kun basisklyngens FD-post analyseres. Migreringen skal:
- Identificer hvilke programmer der bruger hvilke alternative nøgler (synligt i SELECT-klausulen)
ALTERNATE RECORD KEYerklæringer) - Knyt hver alternativ nøgle til det tilsvarende SQL-indeks på måltabellen
- Sørg for, at INSERT- og DELETE-operationer på måltabellen automatisk vedligeholder det tilsvarende alternative indeks, typisk via unikke eller ikke-unikke SQL-indekser, som databaseprogrammet vedligeholder transparent.
Analysen skal opregne alle alternative indeks for hvert KSDS-datasæt og knytte hvert indeks til dets forbrugende programmer.
Problemet med delte datasæt: Implicitte datakontrakter
VSAM-filer deles ofte på tværs af flere programmer og flere JCL-jobtrin. Denne deling skaber implicitte datakontrakter, aftaler mellem programmer om postlayout, nøgleområder og adgangsmønstre, der ikke findes andre steder end i selve koden.
Afhængigheden af det delte datasæt har to dimensioner:
Producent-forbruger-relationer. Program A skriver poster, som Program B læser. Postlayoutet, nøgleværdierne og den rækkefølge, som Program A producerer, skal stemme overens med præcis, hvad Program B forventer at forbruge. Hvis A og B migreres uafhængigt til forskellige målskemaer uden at koordinere den delte datakontrakt, er resultatet lydløs datakorruption: B's læsninger lykkes mod måldatabasen, men returnerer data i et format, som B's logik ikke håndterer korrekt.
Samtidig adgang på tværs af jobtrin. En JCL-jobstrøm kan have flere trin, der hver kører et forskelligt program mod det samme VSAM-datasæt i rækkefølge. Trin 1 skriver, trin 2 læser og transformerer, trin 3 skriver resultaterne. Migreringen skal bevare denne sekventielle afhængighed, den rækkefølge, hvori programmer tilgår og ændrer det delte datasæt, er en del af systemets adfærdsspecifikation.
En komplet analyse af delt datasæt skal:
- Opregn alle VSAM-datasæt og alle programmer, der tilgår det
- Klassificer hvert programs adgang som producent (WRITE/REWRITE/DELETE), forbruger (READ) eller begge dele.
- Dokumentér JCL-jobkonteksten, hvor hvert program kører, hvilket trin, i hvilket job, i hvilken scheduler-afhængighedskæde
- Identificer producent-forbruger-par, hvor producentens outputformat skal matche forbrugerens forventede inputformat nøjagtigt.
Denne analyse kan ikke udføres ved at undersøge et enkelt program isoleret. Den kræver strukturel analyse på tværs af programmer og JCL'er.
Resultaterne før migrering: Hvad analysen skal producere
En strukturel VSAM-analyse, der er tilstrækkelig til planlægning af datamodernisering, producerer seks leverancer:
Leverance 1: VSAM-datasætopgørelse
Hvert VSAM-datasæt i miljøet med: datasætorganisation (KSDS/ESDS/RRDS/LDS), gennemsnitlig og maksimal postlængde, estimeret postantal (fra JCL SPACE-parametre eller katalogposter), nøglestruktur (primær nøgleforskydning, længde; alternative nøglestrukturer) og om datasættet har alternative indekser.
Leverance 2: Katalog over postlayout
For hvert datasæt, hver FD-post og de kopibøger, den refererer til, med: alle feltdefinitioner inklusive REDEFINES-hierarkier, hvert COMP-3-felt med dets nøjagtige præcision og skala, hvert binært (COMP/COMP-5) felt med dets bytelængde, hvert element med variabel længde (OPSTÅR AFHÆNGIG AF med dets kontrollerende felt) og hver betinget variant eller layoutvariant, der er implicit af REDEFINES.
Leverance 3: Klassificering af adgangsmønstre pr. program
For hvert program, der tilgår hvert datasæt: SELECT-klausulens egenskaber (organisation, adgangstilstand, alternativ nøglebrug), det komplette sæt af anvendte adgangsverb (READ/START/WRITE/REWRITE/DELETE), om programmet bruger sekventiel adgang og afhænger af nøglerækkefølge, hvilke alternative indekser programmet bruger, og om programmet har læse-ændre-skrive-mønstre (implicitte transaktionskrav).
Leverance 4: Delt datasætkort
En rettet graf, hvor noder er VSAM-datasæt og -programmer, og kanter repræsenterer adgangsrelationer med deres type (læs/skriv). Grafen viser hver producent, hver forbruger, producent-forbruger-par og JCL-jobsekvenskonteksten for hver adgang.
Leverance 5: Anbefalinger til målskemaer
For hvert VSAM-datasæt er den anbefalede målarkitektur baseret på dens organisation og adgangsmønstre:
| VSAM-type | Primært adgangsmønster | Anbefalet mål |
|---|---|---|
| KSDS, kun direkte nøgleadgang | Punktopslag efter primærnøgle | Relationstabel, indekseret |
| KSDS, med START/LÆS NÆSTE | Områdescanninger i nøgleorden | Relationstabel med klynget indeks |
| KSDS med alternative indekser | Adgang med flere stier | Relationstabel med flere indekser |
| ESDS, kun tilføjelse | Sekventiel tilføjelse, ingen nøgle | Tilføjelsestabel, hændelsesstrøm eller log |
| ESDS, med RBA-adgang | Byte-offset positionering | Objektlagring med metadataindeks |
| RRDS | Adgang til journalnummer | Relationstabel med sekvenskolonne |
| Stort KSDS (bulk, analyser) | Fuld sekventiel scanning | Kolonneformat lager eller datasø |
| LDS | Applikationsstyret internt format | Kræver analyse af applikationslaget |
Leverance 6: Præcisionsfølsomt feltregister
Hvert COMP-3-, COMP-, COMP-5- og flydende-komma-felt på tværs af hvert datasæt med dets COBOL-definition, den korrekte SQL-datatypetilknytning og et flag for ethvert felt, hvor tilknytningen kræver præcisionsvalidering før og efter migrering.
Hvad adskiller VSAM-analyse fra relationel skemaanalyse
Teams, der har erfaring med migrering mellem relationelle databaser, undervurderer sommetider VSAM-analyse, fordi de anvender den mentale model for skemamigrering: udtræk DDL'en, redesign skemaet, migrer dataene. VSAM har ingen DDL i databaseforstand. Skemaet er fordelt på tværs af kildekode, i FD-poster, i kopibøger, i SELECT-klausuler og i PROCEDURE DIVISION-logikken, der bestemmer, hvilken REDEFINES-variant der er aktiv for en given post.
Tre egenskaber gør VSAM-analyse strukturelt anderledes:
Skemaet findes i koden. Postlayoutet for et VSAM-datasæt er defineret i COBOL-kildekoden, ikke i et databasekatalog. At finde det kræver parsing af kildekoden. Ændring af det kræver koordinering af hvert program, der deler kopibogen. Forståelse af alle dets varianter kræver analyse af programlogik, ikke kun FD-posten.
Adgangsmønstre er implicitte i programadfærd. En relationsdatabase eksponerer forespørgselsmønstre gennem EXPLAIN-planer og forespørgselslogfiler. VSAM-adgangsmønstre er kun synlige i PROCEDURE DIVISION for de programmer, der tilgår filen. Forståelse af, om et program afhænger af nøglerækkefølge, alternativ indeksadgang eller områdescanning kræver kodeanalyse.
Delte datasæt skaber skjulte kontrakter. I en relationsdatabase er et skema en artefakt på databaseniveau, som alle forbrugere deler og ser. I VSAM er postlayoutet integreret i hvert programs kopibog. To programmer kan have divergerede kopier af, hvad der nominelt er det samme postlayout, og at opdage denne divergens kræver sammenligning af kopibogsdefinitioner på tværs af programmer, ikke inspektion af en enkelt skemadefinition.
Hvordan SMART TS XL Udfører VSAM strukturel analyse
SMART TS XL's statisk kodeanalyse analyserer alle elementer af VSAM-strukturen, der findes i COBOL-kildekoden: FD-poster, COPY-medlemsudvidelser, SELECT-klausuldeklarationer (organisation, adgangstilstand, primære og alternative nøglespecifikationer) og alle filadgangsverber i PROCEDURE DIVISION. For hvert VSAM-datasæt producerer analysen adgangsmønsterklassifikationen, postlayoutet med fuld REDEFINES-opløsning og COMP-3-feltregistret med præcisionsmetadata.
Applikationsafhængighedskortlægningen opbygger det delte datasætkort: hvert program , der tilgår hvert VSAM-datasæt, klassificeret efter adgangstype, med identificerede producent-forbruger-relationer og løst kopibogsdelingsgrafen. Når 47 programmer deler en kopibog, der definerer et VSAM-postlayout, gør afhængighedskortet alle 47 synlige, før der træffes nogen migreringsbeslutning, ikke efter at en layoutændring har ødelagt 47 programmer på uventede måder.
JCL -udvidelsesfunktionen leverer den operationelle kontekst: hvilke JCL-jobtrin refererer til hvilke VSAM-datasæt i deres DD-sætninger, i hvilken rækkefølge, i hvilke jobstrømme. De producent-forbruger-relationer, der findes på JCL-jobniveau, hvor trin 1 skriver til et VSAM-datasæt, som trin 3 læser, er synlige i JCL-afhængighedsanalysen, hvilket muliggør migreringssekvensering, der bevarer de operationelle rækkefølgeafhængigheder, som batchplanen håndhæver.
Effektanalysefunktionen besvarer det spørgsmål , der går forud for enhver beslutning om VSAM-migrering: Hvis layoutet af dette datasæt ændres, hvilke programmer påvirkes så? Effektomfanget, hvert program, der deler den relevante kopibog, hvert JCL-trin, der refererer til datasættet, opregnes, før migreringsarbejdet påbegyndes, hvilket giver grundlag for koordineret migreringsplanlægning i stedet for at opdage berørte programmer ét defekt program ad gangen.
Virksomhedssøgningsfunktionen gør det muligt at forespørge på hele VSAM-opgørelsen i hele moderniseringsprogrammet: find alle programmer , der tilgår et specifikt VSAM-datasæt, alle kopibøger, der definerer et specifikt postlayout, alle programmer, der bruger START/READ NEXT-mønstre (som angiver rækkefølgeafhængigheder), alle felter defineret som COMP-3 (som kræver præcisionsbevidst måltilknytning) på få sekunder på tværs af millioner af COBOL-linjer.
Som beskrevet i forbindelse med migrering af IMS- og VSAM-datastrukturer sammen med COBOL-programmer, datamigrering og kodeanalyse skal foregå parallelt. SMART TS XLs VSAM strukturanalyse leverer den oversigt, der gør denne parallelisme håndterbar, de delte postlayouts, adgangsmønstrene og de producent-forbruger-relationer, der afgør, om datamigrering kan forløbe uafhængigt eller skal koordineres med programændringer.
Den struktur, du forstår, er den struktur, du kan migrere
Analysen af VSAM-filstrukturen er ikke en overhead-funktion i et moderniseringsprogram. Det er beslutningsgrundlaget. Målskemaet kan ikke designes uden at kende varianterne af postlayoutet. Migreringen kan ikke sekventeres uden at kende producent-forbruger-forholdet. Præcisionen af COMP-3-felter kan ikke bevares uden at vide, hvilke felter der kræver decimalbevidste måltyper.
Ethvert moderniseringsprogram, der springer denne analyse over, opdager, hvad det overså under migreringseksekveringen, når en REDEFINES-variant, der ikke blev analyseret, producerer misdannede poster i målet, når et delt datasæt migreres uden at koordinere alle dets forbrugere, når en intervalscanning, der var baseret på VSAM's nøgleordreturneringer, resulterer i udefineret rækkefølge fra en måltabel, der ikke var designet med et klyngeindeks. Disse opdagelser under udførelsen koster multipla af, hvad analysen ville have kostet under planlægningen.
Forstå strukturen først. Migrer dataene derefter. Rækkefølgen er ikke en formalitet. Det er forskellen på en migrering, der giver korrekte resultater, og en, der producerer data, der ser rigtige ud, indtil den første regulatoriske revision udføres.
