Uso attuale dell'AI
Debug, spiegazione di codice, documentazione, snippet, supporto su codice COBOL/web e ricerca tecnica.
Dispensa completa del corso
Workshop AI per codice e operatività day-to-day
Sessioni 1-4
Mercoledì 20 maggio 2026
Corso in 4 incontri
AI per programmazione
workflow agentici, automazioni interne e casi d'uso pratici
Riepilogo operativo
Che cosa è stato affrontato
Strumenti agentici
Differenza tra chat tradizionale e strumenti che lavorano su progetto, file system, terminale e browser.
Contesto mainframe
Ambienti cliente isolati, dati sensibili, copia-incolla limitato e uso degli screenshot come input.
Demo pratica
Creazione di dati mock, web app locale, caricamento screenshot, OCR programmatico, note ed export CSV.
Chat, progetto, agente
Da assistente a strumento operativo
La differenza pratica è l'accesso al progetto e agli strumenti necessari per verificare il lavoro.
Chat tradizionale
Utile per spiegazioni, snippet, revisione di testi e ragionamento su contenuto incollato.
Agente su progetto
Utile quando il risultato deve diventare file, app, script, test o modifica verificabile.
Prima dei tool
Privacy, dati e permessi
La sessione ha richiamato alcune verifiche minime prima di usare strumenti AI con materiale di lavoro.
Condivisione dati
Controllare le impostazioni del servizio e disattivare il training sui dati quando l'opzione è disponibile.
Dati reali
Per sviluppo e demo usare dataset mock o esempi anonimizzati, non dati cliente.
Permessi dell'agente
Valutare accesso a file, browser, terminale e presenza di file sensibili come .env.
COBOL / mainframe
Il vincolo principale: portare fuori il contesto
Nel lavoro su ambienti cliente non sempre è possibile copiare codice, errori o schermate in modo diretto.
Copia-incolla limitato
Il problema non è solo scrivere codice: spesso mancano input trasferibili verso l'AI o verso strumenti propri.
Error tracking
I codici degli errori e i dati dei job possono restare bloccati dentro schermate mainframe o sessioni remote.
Screenshot come input
Gli screenshot diventano un passaggio realistico per estrarre dati tramite OCR o modelli vision.
Caso pratico
Workflow costruito durante la demo
Obiettivo: ottenere una web app locale per consultare errori mainframe, aggiungere note e riesportare i dati.
Descrizione del problema
Job notturni, errori, motivi, soluzioni e stato di lavorazione.
Dataset mock
CSV realistico generato senza dati sensibili.
Web app locale
Caricamento CSV, filtri, modifica campi, note ed export.
Screenshot mainframe
Immagine mock usata come input di test.
OCR programmatico
Estrazione dei record e parsing dei campi.
CSV finale
Dati visualizzati in UI pulita e scaricabili.
Molti tool interni piccoli possono arrivare a una prima versione funzionante in one-shot con Codex o strumenti simili.
Sviluppo senza dati sensibili
Dataset mock e schema dati
CampoUso nella demo
JobNameidentifica job o procedura
Data / ora esecuzionecolloca temporalmente l'errore
Return code / abendclassifica il problema
Motivodescrive la causa rilevata
Soluzione temporaneaazione immediata
Soluzione definitivacorrezione strutturale
Stato / autoreavanzamento e responsabilità
Codex
Impostazione del progetto e prime scelte
La demo ha usato una cartella progetto con i file di lavoro e ha definito prima le funzioni della web app.
Scelte emerse: vista tabella e schede, filtri, campi modificabili, stato di lettura, download del CSV aggiornato.
Mainframe → app locale
Problema affrontato nella demo
Chi lavora sul mainframe non sempre può copiare facilmente i codici degli errori o passarli all'AI e ai propri strumenti di tracking.
Input disponibile
Schermata mainframe o screenshot mock con lista di job, return code, orari e altri campi.
Elaborazione
Caricamento dello screenshot nella web app, OCR programmatico, parsing dei record e correzioni mirate sui caratteri problematici.
Output
Interfaccia leggibile per consultare gli errori, aggiungere note operative e scaricare un CSV aggiornato.
Risultato della demo
Web app locale per CSV e screenshot
CSV
Caricamento dati, ricerca, filtri, stato e download del file aggiornato.
Screenshot
Caricamento immagine, OCR locale/programmatico e import dei record estratti.
Note e modifiche
Campi operativi modificabili, indicatore di modifica e copia negli appunti.
Sintesi operativa
Punti da ricordare
Partire piccolo
Un tool locale con input e output chiari è un buon primo caso d'uso per strumenti agentici.
Usare dati mock
Prima si replica la forma dei dati; solo dopo si valuta come gestire dati reali, permessi e sicurezza.
Far testare all'agente
Codex può avviare server, usare browser, verificare funzioni e correggere problemi emersi nel test.
OCR e vision
Screenshot e OCR sono una strada praticabile quando l'ambiente mainframe non permette esportazioni dirette.
Sviluppi successivi
Database, dashboard, deploy controllato e diagrammi di esecuzione COBOL sono estensioni naturali del caso visto.
Workflow su progetti reali
Riepilogo dei temi affrontati
Il lavoro è partito dal prototipo della web app errori e ha raccolto casi d'uso emersi dagli schermi condivisi dai partecipanti.
File di lavoro
Excel strutturati, Excel complessi, TXT esportati dal mainframe e dati da anonimizzare.
Strumenti agentici
Codex e Antigravity su cartella progetto, con permessi, test, comandi e iterazioni.
Output possibili
Visualizzatori, documentazione Docusaurus, scraper PDF, snippet JCL/ZCL, Git e test.
Excel / TXT / mainframe
Lavorare con Excel: strutturati vs complessi
Abbiamo distinto due scenari molto diversi: file tabellari usabili come database e fogli Excel costruiti per uso umano.
Excel strutturati come database
Colonne coerenti, intestazioni chiare e un tipo di dato per campo. Bastano spesso poche righe per capire schema, significato e manipolazioni possibili.
Excel classici o non strutturati
Formule, riferimenti tra celle, layout particolari, celle unite e dati distribuiti nel foglio. L'AI deve leggere più contesto e fare più inferenze.
Indicazione pratica: l'AI lavora meglio quando i dati hanno una struttura tabellare prevedibile; con file complessi conviene far costruire piccoli script o tool di supporto.
Scelte operative
Perché Codex è utile sui file complessi
La differenza rispetto a una chat tradizionale è che l'agente può lavorare direttamente sui file e verificare il risultato.
Leggere il progetto
Può ispezionare CSV, Excel, TXT, cartelle di snippet, immagini e file generati, invece di ragionare solo su contenuto incollato in chat.
Scrivere codice di supporto
Può creare parser, utility, visualizzatori HTML, script di conversione o controlli sui dati, rendendo riutilizzabile il lavoro.
Testare e correggere
Può eseguire comandi, verificare build, aprire il browser, leggere errori e iterare fino a un risultato funzionante.
Chat tradizionaleutile per spiegazioni, snippet e ragionamento su testo fornito manualmente
Agente su progettoutile quando il risultato deve diventare file, app, script, documentazione o test
Output riutilizzabilenon solo una risposta, ma uno strumento verificabile che resta nella cartella progetto
Token, modelli, privacy
Uso efficiente degli strumenti AI
Abbiamo discusso quote, reasoning, scelta del modello e attenzione ai dati prima di caricare materiale aziendale reale.
Modelli forti
Più adatti a pianificazione, architettura, debug, refactoring e file difficili; consumano più risorse.
Modelli rapidi
Utili per modifiche semplici, piccoli fix UI, testi e task ripetitivi con contesto limitato.
Quote e uso parallelo
Lanciare più agenti su più progetti consuma molto più velocemente rispetto a un uso sequenziale.
Dati sensibili
Anonimizzare codici e riferimenti, usare ambienti enterprise e mantenere intatta la struttura utile al test.
Per MVP e prototipi può convenire usare un modello forte per ottenere una buona prima versione, poi rifinire con iterazioni più mirate.
File TXT mainframe
Dal file TXT alla comprensione delle relazioni
Un caso discusso riguardava un file esportato dal mainframe con relazioni tra sistemi, job, applicazioni e dipendenze operative.
Capire la struttura
Prima di visualizzare, l'agente deve riconoscere formato, righe, codici e tipo di relazione tra gli elementi.
Anonimizzare
Il file può essere reso sicuro per i test modificando codici e riferimenti senza rompere formato e collegamenti.
Visualizzare
Mermaid o Markdown sono utili per diagrammi semplici; un visualizzatore HTML serve quando le relazioni sono molte.
Risultato interessantenon solo diagrammi statici, ma una pagina HTML interattiva per esplorare nodi e collegamenti
Evoluzione possibileweb app interna che carica un nuovo TXT, lo analizza e rigenera il grafo
StrumentiCodex e Antigravity lavorano in modo simile: cartella progetto, file, terminale, permessi e iterazioni
PDF / scraping / workflow
Scraper intelligente per dati pubblicati in PDF
Il caso discusso riguardava una pagina ufficiale dove vengono pubblicati periodicamente PDF con dati finanziari.
Controllo pagina
Verificare se esiste un nuovo documento, scaricare il PDF corretto e associare il file al trimestre giusto.
Estrazione tabella
Combinare testo estratto dal PDF, screenshot della tabella e un CSV passato già corretto come esempio.
Controllo anomalie
Segnalare nuove categorie, classi di importo, colonne inattese o formati incompatibili con gli output precedenti.
Dashboard workflow
Registrare ultima esecuzione, stato, errori, anomalie, output e log invece di lasciare script isolati.
Crea webapp CSV errori
•••
Vorrei una semplice webapp statica che si prenda in pasto un foglio CSV con errori riscontrati da parte del wireframe della banca e li impagini con una buona UI che mi faciliti la consultazione di questi errori. Vorrei anche poter segnalare quali errori ho letto e poi scaricare il CSV aggiornato.
Worked for 4m 58s ›
Ho trovato un CSV piccolo e pulito: 10 errori, 11 colonne, separatore virgola, già con date/stato/autore/tipologia. Restano scelte di prodotto che incidono sul file esportato e sull'esperienza di consultazione.
Plan
Webapp Statica per Errori Mainframe
Vista tabella e schede, filtri, campi modificabili, stato di lettura, download del CSV aggiornato.
crea un nuovo progetto cloudflare pages e caricaci questa interfaccia
Worked for 4m 5s ›
Fatto: ho creato il nuovo progetto Cloudflare Pages registro-errori-mainframe e caricato l'interfaccia.
URL pubblico verificato:
https://registro-errori-mainframe.pages.dev/Per ridistribuire aggiornamenti dalla cartella progetto:
bashcd "/Users/ig/dev/Tualba/Primo test codex 01"
npx wrangler pages deploy . --project-name registro-errori-mainframe --branch main
Crea la documentazione di questo progetto con Docusaurus. Usa questo verde presente nell'immagine come accent color, white mode per tutto di default
Worked for 16m 30s ›
Fatto. Ho creato la documentazione Docusaurus in docs-site, con tema light di default, switch dark disabilitato e accent color verde #bcda56 campionato dall'immagine.
La documentazione locale è già avviata qui:
http://127.0.0.1:3000/Comandi utili:
bashcd "/Users/ig/dev/Tualba/Primo test codex 01/docs-site"
npm run start
Build produzione:
bashcd "/Users/ig/dev/Tualba/Primo test codex 01/docs-site"
npm run build
npm run serve -- --host 127.0.0.1 --port 3000
Verifiche fatte: npm install, npm run build ok, check browser ok su homepage, tema light, background bianco, accent #bcda56, nessun errore console.
▣deploy.mdDocument · MD
▣guida-utente.mdDocument · MD
▣intro.mdDocument · MD
Show 4 more ⌄
⊞Edited 16 files+685 -1
docs-site/docs/deploy.md +43 -0
docs-site/docs/guida-utente.md +35 -0
docs-site/docs/intro.md +31 -0
Show 13 more files ⌄
May 27, 1:48 PM
Fai degli screenshot dove ha senso e inseriscili nella documentazione
Worked for 3m 38s ›
Fatto. Ho aggiunto screenshot reali in docs-site/static/img/screenshots/ e li ho inseriti nelle sezioni Docusaurus più utili: panoramica, guida utente, OCR, stati/modifiche e sviluppo locale.
Build verificata con:
bashcd "/Users/ig/dev/Tualba/Primo test codex 01/docs-site"
npm run build
Risultato: build OK, immagini renderizzate correttamente, nessun errore console nel browser.
▣guida-utente.mdDocument · MD
▣intro.mdDocument · MD
▣ocr-screenshot.mdDocument · MD
Show 6 more ⌄
⊞Edited 5 files+18 -0
docs-site/docs/guida-utente.md +6 -0
docs-site/docs/intro.md +6 -0
docs-site/docs/ocr-screenshot.md +2 -0
Show 2 more files ⌄
May 27, 1:53 PM
Pubblica la documentazione docusaurus come un nuovo progetto di cloudflare pages, chiamalo documentazione tualba error tracker
Worked for 2m 1s ›
Fatto. Ho creato il nuovo progetto Cloudflare Pages:
documentazione-tualba-error-tracker
URL pubblico verificato:
https://documentazione-tualba-error-tracker.pages.dev/Ho anche aggiornato docs-site/docusaurus.config.js e la pagina docs/deploy.md per puntare al nuovo dominio della documentazione.
Per pubblicare futuri aggiornamenti:
bashcd "/Users/ig/dev/Tualba/Primo test codex 01/docs-site"
npm run build
npx wrangler pages deploy build --project-name documentazione-tualba-error-tracker --branch main
Verifiche fatte: build Docusaurus ok, deploy ok, homepage pubblica HTTP 200, rotta /docs/intro raggiungibile.
▣deploy.mdDocument · MD
⊞Edited 2 files+22 -3
docs/deploy.md +20 -1
docusaurus.config.js +2 -2
12:13 PM
Ask for follow-up changes
+Full access5.5 Extra High
Nuova scheda
Usa avanti per tornare alla documentazione.
Snippet e versioning
Generazione di scheletri JCL/ZCL e gestione Git
Sono stati discussi progetti piccoli ma utili: cartelle di snippet, istruzioni persistenti e commit ordinati.
Snippet locali
Blocchi JCL/ZCL già ordinati e formattati, suddivisi per tipologia, usati come base per generare scheletri coerenti.
Istruzioni persistenti
Regole importanti in README, file di istruzioni, esempi di output e convenzioni di naming; non solo nella chat.
Commit atomici
L'AI può leggere le modifiche, separarle in commit sensati e proporre messaggi descrittivi coerenti.
Merge conflict
Può aiutare a risolvere conflitti leggendo entrambe le versioni, ma il risultato va verificato con test o review.
COBOL legacy
Documentazione, test e refactoring
La parte finale della sessione ha anticipato il lavoro su programmi COBOL storici e routine difficili da modificare.
Documentazione automatica
AI per spiegare codice legacy, produrre documentazione tecnica e funzionale, manuali, guide SIT e pagine navigabili.
Test case
Definire input, output attesi, casi limite, quadrature e confronti prima/dopo per ridurre il rischio del refactoring.
Riscrittura controllata
Refactoring o migrazione verso Java, Python, C o altri linguaggi ha senso solo se il comportamento è verificabile.
Vincolo principalei sorgenti e gli ambienti mainframe non sono sempre accessibili da Git o da una cartella locale
Approccio prudentepartire da una routine specifica, documentarla, generare casi di test e solo dopo riscriverla
Prossima sessioneanalisi di una routine COBOL reale, documentazione tecnica/funzionale e uso CLI/server
Riepilogo operativo
Punti da portare alla sessione successiva
Portare materiale circoscritto
Una routine, un file, un output atteso o una schermata sono più utili di una richiesta troppo generica.
Separare dati e struttura
Anonimizzare i dati sensibili senza distruggere formato, relazioni e casi limite necessari al test.
Chiedere output verificabili
Script, test, CSV, documentazione o web app sono più controllabili di una spiegazione isolata.
Tenere traccia
Git, note, log e documentazione servono a capire cosa è cambiato e perché.
Obiettivo del modulo su MVP, CLI e COBOL
Questa parte del corso si è concentrata su un workflow più trasversale rispetto agli argomenti precedenti.
L’obiettivo era mostrare come usare strumenti agentici come Codex, Antigravity e Gemini non solo su codice COBOL/mainframe, ma anche per:
- creare applicativi full-stack;
- lavorare con front-end, back-end e database;
- prototipare MVP;
- usare AI generativa dentro applicazioni reali;
- analizzare e rifattorizzare codice legacy.
Da coding assistant a coding agent
Abbiamo visto la differenza tra una semplice chat AI e un agente di coding.
Un coding agent può:
- leggere file di progetto;
- modificare codice;
- usare il terminale;
- installare dipendenze;
- eseguire test;
- aprire browser o preview;
- fare screenshot;
- iterare sul risultato.
Questo permette di passare da “chiedere codice” a far costruire parti funzionanti di un’applicazione.
Codex CLI e lavoro da terminale
Abbiamo introdotto Codex CLI come modo per usare Codex da terminale.
Concetti principali:
- Codex può essere lanciato dentro una cartella progetto;
- ogni progetto può avere una o più conversazioni;
- è possibile riprendere conversazioni precedenti;
- si può usare sia in locale sia su server;
- su server headless si può accedere tramite device code.
La CLI rende Codex più adatto a workflow tecnici e ambienti remoti.
ssh linux-ig · Codex CLI · gestionale Pokémon
Caricamento transcript...
Locale vs server remoto
Abbiamo confrontato l’uso di Codex sul laptop con l’uso su server.
Lavorare su server può essere utile perché:
- il laptop resta più leggero;
- i task possono durare più a lungo;
- l’ambiente è più isolato;
- è più facile lavorare su MVP e prototipi;
- l’agente può continuare a lavorare anche se il computer locale viene chiuso.
Per iniziare va bene il locale, ma per workflow avanzati il server è spesso più comodo.
Cartella progetto e permessi
Un punto operativo importante: Codex va lanciato dentro una cartella progetto dedicata.
Meglio evitare di avviarlo dalla home directory, perché lì potrebbero esserci file personali o dati non necessari.
Abbiamo anche visto che i permessi possono essere gestiti su diversi livelli:
- chiedere conferma prima dei comandi;
- concedere maggiore autonomia;
- usare full access solo in ambienti controllati;
- essere più prudenti su progetti reali o sensibili.
Modelli, reasoning e fast mode
Abbiamo ripreso il tema dell’uso efficiente dei modelli.
Indicazioni pratiche:
- modelli più forti per architettura, planning e debugging;
- modelli più piccoli per task semplici o implementazioni guidate;
- fast mode utile quando serve iterare rapidamente;
- fast mode consuma più token;
- account gratuiti richiedono più attenzione ai consumi.
Il punto chiave: usare il modello giusto per il task giusto.
Creare un MVP full-stack da prompt
La demo principale è stata la creazione di un applicativo completo partendo da un prompt naturale.
L’app scelta era un gestionale per carte Pokémon, con:
- back office;
- inventario;
- dettaglio carta;
- prezzi;
- quantità;
- pagina vendita;
- shop pubblico;
- database;
- containerizzazione.
L’obiettivo era mostrare quanto si può ottenere con un singolo prompt ben strutturato.
Nuova scheda
Usa avanti per tornare a Tualba CardVault.
Struttura di un buon prompt per un’app
Il prompt è stato costruito specificando:
- contesto: chi siamo e perché serve l’app;
- obiettivo: cosa deve fare il gestionale;
- dati: carte, prezzi, quantità, stato, lingua;
- funzionalità interne: inventario e vendite;
- funzionalità pubbliche: shop client-facing;
- integrazioni: immagini e prezzi di mercato;
- stack tecnico: frontend, backend, database, Docker;
- evoluzioni future: compatibilità con Stripe.
Più il prompt descrive il workflow reale, migliore sarà la base generata.
Stack tecnico generato
L’applicativo è stato richiesto con uno stack completo:
- front-end;
- back-end;
- database Postgres;
- Prisma Studio;
- Docker;
- Docker Compose;
- link accessibili da rete interna.
Questo mostra che l’AI può generare non solo schermate, ma anche architettura applicativa, servizi e configurazione.
UI library e qualità del front-end
Abbiamo introdotto ShadCN UI come libreria utile per dashboard e gestionali.
Vantaggi:
- componenti già pronti;
- UI moderna;
- layout ordinati;
- buona base per MVP;
- componenti modificabili.
Abbiamo anche confrontato strumenti diversi: Gemini e Antigravity tendono spesso a produrre front-end più curati, mentre Codex migliora molto se viene guidato con stile, immagini o vincoli precisi.
Usare immagini come riferimento UI
Un workflow avanzato visto in sessione:
- generare un mockup con un modello immagine;
- usare l’immagine come riferimento;
- chiedere a Codex di implementare il front-end seguendo quello stile.
Questo aiuta a:
- definire meglio il look & feel;
- suggerire layout più ricchi;
- far emergere funzionalità non previste;
- migliorare la qualità percepita dell’interfaccia.
L’immagine diventa una sorta di brief visivo per l’agente.
Docker, persistenza e portabilità
Docker è stato usato per rendere l’app più portabile.
Serve a evitare il problema:
“Sul mio computer funziona, sul tuo no.”
Con Docker possiamo:
- fissare l’ambiente di esecuzione;
- avviare più servizi insieme;
- includere database e backend;
- facilitare il deploy su server;
- isolare dipendenze e versioni.
Abbiamo anche discusso l’importanza di persistenza dati, cartelle esterne e backup.
Deploy e Cloudflare
Abbiamo visto come un MVP locale può essere adattato per il deploy.
Cloudflare è stato citato come opzione pratica per piccoli tool perché offre:
- hosting per front-end;
- Workers per logica backend;
- database D1;
- piano gratuito utile per prototipi;
- gestione semplice rispetto ad altri cloud più complessi.
Il principio: se sappiamo dove vogliamo deployare, conviene dirlo all’AI già in fase di progettazione.
Multi-agent workflow
Abbiamo discusso la possibilità di far lavorare più agenti sullo stesso progetto.
Esempio:
- Antigravity crea una prima versione;
- Codex modifica o completa il progetto;
- VS Code permette di ispezionare e intervenire manualmente;
- Git tiene traccia delle modifiche.
Questo può aumentare la produttività, ma richiede controllo: più agenti possono anche generare conflitti o modifiche inattese.
Modalità Goal e task lunghi
È stata introdotta la modalità Goal di Codex.
È utile quando il task è:
- ampio;
- misurabile;
- verificabile;
- composto da molte attività simili.
Esempi possibili:
- documentare molti programmi;
- generare test per molte routine;
- analizzare una codebase ampia;
- processare tanti file.
Attenzione: se l’obiettivo non è ben definito, l’AI può lavorare a lungo nella direzione sbagliata.
Analisi di codice COBOL legacy
Nella seconda parte siamo passati a un programma COBOL reale, lungo circa 6.400 righe.
L’obiettivo era capire come affrontare un refactoring importante.
Codex ha analizzato:
- struttura del programma;
- working storage;
- copybook;
- flusso di controllo;
- paragrafi logici;
- uso di
GO TO; - aree tabellari;
- regole di business distribuite.
Il primo valore dell’AI qui non è riscrivere subito, ma aiutare a capire dove intervenire.
Refactoring COBOL: prima test, poi riscrittura
La conclusione principale sul COBOL è stata: non partire da “riscrivi tutto”.
Prima serve costruire una base di verifica.
Workflow consigliato:
- mappare il comportamento attuale;
- raccogliere input reali o rappresentativi;
- salvare gli output originali;
- creare golden master test;
- isolare sezioni o paragrafi critici;
- rifattorizzare per blocchi;
- confrontare sempre gli output.
Senza test affidabili, un refactoring di codice legacy è troppo rischioso.
Costi, token e uso aziendale
Abbiamo chiuso con alcune considerazioni sull’uso aziendale degli agenti AI.
Messaggi chiave:
- molte aziende stanno investendo seriamente in questi strumenti;
- i costi possono crescere molto se l’uso non è controllato;
- una subscription può essere più conveniente dell’uso API puro;
- non bisogna misurare il successo in token consumati;
- il valore va misurato in produttività, qualità e tempo risparmiato.
Il tokenmaxxing NON è una best practice.
Refactoring COBOL con Codex
•••
Questo è un progetto di refactoring della nostra codebase in Cobol. In questo progetto c’è un solo programma, piccola parte di un refactoring molto più grande, su cui dovremmo fare una prova di refactoring. Vorremmo inoltre testarlo per accertarci che funziona come dovrebbe, motivo per cui ti abbiamo fornito anche i file in input.
Fai un’analisi per capire se hai tutto quanto ti serve per procedere, e se hai dei suggerimenti su come procedere dimmi pure.
Considera queste corrispondenze tra il codice nel file cobol e i nomi di file in input:
AF = OF91P AC = FI80IC34 BC = FI80IC39 CC = FI80IC86 TT = OF63E TX = nessun file SYSIN = FI80OF92 FPARIST0 = FPARIST DEROGHE = DEROIC86 PRFLOOR = FLORIC86
Worked for 4m 18s ›
Inizio mappando struttura del progetto, sorgente COBOL e dataset disponibili; poi verifico se le assegnazioni file nel programma sono coerenti con le corrispondenze indicate.
Ho trovato un solo sorgente principale, 5 copybook e tutti i dataset indicati; la directory non è un repository Git.
Il programma apre tre alias per TT e due alias per AF, quindi la parametrizzazione lunghezza record è una parte importante del test.
I dati non sono EBCDIC puro: vedo ASCII per i campi alfanumerici e byte binari/packed decimal nei campi COMP-3, coerente con dump di record mainframe.
Per AC, BC e AF torna un pattern chiaro: lunghezza logica COBOL più CRLF, con un byte finale 0x1A. CC/FI80IC86 richiede verifica più attenta.
Manca cobc nell’ambiente, quindi non posso fare una compilazione locale immediata. Per una prova end-to-end serviranno anche le routine chiamate dinamicamente o stub compatibili.
Analisi iniziale
Per fare analisi e iniziare un refactoring controllato del programma principale c’è abbastanza: codice da analizzare/RRZ824.COB e copybook sono presenti. Per eseguire un test end-to-end locale, invece, mancano alcuni pezzi.
Cosa torna
- Le SELECT principali sono coerenti con la mappa: AC, AF, BC, CC, TT.
- SYSIN non è una SELECT: viene letto con
ACCEPT IF92. Il file FI80OF92 contiene un record da 25 byte valido. - TX non serve come file separato: TX00/TX67/TX99 sono record di output per TT.
- OF63E è utile come golden master: 310.904 record da 124 byte.
Punti critici
- Il compilatore COBOL non è installato sull’host.
- Mancano JCUBFLOR, JCUBGTFS, XSXDATA, XSCINF e ILBOABN0.
- I dataset .TXT hanno CRLF e byte finale 0x1A.
- FI80IC86 sembra trasferito con trimming di spazi finali: va paddato a 147 byte.
Suggerimento operativo
- Normalizzare gli input: rimuovere CRLF/0x1A e paddare FI80IC86 a 147 byte.
- Usare OF63E come golden master normalizzato.
- Eseguire il programma con default AF=153 e TT=124.
- Confrontare output TT byte-per-byte e controllare i contatori finali DISPLAY.
- Solo dopo fare refactoring incrementale.
C’è anche un possibile bug già visibile: AF00-IDLIN2 viene mosso su WB55-IDLDC2 e WD91-IDLDC2, poi subito sovrascritto da AF00-IDLDC2. Sembra un copia/incolla, ma lo toccherei solo dopo golden master.
Demo COBOL · analisi iniziale
Questa che stiamo affrontando adesso è una demo dove sto mostrando ad un team che lavora in Cobol come possono utilizzare Codex per fare un refactoring di questo genere. Vorrei quindi che tagliassimo qualche angolo e procedessimo con la demo giusto per dimostrare il processo.
Pensa a cosa puoi fare per dimostrare le tue capacità di riuscita. Magari prova anche a mostrare un po’ di refactoring smart anche senza fare dei test, giusto per dimostrare che ne sei in grado.
Worked for 6m 42s ›
Per la demo scelgo un taglio pragmatico: un refactoring reale ma circoscritto, senza provare a modernizzare tutto il monolite.
Ho individuato un punto adatto: il blocco F90TT contiene due copie quasi identiche della scrittura TT, e l’inizializzazione dei parametri si presta a EVALUATE TRUE.
Procedo con due modifiche dimostrative: trasformo la cascata di IF in EVALUATE TRUE e centralizzo la scrittura TT in un paragrafo F90WR.
Normalizzo i terminatori perché la patch aveva introdotto alcune righe LF in un file quasi tutto CRLF.
I controlli statici confermano l’effetto: le tre WRITE TX* ora esistono in un solo punto, richiamato da due percorsi.
Refactoring demo reale e circoscritto
⊞Edited 2 files+demo -dup
codice da analizzare/RRZ824.COB EVALUATE TRUE + F90WR
demo-refactoring-RRZ824.md nota demo
- In
RRZ824.COB:1733la cascata di IF sui parametri TT/AF diventa una tabella decisionale leggibile conEVALUATE TRUE. - In
RRZ824.COB:5625la scrittura TT viene centralizzata: i due rami chiamanoPERFORM F90WR THRU F90WR-FN. - Il nuovo paragrafo gestisce scelta TX00/TX99/TX67, skip degli standard STDNO e incremento contatore.
- Non ho compilato in questa fase:
cobcnon è disponibile e mancano le routine dinamiche.
Demo COBOL · refactoring dimostrativo
Installa un compilatore cobol e fai una prova in più
Worked for 12m 7s ›
Installo GnuCOBOL se il sistema lo consente, poi provo almeno una compilazione statica del programma.
sudo apt-get richiede autenticazione interattiva. Provo una strada senza privilegi.
Docker è disponibile senza sudo. Uso quindi un’immagine locale con GnuCOBOL: è la soluzione più rapida per la demo e non richiede privilegi sull’host.
cobc funziona nel container: GnuCOBOL 3.2.0. Rendo l’installazione ripetibile con un Dockerfile.
La compilazione di sintassi passa: solo warning di dialetto/copybook senza newline, nessun errore.
Preparo uno smoke test eseguibile: driver COBOL + stub minimi per le routine dinamiche.
La build completa riesce: abbiamo RRZ824.so, gli stub dinamici e il driver.
Lo smoke con SYSIN vuoto funziona e restituisce RETURN-CODE=12 nel punto atteso.
Con SYSIN reale e input normalizzati il programma legge IF92, costruisce la tabella parametri fino a 39 elementi e poi si ferma in F9999 perché gli stub non implementano la logica business esterna.
Compilatore e smoke test via Docker
Ho installato GnuCOBOL in modo ripetibile via Docker, perché sudo apt-get sull’host richiedeva autenticazione interattiva.
bashdocker build -t analisi-cobol-gnucobol:local tools/gnucobol
docker run --rm -v "$PWD:/work" analisi-cobol-gnucobol:local cobc --version
File aggiunti
tools/gnucobol/Dockerfiletools/gnucobol/README.mdtools/gnucobol/prepare_inputs.pydemo/smoke/DRVRRZ824.COB
Risultati
RRZ824.COBpassa la compilazione di sintassi con GnuCOBOL.- Smoke con SYSIN vuoto: termina con messaggio previsto e exit code 12.
- Smoke con SYSIN reale: arriva più in profondità, fino al limite previsto dagli stub.
- Log principale:
build/gnucobol-data/output/full-smoke.log.
Demo COBOL · compilazione e smoke test
Da che parte sono salvati l'immagine e il container docker che hai usato?
Worked for 41s ›
Controllo la configurazione Docker locale, perché l’immagine non viene salvata come file nel progetto: Docker la mette nel suo storage interno. Verifico anche se restano container creati da quella immagine.
Risposta
L’immagine Docker è salvata nello storage interno di Docker:
/var/lib/docker
Tag immagine usato:
analisi-cobol-gnucobol:local
- Image ID:
sha256:7a408a2a912101fe1fa4c820179efd3ef35a9b5b082d97133e717e2dbe00cefd - Creata:
2026-06-17T11:02:54+02:00 - Size mostrata da
docker images: 465MB
Il container non è rimasto salvato: è stato sempre lanciato con --rm, quindi Docker lo ha eliminato automaticamente a fine esecuzione. Il Dockerfile sorgente resta nel progetto: tools/gnucobol/Dockerfile.
Summarize recent commits
Ask for follow-up changes
+Full accessgpt-5.5 xhigh · ~/dev/tualba/analisi-cobol-01L
Trainer
Ignas Gaucys
Senior AI Engineer & Trainer
- Aiuto le compagnie ad implementare l'AI moderna nei loro prodotti e processi, e offro servizi di formazione sul tema dell'intelligenza artificiale.
- Precedentemente, per oltre 3 anni ho ricoperto il ruolo di COO in una startup, dove ho gestito i team del prodotto e guidato lo sviluppo di una piattaforma che faceva una forte leva sull'AI.
1 / 45