Każdy komputer mainframe w przedsiębiorstwie korzysta z dwóch powiązanych ze sobą języków programowania, których większość współczesnych programistów nigdy nie napisała. COBOL implementuje logikę biznesową, obliczenia, przetwarzanie plików, transformacje rekordów i raportowanie regulacyjne. JCL (Job Control Language) koordynuje wykonywanie tej logiki, definiując, które programy są uruchamiane, w jakiej kolejności, z jakimi plikami, w jakich warunkach oraz co się dzieje w przypadku ich powodzenia lub niepowodzenia. Żaden z języków nie jest kompletny bez drugiego. Program COBOL nie ma pojęcia, skąd pochodzą jego pliki wejściowe ani dokąd trafiają dane wyjściowe; JCL odpowiada na oba te pytania przed odczytaniem pierwszego rekordu.
Dla organizacji zajmujących się konserwacją, audytem lub modernizacją systemów mainframe, zrozumienie relacji JCL-COBOL nie jest opcjonalną wiedzą wstępną. Jest to warunek wstępny do wszystkiego: analizy wpływu przed wprowadzeniem jakichkolwiek zmian, dokumentacji przed migracją, transferu wiedzy przed przejściem ekspertów na emeryturę. Zadanie polegające na przetwarzaniu nocnych rozliczeń, przetwarzanie wsadowe generujące kwartalne raporty regulacyjne, procedura przesyłania danych z jednego systemu do drugiego – wszystkie te procesy są definiowane przez JCL, wykonywane przez COBOL i zrozumiałe tylko dla kurczącej się grupy inżynierów, którzy pracowali z obydwoma językami.
Czym jest JCL?
JCL to skrót od Job Control Language (Język Kontroli Zadań). Jest to język skryptowy używany w systemach mainframe IBM do przesyłania zadań wsadowych do wykonania. JCL sam w sobie nie przetwarza danych. Informuje system operacyjny, jak uruchamiać programy: który program uruchomić, jakie pliki udostępnić, jaką pamięć i zasoby procesora przydzielić, co zrobić w przypadku niepowodzenia kroku oraz w jakiej kolejności uruchamiać wiele kroków w ramach jednego zadania.
Każda oferta pracy w JCL składa się z trzech podstawowych typów oświadczeń:
Polecenie JOB identyfikuje zadanie w systemie i definiuje parametry rozliczeniowe, priorytetowe i harmonogramowania.
Instrukcja EXEC określa program lub procedurę, która ma zostać wykonana w danym kroku.
Instrukcja DD (Data Definition) definiuje zestawy danych, które program będzie odczytywał lub zapisywał, w tym ich lokalizację, format i sposób rozdysponowania.
jkl
//PAYBATCH JOB (ACCT#7), 'PAYROLL RUN',
// CLASS=A, MSGCLASS=X, NOTIFY=&SYSUID
//*
//STEP010 EXEC PGM=PAYROLL1
//STEPLIB DD DSN=PROD.PAYROLL.LOADLIB,DISP=SHR
//EMPFILE DD DSN=PROD.PAYROLL.EMPLOYEE,DISP=SHR
//TRANSACT DD DSN=PROD.PAYROLL.TRANS.D&&DATE,DISP=SHR
//PAYRPT DD SYSOUT=A
//SYSOUT DD SYSOUT=*
//SYSIN DD DUMMYW tym przykładzie: PAYBATCH to nazwa stanowiska, STEP010 to jeden etap pracy, PGM=PAYROLL1 Nazywa program COBOL do wykonania, a instrukcje DD definiują każdy plik, do którego program może uzyskać dostęp. Program COBOL PAYROLL1 nie wie i nie obchodzi go gdzie EMPFILE or TRANSACT Jeśli pochodzą fizycznie, po prostu odczytuje je po nazwie ddname. JCL ustala fizyczną lokalizację, format rekordu i tryb dostępu przed rozpoczęciem wykonywania.
Procedury katalogowane JCL (PROC)
Zamiast pisać ten sam wzorzec JCL dla każdego zadania, zespoły mainframe definiują procedury katalogowane (PROC), które hermetyzują wzorce wielokrotnego użytku. PROC to szablon przechowywany w bibliotece procedur; poszczególne zadania odwołują się do niego i w razie potrzeby nadpisują określone parametry.
jkl
//PAYPROC PROC RUNDATE=TODAY
//COMPILE EXEC PGM=IGYCRCTL,PARM='OBJECT,NODUMP'
//SYSIN DD DSN=PROD.COBOL.SRC(&MEMBER),DISP=SHR
//SYSOBJ DD DSN=&&OBJSET,DISP=(NEW,PASS),
// UNIT=SYSDA,SPACE=(TRK,(10,5))
//LKED EXEC PGM=IEWL,PARM='LIST,LET,XREF'
//SYSLIN DD DSN=&&OBJSET,DISP=(OLD,DELETE)
//SYSLMOD DD DSN=PROD.PAYROLL.LOADLIB(&MEMBER),
// DISP=SHR
// PENDWywołanie procedury PROC z zadania:
jkl
//COMPILE EXEC PAYPROC,MEMBER=PAYROLL1,RUNDATE=20251205To pojedyncze polecenie EXEC rozszerza się w pełną instrukcję PROC w momencie wykonania, MEMBER oraz RUNDATE podstawiony gdziekolwiek &MEMBER oraz &RUNDATE PROC-i są jednym z głównych powodów złożoności mapowania JCL na COBOL: zadanie może wywołać dziesiątki programów COBOL za pośrednictwem jednego odwołania do PROC, a faktyczne wywoływane programy zależą od parametrów symbolicznych, które zmieniają się w zależności od przebiegu.
Jaka jest różnica między JCL i COBOL?
JCL i COBOL są często wymieniane razem, ale pełnią zupełnie różne role. Żaden z nich nie zastępuje drugiego, a oba są niezbędne do działania przetwarzania wsadowego na komputerach mainframe.
| Wymiary | JCL | COBOL |
|---|---|---|
| Cel | Orkiestruje wykonanie | Implementuje logikę biznesową |
| Co definiuje | Zadania, kroki, pliki, warunki | Programy, struktury danych, obliczenia |
| Kiedy działa | Przed wykonaniem programu (konfiguracja) i po (czyszczenie) | Podczas wykonywania programu |
| Odczytuje/zapisuje dane | Poprzez alokację zbioru danych (instrukcje DD) | Za pomocą instrukcji FILE SECTION i READ/WRITE |
| Obsługa błędów | Kody powrotu, warunkowe wykonanie kroku | Obsługa WYJĄTKÓW, procedury błędów PERFORM |
| Przenośność | Specyficzne dla IBM z/OS | Przenośny między platformami za pomocą kompilatorów |
| Kto to pisze? | Programiści systemowi, inżynierowie wsadowi | Twórcy aplikacji |
| Współczesny odpowiednik | Proces CI/CD + orkiestracja kontenerów | Kod aplikacji (Java, Python, C++) |
Najprostszy sposób na zobrazowanie tej relacji: JCL to warstwa wdrażania i koordynacji; COBOL to warstwa aplikacji. W nowoczesnym systemie chmurowym rolę JCL pełniłyby manifesty zadań Kubernetes, skrypty powłoki oraz etapy potoku CI/CD. Rolę COBOL-a pełniłyby usługi aplikacji napisane w Javie, Pythonie lub Go.
Jak JCL wywołuje COBOL: Łańcuch wykonania
Ścieżka od zadania JCL do wykonania kodu COBOL przebiega w spójnym łańcuchu. Zrozumienie każdego kroku stanowi podstawę zrozumienia, co musi uwzględniać mapa JCL-COBOL.
Krok 1: Przesłanie zadania. Zadanie JCL jest przesyłane do Podsystemu Wprowadzania Zadań (JES). JES umieszcza zadanie w kolejce i rozpoczyna odczytywanie jego instrukcji.
Krok 2: Konfiguracja kroku. Dla każdego kroku EXEC system lokalizuje nazwany program w bibliotece ładowania określonej przez instrukcję STEPLIB DD. Jeśli nie określono biblioteki STEPLIB, system przeszukuje bibliotekę linków systemowych.
Krok 3: Alokacja zbiorów danych. Przed uruchomieniem programu system alokuje wszystkie zbiory danych zdefiniowane w tym kroku za pomocą instrukcji DD. Obejmuje to otwieranie plików, weryfikację istnienia zbiorów danych wejściowych oraz tworzenie zbiorów danych wyjściowych.
Krok 4: Wykonanie programu. Program COBOL jest uruchamiany. Uzyskuje dostęp do plików za pomocą nazw ddname zdefiniowanych w JCL, OPEN INPUT EMPFILE w COBOL-u mapuje bezpośrednio do polecenia DD o nazwie EMPFILE w JCL.
Krok 5: Ocena kodu zwrotnego. Po zakończeniu programu COBOL ustawia kod powrotu (zwykle 0 w przypadku powodzenia, 4 w przypadku ostrzeżenia, 8 w przypadku błędu, 12 lub 16 w przypadku poważnego błędu). JCL używa COND parametry lub IF/THEN/ELSE Konstrukcje służące do określania, czy kolejne kroki powinny zostać wykonane na podstawie tego kodu.
Krok 6: Dyspozycja zbioru danych. Po tym kroku system przetwarza dyspozycje zbioru danych zdefiniowane w każdym poleceniu DD: zachowaj, usuń, skataloguj, usuń z katalogu lub przekaż do następnego kroku.
Poniższy przykład pokazuje, jak ten łańcuch wygląda w praktyce, JCL po lewej, a odpowiadające mu elementy COBOL po prawej:
jkl
//STEP020 EXEC PGM=ACCTREC
//STEPLIB DD DSN=PROD.ACCOUNT.LOADLIB,DISP=SHR
//INFILE DD DSN=PROD.ACCT.DAILY.INPUT,DISP=SHR ← maps to COBOL SELECT/ASSIGN
//OUTFILE DD DSN=PROD.ACCT.PROCESSED, ← maps to COBOL SELECT/ASSIGN
// DISP=(NEW,CATLG,DELETE),
// UNIT=SYSDA,SPACE=(CYL,(5,2),RLSE)
//RPTFILE DD SYSOUT=A ← maps to COBOL WRITE report
//SYSOUT DD SYSOUT=*Program COBOL ACCTREC zawiera:
kobol
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT INFILE ASSIGN TO INFILE. *> maps to DD INFILE
SELECT OUTFILE ASSIGN TO OUTFILE. *> maps to DD OUTFILE
SELECT RPTFILE ASSIGN TO RPTFILE. *> maps to DD RPTFILE
DATA DIVISION.
FILE SECTION.
FD INFILE
RECORDING MODE IS F
BLOCK CONTAINS 0 RECORDS
RECORD CONTAINS 200 CHARACTERS.
01 ACCOUNT-RECORD.
05 ACCT-NUMBER PIC X(10).
05 ACCT-BALANCE PIC S9(13)V99 COMP-3.
05 ACCT-STATUS PIC X(2). SELECT INFILE ASSIGN TO INFILE w sekcji FILE-CONTROL języka COBOL łączy się z poleceniem DD o nazwie INFILE w JCL. To jest podstawowa relacja mapowania: COBOL używa logicznych nazw plików; JCL przekształca je na fizyczne zestawy danych.
Kody Abend JCL: co oznaczają
Kody JCL „abend” (nieprawidłowe kody zakończenia) identyfikują przyczynę nieoczekiwanego zakończenia kroku zadania. Pojawiają się w wynikach zadania jako S000 (system nie działa) lub U0000 (kody przerwania pracy użytkownika). Ich zrozumienie jest niezbędne do diagnozowania błędów zadań wsadowych.
| Kod Abend | Typ | Popularny przypadek |
|---|---|---|
| S001 | Konfiguracja | Błąd wejścia/wyjścia podczas odczytu lub zapisu zestawu danych |
| S013 | Konfiguracja | Niezgodność atrybutów DCB, niezgodność długości rekordu lub formatu pomiędzy JCL DD i COBOL FD |
| S0C4 | Konfiguracja | Wyjątek ochrony pamięci masowej, program próbował uzyskać dostęp do pamięci poza przydzielonym obszarem |
| S0C7 | Konfiguracja | Wyjątek danych, próba wykonania operacji arytmetycznej na danych nieliczbowych (bardzo częste przerwanie działania w języku COBOL) |
| S322 | Konfiguracja | Przekroczono limit czasu, zadanie trwało dłużej niż pozwalał parametr TIME |
| S806 | Konfiguracja | Nie znaleziono modułu ładowania, program o nazwie EXEC PGM= nie znajduje się w żadnej przeszukanej bibliotece ładowania |
| S913 | Konfiguracja | Naruszenie bezpieczeństwa dostępu do zbioru danych, odmowa dostępu przez RACF lub równoważny system |
| U0000 | System Rezerwacji Sal Smart Spaces® rozwiązuje problem zarządzania rezerwacjami sal, biurek i przestrzeni wspólnych. Zmiany w ostatniej chwili są od razu widoczne, co ułatwia pracę recepcji i użytkownikom. Kalendarz w czasie rzeczywistym pokazuje wolne zasoby, ich parametry, a nawet zaplanowane sprzątanie. | Zdefiniowany przez aplikację program COBOL o nazwie STOP RUN z kodem użytkownika |
| U4076 | System Rezerwacji Sal Smart Spaces® rozwiązuje problem zarządzania rezerwacjami sal, biurek i przestrzeni wspólnych. Zmiany w ostatniej chwili są od razu widoczne, co ułatwia pracę recepcji i użytkownikom. Kalendarz w czasie rzeczywistym pokazuje wolne zasoby, ich parametry, a nawet zaplanowane sprzątanie. | Nieprawidłowe zakończenie specyficzne dla IMS, błąd dostępu do bazy danych |
Najczęstsza produkcja abend, S0C7, występuje, gdy program COBOL próbuje wykonać obliczenia arytmetyczne na polu zawierającym spacje lub znaki nienumeryczne. Typową przyczyną jest niezgodność między oczekiwanym formatem danych w programie COBOL a rzeczywistymi danymi dostarczonymi przez JCL, co jest dokładnie tym rodzajem rozbieżności, którą ujawnia mapowanie JCL na COBOL, zanim spowoduje awarię produkcyjną o północy.
Parametr COND i wykonanie warunkowe
JCL kontroluje, które kroki zostaną wykonane na podstawie kodów zwrotnych z poprzednich kroków, korzystając z COND parametr:
jkl
//STEP010 EXEC PGM=VALIDATE,COND=(4,LT)
//STEP020 EXEC PGM=PROCESS, COND=(4,LT,STEP010)
//STEP030 EXEC PGM=CLEANUP, COND=(0,NE,STEP010)COND=(4,LT) oznacza: pomiń ten krok, jeśli kod powrotu któregokolwiek z poprzednich kroków jest mniejszy niż 4. COND=(4,LT,STEP010) oznacza: pomiń ten krok, jeśli kod powrotu STEP010 jest mniejszy niż 4. COND=(0,NE,STEP010) oznacza: pomiń STEP030, jeśli kod zwrotny STEP010 nie jest równy 0, tzn. uruchom czyszczenie tylko wtedy, gdy STEP010 zakończył się powodzeniem.
Nowoczesne JCL wykorzystuje IF/THEN/ELSE/ENDIF zamiast tego skonstruuj, co jest bardziej czytelne:
jkl
//IF010 IF (STEP010.RC = 0) THEN
//STEP020 EXEC PGM=PROCESS
// ENDIF
//IF020 IF (STEP010.RC > 4) THEN
//STEP030 EXEC PGM=ERRORHANDLER
// ENDIFMapowanie ścieżek wykonywania warunkowego jest jednym z najważniejszych i najczęściej pomijanych elementów analizy JCL-COBOL. Program COBOL, który uruchamia się tylko wtedy, gdy poprzedni krok zakończy się niepowodzeniem, może obsługiwać błędy, logikę wycofywania lub procedury odzyskiwania – funkcjonalność całkowicie niewidoczną, jeśli spojrzymy tylko na kod źródłowy COBOL bez JCL, który nim steruje.
JCL, COBOL i DB2: stos trójwarstwowy
Większość systemów transakcyjnych komputerów mainframe zawiera trzeci komponent, obok JCL i COBOL: DB2, relacyjną bazę danych IBM. Programy w COBOL uzyskują dostęp do DB2 za pomocą wbudowanych instrukcji SQL (bloków EXEC SQL). JCL zarządza połączeniem z podsystemem DB2 i modułem żądań bazy danych (DBRM) za pomocą określonych instrukcji DD.
jkl
//DBRM DD DSN=PROD.DBRMLIB.DATA(ACCTREC),DISP=SHR
//SYSPRINT DD SYSOUT=*kobol
WORKING-STORAGE SECTION.
EXEC SQL
INCLUDE SQLCA
END-EXEC.
PROCEDURE DIVISION.
MAIN-LOGIC.
EXEC SQL
SELECT ACCT_BALANCE, ACCT_STATUS
INTO :WS-BALANCE, :WS-STATUS
FROM ACCOUNT_MASTER
WHERE ACCT_NUMBER = :WS-ACCT-NUM
END-EXEC.
IF SQLCODE NOT = 0
PERFORM DB2-ERROR-ROUTINE
END-IF.W stosie JCL-COBOL-DB2, JCL zapewnia środowisko wykonawcze i dostęp do zbiorów danych; COBOL implementuje logikę biznesową i wywołuje bazę danych; DB2 przechowuje i pobiera dane zgodnie z kodem SQL wbudowanym w program COBOL. Pełna mapa zależności dowolnego programu COBOL korzystającego z DB2 musi uwzględniać nie tylko to, które zadania JCL go wywołują, ale także to, które tabele DB2 odczytuje i zapisuje, do których kolumn uzyskuje dostęp oraz które inne programy uzyskują dostęp do tych samych tabel, ponieważ zmiana schematu tabeli wpływa na każdy program COBOL, który się do niej odwołuje.
Dlaczego mapowanie JCL-COBOL ma znaczenie dla modernizacji
Mapowanie JCL na COBOL nie jest przede wszystkim ćwiczeniem technicznym. To ćwiczenie z zakresu zarządzania ryzykiem. Każda zmiana w systemie mainframe, czy to modyfikacja parametru JCL, dodanie kroku, zmiana nazwy zbioru danych, czy modyfikacja programu COBOL wywoływanego przez zadanie, niesie ze sobą konsekwencje wykraczające poza zmieniony komponent. Jedynym sposobem na dokładne określenie zakresu tych konsekwencji przed wprowadzeniem zmiany jest posiadanie kompletnej mapy istniejących elementów i ich powiązań.
Przed migracją : Przenoszenie obciążeń wsadowych z komputera mainframe do chmury wymaga znajomości istniejących zadań JCL, wywoływanych przez nie programów COBOL, przepływów danych między krokami, kolejności wykonywania i tego, co się dzieje, gdy kroki się nie powiodą. Bez tej mapy zespół migracyjny pracuje w oparciu o niekompletną dokumentację lub w ogóle jej nie posiada. Kroki są pomijane. Zależności są wykrywane w środowisku produkcyjnym. Terminy przejścia na nowy system ulegają przesunięciu.
Przed jakąkolwiek zmianą kodu : Program COBOL zmodyfikowany bez sprawdzenia, które zadania JCL go wywołują, może zakłócić działanie zadań uruchamianych w innych warunkach lub z innymi konfiguracjami zbioru danych. Zmiana parametru JCL, która wydaje się lokalna, może wpłynąć na działanie programu COBOL opartego na określonych atrybutach zbioru danych. Analiza wpływu wymaga znajomości pełnego łańcucha JCL-COBOL-zestaw danych przed wprowadzeniem jakiejkolwiek zmiany.
Transfer wiedzy : Kiedy programista COBOL, który przez dwadzieścia lat zarządzał systemem wsadowym, odchodzi na emeryturę, zabiera ze sobą mentalny model łączenia zadań JCL i programów COBOL. Udokumentowana mapa to jedyny mechanizm transferu tej wiedzy do kolejnego zespołu. Bez niej nowi programiści dziedziczą system, którego nie mogą bezpiecznie modyfikować.
W przypadku audytu zgodności : Audyty regulacyjne często wymagają wykazania, że obliczenia finansowe, transformacje danych lub mechanizmy kontroli dostępu działają zgodnie z dokumentacją. Jeśli relacja JCL-COBOL jest nieudokumentowana, wykazanie tego jest niemożliwe bez przeprowadzenia inżynierii wstecznej systemu pod presją audytu.
Narzędzia zarządzania i platformy analityczne JCL
Wielojęzyczny charakter danych Search Console w tym artykule, z zapytaniami w językach włoskim, francuskim, hiszpańskim, japońskim i niemieckim, które dotyczą narzędzi do zarządzania JCL, odzwierciedla, jak globalnie rozproszona jest społeczność informatyków zajmujących się komputerami mainframe i jak konsekwentnie zespoły w każdym regionie stają przed tym samym problemem: ich dokumentacja JCL i COBOL jest niekompletna, nieaktualna lub nie istnieje.
Narzędzia dostępne do analizy i zarządzania JCL można podzielić na trzy kategorie:
Narzędzia natywne IBM : IBM oferuje narzędzia Job Entry Subsystem, zarządzanie buforowaniem JES oraz środowisko wykonawcze IBM z/OS Batch Runtime. Obsługują one wykonywanie i monitorowanie, ale nie zapewniają analizy zależności międzyprogramowych ani wizualizacji.
Harmonogramy zadań innych firm : CA7, TWS (Tivoli Workload Scheduler) i Broadcom ESP Workload Automation zarządzają harmonogramowaniem wsadowym tysięcy zadań, zapewniają harmonogramowanie oparte na zależnościach i alarmują o awariach. Rozumieją zależności na poziomie zadań, ale zazwyczaj nie analizują programów COBOL wywoływanych na każdym etapie.
Platformy statycznej analizy kodu i mapowania zależności : Narzędzia, które analizują kod źródłowy JCL i COBOL w celu zbudowania modelu strukturalnego określającego, które zadania wywołują poszczególne programy, które programy uzyskują dostęp do poszczególnych zestawów danych oraz jak dane przepływają przez system. Zapewniają one międzywarstwową widoczność, której nie mogą zapewnić harmonogramy zadań i natywne narzędzia IBM: relację między konkretną instrukcją JCL DD a wpisem w pliku COBOL FILE-CONTROL, który ją mapuje, lub między programem COBOL, który zapisuje dane do zestawu danych, a kolejnym zadaniem, które odczytuje ten zestaw danych jako dane wejściowe.
SMART TS XL należy do tej trzeciej kategorii i rozszerza ją, obejmując wszystkie języki stosowane w środowisku przedsiębiorstwa, COBOL, JCL, PL/I, Assembler, SQL, Java i inne, zapewniając analizę strukturalną w wielu językach, jakiej nie jest w stanie zapewnić żadne narzędzie jednojęzyczne.
W jaki sposób SMART TS XL Mapowanie JCL na COBOL w skali przedsiębiorstwa
Ręczne mapowanie JCL-COBOL jest wykonalne w przypadku pojedynczego zadania, składającego się z trzech kroków. Nie jest wykonalne w przypadku organizacji z 50 000 zadań JCL, 200 000 programów COBOL i milionami odniesień do zbiorów danych zgromadzonych przez cztery dekady. Relacji między konkretnym procesem PROC, parametrami symbolicznymi używanymi do jego wywołania, programami COBOL, do których odnoszą się te parametry, oraz zbiorami danych, do których te programy uzyskują dostęp, nie da się ręcznie prześledzić w takiej skali.
SMART TS XL Analizuje kod źródłowy JCL i COBOL, w tym procedury PROC z symboliczną substytucją parametrów, procedury strumieniowe, elementy INCLUDE, nadpisania i logikę warunkowego wykonywania, a następnie buduje ujednolicony model odniesień, który reprezentuje wszystkie zależności strukturalne w systemie. Model ten jest odpytywalny, nawigowalny i zawsze aktualny, ponieważ jest generowany ponownie ze źródła, a nie utrzymywany jako ręcznie aktualizowany dokument.
Ekspansja JCL Funkcja ta rozwiązuje symboliczną substytucję parametrów, aby pokazać rzeczywiste programy i zestawy danych wywoływane przez dowolną procedurę PROC, uwzględniając nadpisania stosowane przez każde zadanie wywołujące. Procedura PROC, która używa &PGMNAME jako parametr symboliczny pojawia się w modelu jako wszystkie konkretne programy, do których się odnosi, we wszystkich wywołujących je programach, a nie jako nierozwiązane odniesienie.
Funkcja mapowania zależności aplikacji buduje pełny graf od zadania JCL, przez program COBOL, tabelę DB2, aż po program podrzędny, pokazując każdy komponent w systemie i każde połączenie między nimi. Przed jakąkolwiek zmianą modernizacyjną zespół może zapytać: które zadania wywołują ten program? Które zestawy danych odczytuje ten program? Które inne programy zapisują do tych zestawów danych? Które zadania są uruchamiane jako następne w sekwencji?
Możliwość analizy wpływu generuje wyliczony zakres konsekwencji dla każdej proponowanej zmiany: zmodyfikuj ten podręcznik i zobacz każdy program, który go zawiera; zmień układ tego zestawu danych i zobacz każde polecenie JCL DD, które się do niego odwołuje; usuń ten krok z zadania i zobacz każdy krok następczy, który zależy od jego wyników.
Dla zespołów, które mają do czynienia z mapowaniem JCL-COBOL w ramach modernizacja dziedziczna program, SMART TS XL zapewnia podstawę, której dostawcy modernizacji, tacy jak Astadia, TSRI, Advanced i inni, potrzebują przed rozpoczęciem jakichkolwiek prac konwersyjnych: kompletny, dokładny strukturalny spis tego, co istnieje, tak aby zakres konwersji był definiowany na podstawie analizy, a nie założeń.
Mapa nie jest terytorium, ale punktem wyjścia
JCL i COBOL nie znikną. Systemy wsadowe, które przetwarzają listy płac, obsługują roszczenia ubezpieczeniowe, generują raporty regulacyjne i rozliczają transakcje finansowe, będą nadal działać na komputerach mainframe, podczas gdy migracje do chmury będą planowane, zatwierdzane, finansowane i realizowane – proces, który zazwyczaj trwa lata, a nie miesiące. W tym czasie systemy muszą być konserwowane, modyfikowane i zrozumiane.
Mapowanie JCL-COBOL nie jest jednorazowym projektem. To ciągła praktyka: utrzymywanie modelu strukturalnego w stanie aktualnym w miarę modyfikacji programów, dodawania zadań i reorganizacji zbiorów danych. Zespoły, które inwestują w tę praktykę, zachowują możliwość wprowadzania pewnych zmian w systemach, które większość branży traktuje jak czarne skrzynki. Zespoły, które tego nie robią, wprowadzają zmiany w systemach, których nie widzą w pełni, w środowiskach, w których pominięta zależność nie powoduje błędu kompilatora, powoduje awarię produkcji o 3 nad ranem podczas nocnego uruchomienia wsadowego.
