Analiza struktury plików VSAM na potrzeby projektów modernizacji danych

Migracja danych nie może odbywać się w izolacji, musi ewoluować równolegle z aplikacjami COBOL, które odczytują i zapisują te zbiory danych. To ograniczenie definiuje całe wyzwanie modernizacji VSAM. VSAM (Virtual Storage Access Method) to nie tylko format pliku. To kontrakt danych między programami, niejawna specyfikacja, nigdzie indziej niedefiniowana poza wpisami FD i klauzulami SELECT, która reguluje sposób, w jaki każdy program w systemie przedsiębiorstwa generuje i wykorzystuje swoje najważniejsze dane biznesowe. Pojedyncza zmiana układu rekordu, która nie jest odzwierciedlona w każdym programie odczytującym ten rekord, powoduje uszkodzenie danych, które może ujawnić się dopiero po uruchomieniu raportu regulacyjnego dla danych, które nie oznaczają już tego, czego oczekiwał program pobierający dane.

Organizacje, które odnoszą sukcesy w modernizacji danych VSAM, to nie te, które zaczynają od schematu docelowego. To te, które zaczynają od pełnego, opartego na dowodach zrozumienia zawartości plików VSAM, ich struktury, tego, które programy uzyskują do nich dostęp, w jakich wzorcach i jakie niejawne umowy istnieją między producentami a konsumentami. To zrozumienie, analiza struktury plików VSAM, jest warunkiem wstępnym każdej kolejnej decyzji: które zbiory danych VSAM mapują się na tabele relacyjne, które wymagają różnych architektur docelowych, które układy rekordów wymagają konwersji typów danych z zachowaniem precyzji oraz które współdzielone zbiory danych muszą migrować jako skoordynowane jednostki, a nie niezależnie.

Cztery organizacje VSAM i czego każda z nich wymaga

Zbiory danych VSAM występują w czterech odrębnych organizacjach. Każda z nich ma inną charakterystykę strukturalną, inny typowy wzorzec dostępu i inne naturalne odwzorowanie na nowoczesne architektury docelowe. Traktowanie wszystkich zbiorów danych VSAM identycznie, zbiorcze konwertowanie każdego z nich na tabelę relacyjną, powoduje, że cele działają dla niektórych zbiorów danych, a dla innych działają słabo lub nie spełniają swojej funkcji.

KSDS (Key-Sequenced Data Set) to najpopularniejsza organizacja VSAM. Rekordy są fizycznie uporządkowane według klucza podstawowego (primary key), co umożliwia zarówno bezpośredni dostęp według klucza, jak i dostęp sekwencyjny w kolejności kluczy. Pliki KSDS opcjonalnie zawierają indeksy alternatywne, czyli ścieżki kluczy drugorzędnych, które umożliwiają wyszukiwanie według pól innych niż klucz podstawowy. Naturalnym celem dla KSDS jest tabela relacyjna, w której klucz podstawowy staje się kluczem podstawowym, a indeksy alternatywne – indeksami SQL.

ESDS (ang. Entry-Sequenced Data Set) przechowuje rekordy w kolejności ich zapisu. Nie ma klucza, rekordy są adresowane za pomocą fizycznego przesunięcia bajtu (RBA: Relative Byte Address). Pliki ESDS są zazwyczaj używane do przechowywania danych o charakterze logicznym: śladów audytu, dzienników transakcji i strumieni zdarzeń. Naturalnym celem dla ESDS jest relacyjna tabela z możliwością dopisywania, strumień zdarzeń (temat Kafki) lub baza danych szeregów czasowych, w zależności od sposobu, w jaki programy uzyskują dostęp do danych.

RRDS (Relative Record Data Set) przechowuje rekordy o stałej długości adresowane względnym numerem rekordu. Każdy slot w pliku odpowiada numerowi rekordu; sloty mogą być puste (usunięte). Pliki RRDS są używane w scenariuszach z dostępem bezpośrednim, w których numer rekordu jest istotny dla aplikacji, często jako proste tabele odnośników lub pamięć oparta na skrótach. Naturalnym celem jest tabela relacyjna z numerycznym identyfikatorem sekwencji lub struktura wyszukiwania w pamięci, jeśli zbiór danych jest mały i często używany.

LDS (Linear Data Set) to pamięć masowa adresowana bajtowo, której struktura rekordów nie jest widoczna dla VSAM. Jest ona używana przez aplikacje (zazwyczaj DB2, obciążenia Java lub programy niestandardowe), które zarządzają własnym formatem wewnętrznym w zakresie bajtów VSAM. Plików LDS nie można analizować za pomocą standardowych wpisów COBOL FD, ich struktura istnieje tylko w warstwie aplikacji, która je zapisuje.

Wyniki analizy każdego zestawu danych muszą wskazywać, z jakiej organizacji korzysta, ponieważ to właśnie organizacja decyduje o wszystkim, co dzieje się dalej: architekturze docelowej, wzorcu dostępu i konkretnej analizie niezbędnej do zrozumienia jej struktury.

Problem analizy układu rekordów

Układ rekordów jest najbardziej złożonym analitycznie wymiarem analizy struktury VSAM. W przeciwieństwie do schematu relacyjnego, w którym każda kolumna ma zdefiniowany typ, nazwę i ograniczenie narzucone przez silnik bazy danych, rekordy VSAM nie posiadają samoopisującej się struktury. Układ istnieje w całości we wpisie FD w języku COBOL, a wpisy FD rzadko są proste.

Wpisy FD i członkowie COPY

Struktura rekordów zbioru danych VSAM jest zdefiniowana we wpisie FILE DESCRIPTION (FD) w COBOL DATA DIVISION. W dobrze utrzymanych bazach kodu wpis FD odwołuje się do elementu COPY, czyli współdzielonego repozytorium, które definiuje układ rekordów i jest uwzględniane przez każdy program uzyskujący dostęp do zbioru danych:

kobol

       FILE SECTION.
       FD  CUSTOMER-FILE
           LABEL RECORDS ARE STANDARD
           RECORD CONTAINS 250 CHARACTERS.
       01  CUSTOMER-RECORD.
           COPY CUSTMSTR.

Członek COPY CUSTMSTR definiuje rzeczywisty układ pola. Jeśli 47 programów obejmuje CUSTMSTR, wówczas 47 programów ma wspólną zależność od zdefiniowanego układu rekordów. Zmiana nazwy pola w CUSTMSTR dotyczy wszystkich 47. Jest to problem sprzężenia kopii zastosowany do danych: układ rekordów VSAM to współdzielona zależność, której nie można zmienić bez koordynacji każdego programu, który z niej korzysta.

Do analizy migracji, każdy wpis FD musi być powiązany z jego kopią, a każda kopia musi być zmapowana do każdego programu, który ją zawiera. Graf zależności w układzie współdzielonym stanowi podstawę zrozumienia zakresu migracji.

REDEFINIUJE: Wiele układów, jeden rekord

REDEFINES Klauzula REDEFINES to miejsce, w którym analiza rekordu VSAM staje się naprawdę złożona. REDEFINES pozwala różnym interpretacjom pól nakładać się na tę samą fizyczną pamięć. Rekord VSAM zawierający kod typu transakcji może użyć REDEFINES do odmiennej interpretacji pozostałych bajtów w zależności od tego kodu:

kobol

       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).

Ten rekord nie ma jednego układu, ale trzy, w zależności od TXN-TYPEW docelowym schemacie relacyjnym zazwyczaj wymaga to polimorficznej konstrukcji tabeli (pojedynczej, szerokiej tabeli z kolumnami dopuszczającymi wartości null dla każdego wariantu), znormalizowanej konstrukcji (wiersz nadrzędny i wiersze potomne specyficzne dla typu) lub kolumny JSON zawierającej dane wariantu. Żadnej z tych decyzji nie można podjąć bez analizy… TXN-TYPE wartości istnieją w danych i które warianty REDEFINES są faktycznie używane.

Kompleksowa analiza układu rekordu musi:

• Zidentyfikuj każdą hierarchię REDEFINES w każdym wpisie FD
• Określ, który wariant REDEFINES jest aktywny w jakich warunkach (wymaga analizy logiki programu, a nie tylko analizy FD)
• Udokumentuj typy pól, długości i precyzję dziesiętną dla każdego wariantu
• Zalecana jest odpowiednia strategia normalizacji dla schematu docelowego

COMP-3 i precyzja numeryczna

COBOL-e PIC S9(11)V99 COMP-3 (upakowane dane dziesiętne) ma specyficzne cechy precyzji i skali, które nie mają bezpośredniego odpowiednika w standardowych typach danych SQL. V oznacza domniemany przecinek dziesiętny, wartość jest przechowywana jako liczba całkowita z domniemaną skalą 2 miejsc dziesiętnych. COMP-3 pakuje dwie cyfry dziesiętne na bajt, przy czym ostatnia połowa bajtu zawiera znak.

Po przeniesieniu tego pola do relacyjnej bazy danych prawidłowym celem SQL jest DECIMAL(13, 2), Nie FLOAT, co wprowadziłoby błędy zaokrągleń, a nie INTEGER, co spowodowałoby utratę miejsc dziesiętnych. W systemach finansowych, w których pola COMP-3 przechowują kwoty pieniężne, wymóg precyzji nie podlega negocjacjom. Migracja, która konwertuje PIC S9(11)V99 COMP-3 do typu zmiennoprzecinkowego w schemacie docelowym wprowadza błędy zaokrągleń, które kumulują się podczas wykonywania partii i mogą mieć wpływ na raportowanie regulacyjne.

Każde pole COMP-3 w każdym wpisie FD musi zostać udokumentowane z uwzględnieniem dokładnej precyzji, skali i konwencji znaku przed rozpoczęciem projektowania schematu docelowego.

Analiza wzorców dostępu VSAM w źródle COBOL

Wpis FD opisuje zawartość rekordu. DZIAŁ PROCEDUR COBOL opisuje sposób, w jaki program go wykorzystuje. Oba są niezbędne do przeprowadzenia pełnej analizy strukturalnej. Analiza wzorców dostępu bada każdy czasownik dostępu do pliku w każdym programie, który ma kontakt ze zbiorem danych.

Klauzula SELECT: Pierwszy sygnał

Klauzula SELECT w rozdziale ENVIRONMENT DIVISION ustala, w jaki sposób program COBOL będzie uzyskiwał dostęp do pliku VSAM:

kobol

       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.

Ta klauzula SELECT ujawnia:

• ORGANIZATION IS INDEXED → KSDS
• ACCESS MODE IS DYNAMIC → program wykorzystuje zarówno dostęp sekwencyjny, jak i losowy
• ALTERNATE RECORD KEY IS CUST-ALT-KEY WITH DUPLICATES → istnieje alternatywny indeks i ten program go używa

Szczególnie istotny jest tryb dostępu dynamicznego: program uzyskujący dostęp do KSDS w trybie DYNAMICZNYM może używać READ z kluczem umożliwiającym bezpośredni dostęp i READ NEXT do sekwencyjnego skanowania z punktu pozycjonowanego. Oba wzorce dostępu muszą być replikowane w systemie docelowym, co może wymagać obsługi zarówno bezpośredniego wyszukiwania (zapytanie o klucz podstawowy), jak i skanowania zakresu (uporządkowane przechodzenie) w schemacie relacyjnym.

Czasowniki dostępu i ich implikacje migracyjne

Każdy rozkaz dostępu do pliku ujawnia inny wymiar interakcji programu ze zbiorem danych VSAM:

CZYTAJ (bezpośrednio): READ CUSTOMER-FILE KEY IS WS-CUST-KEY, bezpośrednie wyszukiwanie klucza. Mapy do SELECT ... WHERE primary_key = ?Większość programów KSDS wykorzystuje ten wzorzec; przekłada się on bezpośrednio na relacyjne wyszukiwanie indeksowane.

CZYTAJ (sekwencyjnie): READ CUSTOMER-FILE NEXT RECORD, sekwencyjne skanowanie z bieżącej pozycji. Mapy do SELECT ... ORDER BY primary_key z pozycjonowaniem kursora. Ukryta zależność kolejnościowa – programy, które wykorzystują naturalną kolejność kluczy VSAM do przetwarzania sekwencyjnego, muszą być jawnie zachowane w systemie docelowym.

POCZĄTEK: START CUSTOMER-FILE KEY >= WS-SEARCH-KEY następnie READ NEXT, skanowanie zakresu z częściowej pozycji klucza. Mapowanie na zapytanie o zakres: SELECT ... WHERE primary_key >= ? ORDER BY primary_keyProgramy używające START ustalają dolną granicę dla skanowania sekwencyjnego. Jest to krytyczny wzorzec dostępu dla plików KSDS, który nie ma prostego odpowiednika, chyba że tabela docelowa ma taką samą kolejność kluczy.

PISAĆ: Wstawia nowy rekord według klucza. Mapuje do INSERT INTOJeśli plik VSAM ma alternatywne indeksy, zapis musi zachować spójność z tymi indeksami. W VSAM dzieje się to automatycznie. W relacyjnej bazie danych wymagany jest wyzwalacz bazy danych lub kod na poziomie aplikacji, aby zachować równoważne tabele indeksów drugorzędnych.

PRZEPISAĆ: Aktualizuje rekord w miejscu. Rekord musi być aktualnie przechowywany (po ODCZYCIE z intencją wstrzymania). Mapuje do UPDATE ... WHERE primary_key = ?. REWRITE to wzorzec odczytu-modyfikacji-zapisu; migracja musi zachować integralność transakcji podczas odczytu i zapisu.

DELETE: Usuwa rekord według klucza. W plikach KSDS DELETE to fizyczne usunięcie. Programy, które oczekują, że usunięty slot będzie niedostępny dla przyszłych sekwencyjnych skanowań, polegają na tym fizycznym zachowaniu usuwania. Miękkie usunięcie (flaga logicznego usuwania) w miejscu docelowym nie powoduje równoważnego zachowania, chyba że każdy program pobierający rekord zostanie zaktualizowany w celu filtrowania logicznie usuniętych rekordów.

Alternatywne użycie indeksu: ukryta zależność

Indeksy alternatywne w plikach KSDS to jedna z najczęściej pomijanych zależności w migracji VSAM. Indeks alternatywny umożliwia programowi dostęp do KSDS za pomocą pola innego niż klucz główny. Indeks alternatywny sam w sobie jest oddzielnym zestawem danych VSAM (ścieżką PATH), który musi być utrzymywany w synchronizacji z klastrem bazowym.

Program, który uzyskuje dostęp CUSTOMER-FILE poprzez swój klucz alternatywny CUST-ALT-KEY ma zależność, która jest niewidoczna, jeśli analizowany jest tylko wpis FD klastra bazowego. Migracja musi:

1. Określ, które programy używają poszczególnych kluczy alternatywnych (widocznych w klauzuli SELECT) ALTERNATE RECORD KEY deklaracje)
2. Przypisz każdy klucz alternatywny do odpowiedniego indeksu SQL w tabeli docelowej
3. Upewnij się, że operacje INSERT i DELETE w tabeli docelowej automatycznie zachowują odpowiednik indeksu alternatywnego, zazwyczaj za pomocą unikatowych lub nieunikalnych indeksów SQL, które moduł bazy danych utrzymuje transparentnie

Analiza musi wyliczyć wszystkie indeksy alternatywne dla każdego zestawu danych KSDS i zamapować każdy z nich na programy, które go wykorzystują.

Problem współdzielonego zbioru danych: niejawne kontrakty danych

Pliki VSAM są często współdzielone przez wiele programów i wiele etapów zadań JCL. To współdzielone tworzy niejawne kontrakty danych – umowy między programami dotyczące układu rekordów, zakresów kluczy i wzorców dostępu, które nie istnieją nigdzie poza samym kodem.

Zależność współdzielonego zbioru danych ma dwa wymiary:

Relacje producent-konsument. Program A zapisuje rekordy, które Program B odczytuje. Układ rekordów, wartości kluczy i kolejność generowana przez Program A muszą dokładnie odpowiadać temu, co Program B spodziewa się skonsumować. Jeśli A i B zostaną niezależnie zmigrowane do różnych schematów docelowych bez koordynacji współdzielonego kontraktu danych, rezultatem jest ukryte uszkodzenie danych: odczyty B z docelowej bazy danych kończą się powodzeniem, ale zwracają dane w formacie, którego logika B nie obsługuje poprawnie.

Równoczesny dostęp między etapami zadania. Strumień zadań JCL może składać się z wielu etapów, z których każdy uruchamia inny program na tym samym zestawie danych VSAM w sekwencji. Etap 1 zapisuje dane, etap 2 odczytuje i transformuje dane, etap 3 zapisuje wyniki. Migracja musi zachować tę sekwencyjną zależność, a kolejność, w jakiej programy uzyskują dostęp do współdzielonego zestawu danych i go modyfikują, jest częścią specyfikacji behawioralnej systemu.

Pełna analiza współdzielonego zbioru danych musi:

• Wypisz każdy zestaw danych VSAM i każdy program, który uzyskuje do niego dostęp
• Klasyfikuj dostęp każdego programu jako producenta (ZAPISZ/PRZEPISZ/USUWAJ), konsumenta (ODCZYT) lub oba
• Udokumentuj kontekst zadania JCL, w którym uruchamiany jest każdy program, który krok, w którym zadaniu, w którym łańcuchu zależności harmonogramu
• Zidentyfikuj pary producent-konsument, w których format wyjściowy producenta musi dokładnie odpowiadać oczekiwanemu formatowi wejściowemu konsumenta.

Tej analizy nie da się przeprowadzić, badając dowolny program w izolacji. Wymaga ona analizy strukturalnej obejmującej wiele programów i JCL.

Elementy dostarczane przed migracją: co musi wygenerować analiza

Analiza strukturalna VSAM wystarczająca do zaplanowania modernizacji danych generuje sześć produktów:

Dostarczany element 1: Inwentaryzacja zbioru danych VSAM

Każdy zestaw danych VSAM w środowisku, zawierający: organizację zestawu danych (KSDS/ESDS/RRDS/LDS), średnią i maksymalną długość rekordu, szacowaną liczbę rekordów (na podstawie parametrów JCL SPACE lub wpisów katalogu), strukturę klucza (przesunięcie klucza głównego, długość, alternatywne struktury klucza) oraz informację, czy zestaw danych ma alternatywne indeksy.

Przedmiot dostawy 2: Katalog układów rekordów

Dla każdego zestawu danych, każdego wpisu FD i podręczników, do których się odwołuje, ze wszystkimi definicjami pól, w tym hierarchiami REDEFINES, każdym polem COMP-3 z jego dokładną precyzją i skalą, każdym polem binarnym (COMP/COMP-5) z jego długością w bajtach, każdym elementem o zmiennej długości (OCCURS DEPENDING ON z jego polem sterującym) i każdym wariantem warunkowym lub układowym sugerowanym przez REDEFINES.

Przedmiot dostawy 3: Klasyfikacja wzorców dostępu według programu

Dla każdego programu uzyskującego dostęp do każdego zestawu danych: charakterystyka klauzuli SELECT (organizacja, tryb dostępu, użycie klucza alternatywnego), kompletny zestaw użytych czasowników dostępu (ODCZYT/START/ZAPIS/PRZEPISZ/USUWANIE), informacja, czy program korzysta z dostępu sekwencyjnego i zależy od kolejności kluczy, jakich indeksów alternatywnych używa program oraz czy program ma wzorce odczytu-modyfikacji-zapisu (wymagania niejawnych transakcji).

Przedmiot dostawy 4: Mapa współdzielonego zbioru danych

Graf skierowany, w którym węzły to zbiory danych i programy VSAM, a krawędzie reprezentują relacje dostępu z ich typem (odczyt/zapis). Graf przedstawia każdego producenta, każdego konsumenta, pary producent-konsument oraz kontekst sekwencji zadań JCL dla każdego dostępu.

Przedmiot 5: Rekomendacje dotyczące schematu docelowego

Zalecana architektura docelowa dla każdego zestawu danych VSAM oparta na jego organizacji i wzorcach dostępu:

Typ VSAM	Podstawowy wzorzec dostępu	Zalecany cel
KSDS, dostęp tylko za pomocą klucza bezpośredniego	Wyszukiwanie punktów według klucza podstawowego	Tabela relacyjna, indeksowana
KSDS z opcją START/CZYTAJ DALEJ	Skanowanie zasięgu w kolejności kluczowej	Tabela relacyjna z indeksem klastrowym
KSDS z indeksami alternatywnymi	Dostęp do klucza wielościeżkowego	Tabela relacyjna z wieloma indeksami
ESDS, tylko do dołączania	Dołączanie sekwencyjne, bez klucza	Tabela, strumień zdarzeń lub dziennik tylko do dołączenia
ESDS z dostępem RBA	Pozycjonowanie przesunięcia bajtów	Przechowywanie obiektów z indeksem metadanych
RRDS	Dostęp do numeru rekordu	Tabela relacyjna z kolumną sekwencji
Duże KSDS (hurtowe, analityczne)	Pełne sekwencyjne skanowanie	Magazyn kolumnowy lub jezioro danych
LDS	Format wewnętrzny zarządzany przez aplikację	Wymaga analizy warstwy aplikacji

Przedmiot dostawy 6: Rejestr terenowy wrażliwy na precyzję

Każde pole COMP-3, COMP, COMP-5 i pole zmiennoprzecinkowe w każdym zestawie danych, wraz z definicją COBOL, poprawnym mapowaniem typów danych SQL i flagą dla każdego pola, którego mapowanie wymaga walidacji precyzji przed i po migracji.

Czym analiza VSAM różni się od analizy schematów relacyjnych

Zespoły posiadające doświadczenie w migracji między relacyjnymi bazami danych czasami niedoceniają analizy VSAM, ponieważ stosują mentalny model migracji schematu: wyodrębniają DDL, przeprojektowują schemat, migrują dane. VSAM nie posiada DDL w rozumieniu bazy danych. Schemat jest rozproszony w kodzie źródłowym, we wpisach FD, w copybookach, w klauzulach SELECT oraz w logice PROCEDURE DIVISION, która określa, który wariant REDEFINES jest aktywny dla danego rekordu.

Analiza VSAM różni się strukturalnie trzema właściwościami:

Schemat znajduje się w kodzie. Układ rekordów dla zbioru danych VSAM jest zdefiniowany w kodzie źródłowym COBOL, a nie w katalogu bazy danych. Znalezienie go wymaga analizy kodu źródłowego. Jego zmiana wymaga koordynacji wszystkich programów współdzielących ten zbiór. Zrozumienie wszystkich jego wariantów wymaga analizy logiki programu, a nie tylko wpisu w katalogu FD.

Wzorce dostępu są niejawne w zachowaniu programu. Relacyjna baza danych ujawnia wzorce zapytań za pomocą planów EXPLAIN i logów zapytań. Wzorce dostępu VSAM są widoczne tylko w PROCEDURE DIVISION programów uzyskujących dostęp do pliku. Zrozumienie, czy program zależy od kolejności kluczy, alternatywnego dostępu do indeksu, czy skanowania zakresów, wymaga analizy kodu.

Współdzielone zbiory danych tworzą ukryte kontrakty. W relacyjnej bazie danych schemat jest artefaktem na poziomie bazy danych, który jest współdzielony i widoczny dla wszystkich użytkowników. W VSAM układ rekordów jest osadzony w kopii zapasowej każdego programu. Dwa programy mogą mieć rozbieżne kopie tego, co nominalnie jest tym samym układem rekordów, a odkrycie tej rozbieżności wymaga porównania definicji kopii zapasowej w różnych programach, a nie analizy pojedynczej definicji schematu.

W jaki sposób SMART TS XL Wykonuje analizę strukturalną VSAM

SMART TS XL'S statyczna analiza kodu Analizuje każdy element struktury VSAM istniejący w kodzie źródłowym COBOL: wpisy FD, rozszerzenia elementów COPY, deklaracje klauzuli SELECT (organizacja, tryb dostępu, specyfikacje klucza podstawowego i alternatywnego) oraz każdy czasownik dostępu do pliku w PROCEDURE DIVISION. Dla każdego zestawu danych VSAM analiza generuje klasyfikację wzorca dostępu, układ rekordów z pełnym rozwiązaniem REDEFINES oraz rejestr pól COMP-3 z precyzyjnymi metadanymi.

Mapowanie zależności aplikacji tworzy mapę współdzielonego zbioru danych: każdy program uzyskujący dostęp do każdego zbioru danych VSAM, sklasyfikowany według typu dostępu, ze zidentyfikowanymi relacjami producent-konsument i rozwiązanym grafem współdzielenia kopii. Gdy 47 programów współdzieli kopię definiującą układ rekordów VSAM, mapa zależności sprawia, że ​​wszystkie 47 programów jest widocznych przed podjęciem decyzji o migracji, a nie po tym, jak zmiana układu spowoduje nieoczekiwane uszkodzenie 47 programów.

Możliwość rozszerzenia JCL zapewnia kontekst operacyjny: które kroki zadania JCL odwołują się do których zestawów danych VSAM w swoich instrukcjach DD, w jakiej kolejności i w których strumieniach zadań. Relacje producent-konsument istniejące na poziomie zadania JCL, gdzie krok 1 zapisuje do zestawu danych VSAM, który krok 3 odczytuje, są widoczne w analizie zależności JCL, umożliwiając sekwencjonowanie migracji z zachowaniem zależności kolejności operacyjnej wymuszanej przez harmonogram wsadowy.

Funkcja analizy wpływu odpowiada na pytanie poprzedzające każdą decyzję o migracji VSAM: jeśli układ tego zestawu danych ulegnie zmianie, które programy zostaną nią dotknięte? Zakres wpływu, każdy program współdzielący odpowiedni copybook, każdy krok JCL odwołujący się do zestawu danych – wszystko to jest wyszczególnione przed rozpoczęciem jakichkolwiek prac migracyjnych, co stanowi podstawę skoordynowanego planowania migracji, zamiast odkrywania uszkodzonych programów pojedynczo.

Funkcja wyszukiwania w przedsiębiorstwie umożliwia przeszukiwanie całego inwentarza VSAM w trakcie całego programu modernizacji: znajdź każdy program uzyskujący dostęp do określonego zestawu danych VSAM, każdy copybook definiujący konkretny układ rekordów, każdy program używający wzorców START/READ NEXT (oznaczających zależności kolejnościowe), każde pole zdefiniowane jako COMP-3 (wymagające mapowania docelowego uwzględniającego precyzję) w ciągu kilku sekund, w milionach wierszy kodu COBOL.

Jak opisano w kontekście migracja struktur danych IMS i VSAM wraz z programami COBOLmigracja danych i analiza kodu muszą przebiegać równolegle. SMART TS XLStrukturalna analiza VSAM firmy Microsoft zapewnia inwentaryzację umożliwiającą realizację paralelizmu, współdzielone układy rekordów, wzorce dostępu i relacje producent-konsument, które decydują o tym, czy migracja danych może przebiegać niezależnie, czy też musi być skoordynowana ze zmianami w programie.

Struktura, którą rozumiesz, jest strukturą, którą możesz migrować

Analiza struktury plików VSAM nie stanowi dodatkowego obciążenia w programie modernizacji. Stanowi podstawę podejmowania decyzji. Schematu docelowego nie można zaprojektować bez znajomości wariantów układu rekordów. Migracji nie można zaplanować bez znajomości relacji producent-konsument. Precyzji pól COMP-3 nie można zachować bez wiedzy, które pola wymagają typów docelowych uwzględniających miejsca dziesiętne.

Każdy program modernizacyjny, który pomija tę analizę, odkrywa to, co przeoczył podczas migracji: gdy wariant REDEFINES, który nie został przeanalizowany, generuje nieprawidłowe rekordy w systemie docelowym, gdy współdzielony zestaw danych jest migrowany bez koordynacji wszystkich jego odbiorców, gdy skanowanie zakresu oparte na kolejności kluczy VSAM zwraca wynik w postaci niezdefiniowanej kolejności z tabeli docelowej, która nie została zaprojektowana z indeksem klastrowym. Koszt tych odkryć podczas realizacji jest wielokrotnością kosztów analizy na etapie planowania.

Najpierw zrozum strukturę. Następnie przeprowadź migrację danych. Kolejność nie jest formalnością. To różnica między migracją, która daje poprawne wyniki, a taką, która generuje dane wyglądające poprawnie aż do pierwszego audytu regulacyjnego.