IBM i e Intelligenza Artificiale: le risposte alle domande che tutti si fanno (con esempi)
L'IA sta arrivando anche su IBM i. Ma come si fa, concretamente, a preparare i dati? E quali sono gli ostacoli reali? Ecco le risposte alle domande più comuni, con esempi pratici.
Come posso preparare i dati di IBM i per l'intelligenza artificiale?
La risposta è più semplice di quanto sembri: parti da dove i dati vivono già.
Il DB2 for i contiene anni di storia aziendale: ordini, clienti, fatture, movimenti.
È un patrimonio informativo enorme.
Il problema è che spesso questo tesoro è chiuso in una cassaforte con etichette scritte in una lingua che l'IA non capisce.
Facciamo un esempio. Immagina una tabella DB2 for i con un campo chiamato CUSNM. Tu sai che significa "customer name". Ma un modello di IA che lo vede per la prima volta che cosa capisce? Niente. Potrebbe pensare a un codice fiscale, a un numero di serie, a un codice interno. Stessa cosa per ORDDT (order date) o ITMNBR (item number). Sono abbreviazioni nate decenni fa, quando i nomi dei campi potevano avere al massimo 10 caratteri. Erano un compromesso necessario. Oggi sono un ostacolo.
E qui arriva il primo trucco che forse non tutti conoscono. DB2 for i, nella sua parte SQL, supporta nomi di colonna fino a 128 byte. Come? Usando il costrutto FOR COLUMN quando crei la tabella:
sql
CREATE TABLE CLIENTI (
CUSNM FOR COLUMN customer_name CHAR(30),
ORDDT FOR COLUMN order_date DATE
);Così le applicazioni legacy continuano a usare CUSNM e ORDDT, mentre gli strumenti moderni (SQL, ODBC, e i modelli di IA) vedono customer_name e order_date. Un piccolo stratagemma che fa una differenza enorme.
Quali sono i limiti dei nomi dei campi in DB2 for i e come si superano?
Il problema non è solo "quanto sono lunghi i nomi", ma quanto sono documentati e contestualizzati. Ci sono tre ostacoli principali:
1. Il limite storico dei 10 caratteri. I nomi nativi di DB2 for i sono spesso criptici: CUSNM, ORDDT, ITMNBR. Per un modello di IA, sono rumore. La soluzione è usare FOR COLUMN per assegnare un nome lungo e descrittivo in SQL, mantenendo l'alias corto per le interfacce legacy.
2. I caratteri speciali. I nomi nativi di IBM i possono contenere @, # e $. Peccato che molti driver ODBC e strumenti di data warehousing li digeriscano male. Se prevedi di esportare i dati verso l'IA, meglio evitarli.
3. La deriva semantica. In un sistema lo stesso concetto si chiama CUSNM, in un altro CLINOME, in un terzo NOMECLI. Per un essere umano è chiaro che sono la stessa cosa. Per un modello di IA no. Serve una mappatura, un dizionario che dica: "questi tre nomi significano tutti customer_name".
La soluzione più pragmatica è costruire un data layer intermedio. Sincronizzi i dati da DB2 for i verso un data warehouse cloud (con tecniche come CDC, Change Data Capture), e lasci che l'IA lavori su quella copia. Il core transazionale resta intoccato. La sicurezza di IBM i resta intatta.
Cos'è X-Analysis e perché è utile per l'intelligenza artificiale?
X-Analysis è uno strumento che analizza le applicazioni IBM i da oltre 25 anni. Usato da aziende come Fiserv, Mazda, Siemens e Halliburton, nelle ultime release è stato potenziato con funzionalità di IA che lo rendono perfetto per chi vuole preparare i dati di IBM i a un percorso di intelligenza artificiale.
Cosa fa concretamente?
Immagina di avere un programma RPG scritto vent'anni fa. Dentro c'è un campo CUSNM. Nessuno si ricorda più cosa significhi esattamente. X-Analysis analizza il codice sorgente, ricostruisce il data flow e ti dice esattamente cosa fa quel campo, dove viene usato e come si collega al resto dell'applicazione.
E non si ferma qui. X-Analysis è in grado di estrarre automaticamente i nomi lunghi per i campi, riutilizzando il testo descrittivo dei file concatenato con underscore. In pratica, quello che per te era CUSNM diventa customer_name. Tutto automaticamente, senza scrivere una riga di codice.
E con l'IA? X-Analysis AI utilizza il repository di analisi come base per il RAG (Retrieval Augmented Generation), permettendo di interrogare l'applicazione in linguaggio naturale. In pratica, puoi chiedere: "Spiegami cosa fa questo programma" e ottenere una risposta basata sulla realtà del codice, non su supposizioni. E con il supporto MCP (Model Context Protocol), strumenti come IBM Bob possono interrogare direttamente il repository di X-Analysis durante lo sviluppo.
Perché non posso connettere l'IA direttamente al DB2 di produzione?
È una cattiva idea, e i motivi sono concreti:
Carichi imprevedibili: un agente IA può lanciare query pesanti a qualsiasi ora.
Problemi di sicurezza: l'IA moltiplica le vie d'accesso al sistema tramite protocolli come ODBC, SSH, DRDA e HTTP, superando il vecchio perimetro protetto dei terminali 5250.
Blocchi e contenzioni: il core transazionale potrebbe rallentare .
Come evidenziato dall'esperto Richard Dolewski su IT Jungle, il modello nativo "Deny by Default" di IBM è ancora valido, ma non basta più.
Per implementare l'IA in sicurezza, servono strategie basate su quattro pilastri:
visibilità totale del patrimonio informativo,
controllo operativo granulare dei flussi,
resilienza dell'infrastruttura
governance rigida dei profili di accesso.
La strada giusta è il data layer: sincronizzi i dati da DB2 for i verso un ambiente dedicato (cloud o on-premise) e lasci che l'IA lavori su quella copia.
Il core resta intoccato.
Come si estraggono le business rule dal codice RPG e COBOL per l'IA?
X-Analysis è in grado di estrarre le business rule dal codice RPG e COBOL, scrivendole in pseudo-codice o in inglese strutturato. Immagina di poter dire a un modello di IA: "Questa non è solo una query SQL. È una regola di business che dice che un ordine può essere spedito solo se il cliente ha un credito positivo". X-Analysis te lo documenta automaticamente.
Questo è fondamentale perché le regole di business sono spesso sepolte nel codice, mescolate con logica di interfaccia, I/O su database e controllo di flusso. Senza estrarle e documentarle, qualsiasi modello di IA rischia di produrre risultati inutili o fuorvianti.
In sintesi: da dove si comincia?
Portare l'IA su IBM i non è fantascienza. È un lavoro di metodo:
Parti dai dati: il DB2 for i è il tuo patrimonio.
Rendi i nomi comprensibili: usa FOR COLUMN e strumenti come X-Analysis per creare un dizionario dei dati.
Estrai le business rule: documenta la logica che sta dietro ai dati.
Costruisci un data layer: sincronizza i dati con CDC e lascia che l'IA lavori su una copia.
Non toccare il core: la sicurezza di IBM i resta intatta.
E tu, quanti CUSNM hai nel tuo DB2? Forse è il momento di dare loro un nome vero. 😉
tratto dall'articolo
Commenti