Lavorare con IBM i con IBM Bob

Se non hai mai scritto una riga di RPG, IBM i è una delle piattaforme più affascinanti per la produzione su larga scala. Se ne hai scritte qualche milione di righe, sai già dove vive il dolore quotidiano. Questo post copre entrambi: uno schizzo tecnico di ciò che rende IBM i unico, dove l'attrito della modernizzazione si manifesta realmente, come IBM Bob si inserisce in un workflow IBM i oggi, i passaggi di configurazione per iniziare, e cosa c'è dopo sulla roadmap per la piattaforma.

Cos'è realmente IBM i

IBM i non è un sistema operativo legacy nel senso di "dovremmo riscriverlo". È una piattaforma integrata — l'OS, il database, il modello di sicurezza e il runtime sono progettati e distribuiti come una cosa sola — che genera entrate per banche, assicurazioni, ospedali, produttori e aziende di logistica da decenni. Quindi dovremmo chiamarlo leggendario.

Alcuni dettagli che tendono a sorprendere gli sviluppatori che lo vedono per la prima volta:

Single-level storage. RAM e disco condividono uno spazio di indirizzamento virtuale. I puntatori agli oggetti persistono attraverso i riavvii. L'OS tratta memoria e storage come un singolo livello e pagina tra loro in modo trasparente. La maggior parte dei sistemi moderni sta ancora recuperando terreno.
TIMI, il Technology Independent Machine Interface. I binari RPG compilati su hardware degli anni '90 girano senza modifiche sui chip POWER attuali. L'OS ritraduce contro il nuovo set di istruzioni sotto il cofano. L'analogo moderno più vicino è WebAssembly, decenni prima.
OS basato su oggetti. Programmi, file, code e autorizzazioni sono oggetti tipizzati con attributi — non file con metadati aggiunti. La sicurezza è applicata a livello di oggetto.
Db2 for i è integrato, non aggiunto. SQL e I/O nativo a livello di record accedono agli stessi dati. Un file fisico di 40 anni può essere interrogato attraverso una vista SQL moderna senza un progetto di migrazione.
Il source può vivere sul sistema o in Git — la tua scelta. Storicamente, il source IBM i era memorizzato come members all'interno di source physical files (QSYS), compilati direttamente sul sistema. La piattaforma originariamente posizionava la LPAR come fonte di verità. Ma IBM i si è evoluto: i compilatori e l'OS ora supportano completamente workflow moderni centrati su Git, file di stream IFS e sviluppo locale se lo scegli. Molti shop usano ancora le librerie QSYS, ma la piattaforma ti dà opzioni

La piattaforma supporta anche pattern di delivery moderni out of the box: motori di API REST nativi come parte dell'OS, cloud ibrido attraverso Power Virtual Server, e inferenza AI in esecuzione sullo stesso hardware dei carichi di lavoro transazionali. RPG, COBOL, CL e SQL coesistono con le pratiche di sviluppo che il resto della tua organizzazione di ingegneria già usa.

La piattaforma non è il problema. L'attrito è intorno ad essa.

Dove si manifesta l'attrito

Quattro pattern emergono in quasi ogni shop IBM i. Nessuno di essi riguarda RPG stesso — il linguaggio va bene — ma il contesto intorno al codice che non è mai stato scritto, e il modo in cui la piattaforma memorizza e condivide quel contesto.

Contesto implicito, by design. Un programma RPG funzionante può coprire quattro generazioni di linguaggio in un source — RPG II, RPG IV, copybook /COPY (dichiarazioni condivise incluse al momento della compilazione) e procedure in formato libero — con sintassi sensibile alle colonne e indicatori numerati (*IN01–*IN99) che fanno il lavoro che il flusso di controllo strutturato e i booleani nominati fanno nella maggior parte degli altri linguaggi. La sintassi è apprendibile in una settimana; le convenzioni e le regole di business intorno ad essa vivono nelle teste degli ingegneri senior.
Il cambiamento non è mai locale. Il tipo di un campo non è dichiarato nel programma che lo usa — è dichiarato nella tabella del database stessa, in un file source separato (un member DDS). Ogni programma che legge o scrive quella tabella eredita quelle definizioni semplicemente referenziando il file in cima. Quindi allungare una colonna da 10 a 12 cifre non è mai una modifica di un solo programma: si propaga attraverso ogni programma che tocca il file, e la lista di quei programmi è raramente scritta da qualche parte. Ogni cambiamento a un carico di lavoro critico comporta quindi un rischio di continuità, e la modernizzazione si blocca.
Il source vive raramente dove gli strumenti moderni se lo aspettano. La copia canonica di un programma è sul sistema, non in un repo Git su un laptop. Leggere codice che qualcun altro ha scritto quindici anni fa inizia con trovarlo sulla LPAR, esportarlo, e poi decidere se l'export è la copia canonica — un workflow a cui qualsiasi strumento che assume un albero di lavoro locale deve essere adattato prima di guadagnarsi il suo posto.
RPG a formato fisso non assomiglia per niente al codice moderno. La maggior parte del RPG di produzione è stata scritta in formato fisso: sintassi sensibile alle colonne dove i codici operativi vivono nelle colonne 26–35, Factor 1 in 12–25, e i commenti si adattano solo dopo la colonna 80. Si legge come linguaggio assembly per chiunque sia stato formato su Python o JavaScript. IBM ha reinventato il linguaggio con RPG completamente in formato libero (RPG IV, poi semplicemente "RPG"), che appare e si comporta come un linguaggio procedurale moderno — blocchi strutturati, variabili nominate, espressioni standard. Il gap di sintassi è reale, ma il linguaggio stesso si è evoluto. L'attrito è che decenni di codice funzionante sono ancora in formato fisso, e riscriverlo comporta un rischio che la maggior parte degli shop non può giustificare.

Cosa fa Bob su un'applicazione RPG per IBM i

Punta Bob verso un programma RPG e inizia in modalità Ask:

"Guidami attraverso cosa fa questo programma e quali file tocca."
"Dove viene impostato CUSTNO, e quali programmi lo leggono dopo?"
"Cosa si romperebbe se cambiassi la lunghezza di questo campo?"

Passa alla modalità Plan quando hai un cambiamento in mente: una conversione in formato libero, una migrazione SQL dall'I/O a livello di record, o spezzare un monolite in moduli. Bob produce un piano, le dipendenze che ha toccato, e i passaggi che intende fare, prima che qualsiasi file venga modificato.

Passa alla modalità Code per applicare il cambiamento. Bob:

Converte RPG a formato fisso in formato libero usando pattern ripetibili, file per file.
Migra I/O a livello di record a SQL embedded dove appropriato.
Genera suite di test RPGUnit contro procedure esistenti in modo che la conversione sia verificabile, non solo compilata.
Produce documentazione in linguaggio semplice e diagrammi Mermaid dal source — artefatti ricercabili e condivisibili che sopravvivono a qualsiasi singolo ingegnere.

Lo stesso workflow gestisce RPG II/III/ILE, CL, DDS, SQL e COBOL, quindi un nuovo assunto che legge un programma scritto prima che nascesse non è più bloccato dalla sintassi.

Rendi il tuo source IBM i Bob-ready

Bob oggi lavora contro source sul tuo computer locale. La configurazione è breve:

Scarica il tuo source. Esporta i tuoi member RPG, RPGLE, CL, DDS e SQL in una cartella locale. L'esploratore di progetti Code for i documenta l'export dai physical file members: migrate source
Apri la cartella in Bob. File → Open Folder sulla radice del source. Bob indicizza la codebase alla prima apertura.
Installa la toolchain IBM i. Dal pannello Extensions, aggiungi l'IBM i Development Pack (il bundle Code for i) e un renderer Mermaid per i diagrammi che Bob produce.
Avvia una sessione in modalità Ask. Scegli un singolo programma — idealmente uno che nessuno nel team comprende completamente — e chiedi a Bob di spiegarlo. Questo è il modo più veloce per vedere se Bob si guadagna il suo posto nel tuo workflow.

Se il tuo team proviene da SEU o RDi, la migrazione è principalmente il passaggio di export sopra più l'installazione dell'estensione. La superficie di editing è un ambiente moderno della famiglia VS Code con evidenziazione della sintassi, completamento del codice e il workflow AI descritto in precedenza; i numeri di riga sono ancora disponibili per gli ingegneri che li vogliono.

Cosa c'è dopo per Bob su IBM i

Il Premium Package for i recentemente annunciato fornisce un'esperienza nativa e ottimizzata per i team di sviluppo IBM i. Premium Package for i diventerà generalmente disponibile il 24 giugno.

Premium Package for i. Con il GA del 24 giugno, Bob si connetterà direttamente al tuo IBM i. Da una singola sessione leggi i source members direttamente da QSYS, li modifichi con lo stesso workflow sopra, ed esegui cicli di compilazione e test contro il sistema direttamente. Insieme alla connettività, Bob acquisisce skill e workflow integrati sintonizzati sullo sviluppo IBM i — conversione da fisso a libero, refactoring, generazione di documentazione — in modo che un prompt iniziale su una codebase RPG atterri più direttamente sulle convenzioni IBM i out of the box. Concretamente, questo significa:

Una sessione Bob connessa a una LPAR di sviluppo; nessun ciclo separato di export-edit-import.
Gli errori di compilazione e i risultati dei test dall'IBM i riemergono nella conversazione in cui Bob è già.
Skill e workflow integrati per i pattern di refactoring, conversioni e generazione di test che gli shop IBM i eseguono ripetutamente.

Più avanti — SDLC end-to-end. Tre filoni sono in progettazione attiva per i rilasci futuri:

Integrazione DevOps. Bob che partecipa a build, deploy, monitor e CI/CD per carichi di lavoro IBM i — eseguendo un passaggio di regressione contro una LPAR di test, promuovendo un cambiamento attraverso gli ambienti, e riportando un problema runtime in una sessione.
Performance SQL. Analisi dei dati e ottimizzazione degli indici come capacità di prima classe, oltre ai pattern di migrazione SQL embedded che Bob già produce oggi.
Assistente di conoscenza IBM i. Risposte basate sul recupero attraverso la codebase, documentazione di progettazione e ticket — in modo che il contesto che vive fuori dal source sia raggiungibile dalla stessa conversazione.

Per un team che adotta Bob oggi, il workflow di file locale sopra è il punto di partenza giusto; gli elementi in questa sezione descrivono come quel workflow si accorcia e si estende man mano che l'offerta IBM i matura.

Riferimenti clienti

Team in healthcare, agricoltura, IT aziendale e logistica stanno usando Bob contro codebase IBM i di produzione oggi:

MEDHOST. Applicazioni healthcare che coprono più generazioni RPG attraverso deployment ospedalieri negli Stati Uniti. Il team usa Bob per l'analisi dell'impatto e la conversione da fisso a libero, e per l'onboarding di sviluppatori più recenti su programmi i cui autori originali sono andati via da tempo.
NI+C. Integratore aziendale giapponese con programmi RPG che erano stati in esecuzione senza modifiche per oltre un decennio senza documentazione di progettazione sopravvissuta. Bob ha prodotto doc di progettazione e diagrammi Mermaid abbastanza accurati che gli ingegneri che in precedenza erano rimbalzati sugli assistenti AI hanno continuato a usarlo per lavoro reale.
Heartland Co-op. Cooperativa agricola con sede in Iowa che trasmette dati di sensori IoT in tempo reale nel suo ambiente IBM i per il monitoraggio della qualità del grano e delle attrezzature. Bob aiuta gli sviluppatori a ragionare attraverso le interdipendenze tra la pipeline IoT, la contabilità del grano e i sistemi operativi core, e accorcia il ramp-up per i nuovi assunti.
Carreras Grupo Logístico. Uno dei primi adottanti aziendali di Bob in Spagna, usandolo per spiegare la logica dei programmi legacy, generare documentazione e refactorizzare attraverso i moduli di una piattaforma logistica.

Il filo comune attraverso tutti e quattro è lo stesso: la codebase IBM i esistente rimane al suo posto, e il lavoro di spiegazione, conversione e documentazione viene eseguito accanto al sistema di produzione piuttosto che prima di un progetto di sostituzione.

Iniziare

Inizia una prova gratuita
Scarica un programma RPG in una cartella locale e aprilo in Bob.
In modalità Ask, richiedi un walkthrough e un diagramma Mermaid del suo flusso di dati.

Quella sessione — un programma, una conversazione — è il percorso più breve verso una risposta reale su se Bob si adatta al modo in cui il tuo team lavora.