Programmare su IBM i: sorgenti, ILE, RPG e SQL

Rivista il Verificata su IBM i 7.5

Accedi per salvare

Programmare su IBM i è un mestiere con regole proprie, e quasi tutte hanno un motivo che non si trova scritto da nessuna parte: si impara guardando qualcuno lavorare, e quando quel qualcuno va in pensione se ne va anche il motivo.

Questa guida mette per iscritto quello che di solito si tramanda a voce. Dove sta il codice, come diventa un programma, che cosa distingue un modulo da un service program, perché lo stesso file si può leggere in due modi completamente diversi, e come si fa a capire dove si è rotto qualcosa quando alle sette del mattino la chiusura è ferma.

A chi è rivolta

A chi arriva da altri linguaggi. L'RPG non è il problema: la sintassi si impara in una settimana. Il problema è tutto quello che c'è intorno — il sorgente dentro un file, la compilazione che produce un oggetto, i gruppi di attivazione, la differenza fra leggere un file a record e interrogarlo in SQL. Chi arriva da Java o da Python sa scrivere codice e non sa dove metterlo.

A chi ci lavora da anni. Buona parte di questa guida è materia nota a chi programma su questa piattaforma da tempo, ma non tutta: i capitoli su ILE, sull'SQL incorporato e sulla modernizzazione toccano cose che in molti reparti non si sono mai adottate, non perché siano state valutate e scartate, ma perché non se ne è mai parlato.

Che cosa non è

Non è un corso di RPG. Non ci sono esercizi, e la sintassi compare solo dove serve a spiegare un concetto. Chi cerca il linguaggio istruzione per istruzione trova la documentazione IBM, che su questo è completa e ben fatta — solo, è in inglese e presuppone il contesto che questa guida prova a dare.

Non è nemmeno un manifesto sulla modernizzazione. Il codice che gira in produzione da vent'anni non è debito tecnico per il fatto di essere vecchio: è capitale che ha smesso di costare. Il capitolo sulla modernizzazione parla di come cambiare le parti che vale la pena cambiare, non di riscrivere tutto.

Come è organizzata

Si parte da dove sta il codice e da come diventa un oggetto eseguibile, perché è il passaggio che confonde di più chi arriva da fuori. Poi i due linguaggi che si incontrano davvero, RPG e CL. Poi i dati, che su questa piattaforma si possono descrivere in due modi e leggere in due modi. Poi la parte che si usa più di tutte e si insegna meno: capire dove si è rotto qualcosa. E infine come si cambia il software senza fermarlo, e con quali strumenti si lavora oggi.

I capitoli si leggono in ordine la prima volta. Dopo si consultano da soli.

Nota

questa guida presuppone di sapere che cos'è una libreria e come funziona la lista librerie. Se sono termini nuovi, la guida sistemistica copre quella parte, e i due percorsi si incrociano spesso: molti problemi che sembrano di programmazione sono di ambiente.

Capitoli della guida

  1. Dove sta il codice Il sorgente sta dentro un file, la compilazione produce un oggetto, e non esiste una cartella del progetto. Il primo scoglio per chiunque arrivi da fuori.
  2. ILE: moduli, programmi e service program Che cosa cambia davvero fra CRTBNDRPG e la coppia modulo più programma, a cosa serve un service program, e perché i gruppi di attivazione fanno danni quando nessuno li ha decisi.
  3. RPG: dalle colonne al free-form Perché il codice vecchio è scritto a colonne, che cosa è cambiato davvero con il free-form, e come si convive con due forme dello stesso linguaggio nello stesso applicativo.
  4. CL: il linguaggio che tiene insieme il resto Non è un linguaggio di serie B: è quello che lancia i batch, gestisce gli errori e parla con il sistema. Ed è quello che nessuno ha mai insegnato per bene.
  5. DDS e SQL: due modi di descrivere i dati Lo stesso file è un file fisico e una tabella. Quando conviene continuare con il DDS, quando conviene passare all'SQL, e che cosa si perde a non decidere.
  6. SQL dentro i programmi Come si scrive SQL dentro un RPG, perché SQLCODE zero non significa che è andato tutto bene, e dove si nasconde l'iniezione anche su questa piattaforma.
  7. Quando si rompe: errori e debug Come si legge un errore RPG, come si entra nel debugger su un job che non è il tuo, e come si evita che un programma muoia in silenzio alle tre di notte.
  8. Modernizzare senza riscrivere Il codice vecchio non è debito tecnico per il fatto di essere vecchio. Che cosa conviene cambiare, in quale ordine, e come si espone un programma esistente al resto del mondo.
  9. Gli strumenti con cui si lavora oggi SEU non capisce il free-form completo, e questo da solo dice dove è arrivato il mestiere. Che cosa si usa davvero per scrivere codice su questa piattaforma.
← Torna al blog

Commenti

Nessun commento ancora. Sii il primo a commentare!

Devi avere un account per commentare. Accedi · Registrati