Gli strumenti con cui si lavora oggi

Si può ancora programmare su IBM i esattamente come nel 1995, e molti lo fanno. Funziona, e non è una colpa. Ma c'è un fatto tecnico che vale più di qualunque discussione: SEU non capisce il free-form completo. L'editor integrato è stato stabilizzato — riceve correzioni, non funzioni nuove — e la sintassi introdotta dopo non gli è mai stata insegnata.

Chi scrive **FREE in SEU vede segnalati come errori dei costrutti corretti. Non è un'opinione sugli editor: è il motivo per cui, a un certo punto, si cambia strumento.

Le tre strade

SEU e PDM. L'editor e il gestore integrati, dentro la sessione 5250. Restano l'unica cosa disponibile ovunque, senza installare niente, e per una correzione al volo su un sistema a cui ci si è appena collegati sono ancora la strada più rapida.

RDi — Rational Developer for i. L'ambiente basato su Eclipse, prodotto IBM a pagamento. È completo: editor che conosce il linguaggio, debugger grafico, navigazione fra i sorgenti, integrazione con la compilazione. È lo strumento di riferimento nei reparti strutturati.

VS Code con Code for IBM i. L'estensione che porta lo sviluppo su questa piattaforma dentro l'editor più diffuso al mondo: si aprono i membri dei file sorgente come se fossero file, si compila dall'editor, si vedono gli errori sulla riga, si naviga negli oggetti e nel database. È gratuita, è viva, ed è la strada con cui oggi entra chi arriva da fuori.

Che cosa cambia davvero cambiando strumento

Non è l'estetica. Sono tre cose che in una sessione 5250 non esistono.

Cercare in tutto il codice in un secondo. Trovare tutti i punti in cui si usa un campo, o tutti i programmi che chiamano una procedura, è un'operazione che con gli strumenti storici richiede comandi dedicati e pazienza.

Vedere l'errore sulla riga. Compilando con OPTION(*EVENTF), l'editor legge il file di eventi e mette gli errori dove sono, invece di lasciare il listato di spool da consultare a parte.

Avere il sorgente sotto git. Con i sorgenti sull'IFS si usano i rami, la storia, le differenze e le richieste di revisione come in qualunque altro progetto. È il punto in cui lo sviluppo su questa piattaforma smette di essere un mondo a parte anche nel modo di lavorare.

Il resto della cassetta

ACS — Access Client Solutions. È il programma con cui ci si collega: emulatore 5250, esplorazione dell'IFS, trasferimento file, e soprattutto Run SQL Scripts, che è l'ambiente in cui si scrivono e si provano le query. Gira in Java su qualunque sistema operativo, è gratuito, e ha sostituito il vecchio client Windows.

I comandi di compilazione automatizzati. Il vuoto lasciato dall'assenza di un file di progetto è stato colmato da strumenti della comunità che compilano un applicativo intero seguendo le dipendenze, e che si integrano con git e con i sistemi di integrazione continua. Sono la risposta alla domanda "come faccio a ricompilare tutto in ordine senza un CL scritto a mano".

I gestori di pacchetti. Su IBM i gira una raccolta ampia di software open source — Python, Node, Git, Bash — installabile e aggiornabile come su qualunque sistema Unix. È il motivo per cui oggi si può automatizzare qualcosa sul sistema senza scrivere un CL.

Come si comincia, se si comincia adesso

L'ordine con meno attrito, per chi vuole cambiare modo di lavorare senza chiedere un progetto:

1. ACS, per avere Run SQL Scripts. Da solo cambia il modo di guardare i dati.
2. VS Code con Code for IBM i, collegato al sistema. I sorgenti restano dove sono.
3. OPTION(*EVENTF) nelle compilazioni, per avere gli errori sulla riga giusta.
4. Un applicativo nuovo con i sorgenti sull'IFS e sotto git, per provare il flusso completo dove non si rompe niente.