Il linguaggio RPG

Questa è una delle tante assurdità dell'informatica!

Se io parlassi di FORTRAN, BASIC, Assembler, ADA, COBOL e via discorrendo, tutti saprebbero che si tratta di linguaggi di programmazione, più o meno recenti e più o meno utilizzati.

FORTRAN è servito per sviluppare sul computer complessi calcoli matematici. Poi, che qualcuno abbia pensato di utilizzare un linguaggio che non trattava l'input/output anche per elaborare fatture potrà sembrare bizzarro, ma così è stato!

Un programma scientifico è evidente che richiede pochissimi dati in ingresso e pochissimi dati in uscita, così come l'elaborazione di dati aziendali necessita proprio dell'opposto: semplici operazioni aritmetiche e tanto input/output.

BASIC è il linguaggio che ha tenuto a battesimo intere generazioni di programmatori. La semplicità dell'approccio iniziale ed una buona elasticità ne decretarono subito il successo. Anche in questo caso, un linguaggio nato in università per insegnare le basi della programmazione agli studenti, divenne uno standard di programmazione, con tutti i suoi bravi dialetti e derivati.

Peccato che anche il Basic non fosse molto ben disposto ne al trattamento dei dati su disco, ne alla composizione di report e, malgrado ciò, fu ampiamente utilizzato nelle applicazioni aziendali.

Assembler è stato il padre dei linguaggi di programmazione, il capostipite. Il linguaggio era poverissimo di istruzioni, visto che tutto ciò che sapeva fare era muovere dei dati dal registro A al registro B (o poco più). Si trattava di un linguaggio di macchina che obbligava i programmatori a scrivere fiumi di istruzioni per fare anche le cose più semplici e ricorrenti.

ADA è un linguaggio progettato per la difesa degli Stati Uniti. Come tale qualcuno ha pensato bene che fosse l'esempio migliore da proporre agli studenti universitari italiani, che, evidentemente, tutto devono imparare, tranne cose utili!

COBOL, invece, è un vero e proprio linguaggio realizzato per la gestione aziendale. Finalmente!

E visto che non tutti i programmatori del mondo dovevano occuparsi di calcoli scientifici o di disegno tecnico o di video games, non c'erano dubbi: se avevi bisogno di progettare applicazioni per le aziende, potevi usare il COBOL.

E che questo sia stato e sia tuttora un linguaggio mirato per le esigenze di programmazione e gestione di dati aziendali non c'è alcun dubbio.

Qualche dubbio, però, viene nel momento in cui se ne valutano le prestazioni in termini di tempi di scrittura del codice.

COBOL è un linguaggio prolisso come pochi altri, che costringe i programmatori a scrivere fiumi di parole, tutte in termini inglesi.

Adatto agli scopi, dunque, ma non certo sintetico.

E la storia dei linguaggi potrebbe per molti finire qui.

Ma e l'RPG?

Ecco il mistero! Parallelamente allo sviluppo e affermazione del COBOL è nato (e a sua volta si è sviluppato) il linguaggio RPG.

Le storie però sono diverse: COBOL viene presentato come linguaggio standard utilizzabile su diverse piattaforme e diventa infatti anche ANSI COBOL. 

RPG, invece, viene sviluppato dalla IBM come "strumento di utilità".

Il nome assai riduttivo la dice lunga su questo fatto: RPG sta per Report Program Generator, cioè programma generatore di stampe.

La nascita risale al 1961 (per i sistemi IBM 1401) e anche successivamente il compilatore è usabile solamente su sistemi IBM 360 e questo spiega già in parte l'ostruzionismo che l'RPG ha avuto almeno dai concorrenti IBM.

Veramente il linguaggio racchiudeva in sé delle potenzialità notevolissime, che neppure la IBM ha saputo apprezzare per molti anni.

Salvo casi particolari (tra cui il sottoscritto) chi utilizzava sistemi IBM 360 programmava in Assembler o in COBOL.

In effetti le prime versioni di RPG erano piuttosto lacunose nella gestione delle periferiche. Ma il problema era facilmente aggirabile con piccole subroutines scritte in Assembler, che si potevano evocare dall'interno del programma RPG.

Dopo la famiglia dei sistemi 360 uscirono i 370 ed il discorso della programmazione continuò imperterrito: COBOL o Assembler.

All'epoca io riuscii a dimostrare, proprio a sistemisti della IBM di Milano, che i tempi per lo sviluppo usando i tre linguaggi in vigore erano assolutamente a favore dell'RPG. In pratica un programma di medie difficoltà scritto in Assembler richiedeva un mese-uomo, in COBOL sette giorni, in RPG 1 giorno! 

Ma non solo, i tempi di ripresa di un programma per l'inevitabile manutenzione, erano ancora più interessanti, vista la sinteticità dell'RPG rispetto agli altri linguaggi e l'auto documentazione che offriva.

Il tempo mi diede ragione (anche se con molto ritardo) e questo articolo vuole in un certo senso rendere onore al merito ad uno strumento nel quale ho creduto per primo e che mi ha sostenuto per molti anni di attività.

All'inizio degli anni settanta, infatti, IBM annunciava un nuovo sistema il System 3, che - guarda caso!- era programmabile solamente in RPG!

A onor del vero l'RPG un problema lo aveva ed era la serie di Indicatori che metteva a disposizione del programmatore. Gli Indicatori in pratica erano degli switch gestibili all'interno del programma per condizionarne il flusso e quant'altro.

Molti programmatori non capirono che la comodità di questi indicatori aveva una controindicazione: dovevano essere usati con molta parsimonia, altrimenti si rischiava di inondare le varie righe di codice con condizioni di tipo and/or difficilmente controllabili in fase di debug, qualcosa che rischiava d'essere peggio del famigerato GOTO di altri linguaggi. Ma i linguaggi strutturati all'epoca non esistevano!

Schivato il problema, il linguaggio RPG era quanto di più pratico si potesse immaginare per sviluppare software gestionale, al punto che dopo 35 anni ha ancora un solido futuro innanzi a sé.

La IBM ha distribuito per ogni famiglia di minicomputer uscita tra gli anni 60 ad oggi, una versione aggiornata e implementata del linguaggio RPG. Che da RPG puro e semplice è diventato RPG II, poi RPG III, quindi RPG AS/400, RPG/ILE e attualmente s'è aggiunta anche una versione Visual RPG. 

Da linguaggio sequenziale, coi suoi bravi goto, è diventato un linguaggio moderno, con call a subroutines esterne, strutturazione identica agli altri linguaggi, abbandono del formato fisso delle istruzioni, apertura al mondo delle interfacce grafiche, e via dicendo.

Una caratteristica peculiare dell'RPG era il ciclo fisso di esecuzione delle istruzioni: input, calcolo, output, con tutta la gestione delle condizioni particolari (uscite di dettaglio e totali, per esempio, o ancora, ciclo di overflow del modulo in stampa).

L'RPG garantiva l'esatta gestione di flussi di due o più files di input da elaborare secondo priorità di codici, svolgendo automaticamente tutte le funzioni richieste dalla casistica, con il semplice utilizzo di un indicatore speciale (MR).

Anche i vari livelli di totalizzazione erano automatizzati, con uscite di esecuzione dell'output in sequenza gerarchica: prima il dettaglio, poi i totali di più basso livello, seguiti da quelli superiori, fino a 9 livelli più totali generali.

L'output era facilmente mascherabile per le varie esigenze di formattazione dei campi.

I programmi potevano dare luogo a chiamate di altri sottoprogrammi, con passaggio di parametri.

L'RPG era nato in epoca in cui si elaborava solo batch, ma seppe subito adattarsi alla perfezione al mondo interattivo. La gestione delle comunicazioni da/per i terminali collegati in locale o remoto al sistema centrale era ed è tutt'ora della massima semplicità ed efficacia, con tempi di risposta decisamente molto bassi.

Se pensiamo alla continuità, in perfetta compatibilità, dal 1965 ad oggi, capiamo quale garanzia d'investimento duraturo il linguaggio abbia saputo offrire ai consulenti informatici, alle aziende utilizzatrici ed ai programmatori che con esso sono cresciuti, potendo focalizzare la loro attenzione sui problemi reali dei clienti più che sulle problematiche tecniche dei tools di sviluppo.

Ricky Spelta