Bob incontra il mainframe

Quando abbiamo lanciato Bob, abbiamo detto che il problema interessante non era scrivere nuovo codice ma lavorare all'interno di un sistema già esistente — trovare il posto giusto per fare una modifica, rispettare le convenzioni che un team ha stabilito anni fa, mantenere un comportamento coerente tra file che crescono da lungo tempo.

La versione con il ciclo di vita più lungo di un «sistema già esistente» gira su un mainframe. Decenni di COBOL e PL/I, milioni di righe, decine di migliaia di programmi interconnessi tramite Db2, CICS, IMS e scheduler batch — codice che continua a far girare il business senza interruzioni che non ci si può permettere.

Oggi rendiamo IBM Bob Premium Package for Z (Bob PP4Z) generalmente disponibile. Sostituisce IBM watsonx Code Assistant for Z e porta l'expertise di IBM Z — linguaggi della piattaforma, consapevolezza del middleware e analisi deterministica a livello enterprise — direttamente nell'esperienza Bob.

Questa è la storia ingegneristica, non un tour delle funzionalità. Invece di elencare tutto ciò che PP4Z fa, vogliamo fare tre cose:

Spiegare perché un modello generico sbaglia le tue applicazioni mainframe più spesso di quanto ammetta.
Mostrare come ancoriamo Bob a fatti deterministici sul tuo ambiente invece che a probabilità.
Percorrere i modi, le skill e i workflow specifici per Z — e cosa puoi costruire con essi.

1. Perché il mainframe è il caso difficile

Un modello generico puntato su un ambiente mainframe incontra tre problemi che nessun prompting intelligente risolve davvero. Il design di PP4Z fornisce soluzioni per ciascuno.

1.1. La scala e cosa fa a una finestra di contesto

Una singola applicazione aziendale può essere milioni di righe di COBOL, decine di migliaia di moduli interconnessi tra COBOL, PL/I e assembler, e migliaia di job batch concatenati da uno scheduler enterprise. Anche un «piccolo» spaccato di 200 programmi è comodamente centinaia di migliaia di righe.

Questo non entra in una finestra di contesto, e il problema non è solo la finestra. Con la crescita del contesto, le prestazioni del modello degradano (Chroma Research Context Rot Study, 2025) — le risposte diventano incomplete, incoerenti o sbagliare con sicurezza. Includere «i file rilevanti» presuppone che tu sappia già quali sono rilevanti, che è esattamente quello che stavi cercando di scoprire.

1.2. Il significato che non è nel codice

Il codice mainframe è semanticamente denso. Il significato aziendale vive nei nomi dei campi e in decenni di convenzioni, non in qualcosa che un parser può leggere. Qualcosa si può indovinare — SERIALN è probabilmente un numero di serie, TOT-STTM probabilmente una liquidazione totale. La maggior parte no: cosa è C-M? M-CAP? Perché il prefisso CCZD? Cosa separa NO-SIN, NO-EVN e NO-CNT?

Il significato è reale e strutturale, ma non è deducibile solo dal codice. La risposta tradizionale è un dizionario dei dati — ma la scala (milioni, se non miliardi di variabili) lo rende difficile da costruire a mano o con forza bruta e un modello di linguaggio.

1.3. La risposta più probabile non è quella giusta

Un modello linguistico restituisce ciò che è statisticamente probabile. I modelli sono non deterministici; la stessa domanda può ottenere risposte diverse in giorni diversi. Su un sistema dove una risposta sbagliata sul flusso di controllo può travisare la logica aziendale, questo è un rischio significativo.

È uno scenario che probabilmente hai incontrato tu stesso, assumendo che tu l'abbia riconosciuto. Prendi una vera applicazione batch COBOL: 233 programmi, 742 copybook, oltre 20 MB di codice, con un utility di data molto chiamato, N991DATE. Dai metadati, la ground truth è che 30 programmi lo chiamano. Ora chiedi direttamente a un modello frontier:

Giorno 1. Non può caricare tutto, quindi cerca le istruzioni CALL statiche e riporta 13. Chiesto delle chiamate dinamiche, allarga la regex e riporta 29. Quello che manca, CHKOUTB, vive in un file chiamato ROCHKOUT.cbl — perché per convenzione il nome di un file di solito corrisponde al suo PROGRAM-ID, ma non è mai obbligatorio.
Giorno 2. Stessa domanda, euristiche diverse, e ora riporta 31 — sovraconteggio. Un falso positivo, N285RODR, si limita a dichiarare il letterale 'N991DATE' nel working storage e non lo usa mai. Il modello arriva a quella conclusione solo dopo diversi follow-up.

Nessuna di queste euristiche è irragionevole. Semplicemente non sono abbastanza buone, e «chi chiama X» è una delle domande centrali durante l'analisi di impatto e la comprensione dei programmi. Le domande più avanzate — quali tabelle vengono aggiornate in più di un programma, quali file vengono letti ma mai scritti, quali variabili alimentano il calcolo di WS-UIT02 in PREMPZ72 — necessitano di un'analisi completa e precisa che il pattern-matching non può fornire.

La conclusione non è «i modelli non sono utili per la comprensione dei programmi mainframe». È che la qualità delle risposte del modello migliora sostanzialmente quando c'è qualcosa di vero su cui ragionare. I modelli di linguaggio eccellono nell'elaborazione dei dati.

2. Ancorare Bob ai fatti, non alle probabilità

La risposta di PP4Z è smettere di chiedere al modello di ricostruire il sistema dal codice sorgente, e invece dargli una rappresentazione deterministica e interrogabile dell'ambiente su cui ragionare. Tre meccanismi fanno l'ancoraggio: il modello riceve istruzioni di segnalare costrutti z/OS ambigui nella richiesta stessa; i prompt vengono arricchiti con insight autorevoli di IBM Z, documentazione IBM, materiale di riferimento, campioni verificati e altro ancora, con i pregiudizi della programmazione generica attivamente soppressi; e al modello viene indicato di rispondere prima dai metadati di analisi. L'obiettivo è rendere le risposte tracciabili al sistema IBM Z, non a una distribuzione di addestramento.

2.1. Z Understand: un modello interrogabile del tuo ambiente

Z Understand è la piattaforma di analisi statica alla base di PP4Z. Gira su un server con accesso alla tua sorgente completa, include scanner per COBOL, PL/I e assembler più JCL e scheduler come Control-M e TWS, e processa migliaia di programmi in parallelo in un repository interrogabile. Mantiene struttura deterministica e coerente su ambienti di 10.000+ programmi.

Aiuta pensarlo come una pipeline di compilazione con un output diverso: non un eseguibile, ma conoscenza strutturata e interrogabile — definizioni di dati, flusso di controllo tra programmi e job, flusso di dati preciso (inclusi REDEFINES e offset di memoria) e interazioni dei sottosistemi.

2.2. Lasciare che il modello scriva le proprie query

Come vengono esposti i metadati è importante quanto i metadati stessi. Le API fisse e i pattern di query MCP predefiniti sono molto efficienti per domande note e attese, ma falliscono nell'analisi aperta. Durante l'analisi aperta una domanda reale si ramifica in molte sotto-query che cambiano man mano che il ragionamento procede.

Abbiamo quindi insegnato a Bob come andare oltre le query predefinite e generare ed eseguire le proprie query contro i metadati. Questo sfrutta ciò in cui i modelli sono genuinamente bravi — ragionamento e generazione di query — e scala come scalano i dati strutturati: che tu abbia 10 o 10.000 programmi, la query è la stessa; cresce solo il set di risultati.

2.3. Estensibilità, scanner personalizzati e dati di runtime

L'analisi puramente sintattica manca le relazioni che contano quando chiamate dinamiche, astrazioni API e preprocessori nascondono il vero flusso. Il framework Z Understand Extensibility colma questa lacuna:

Risoluzione di chiamate API / macro mappa chiamate indirette e guidate da parametri ai loro target reali, sostituendo archi di chiamata generici con relazioni concrette chiamante-chiamato, tramite config JSON o user exit.
Estensibilità dei preprocessori interpreta istruzioni non standard preservando la vista sorgente originale, mappando pulitamente tra codice pre- e post-elaborato.
Scanner personalizzati portano linguaggi proprietari, 4GL e persino sorgenti non-codice in un unico modello attraverso un'interfaccia JSON guidata da schema.

L'analisi statica ti dice cosa può accadere; i dati di runtime ti dicono cosa è accaduto. PP4Z trasforma il debugger in uno strumento di raccolta dati e consegna queste tracce precise a Bob.

2.4. Il dizionario dei dati: rilevanza rispetto alla completezza

Documentare miliardi di variabili non è fattibile né manutenibile, quindi PP4Z non ci prova. L'analisi deterministica classifica le variabili in base a quanto guidano effettivamente il comportamento — frequenza di utilizzo, distribuzione nelle regioni di codice, partecipazione al flusso di controllo, interazione con database e I/O — e seleziona il piccolo insieme che rivela lo scopo di un programma.

Il risultato utile qui: la copertura limitata è sufficiente. Definire approssimativamente le prime 10-20 variabili per programma migliora materialmente la comprensione senza documentazione esaustiva. Z Understand Services automatizza questo su interi portfolio dalla CLI, un punteggio di confidenza conserva solo le definizioni sopra una soglia, e un passaggio human-in-the-loop nell'IDE consente agli sviluppatori di rivedere, correggere e allineare l'output con glossari esistenti.

3. Specializzare Bob per Z

L'ancoraggio dà a Bob buoni fatti. La specializzazione è ciò che lo rende prevedibile in un ambiente dove gli output devono essere spiegabili e i processi devono soddisfare la governance. PP4Z è costruito su quattro elementi: modi, strumenti, skill e workflow.

I modi stabiliscono il ruolo e i confini per un flusso di interazione. Un modo architetto priorizza analisi, documentazione e scoperta delle dipendenze, con la modifica del codice esplicitamente vietata. Un modo sviluppatore è ottimizzato per la generazione e il refactoring con l'applicazione degli standard di codifica integrata.
Gli strumenti danno al modello accesso diretto alla conoscenza strutturata del sistema — scansione di programmi, interrogazione di metadati, ricerca nel dizionario dei dati, servizi di analisi a livello enterprise.
Le skill codificano l'expertise ricorrente in passi ripetibili e verificabili. La skill di pianificazione dell'implementazione, ad esempio, applica una sequenza fissa: acquisire e validare il contesto, formulare i requisiti, mappare l'impatto dai metadati, quindi produrre un piano persistito e revisionabile.
I workflow aggiungono orchestrazione con stato — applicando l'ordine, validando i risultati intermedi, fermandosi su input errati. Il workflow del dizionario dei dati si ferma se non trova variabili invece di inventarne alcune.

Gli standard e la governance vengono applicati per impostazione predefinita attraverso le regole agents.md a livello di repository. Puoi anche creare le tue skill, senza scrivere codice.

Quando questi si combinano, un singolo prompt può guidare un'attività end-to-end:

«Aggiungi una colonna alla Motor Policy Table che cattura se il veicolo è elettrico. Applica i miei standard di codifica e aggiorna tutti i programmi interessati.»

Bob legge l'intenzione, costruisce un piano, seleziona i modi, le skill e le regole di repository corretti, ed esegue in modo sicuro gli strumenti necessari — governance, esecuzione e ragionamento in un unico passaggio, con la tua approvazione delle modifiche.

4. Cosa puoi costruire oggi

Documentazione che non si desincronizza. Tratta i doc come un artefatto generato ancorato a metadati deterministici più contesto di sorgente e runtime — rigenerabile su richiesta, allineato al sistema attuale.
Transizione COBOL-to-Java deterministica su z/OS. PP4Z usa i metadati come spina dorsale della trasformazione, costruendo modelli paralleli di sorgente e target in modo che l'architettura sia riproducibile e la logica aziendale mappata con precisione.
Refactoring mirato ed estrazione di funzioni. Bob produce una lista classificata di candidati al refactoring annotati con funzione aziendale, poi estrae moduli autonomi con input e output chiari.
Tooling nativo z/OS. Capacità di Z Open Editor più nuovi tool MCP: Dependency Based Build (DBB), Z Code Scan e IBM Debug for z/OS per trasformare sessioni di debug live in analisi della causa radice assistita dall'IA.

Una nota sull'onestà, poiché questo è un post di ingegneria: niente di tutto ciò rimuove lo sviluppatore dal loop, e non è questo l'intento. I modi, i gate di approvazione e il dizionario dei dati human-in-the-loop esistono tutti perché su questi sistemi «quasi giusto» è la modalità di fallimento, non l'obiettivo.

5. Come ottenere l'accesso

Bob Premium Package for Z (PP4Z) è un add-on di IBM Bob, non un prodotto separato da scaricare. PP4Z opera contro un ambiente mainframe attivo all'interno di un ambiente enterprise — l'abilitazione è gestita dalle vendite.

Inizia dal tuo rappresentante IBM, o usa Contatta le vendite su bob.ibm.com. Configurano il piano base IBM Bob e l'add-on Z per la tua organizzazione.
Una volta che il tuo amministratore Bob ti assegna un seat con l'add-on Z, l'abilitazione viene rilevata quando usi IBM Bob. Installa la Bob IDE, accedi, e i modi, le skill e gli strumenti specifici per Z appaiono.

6. Per iniziare

Se stai già usando Bob, PP4Z aggiunge i modi, le skill e gli strumenti specifici per Z in aggiunta a ciò che hai.
Usa la capacità di comprensione integrata per ottenere insight più profondi sul codice nel tuo workspace.
Punta Z Understand su una vera applicazione dove conosci già le risposte giuste — e verifica l'analisi di Bob rispetto alla tua ground truth.
Inizia con una domanda a cui non hai mai ottenuto una risposta diretta: chi chiama davvero questa utility? Quali tabelle tocca questo job? Cosa significa questa variabile?
Fai domande più complesse che mescolano dati e ragionamento: «Dammi un call graph con diagrammi organizzati per argomenti»

Link