Analýza závislostí databáze IMS: Co musí modernizační týmy vědět před jakýmkoli přesunem

IMS není zastaralý systém v tom smyslu, že by byl zastaralý. Je to databázový engine, který stojí za pohledávkami velkých bank, správou pojistných smluv pojišťoven a zpracováním pojistných událostí plátců zdravotní péče. IBM jej nadále vyvíjí. Problém není v tom, že IMS přestal fungovat, problém je v tom, že každý vývojář, který věděl, jak se orientovat v jeho hierarchických segmentových stromech, odchází do důchodu, každá změna v systému založeném na IMS vyžaduje pochopení datového modelu, který nemá SQL, a každý migrační plán, který s IMS zachází jako s relační databází, tento rozdíl objevuje tvrdě.

Těžší cesta spočívá v zjištění, že program v COBOLu přistupuje k IMS nikoli jednoduchým vyhledáváním klíčů, ale hierarchickým procházením, které musí být replikováno v cílovém systému s ekvivalentní navigační logikou. Nebo zjištění, že logický vztah mezi dvěma fyzickými databázemi IMS vytváří závislost, kterou DBD žádné z databází plně nedokumentuje, a že migrace konvertovala obě databáze nezávisle a zároveň tiše narušila každý program, který tento logický vztah používal. Nebo zjištění, že sekundární indexová databáze, struktura, kterou většina migračních plánů nikdy neinventarizuje, byla jedinou cestou, kterou kritický program pro tvorbu sestav dosáhl svých dat.

Žádné z těchto překvapení nepřežije kontakt s důkladnou analýzou závislostí před migrací. Přežijí kontakt s předpoklady.

Čím se analýza závislostí IMS liší

Analýza závislostí pro relační databázové prostředí, DB2, Oracle, SQL Server, probíhá podle dobře známé cesty. Analyzujte SQL v kódu aplikace, identifikujte odkazy na tabulky a sloupce, vytvořte mapu programů, které přistupují ke kterým tabulkám, a použijte tuto mapu k určení rozsahu a pořadí migrace. Struktura je explicitní. Závislosti jsou viditelné v textu SQL.

Analýza závislostí IMS je složitější ve všech dimenzích.

Struktura je hierarchická, nikoli relační. Databáze IMS je organizována jako strom typů segmentů, kde každý typ segmentu má definovaný vztah rodič-dítě. Program v COBOLu, který čte záznamy pacientů z databáze IMS, se nespustí. SELECT * FROM PATIENTS WHERE ID = ?Vydá volání Get Unique (GU) pro navigaci v hierarchii do kořenového segmentu a poté volá Get Next Within Parent (GNP) pro procházení podřízených segmentů. Závislost programu není na tabulce, ale na specifické cestě hierarchickou strukturou a změna této struktury může narušit programy, které se v ní pohybují způsoby, které by žádná analýza na úrovni SQL neodhalila.

Závislosti jsou rozděleny do tří samostatných struktur. Úplný obraz toho, co program v COBOLu dělá s IMS, vyžaduje analýzu:

• DBD (deskriptor databáze): definuje hierarchii fyzických segmentů, klíčová pole, metody přístupu (HDAM, HIDAM, HISAM, HSAM) a jakékoli sekundární indexy nebo logické vztahy
• PSB (blok specifikace programu): definuje, ke kterým databázím má program povolen přístup, prostřednictvím kterých desek plošných spojů, s jakou citlivostí a specifikacemi záměru
• Zdrojový kód v COBOLu: obsahuje skutečná volání DL/I, která určují, ke kterým segmentům se přistupuje, s jakými funkcemi volání, v jakém pořadí a s jakými SSA.

Žádný samostatný zdroj neobsahuje úplný obrázek. Analýza, která čte pouze zdrojový kód v COBOLu, vidí typy volání a názvy segmentů, ale nikoli fyzickou strukturu databáze. Analýza, která čte pouze DBD a PSB, vidí, co program smí dělat, ale ne to, co skutečně dělá.

Navigace je závislá na pozici. V relační databázi je každý řádek nezávisle adresovatelný klíčem. V IMS ovlivňuje aktuální pozice programu v hierarchii, co vracejí následná volání. Volání GN (Get Next) vrací další segment v hierarchické posloupnosti z místa, kde se program aktuálně nachází. Závislost není jen na typu segmentu, ale na cestě průchodu, která vedla k aktuální pozici. Programy, které se spoléhají na implicitní hierarchické řazení IMS, mají závislost, která mizí, když jsou data migrována do relační databáze, kde není zaručeno ekvivalentní řazení.

Inventář volání DL/I: Co odhaluje zdrojový kód COBOLu

Nejpřímo užitečnější analýzou před migrací je kompletní inventarizace všech volání DL/I v každém programu v COBOLu, který přistupuje k IMS. Tato inventarizace sděluje migračnímu týmu, co každý program s IMS dělá, nikoli co je povoleno dělat (což definuje PSB), ale co skutečně dělá.

Volání DL/I v COBOLu se objevují ve dvou formách:

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

Oba formuláře obsahují stejné analytické informace: funkční kód, použitou desku plošných spojů, cílový segment a volitelně SSA (argument vyhledávání segmentu), který kvalifikuje volání. Kompletní inventář volání DL/I extrahuje toto vše z každého programu.

Taxonomie funkčního kódu a její důsledky pro migraci

Kód funkce DL/I je nejvýznamnějším prvkem každého volání z hlediska migrace. Každý kód funkce implikuje jiný vzor přístupu k datům, který musí být replikován v cílové relační databázi:

Funkce pouze pro čtení: GU, Získat jedinečnost: přejděte přímo do segmentu pomocí kvalifikovaných SSA. Ekvivalent k příkazu SELECT s klauzulí WHERE v relačních termínech. Migrace je snadná, pokud se klíč segmentu čistě mapuje na relační primární klíč.

GN, Get Next: přechod na další segment v hierarchické posloupnosti. Toto je funkční kód, který nemá žádný přímý relační ekvivalent, spoléhá se na poziční stav IMS a implicitní řazení. Programy, které extenzivně používají GN, vyžadují pečlivou analýzu toho, na jakém řazení závisí.

GNP, Získat další v rámci nadřazeného segmentu: načte následující potomky aktuálního nadřazeného segmentu. Ekvivalent načtení všech řádků ve vztahu cizího klíče. Obecně se čistě mapuje na SELECT s klauzulí WHERE cizího klíče.

Funkce Hold (předpoklady pro aktualizaci): GHU, GHN, GHNP, ekvivalenty příkazů GU, GN, GNP typu Get Hold. Příznak „hold“ označuje, že bude následovat operace aktualizace (REPL) nebo mazání (DLET). Programy, které používají volání hold, jsou programy typu read-modify-write; migrace musí zachovat transakční integritu v rámci hold a následné aktualizace.

Funkce aktualizace: ISRT, Vložit: přidá nový výskyt segmentu. Ekvivalent k INSERT. DLET, Smazat: odstraní aktuálně zadržený segment a všechny jeho závislé segmenty. Chování „všechny závislé segmenty“ je kaskáda specifická pro IMS, která musí být v cílovém systému explicitně implementována. REPL, Nahradit: aktualizuje aktuálně držený segment novými daty. Ekvivalent k UPDATE.

Proč je to důležité pro rozsah migrace: Program s pouze voláními GU a GNP je konzumentem dat IMS pouze pro čtení, s nižším rizikem migrace a jednodušším ověřováním. Program používající GHU, REPL a DLET je program pro zpracování transakcí, který modifikuje hierarchické struktury; jeho migrace vyžaduje zachování transakční integrity napříč operacemi, které IMS v současné době atomicky vynucuje.

Tři typy závislostí, které komplikují každou migraci

Logické vztahy

Logické vztahy IMS propojují segmenty napříč dvěma fyzicky oddělenými databázemi. Logický podřízený segment v databázi A má logického nadřazeného segmentu v databázi B. Když program v COBOLu prochází logickým vztahem, prochází cestou, která fyzicky překračuje hranice databáze. Tento průchod IMS transparentně spravuje, ale zmizí, když jsou databáze migrovány nezávisle.

Logické vztahy představují typ závislosti s nejvyšším rizikem v migraci IMS z jednoho důvodu: ve zdrojovém kódu COBOLu jsou neviditelné. Program COBOL volá GNP pro získání potomků segmentu. Zda tento GNP prochází fyzickým vztahem rodič-dítě nebo logickým vztahem, je určeno PSB a DBD, nikoli kódem COBOL. Migrační tým, který analyzuje pouze zdrojový kód COBOL, nemá možnost zjistit, zda volání GNP překračuje hranici logického vztahu, aniž by samostatně analyzoval PSB a DBD.

Programy, které používají logické vztahy, vyžadují migraci k replikaci sémantiky logického vztahu v cílovém systému, obvykle JOIN v relačním modelu, a k ověření, že každý program používající tento vztah obdrží z JOIN ekvivalentní výsledky, které obdržel z logického průchodu IMS.

Sekundární indexové databáze

Sekundární indexové databáze IMS poskytují alternativní přístupovou cestu k primární databázi, což umožňuje programům načítat segmenty podle jiného pole než kořenového klíče. Sekundární indexová databáze je samostatná databáze IMS s vlastní DBD, ale její data jsou odvozena z primární databáze.

Migrační týmy často objevují sekundární indexové databáze během analýzy, nikoli během plánování, protože:

• Jsou definovány v databázích DBD, které nejsou vždy seskupeny s databázemi DBD primární databáze.
• Programy, které používají sekundární indexy, pojmenovávají indexovou databázi ve svých PSB, ale programy, které se k primární databázi připojují prostřednictvím sekundárního indexu, to nemusí v COBOLu zřejmě uvádět.
• Dokumentace může popisovat primární databázi bez zmínky o jejích sekundárních indexech.

Program, který přistupuje k IMS prostřednictvím sekundárního indexu, má závislost na přístupovém vzoru, která musí být v cíli replikována jako index bez primárního klíče nebo jiná strategie dotazování. Pokud toto během migrace chybí, program sice běží bez chyby, ale nemůže najít hledané záznamy.

Databáze GSAM

Databáze GSAM (Generalized Sequential Access Method) jsou rozhraním IMS pro sekvenční dávkové zpracování, které v podstatě umožňuje dávkovým programům v COBOLu používat volání DL/I pro funkčně sekvenční souborový I/O. Databáze GSAM nemají hierarchie segmentů; jsou to ploché sekvenční struktury, ke kterým se přistupuje prostřednictvím IMS, aby se mohly využít jeho schopností obnovy a restartu.

Programy, které používají databáze GSAM, jsou dávkové programy, jejichž chování při obnově závisí na podpoře kontrolních bodů/restartu IMS. Migrace musí toto chování při obnově zachovat nebo jej nahradit ekvivalentním mechanismem v cílové platformě.

Vytvoření inventáře závislostí před migrací

Kompletní analýza závislostí IMS vytváří šest výstupů, které společně definují rozsah migrace, riziko a posloupnost.

Výstup 1: Mapování desek plošných spojů do databáze

Každá deska plošných spojů (PCB) v každé PSB se mapuje na specifickou databázi DBD (konkrétní databázi IMS). Výpis každé desky plošných spojů napříč všemi PSB a mapování každé z nich na její DBD vytváří směrodatný seznam programů, které mají povolen přístup ke kterým databázím. Toto je výchozí bod pro pochopení rozsahu, ale nadhodnocuje skutečné závislosti, protože programy mohou mít PSB, které obsahují více databází, než ve skutečnosti používají.

Výstup 2: Skutečný inventář hovorů podle programu

Analýza volání DL/I každého COBOL programu vytváří skutečný seznam použití: které PCB každý program skutečně volá, které funkční kódy používá, ke kterým typům segmentů přistupuje a zda používá kvalifikované SSA (přístup pomocí segmentového klíče) nebo nekvalifikovanou navigaci (poziční průchod). To zužuje rozsah z oprávnění definovaných PSB na skutečné chování programu.

Výstup 3: Mapa využití logických vztahů

Křížové porovnání inventáře volání s DBD identifikuje, která volání GNP nebo GN programů procházejí logickými vztahy. To vyžaduje analýzu nejen zdrojového kódu COBOL a PSB, ale i struktur DBD, které definují, které vztahy rodič-dítě jsou fyzické a které logické.

Výstup 4: Mapa využití sekundárního indexu

Programy, které ve svých PSB pojmenovávají sekundární indexové databáze nebo vydávají volání s SSA odkazujícími na pole klíčů nekořenového typu, jsou identifikovány jako uživatelé sekundárních indexů. Mapa dokumentuje, které sekundární indexy existují, které primární databáze podporují a které programy jsou na nich závislé.

Výstup 5: Distribuce typů volání podle databáze

Pro každou databázi IMS v rozsahu působnosti ukazuje rozložení typů volání mezi všemi programy, které k ní přistupují, složitost její migrace:

• Databáze, ke kterým přistupují pouze funkce pro čtení (GU, GN, GNP), se migrují snadněji.
• Databáze, ke kterým přistupují funkce hold a aktualizace (GHU + REPL, GHN + DLET), vyžadují replikaci transakční integrity.
• Databáze s vysokým využitím GN indikují závislosti na poziční navigaci, které vyžadují analýzu uspořádání
• Databáze s logickými vztahy vyžadují v cíli sémantiku cross-databázového JOIN.

Výstup 6: Klasifikace rizik programu

Pomocí distribuce typů volání a inventáře typů závislostí je každý program klasifikován podle migračního rizika:

Programy, které používají pouze GU a GNP s kvalifikovanými SSA, přistupují k jediné databázi bez logických vztahů a nemají žádná volání hold/update, jsou kandidáty s nejnižším rizikem pro rané migrační vlny. Programy, které extenzivně používají GN, přistupují k více databázím prostřednictvím logických vztahů nebo provádějí složité sekvence hold/update, jsou programy s nejvyšším rizikem, které vyžadují nejdůkladnější analýzu a validaci před migrací.

Co analýza mění v plánování migrace

Analýza závislostí nejen dokumentuje, co existuje, ale také mění rozhodnutí, která následují.

Rozhodování o posloupnosti. Programy, které sdílejí databáze IMS prostřednictvím logických vztahů, nelze migrovat nezávisle. Pokud program A čte logický podřízený segment, který má logického rodiče ve stejné databázi jako kořenový segment programu B, migrace A bez migrace B (nebo vytvoření mostu) přeruší A. Graf závislostí určuje, které programy se musí přesunout společně.

Rozhodnutí o návrhu cíle. Distribuce typů volání určuje, jak by mělo být strukturováno cílové relační schéma. Hierarchický vztah rodič-dítě, ke kterému se přistupuje výhradně prostřednictvím volání GU a GNP s kvalifikovaným klíčem, se v cíli čistě překládá na vztah cizího klíče. Stejný vztah, ke kterému se přistupuje prostřednictvím volání GN s pozičními závislostmi, vyžaduje, aby cílové schéma zachovalo ekvivalentní řazení, buď prostřednictvím explicitního ORDER BY, pole sekvence nebo jiného přístupového vzoru, který dosahuje stejného výsledku.

Rozhodnutí o rozsahu validace. Analýza identifikuje, které programy jsou pouze pro čtení a které jsou transakčními procesory. Programy pouze pro čtení lze validovat porovnáním výstupních výsledků mezi původním systémem IMS a migrovaným systémem. Transakční procesory vyžadují testování transakční ekvivalence, které zajišťuje, že stejná sekvence operací s cílem produkuje ekvivalentní změny stavu dat oproti originálu.

Klasifikace rizik. Logický vztah a zjištění sekundárního indexu jsou primárními vstupy pro klasifikaci rizik. Každý migrační program má registr rizik. Analýza závislostí IMS říká týmu, které položky do něj má vkládat.

Jak SMART TS XL Provádí analýzu závislostí IMS

SMART TS XLJe statická analýza kódu Analyzuje všechna volání DL/I programu v COBOLu, a to jak formuláře rozhraní volání EXEC DLI, tak xxxTDLI, a z každého volání extrahuje kód funkce, referenci PCB, název segmentu a strukturu SSA. Tím se vytvoří skutečný inventář volání na úrovni programu, v celém portfoliu COBOLu, bez nutnosti spuštěného systému IMS nebo ruční kontroly kódu.

Mapování závislostí aplikací rozšiřuje tento inventář do grafu závislostí mezi programy: které programy sdílejí přístup ke kterým databázím IMS, které programy používají stejné PCB, přístupové vzorce kterých programů se překrývají způsobem, který vyžaduje koordinovanou migraci. Když logický vztah propojuje segmenty napříč databázemi, mapa závislostí reprezentuje toto propojení mezi databázemi jako explicitní vztah, který musí být v cílovém systému zachován.

Analýza dopadů odpovídá na otázku, na kterou musí odpovědět každý migrační tým před převodem jakékoli databáze: pokud bude tato databáze IMS migrována, které programy budou ovlivněny, které přístupové vzorce musí být replikovány a které testovací případy musí být validovány pro potvrzení ekvivalence. Odpověď není odhad, ale výčtový seznam odvozený ze skutečného inventáře volání DL/I.

Možnost rozšíření JCL přidává operační kontext: které kroky úlohy JCL volají které programy, které přistupují k IMS, v jakém pořadí a s jakými specifikacemi PSB. Řetězec operačních závislostí, tedy sekvence dávkových úloh, která zpracovává data IMS prostřednictvím více programů, je pro plánování migrace stejně důležitý jako vzory přístupu na úrovni programu. Migrace databáze bez migrace orchestrace dávkových úloh, která ji obklopuje, vytváří systém, který správně zpracovává záznamy izolovaně a v produkčním prostředí selhává při spuštění sekvence úloh.

Pro týmy provádějící starší modernizace systémů podporovaných IMS, strukturální důkazy vytvořené SMART TS XL je vstupem pro každé následné rozhodnutí o migraci: které programy migrují v jaké vlně, které databáze lze převést nezávisle a které vyžadují koordinovanou konverzi, které přístupové vzorce vyžadují spíše rearchitekturu než přímý překlad. Jak je popsáno v kontextu migrace struktur IMS a VSAM vedle programů v COBOLuPropojení mezi programy v COBOLu a staršími datovými strukturami znamená, že migrace dat a analýza kódu musí probíhat paralelně, inventář závislostí je mechanismus, který umožňuje paralelní plánování.

Inventář není migrace

Analýza závislostí IMS produkuje znalosti. Migrace stále vyžaduje rozhodnutí, inženýrské práce a validaci. Analýza mění kvalitu rozhodnutí, úplnost technického rozsahu a spolehlivost validace.

Organizace, které úspěšně migrují databáze IMS, nejsou ty s nejagresivnějšími časovými harmonogramy ani s největšími migračními rozpočty. Jsou to ty, které věděly, co mají, ještě než s přesunem začaly – každý program, který přistupoval k jednotlivým databázím, každý funkční kód, který odhaloval přístupový vzorec každého programu, každý logický vztah, který vytvářel závislosti mezi databázemi, každý sekundární index, který poskytoval přístupovou cestu, jež by bez explicitní replikace nepřežila konverzi.

Tyto znalosti nepocházejí z dokumentace. Pocházejí z analýzy kódu.