To pytanie pochodzi z inicjatyw modernizacji przedsiębiorstw, w których transakcje CICS z dziesięcioletnim stażem, napędzające systemy bankowe lub ubezpieczeniowe, są udostępniane jako nowoczesne REST API za pośrednictwem z/OS Connect lub podobnego oprogramowania pośredniczącego. Złożoność wynika z niezgodności między stateless HTTP a stateful kontekstem transakcyjnym CICS, szczególnie dotyczącej marshalling danych między JSON a COBOL copybookami. Historycznie, podejścia zapewnienia jakości zaprojektowane zarówno dla czystego testowania zielonego ekranu na mainframe, jak i nowoczesnych mikrousług okazują się niewystarczające dla tej hybrydowej granicy, prowadząc do wad produkcyjnych, które ujawniają się tylko w określonych warunkach obciążenia lub ekstremalnych przypadkach danych.
Manualne QA staje przed unikalnymi wyzwaniami w tym środowisku, ponieważ wady ujawniają się na przecięciu zachowań systemów rozproszonych i ograniczeń starszego mainframe. Buffery COMMAREA mają stałe długości zdefiniowane w COBOL copybookach, ale ładunki JSON mają zmienną długość, co powoduje ciche przycinanie zamiast wyraźnych błędów, gdy z/OS Connect wykonuje mapowanie danych. Dodatkowo, transakcje CICS korzystające z EXEC CICS SYNCPOINT dla spójności bazy danych mogą pozostawiać osierocone rekordy, jeśli klient REST wygasa zanim mainframe wykona commit, mimo że odpowiedź HTTP może mylnie wskazywać na sukces. Wreszcie, wyzwalacze TDQ dla przetwarzania asynchronicznego mogą uruchamiać się wielokrotnie podczas kontencji blokad rekordów RLS w różnych regionach CICS, co powoduje duplikację inicjatyw roboczych, które automatyczne testowanie API nie może wykryć.
Systematyczna metodologia wymaga trzech warstw walidacji.
Po pierwsze, Boundary Analysis Testing wykorzystuje partycjonowanie ekwiwalentów derived from copybook do wstrzykiwania ładunków na dokładnych granicach długości COMMAREA, weryfikując, że EIBCALEN (Długość obszaru komunikacyjnego bloku interfejsu wykonania) pasuje do oczekiwanych wartości w programie COBOL.
Po drugie, Transactional Integrity Verification polega na konfiguracji proxy sieciowych w celu wprowadzenia celowych timeoutów podczas operacji SYNCPOINT w locie, a następnie użyciu poleceń CEMT (Master Terminal) do inspekcji stanów regionów CICS i System Logger z/OS do audytu wyników UR (Jednostka odzyskiwania).
Po trzecie, Concurrency Stress Testing wykorzystuje wielu klientów REST do symulowania kontencji RLS, weryfikując idempotencję TDQ poprzez inspekcję kolejki CEBR (Browse Transaction) oraz użycie narzędzi EXAMINE VSAM dla walidacji integralności plików.
Duża firma ubezpieczeniowa przeniosła swoją transakcję zapytania polisy CICS do aplikacji mobilnej dla klientów za pośrednictwem REST API. Po wdrożeniu pojawiły się sporadyczne uszkodzenia danych, gdzie adresy posiadaczy polis były przycinane w połowie nazwy ulicy, a duplikowane listy dotyczące wyznaczenia polis były wysyłane do klientów o dużej wartości, tworząc ryzyko zgodności regulacyjnej i szkody w reputacji.
COBOL copybook zdefiniował pole adresu jako PIC X(30), ale aplikacja mobilna wysyłała znaki Unicode UTF-8, w tym znaki akcentowane wielobajtowe. Gdy z/OS Connect mapował to na EBCDIC, liczba bajtów przekraczała bufor, nie wywołując wyjątków ze względu na logikę cichego przycinania. Tymczasem, przy obciążeniu produkcyjnym, wyzwalacze TDQ uruchomiły się dwa razy, gdy blokady RLS opóźniły pierwsze potwierdzenie wyzwalacza, co spowodowało, że zadanie wsadowe przetworzyło identyczne żądania dwa razy.
Rozwiązanie 1: Automatyczne testowanie API z programem symulującym mainframe
Zespół rozważał użycie WireMock do symulacji odpowiedzi CICS bez wykorzystywania rzeczywistego mainframe, co pozwoliłoby na szybkie testowanie regresyjne.
Zalety: Szybkie cykle wykonania, brak zużycia drogiego MIPS mainframe oraz możliwość uruchamiania w CI/CD bez łączności z mainframe.
Wady: Nie może wykryć zachowania przycinania COMMAREA, kontencji blokady VSAM ani rzeczywistych błędów konwersji kodowania EBCDIC, co daje fałszywe poczucie pokrycia testowego.
Rozwiązanie 2: Debugowanie regionu CICS bezpośrednio
Dołączając CEDX (Execution Diagnostic Facility) do śledzenia każdego wywołania EXEC CICS i inspekcji zawartości COMMAREA w czasie rzeczywistym.
Zalety: Możliwość precyzyjnego zlokalizowania błędów poleceń oraz podglądu układów pamięci surowych struktur COBOL.
Wady: Wymaga specjalistycznej wiedzy na temat mainframe, której brakowało zespołowi QA, znacznie wpływa na wydajność regionu CICS i nie może symulować realistycznego opóźnienia sieciowego między rozproszonymi klientami REST a mainframe.
**Rozwiązanie 3: Systematyczne testowanie granic manualnych z inspekcją CEBR
Ręczne tworzenie żądań REST z długościami ładunków 29, 30 i 31 znaków za pomocą Postman lub cURL, a następnie użycie CEBR do inspekcji zawartości TDQ i CEMT INQUIRE FILE do sprawdzenia stanów blokad RLS VSAM.
Zalety: Waliduje rzeczywistą ścieżkę kodu produkcyjnego, w tym konwersję kodowania znaków, egzekucję granic COMMAREA oraz zachowanie blokad RLS między wieloma regionami CICS.
Wady: Proces ręczny czasochłonny, wymagający dostępu do poświadczeń TSO mainframe i umiejętności interakcji z terminalem CICS.
Rozwiązanie 3 zostało wybrane, ponieważ tylko bezpośrednia walidacja mogła ujawnić ciche przepełnienie COMMAREA oraz warunek duplikacji wyzwalacza TDQ pod kątem kontencji RLS. Zespół stworzył kompleksową matrycę testów zmieniającą długości ładunków (wartości graniczne), zestawy znaków (ASCII vs EBCDIC vs UTF-8) oraz obciążenia użytkowników (5, 10 i 20 równoczesnych żądań).
Wykorzystali CEDF, aby krok po kroku przejść przez wykonanie programu COBOL i zweryfikować wartości EIBCALEN, potwierdzając, że logika programu nie zweryfikowała długości przychodzących buforów przed ich przetworzeniem. W przypadku problemu z TDQ użyli CEMT INQUIRE TDQUEUE, aby monitorować liczniki wyzwalaczy w scenariuszach dostępu równoległego.
Testowanie ujawniło, że znaki UTF-8 przekraczające 30 bajtów (a nie znaki) powodowały przycinanie, szczególnie gdy klienci wprowadzali adresy z wieloma znakami akcentowanymi. Program COBOL został zmodyfikowany, aby sprawdzać EIBCALEN w porównaniu do oczekiwanych długości COMMAREA i odrzucać zbyt duże ładunki z odpowiednimi kodami błędów HTTP 400.
W przypadku problemu z TDQ testowanie ujawniło, że gdy czas oczekiwania na blokadę RLS przekraczał 2 sekundy, logika ponownego próbowania bramy REST tworzyła duplikaty wpisów TDQ. Architektura została zmodyfikowana w celu wdrożenia przetwarzania idempotentnego z użyciem unikalnych identyfikatorów korelacji przekazywanych przez DFHCOMMAREA, zapewniając, że duplikaty wyzwalaczy były wykrywane i odrzucane przez procesor wsadowy. Po wdrożeniu monitorowanie wykazało brak błędów przycinania i wyeliminowało duplikaty korespondencji.
Jak weryfikujesz zachowanie wycofania transakcji CICS, gdy klient REST rozłącza się po wysłaniu żądania, ale przed otrzymaniem odpowiedzi?
Większość kandydatów sugeruje po prostu sprawdzenie stanu bazy danych po rozłączeniu. Jednak właściwe podejście polega na użyciu CEMT INQUIRE TASK, aby zweryfikować, że transakcja została usunięta z regionu CICS, a następnie zbadaniu LOGSTREAM systemu z/OS, aby potwierdzić, że UR (Jednostka odzyskiwania) została wycofana. Dodatkowo, należy zweryfikować spójność VSAM RBA (Relative Byte Address) korzystając z IDCAMS VERIFY, aby upewnić się, że nie istnieją osierocone rekordy. Subtelny punkt, który umyka kandydatom, polega na tym, że CICS może zatwierdzić lokalnie, ale brama REST może nie wysłać potwierdzenia, co wymaga inspekcji dzienników błędów z/OS Connect w poszukiwaniu timeoutów HCON (HTTP Connection) w porównaniu do kodów abendów CICS, takich jak AEXZ (timeout).
Jak testując przetwarzanie TDQ, odróżniasz wyzwalacze TDQ wewnątrz partycji przetwarzane w tym samym regionie CICS od wyzwalaczy TDQ międzypartyjnych zapisywanych w datasetach z/OS i przetwarzanych przez zadania wsadowe?
Kandydaci często przegapiają, że zachowanie TDQ zmienia się zasadniczo w zależności od definicji DESTID w DCT (Destination Control Table). Dla wyzwalaczy TDQ wewnątrz partycji (opartych na pamięci) użyj CEBR, aby inspekcjonować głębokości kolejek i CEMT SET TDQUEUE, aby ręcznie wywołać przetwarzanie, weryfikując natychmiastowe uruchomienie transakcji CICS. Dla wyzwalaczy TDQ międzypartyjnych musisz monitorować fizyczny dataset z/OS przy użyciu ISPF 3.4 lub SDSF, aby zaobserwować rejestry wyzwalaczy, a następnie zweryfikować wykonanie klasy inicjacyjnej JOB. Kluczowa różnica polega na tym, że wyzwalacze TDQ wewnątrz partycji utrzymują spójność transakcji CICS za pomocą SYNCPOINT, podczas gdy wyzwalacze TDQ międzypartyjne wymagają oddzielnych strategii blokowania VSAM RLS, aby zapobiec wyścigom przy usuwaniu rekordów między CICS a zadaniami wsadowymi, które uzyskują dostęp do tego samego DESTID.
Jak weryfikujesz mapowanie JSON do COBOL copybook, gdy copybook zawiera klauzule OCCURS DEPENDING ON (ODO) z tablicami zmiennych długości?
Wielu testerów sprawdza tylko struktury o stałej długości i pomija złożoność ODO. Dla klauzul ODO należy upewnić się, że z/OS Connect poprawnie uzupełnia pole licznika zależności przed danymi tablicy w COMMAREA. Przypadki testowe powinny obejmować: (1) Zero wystąpień (pusta tablica), (2) Jedno wystąpienie, (3) Maksymalna liczba wystąpień oraz (4) Przekroczenie maksymalnej liczby wystąpień w celu zweryfikowania obsługi błędów. Użyj CEBR lub CEDF, aby inspekcjonować układ COMMAREA w formacie szesnastkowym, upewniając się, że binarne pola COMP utrzymują poprawną kolejność bajtów Big-Endian po konwersji liczb JSON. Złożoność wynika z faktu, że tablice JSON nie mają jawnego wskaźnika długości, co wymaga, aby mapper obliczył wartości ODO na podstawie liczby elementów, co może błędnie policzyć, jeśli w ładunku JSON występują wartości null, co prowadzi do przepełnienia tabeli COBOL lub jej przycinania.