IMS nie jest systemem legacy w sensie przestarzałym. Jest to silnik bazy danych, który odpowiada za obsługę należności dużych banków, administrację polisami firm ubezpieczeniowych i przetwarzanie roszczeń płatników świadczeń zdrowotnych. IBM stale go rozwija. Problemem nie jest to, że IMS przestał działać, ale to, że każdy programista, który potrafił poruszać się po hierarchicznych drzewach segmentów, odchodzi na emeryturę. Każda zmiana w systemie opartym na IMS wymaga zrozumienia modelu danych, który nie zawiera języka SQL, a każdy plan migracji, który traktuje IMS jak relacyjną bazę danych, odkrywa tę różnicę na własnej skórze.
Trudnym sposobem jest odkrycie w trakcie migracji, że program COBOL uzyskuje dostęp do IMS nie poprzez proste wyszukiwanie klucza, ale poprzez hierarchiczne przechodzenie, które musi zostać powtórzone w systemie docelowym z równoważną logiką nawigacji. Lub odkrycie, że logiczna relacja między dwiema fizycznymi bazami danych IMS tworzy zależność, której DBD żadnej z baz danych nie dokumentuje w pełni, oraz że migracja niezależnie przekonwertowała obie bazy danych, jednocześnie po cichu przerywając działanie każdego programu korzystającego z tej logicznej relacji. Lub odkrycie, że drugorzędna baza danych indeksów, struktura, której większość planów migracji nigdy nie inwentaryzuje, była jedyną ścieżką, którą krytyczny program raportujący dotarł do swoich danych.
Żadne z tych niespodzianek nie przetrwa kontaktu z rygorystyczną analizą zależności przed migracją. Przetrwają kontakt z założeniami.
Analiza zależności IMS w skali portfela
SMART TS XL identyfikuje zależności IMS między bazami danych, które są niewidoczne w samym kodzie źródłowym COBOL.
Więcej informacjiCzym wyróżnia się analiza zależności IMS
Analiza zależności dla środowiska relacyjnej bazy danych (DB2, Oracle, SQL Server) przebiega według dobrze znanej ścieżki. Analiza kodu SQL w kodzie aplikacji, identyfikacja odwołań do tabel i kolumn, utworzenie mapy programów uzyskujących dostęp do poszczególnych tabel i wykorzystanie tej mapy do określenia zakresu i kolejności migracji. Struktura jest jawna. Zależności są widoczne w tekście SQL.
Analiza zależności IMS jest bardziej złożona w każdym wymiarze.
Struktura jest hierarchiczna, nie relacyjna. Baza danych IMS jest zorganizowana jako drzewo typów segmentów, gdzie każdy typ segmentu ma zdefiniowaną relację nadrzędny-podrzędny. Program COBOL odczytujący dokumentację medyczną z bazy danych IMS nie wykonuje SELECT * FROM PATIENTS WHERE ID = ?. Wysyła wywołanie Get Unique (GU), aby przejść przez hierarchię do segmentu głównego, a następnie wywołanie Get Next Within Parent (GNP), aby przejść przez segmenty potomne. Zależność programu nie jest zależna od tabeli, lecz od określonej ścieżki w strukturze hierarchicznej, a zmiana tej struktury może zakłócić działanie programów, które nawigują po niej w sposób niezauważalny dla żadnej analizy na poziomie SQL.
Zależności są rozłożone na trzy oddzielne struktury. Pełny obraz tego, co program COBOL robi z IMS, wymaga analizy:
- DBD (deskryptor bazy danych): definiuje hierarchię segmentów fizycznych, pola kluczy, metody dostępu (HDAM, HIDAM, HISAM, HSAM) oraz wszelkie indeksy drugorzędne lub relacje logiczne
- PSB (Blok Specyfikacji Programu): definiuje, do których baz danych program ma prawo dostępu, poprzez które płytki PCB, z jakimi specyfikacjami czułości i intencji
- Kod źródłowy COBOL: zawiera rzeczywiste wywołania DL/I, które określają, do których segmentów uzyskuje się dostęp, z jakimi funkcjami wywołania, w jakiej kolejności i z jakimi SSA
Żadne pojedyncze źródło nie zawiera pełnego obrazu. Analiza, która odczytuje tylko kod źródłowy COBOL, widzi typy wywołań i nazwy segmentów, ale nie fizyczną strukturę bazy danych. Analiza, która odczytuje tylko DBD i PSB, widzi, co program ma prawo robić, ale nie to, co faktycznie robi.
Nawigacja jest zależna od pozycji. W relacyjnej bazie danych każdy wiersz jest niezależnie adresowalny za pomocą klucza. W IMS bieżąca pozycja programu w hierarchii wpływa na to, co zwracają kolejne wywołania. Wywołanie GN (Get Next) zwraca kolejny segment w sekwencji hierarchicznej z miejsca, w którym aktualnie znajduje się program. Zależność ta dotyczy nie tylko typu segmentu, ale także ścieżki przejścia, która doprowadziła do bieżącej pozycji. Programy korzystające z niejawnego hierarchicznego uporządkowania IMS mają zależność, która znika po migracji danych do relacyjnej bazy danych, gdzie nie ma gwarancji równoważnego uporządkowania.
Inwentarz połączeń DL/I: co ujawnia kod źródłowy COBOL
Najbardziej użyteczną analizą przed migracją jest kompletny spis wszystkich wywołań DL/I w każdym programie COBOL, który uzyskuje dostęp do IMS. Ten spis informuje zespół ds. migracji, co każdy program robi z IMS, a nie co ma uprawnienia (zgodnie z definicją PSB), ale co faktycznie robi.
Wywołania DL/I w języku COBOL występują w dwóch formach:
kobol
* 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-CUSTOMERObie formy zawierają te same informacje analityczne: kod funkcji, używany PCB, segment docelowy oraz opcjonalnie argument wyszukiwania segmentów (SSA) kwalifikujący wywołanie. Pełny inwentarz wywołań DL/I wyodrębnia wszystkie te informacje z każdego programu.
Taksonomia kodów funkcji i jej implikacje dla migracji
Kod funkcji DL/I jest najważniejszym elementem każdego wywołania pod kątem migracji. Każdy kod funkcji implikuje inny wzorzec dostępu do danych, który musi zostać powtórzony w docelowej relacyjnej bazie danych:
Funkcje tylko do odczytu: GU, Get Unique: przejdź bezpośrednio do segmentu za pomocą kwalifikowanych klauzul SSA. Odpowiednik instrukcji SELECT z klauzulą WHERE w kontekście relacyjnym. Łatwa migracja, jeśli klucz segmentu jest poprawnie odwzorowany na relacyjny klucz podstawowy.
GN, Get Next: przejdź do następnego segmentu w hierarchicznej sekwencji. Jest to kod funkcji, który nie ma bezpośredniego odpowiednika relacyjnego, opiera się na stanie pozycyjnym IMS i niejawnym uporządkowaniu. Programy intensywnie korzystające z GN wymagają dokładnej analizy, od jakiego uporządkowania zależą.
GNP, Pobierz następny element w segmencie nadrzędnym: pobierz kolejne elementy podrzędne bieżącego segmentu nadrzędnego. Odpowiednik pobrania wszystkich wierszy w relacji klucza obcego. Zazwyczaj mapuje się to poprawnie na instrukcję SELECT z klauzulą WHERE klucza obcego.
Funkcje przytrzymywania (wymagania wstępne aktualizacji): GHU, GHN, GHNP, Get Hold to odpowiedniki GU, GN i GNP. Flaga „hold” oznacza, że nastąpi operacja aktualizacji (REPL) lub usunięcia (DLET). Programy korzystające z wywołań hold to programy odczytu-modyfikacji-zapisu; migracja musi zachować integralność transakcyjną podczas wstrzymania i późniejszej aktualizacji.
Funkcje aktualizacji: ISRT, Wstaw: dodaje nowe wystąpienie segmentu. Odpowiednik polecenia INSERT. DLET, Usuń: usuwa aktualnie przechowywany segment i wszystkie jego elementy zależne. Zachowanie „wszystkie elementy zależne” to kaskada specyficzna dla IMS, która musi być jawnie zaimplementowana w systemie docelowym. REPL, Zamień: aktualizuje aktualnie przechowywany segment nowymi danymi. Odpowiednik polecenia UPDATE.
Dlaczego ma to znaczenie dla zakresu migracji: Program z samymi wywołaniami GU i GNP jest odbiorcą danych IMS tylko do odczytu, co wiąże się z mniejszym ryzykiem migracji i jest prostsze do walidacji. Program wykorzystujący GHU, REPL i DLET to program do przetwarzania transakcji, który modyfikuje struktury hierarchiczne; jego migracja wymaga zachowania integralności transakcyjnej między operacjami, którą IMS obecnie wymusza atomowo.
Trzy typy zależności, które utrudniają każdą migrację
Relacje logiczne
Logiczne relacje IMS łączą segmenty w dwóch fizycznie oddzielnych bazach danych. Logiczny segment podrzędny w bazie danych A ma logiczny segment nadrzędny w bazie danych B. Gdy program COBOL porusza się po relacji logicznej, pokonuje ścieżkę, która fizycznie przekracza granice bazy danych. Przejście to jest zarządzane transparentnie przez IMS, ale znika, gdy bazy danych są migrowane niezależnie.
Relacje logiczne są typem zależności o najwyższym ryzyku w migracji IMS z jednego powodu: są niewidoczne w kodzie źródłowym COBOL. Program COBOL wywołuje GNP, aby uzyskać potomków segmentu. To, czy GNP przekracza fizyczną relację rodzic-dziecko, czy relację logiczną, jest określane przez PSB i DBD, a nie przez kod COBOL. Zespół ds. migracji, który analizuje tylko kod źródłowy COBOL, nie ma możliwości stwierdzenia, że wywołanie GNP przekracza granicę relacji logicznej bez oddzielnej analizy PSB i DBD.
Programy wykorzystujące relacje logiczne wymagają migracji w celu replikacji semantyki relacji logicznej w systemie docelowym (zwykle połączenia JOIN w modelu relacyjnym) oraz sprawdzenia, czy każdy program wykorzystujący relację otrzymuje równoważne wyniki połączenia JOIN, jakie otrzymał w wyniku logicznego przeglądania IMS.
Bazy danych indeksów wtórnych
Bazy danych indeksów pomocniczych IMS zapewniają alternatywną ścieżkę dostępu do bazy głównej, umożliwiając programom pobieranie segmentów według pola innego niż klucz główny. Baza danych indeksów pomocniczych to odrębna baza danych IMS z własną bazą danych (DBD), ale jej dane pochodzą z bazy głównej.
Zespoły zajmujące się migracją często odkrywają bazy danych indeksów wtórnych w trakcie analizy, a nie w trakcie planowania, ponieważ:
- Są one definiowane w DBD, które nie zawsze są grupowane z podstawowymi DBD bazy danych
- Programy korzystające z indeksów pomocniczych podają nazwę bazy danych indeksów w swoich plikach PSB, natomiast programy, które przechodzą do bazy danych podstawowej za pośrednictwem indeksu pomocniczego, mogą nie ujawniać tego w kodzie źródłowym COBOL.
- Dokumentacja może opisywać bazę danych podstawową bez wspominania o jej indeksach drugorzędnych
Program uzyskujący dostęp do IMS poprzez indeks pomocniczy ma zależność od wzorca dostępu, która musi zostać zreplikowana w systemie docelowym jako indeks inny niż klucz podstawowy lub inna strategia zapytania. Pominięcie tego podczas migracji powoduje, że program działa bezbłędnie, ale nie może znaleźć poszukiwanych rekordów.
Bazy danych GSAM
Bazy danych GSAM (Generalized Sequential Access Method) stanowią interfejs IMS do sekwencyjnego przetwarzania wsadowego, umożliwiając programom wsadowym COBOL korzystanie z wywołań DL/I do funkcjonalnie sekwencyjnego wejścia/wyjścia plików. Bazy danych GSAM nie posiadają hierarchii segmentów; są to płaskie struktury sekwencyjne, do których dostęp można uzyskać za pośrednictwem IMS, aby skorzystać z funkcji odzyskiwania i ponownego uruchamiania IMS.
Programy korzystające z baz danych GSAM to programy wsadowe, których mechanizm odzyskiwania zależy od obsługi punktów kontrolnych/restartu IMS. Migracja musi zachować ten mechanizm odzyskiwania lub zastąpić go równoważnym mechanizmem na platformie docelowej.
Tworzenie inwentarza zależności przed migracją
Pełna analiza zależności IMS generuje sześć elementów, które razem definiują zakres, ryzyko i kolejność migracji.
Przedmiot dostawy 1: Mapowanie PCB do bazy danych
Każdy PCB w każdym PSB jest mapowany na konkretny DBD (konkretną bazę danych IMS). Wylistowanie każdego PCB we wszystkich PSB i mapowanie każdego z nich na jego DBD tworzy autorytatywną listę programów uprawnionych do dostępu do poszczególnych baz danych. Jest to punkt wyjścia do zrozumienia zakresu, ale zawyża on rzeczywiste zależności, ponieważ programy mogą mieć PSB zawierające więcej baz danych, niż faktycznie wykorzystują.
Dostarczany element 2: Rzeczywista liczba połączeń na program
Analiza składniowa wywołań DL/I każdego programu COBOL generuje rzeczywistą listę użycia: które PCB są faktycznie wywoływane przez każdy program, jakich kodów funkcji używa, do których typów segmentów uzyskuje dostęp oraz czy korzysta z kwalifikowanych kluczy dostępu (SSA) czy nawigacji niekwalifikowanej (przechodzenie pozycyjne). To zawęża zakres od uprawnień zdefiniowanych w PSB do faktycznego działania programu.
Przedmiot dostawy 3: Mapa wykorzystania relacji logicznych
Odwołanie krzyżowe inwentarza wywołań do DBD pozwala zidentyfikować, które wywołania GNP lub GN programów przechodzą przez relacje logiczne. Wymaga to analizy nie tylko kodu źródłowego COBOL i PSB, ale także struktur DBD, które definiują, które relacje nadrzędny-podrzędny są fizyczne, a które logiczne.
Element dostarczalny 4: Mapa wykorzystania indeksu wtórnego
Programy, które w swoich plikach PSB nadają nazwy bazom indeksów pomocniczych lub wywołują polecenia SSA odwołujące się do pól kluczy innych niż klucz główny, są identyfikowane jako użytkownicy indeksów pomocniczych. Mapa dokumentuje, które indeksy pomocnicze istnieją, które bazy danych podstawowych obsługują i które programy od nich zależą.
Element dostarczalny 5: Dystrybucja typów połączeń według bazy danych
W przypadku każdej bazy danych IMS w zakresie rozkład typów wywołań we wszystkich programach, które uzyskują do niej dostęp, wskazuje na złożoność jej migracji:
- Bazy danych, do których dostęp uzyskuje się wyłącznie za pomocą funkcji odczytu (GU, GN, GNP), są łatwiejsze w migracji
- Bazy danych, do których dostęp uzyskuje się za pomocą funkcji wstrzymywania i aktualizacji (GHU + REPL, GHN + DLET), wymagają replikacji integralności transakcyjnej
- Bazy danych o dużym wykorzystaniu GN wskazują na zależności nawigacji pozycyjnej, które wymagają analizy kolejności
- Bazy danych z relacjami logicznymi wymagają semantyki JOIN między bazami danych w systemie docelowym
Zadanie 6: Klasyfikacja ryzyka programu
Korzystając z dystrybucji typów wywołań i inwentaryzacji typów zależności, każdy program jest klasyfikowany według ryzyka migracji:
Programy korzystające wyłącznie z GU i GNP z kwalifikowanymi SSA, uzyskujące dostęp do pojedynczej bazy danych bez relacji logicznych i nie wykonujące wywołań hold/update są kandydatami o najniższym ryzyku we wczesnych falach migracji. Programy intensywnie korzystające z GN, uzyskujące dostęp do wielu baz danych poprzez relacje logiczne lub wykonujące złożone sekwencje hold/update są programami o najwyższym ryzyku, które wymagają najdokładniejszej analizy i walidacji przed migracją.
Co analiza zmienia w planowaniu migracji
Analiza zależności nie tylko dokumentuje to, co istnieje, ale także zmienia podejmowane w jej wyniku decyzje.
Decyzje dotyczące kolejności. Programy współdzielące bazy danych IMS poprzez relacje logiczne nie mogą być migrowane niezależnie. Jeśli program A odczytuje logiczny segment potomny, który ma logiczny segment nadrzędny w tej samej bazie danych co segment główny programu B, migracja programu A bez migracji programu B (lub utworzenia mostu) powoduje przerwanie migracji programu A. Graf zależności określa, które programy muszą zostać przeniesione razem.
Decyzje dotyczące projektu docelowego. Dystrybucja typów wywołań określa, jak powinien być ustrukturyzowany schemat relacyjny docelowy. Hierarchiczna relacja rodzic-dziecko, dostępna wyłącznie poprzez wywołania GU i GNP z kluczem kwalifikowanym, jest jednoznacznie przekładana na relację klucza obcego w obiekcie docelowym. Ta sama relacja, dostępna poprzez wywołania GN z zależnościami pozycyjnymi, wymaga, aby schemat docelowy zachował równoważną kolejność, albo poprzez jawne ORDER BY, pole sekwencji, albo inny wzorzec dostępu, który osiąga ten sam rezultat.
Decyzje dotyczące zakresu walidacji. Analiza identyfikuje, które programy są odbiorcami danych IMS w trybie tylko do odczytu, a które są procesorami transakcyjnymi. Programy w trybie tylko do odczytu można walidować, porównując wyniki wyjściowe między oryginalnym systemem IMS a systemem migrowanym. Procesory transakcyjne wymagają testowania równoważności transakcji, aby upewnić się, że ta sama sekwencja operacji na systemie docelowym powoduje zmiany stanu danych równoważne zmianom stanu danych w oryginale.
Klasyfikacja ryzyka. Logiczna relacja i wyniki indeksów wtórnych stanowią podstawowe dane wejściowe do klasyfikacji ryzyka. Każdy program migracji posiada rejestr ryzyka. Analiza zależności IMS informuje zespół, jakie wpisy należy w nim umieścić.
W jaki sposób SMART TS XL Wykonuje analizę zależności IMS
SMART TS XL'S statyczna analiza kodu Analizuje wywołania DL/I każdego programu COBOL, zarówno w formie interfejsu wywołań EXEC DLI, jak i xxxTDLI, wyodrębniając kod funkcji, referencję do PCB, nazwę segmentu i strukturę SSA z każdego wywołania. Generuje to rzeczywistą inwentaryzację wywołań na poziomie programu, w całym portfolio COBOL, bez konieczności uruchamiania systemu IMS lub ręcznego przeglądu kodu.
Mapowanie zależności aplikacji rozszerza ten inwentarz do grafu zależności międzyprogramowych: które programy mają wspólny dostęp do poszczególnych baz danych IMS, które programy korzystają z tych samych PCB, a wzorce dostępu programów nakładają się na siebie w sposób wymagający skoordynowanej migracji. Gdy logiczna relacja łączy segmenty w różnych bazach danych, mapa zależności reprezentuje to połączenie między bazami danych jako jawną relację, która musi zostać zachowana w systemie docelowym.
Funkcja analizy wpływu odpowiada na pytanie, na które musi odpowiedzieć każdy zespół migracyjny przed konwersją bazy danych: jeśli baza danych IMS zostanie przeniesiona, które programy zostaną objęte migracją, które wzorce dostępu należy zreplikować i które przypadki testowe należy zweryfikować w celu potwierdzenia równoważności. Odpowiedź nie jest szacunkiem, lecz listą enumerowaną pochodzącą z rzeczywistego inwentarza połączeń DL/I.
Możliwość rozszerzenia JCL dodaje kontekst operacyjny: które kroki zadań JCL wywołują które programy uzyskują dostęp do IMS, w jakiej kolejności i z jakimi specyfikacjami PSB. Łańcuch zależności operacyjnych, czyli sekwencja zadań wsadowych przetwarzająca dane IMS za pośrednictwem wielu programów, jest równie ważna dla planowania migracji, jak wzorce dostępu na poziomie programu. Migracja bazy danych bez migracji orkiestracji zadań wsadowych, która ją otacza, tworzy system, który poprawnie przetwarza rekordy w izolacji i ulega awarii w środowisku produkcyjnym po uruchomieniu sekwencji zadań.
Dla zespołów prowadzących modernizacja dziedziczna systemów wspieranych przez IMS, dowody strukturalne wytworzone przez SMART TS XL jest elementem wejściowym każdej kolejnej decyzji o migracji: które programy migrują w której fali, które bazy danych można konwertować niezależnie, a które wymagają skoordynowanej konwersji, które wzorce dostępu wymagają przebudowy architektury, a nie bezpośredniej translacji. Jak opisano w kontekście migracja struktur IMS i VSAM wraz z programami COBOL, powiązanie programów COBOL i starszych struktur danych oznacza, że migracja danych i analiza kodu muszą być przeprowadzane równolegle; inwentaryzacja zależności jest mechanizmem, który umożliwia równoległe planowanie.
Inwentaryzacja nie jest migracją
Analiza zależności IMS generuje wiedzę. Migracja nadal wymaga decyzji, inżynierii i walidacji. Analiza zmienia jakość decyzji, kompletność zakresu inżynierii oraz pewność walidacji.
Organizacje, które pomyślnie migrują bazy danych IMS, nie mają najbardziej napiętych harmonogramów ani największych budżetów na migrację. To one wiedziały, co mają, zanim rozpoczęły przenoszenie: każdy program uzyskujący dostęp do każdej bazy danych, każdy kod funkcji ujawniający wzorzec dostępu każdego programu, każdą relację logiczną tworzącą zależności między bazami danych, każdy indeks pomocniczy zapewniający ścieżkę dostępu, która nie przetrwałaby konwersji bez jawnej replikacji.
Ta wiedza nie pochodzi z dokumentacji. Pochodzi z analizy kodu.
