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.
Commenti
Nessun commento ancora. Sii il primo a commentare!
Devi avere un account per commentare. Accedi · Registrati