Bob spotyka mainframe

Kiedy uruchamialiśmy Boba, powiedzieliśmy, że interesującym problemem nie jest pisanie nowego kodu, ale praca wewnątrz systemu, który już istnieje — znalezienie właściwego miejsca do wprowadzenia zmiany, szanowanie konwencji ustalonych przez zespół lata temu, utrzymanie spójnego zachowania w plikach, które rozrastają się od długiego czasu.

Najdłużej działająca wersja „systemu, który już istnieje" działa na mainframe. Dziesięciolecia COBOLa i PL/I, miliony linii kodu, dziesiątki tysięcy programów połączonych przez Db2, CICS, IMS i harmonogramy wsadowe — kod, który bez przerwy napędza biznes, bez zakłóceń, na które nie można sobie pozwolić.

Dziś ogólnie udostępniamy IBM Bob Premium Package for Z (Bob PP4Z). Zastępuje IBM watsonx Code Assistant for Z i wprowadza wiedzę specjalistyczną IBM Z — języki platformy, świadomość middleware i deterministyczną analizę całego środowiska enterprise — bezpośrednio do doświadczenia Boba.

To historia inżynierska, nie prezentacja funkcji. Zamiast wymieniać wszystko, co robi PP4Z, chcemy zrobić trzy rzeczy:

Wyjaśnić, dlaczego model ogólnego przeznaczenia częściej myli się z aplikacjami mainframe, niż przyznaje.
Pokazać, jak zakotwiczamy Boba w deterministycznych faktach dotyczących twojego środowiska, a nie w prawdopodobieństwach.
Przejść przez tryby, skille i workflowy specyficzne dla Z — i co możesz z nimi zbudować.

1. Dlaczego mainframe jest trudnym przypadkiem

Model ogólnego przeznaczenia skierowany na środowisko mainframe napotyka trzy problemy, których żadne inteligentne promptowanie naprawdę nie rozwiązuje. Projekt PP4Z oferuje rozwiązania dla każdego z nich.

1.1. Skala i jej wpływ na okno kontekstu

Pojedyncza aplikacja biznesowa może mieć miliony linii COBOLa, dziesiątki tysięcy wzajemnie połączonych modułów w COBOLu, PL/I i asemblerze oraz tysiące zadań wsadowych połączonych przez harmonogram enterprise. Nawet „mały" wycinek 200 programów to wygodnie setki tysięcy linii kodu.

To nie mieści się w oknie kontekstu, a problem nie dotyczy tylko okna. Wraz z rozrostem kontekstu spada wydajność modelu (Chroma Research Context Rot Study, 2025) — odpowiedzi stają się niekompletne, niespójne lub pewnie błędne. Dodawanie „odpowiednich plików" zakłada, że już wiesz, które są odpowiednie — a to właśnie było to, co starałeś się dowiedzieć.

1.2. Znaczenie, którego nie ma w kodzie

Kod mainframe jest semantycznie gęsty. Znaczenie biznesowe tkwi w nazwach pól i dziesięcioleciach konwencji, a nie w czymś, co parser może odczytać. Część można zgadnąć — SERIALN to prawdopodobnie numer seryjny, TOT-STTM to prawdopodobnie całkowite rozliczenie. Większości nie można: czym jest C-M? M-CAP? Dlaczego prefiks CCZD? Co odróżnia NO-SIN, NO-EVN i NO-CNT?

Znaczenie jest rzeczywiste i nośne, ale nie da się go wydedukować tylko z kodu. Tradycyjną odpowiedzią jest słownik danych — ale skala (miliony, jeśli nie miliardy zmiennych) sprawia, że jego ręczne zbudowanie lub budowanie z użyciem modelu językowego jest zniechęcające.

1.3. Najbardziej prawdopodobna odpowiedź nie jest właściwą odpowiedzią

Model językowy zwraca to, co jest statystycznie prawdopodobne. Modele są niedeterministyczne; to samo pytanie może dawać różne odpowiedzi w różnych dniach. W systemie, gdzie błędna odpowiedź dotycząca przepływu sterowania może błędnie przedstawiać logikę biznesową, to jest znaczące ryzyko.

To scenariusz, który prawdopodobnie sam napotkałeś, zakładając, że go rozpoznałeś. Weź prawdziwą aplikację wsadową COBOL: 233 programy, 742 copybooki, ponad 20 MB kodu, z intensywnie wywoływanym narzędziem daty N991DATE. Na podstawie metadanych prawda jest taka, że wywołuje je 30 programów. Zapytaj teraz bezpośrednio model frontier:

Dzień 1. Nie może załadować wszystkiego, więc szuka statycznych instrukcji CALL i raportuje 13. Zapytany o wywołania dynamiczne, poszerza regex i raportuje 29. Ten, który pomija, CHKOUTB, znajduje się w pliku o nazwie ROCHKOUT.cbl — bo zgodnie z konwencją nazwa pliku zwykle pasuje do jego PROGRAM-ID, ale nigdy nie jest wymagana.
Dzień 2. To samo pytanie, inne heurystyki i teraz raportuje 31 — nadliczenie. Jeden fałszywy wynik, N285RODR, jedynie deklaruje literał 'N991DATE' w working storage i nigdy go nie używa. Model dochodzi do tego dopiero po kilku dalszych pytaniach.

Żadna z tych heurystyk nie jest nieracjonalna. Po prostu nie są wystarczająco dobre, a „kto wywołuje X" to jedno z kluczowych pytań podczas analizy wpływu i rozumienia programów. Bardziej zaawansowane pytania — które tabele są aktualizowane w więcej niż jednym programie, które pliki są czytane, ale nigdy zapisywane, które zmienne zasilają obliczenie WS-UIT02 w PREMPZ72 — wymagają kompletnej, precyzyjnej analizy, której dopasowywanie wzorców nie może zapewnić.

Wniosek nie jest taki, że „modele nie są przydatne do rozumienia programów mainframe". Chodzi o to, że jakość odpowiedzi modelu znacznie się poprawia, gdy ma coś prawdziwego, nad czym może rozumować. Modele językowe doskonale sprawdzają się w przetwarzaniu danych.

2. Zakotwiczenie Boba w faktach, a nie prawdopodobieństwach

Odpowiedzią PP4Z jest zaprzestanie proszenia modelu o rekonstrukcję systemu z kodu źródłowego i zamiast tego danie mu deterministycznej, pytanej reprezentacji środowiska, na której może rozumować. Trzy mechanizmy zapewniają zakotwiczenie: model otrzymuje polecenie oznaczania niejednoznacznych konstrukcji z/OS w samym żądaniu; prompty są wzbogacane o autorytatywne spostrzeżenia IBM Z, dokumentację IBM, materiały referencyjne, zweryfikowane przykłady i więcej, z aktywnym tłumieniem uprzedzeń programowania ogólnego; i model otrzymuje polecenie odpowiadania najpierw z metadanych analizy. Celem jest uczynienie odpowiedzi identyfikowalnymi do systemu IBM Z, a nie do rozkładu trenowania.

2.1. Z Understand: pytalny model twojego środowiska

Z Understand to platforma analizy statycznej leżąca u podstaw PP4Z. Działa na serwerze z dostępem do twojego pełnego źródła, zawiera skanery dla COBOL, PL/I i asemblera oraz JCL i harmonogramy jak Control-M i TWS, i przetwarza tysiące programów równolegle w jedno pytalne repozytorium. Utrzymuje deterministyczną, spójną strukturę w środowiskach 10 000+ programów.

Pomocne jest myślenie o tym jak o pipeline kompilatora z innym wynikiem: nie plikiem wykonywalnym, ale ustrukturowaną, pytaną wiedzą — definicjami danych, przepływem sterowania między programami i zadaniami, precyzyjnym przepływem danych (w tym REDEFINES i przesunięciami pamięci) oraz interakcjami podsystemów.

2.2. Pozwolenie modelowi pisać własne zapytania

Sposób ujawniania metadanych ma równie duże znaczenie jak same metadane. Stałe API i predefiniowane wzorce zapytań MCP są bardzo wydajne dla znanych i oczekiwanych pytań, ale zawodzą przy otwartej analizie. Podczas otwartej analizy jedno prawdziwe pytanie rozgałęzia się w wiele podzapytań, które zmieniają się w miarę postępu rozumowania.

Nauczyliśmy więc Boba, jak wychodzić poza dostarczone gotowe zapytania i generować i uruchamiać własne zapytania do metadanych. Opiera się to na tym, w czym modele naprawdę są dobre — rozumowaniu i generowaniu zapytań — i skaluje się tak, jak skalują się dane strukturyzowane: niezależnie od tego, czy masz 10, czy 10 000 programów, zapytanie jest takie samo; rośnie tylko zestaw wyników.

2.3. Rozszerzalność, niestandardowe skanery i dane wykonawcze

Czysta analiza składniowa pomija relacje, które mają znaczenie, gdy dynamiczne wywołania, abstrakcje API i preprocesory ukrywają rzeczywisty przepływ. Framework Z Understand Extensibility wypełnia tę lukę:

Rozwiązywanie wywołań API / makr mapuje wywołania pośrednie i oparte na parametrach na ich rzeczywiste cele, zastępując generyczne krawędzie wywołań konkretnymi relacjami wywołujący–wywoływany, za pomocą konfiguracji JSON lub wyjść użytkownika.
Rozszerzalność preprocesora interpretuje niestandardowe instrukcje, zachowując oryginalny widok źródłowy, czysto mapując między kodem przed i po przetwarzaniu.
Niestandardowe skanery wprowadzają zastrzeżone języki, 4GL i nawet źródła niebędące kodem do jednego modelu przez interfejs JSON oparty na schemacie.

Analiza statyczna mówi ci, co może się zdarzyć; dane wykonawcze mówią ci, co się zdarzyło. PP4Z zamienia debugger w instrument zbierania danych i przekazuje te precyzyjne ślady do Boba.

2.4. Słownik danych: trafność ponad kompletność

Dokumentowanie miliardów zmiennych nie jest ani wykonalne, ani możliwe do utrzymania, więc PP4Z tego nie próbuje. Deterministyczna analiza szereguje zmienne według tego, jak bardzo napędzają zachowanie — częstotliwość użycia, rozkład w obszarach kodu, udział w przepływie sterowania, interakcja z bazami danych i we/wy — i wybiera mały zestaw, który ujawnia cel programu.

Przydatne odkrycie: ograniczone pokrycie wystarczy. Zdefiniowanie około 10–20 pierwszych zmiennych na program znacząco poprawia zrozumienie bez wyczerpującej dokumentacji. Z Understand Services automatyzuje to w całych portfelach z CLI, wynik zaufania zachowuje tylko definicje powyżej progu, a krok human-in-the-loop w IDE pozwala programistom przeglądać, poprawiać i dostosowywać wyniki do istniejących słowników.

3. Specjalizacja Boba dla Z

Zakotwiczenie daje Bobowi dobre fakty. Specjalizacja sprawia, że zachowuje się przewidywalnie w środowisku, gdzie wyniki muszą być wyjaśnialne, a procesy muszą spełniać wymogi zarządzania. PP4Z zbudowany jest na czterech elementach: trybach, narzędziach, skillach i workflowach.

Tryby ustawiają rolę i granice dla przepływu interakcji. Tryb architekta priorytetowo traktuje analizę, dokumentację i odkrywanie zależności, z jawnym zakazem modyfikacji kodu. Tryb programisty jest dostrojony do generowania i refaktoryzacji z wbudowanym egzekwowaniem standardów kodowania.
Narzędzia dają modelowi bezpośredni dostęp do ustrukturyzowanej wiedzy o systemie — skanowania programów, przesłuchiwania metadanych, wyszukiwania w słowniku danych, usług analitycznych dla całego przedsiębiorstwa.
Skille kodyfikują powtarzającą się wiedzę specjalistyczną w powtarzalne, audytowalne kroki. Skill planowania implementacji na przykład wymusza stałą sekwencję: pozyskanie i walidacja kontekstu, sformułowanie wymagań, mapowanie wpływu z metadanych, a następnie wytworzenie utrwalonego, sprawdzalnego planu.
Workflowy dodają stanową orkiestrację — egzekwując kolejność, walidując wyniki pośrednie, zatrzymując się na złym wejściu. Workflow słownika danych zatrzymuje się, jeśli nie znajdzie zmiennych, zamiast je wymyślać.

Standardy i zarządzanie są domyślnie egzekwowane przez reguły agents.md na poziomie repozytorium. Możesz też tworzyć własne skille — bez pisania kodu.

Gdy te elementy się łączą, jeden prompt może napędzać zadanie od końca do końca:

„Dodaj kolumnę do Motor Policy Table, która rejestruje, czy pojazd jest elektryczny. Zastosuj moje standardy kodowania i zaktualizuj wszystkie dotknięte programy."

Bob odczytuje intencję, buduje plan, wybiera właściwe tryby, skille i reguły repozytorium, i bezpiecznie uruchamia potrzebne narzędzia — zarządzanie, wykonanie i rozumowanie w jednym przebiegu, z twoją akceptacją zmian.

4. Co możesz zbudować już dziś

Dokumentacja, która się nie rozjeżdża. Traktuj dokumenty jako generowany artefakt zakotwiczony w deterministycznych metadanych plus kontekst źródłowy i wykonawczy — regenerowalny na żądanie, zgodny z bieżącym systemem.
Deterministyczne przejście z COBOLa na Javę w z/OS. PP4Z używa metadanych jako szkieletu transformacji, budując równoległe modele źródła i celu, tak aby architektura była reprodukowalna, a logika biznesowa mapowana precyzyjnie.
Ukierunkowana refaktoryzacja i ekstrakcja funkcji. Bob tworzy uszeregowaną listę kandydatów do refaktoryzacji z adnotacjami funkcji biznesowych, a następnie wyodrębnia samodzielne moduły z wyraźnymi wejściami i wyjściami.
Natywne narzędzia z/OS. Możliwości Z Open Editor plus nowe narzędzia MCP: Dependency Based Build (DBB), Z Code Scan i IBM Debug for z/OS do zamiany sesji debugowania na analizę przyczyn źródłowych wspomaganą przez AI.

Uwaga na temat szczerości, bo to post inżynierski: żadne z tych rozwiązań nie usuwa programisty z pętli i nie jest to zamierzone. Tryby, bramki zatwierdzeń i słownik danych human-in-the-loop istnieją dlatego, że w tych systemach „przeważnie poprawnie" jest trybem awarii, a nie celem.

5. Jak uzyskać dostęp

Bob Premium Package for Z (PP4Z) to dodatek do IBM Boba, a nie oddzielny produkt do pobrania. PP4Z działa w stosunku do aktywnego środowiska mainframe w środowisku enterprise — uprawnienie jest prowadzone przez sprzedaż.

Zacznij od swojego przedstawiciela IBM lub skorzystaj z opcji Kontakt ze sprzedażą na bob.ibm.com. Konfigurują bazowy plan IBM Bob i dodatek Z dla twojej organizacji.
Po tym, jak administrator Boba przypisze ci miejsce z dodatkiem Z, uprawnienie jest wykrywane, gdy używasz IBM Boba. Zainstaluj Bob IDE, zaloguj się, a tryby, skille i narzędzia specyficzne dla Z się pojawią.

6. Jak zacząć

Jeśli już używasz Boba, PP4Z dodaje tryby, skille i narzędzia specyficzne dla Z na wierzch tego, co masz.
Użyj wbudowanej możliwości rozumienia, aby uzyskać głębszy wgląd w kod w swoim workspace.
Skieruj Z Understand na prawdziwą aplikację, gdzie już znasz właściwe odpowiedzi — i sprawdź analizę Boba z twoją prawdą gruntową.
Zacznij od pytania, na które nigdy nie uzyskałeś bezpośredniej odpowiedzi: kto tak naprawdę wywołuje to narzędzie, których tabel dotyka to zadanie, co oznacza ta zmienna?
Zadawaj bardziej wymagające pytania łączące dane i rozumowanie: „Daj mi graf wywołań z diagramami pogrupowanymi według tematów"

Linki