|
Storia del linguaggio RPG
L'RPG
è un linguaggio creato da IBM nel 1959 e già utilizzabile su uno
dei primi minielaboratori: l'IBM 1401.
Poi è stato reso disponibile sui sistemi IBM 360, 370, S/3, 32, 34, 36,
38, AS/400 ed infine
iSeries (sistemi più che attuali al giorno d'oggi).
Fino ai sistemi 370 in realtà il linguaggio era considerato dai più come
semplice utility e non godette di gran fama. Fu dai sistemi S/3 in
avanti che divenne il principale linguaggio di sviluppo per applicazioni
commerciali proposto da IBM, almeno sui mini elaboratori...sempre che un
sistema d'elaborazione con attaccati 200 o più terminali locali o remoti
(e magari dal costo di un paio di miliardi di lire) sia ancora
considerabile "mini" elaboratore.
Lo scopo, dato anche il nome che significa Report Program Generator
(programma generatore di stampe), apparve subito evidente: l'IBM 1401
dell'epoca è un sistema d'elaborazione principalmente orientato alle
aziende, quindi con esigenze massicce di stampare tabulati e moduli
commerciali (bolle, fatture, estratti conto, ecc.).
Il sistema 1401 è la prima macchina annunciata da IBM, dopo il
Ramac 305, a non avere più pannelli di controllo con spinotti da
inserire. Si tratta di un vero computer, con i suoi bravi linguaggi di
programmazione, tra cui appunto anche il nuovo RPG.
Il linguaggio è pesantemente orientato ad avere un input da schede
perforate, svolgere determinati calcoli, anche fortemente condizionati,
per mandare infine i risultati verso la stampante.
Un linguaggio molto mirato al suo scopo primario. Probabilmente
l'ideatore (ignoro chi sia stato a progettarlo) non s'era posto altri
obiettivi.
L'evoluzione del linguaggio RPG
- Nel 1959, prima edizione dell'RPG I a schede per sistemi IBM 1401
- Per sistemi IBM 360 e 370, con versione RPG schede, RPG TOS (Tape
Operating System), RPG DOS (Disk Operating System)
- RPG II per sistemi IBM S/3
- RPG II per sistemi IBM S/32, S/34, S/36
- RPG III per sistemi IBM S/38
- RPG/400 per sistemi IBM AS/400
- RPG/ILE Per sistemi AS/400
- Visual RPG per sistemi AS/400 e iSeries
L'RPG e la concorrenza a IBM
Con questo linguaggio decisamente proprietario, IBM si era affrancata la
fedeltà di tutti i suoi clienti, che vedevano le loro applicazioni
imperniate sull'RPG, come chiave di successo del loro sistema
informativo.
La concorrenza cercò ovviamente di proporre una propria versione RPG,
per attirare clienti insofferenti del legame vincolante con IBM, ma in
linea di massima si trattò di brutte imitazioni, molto arretrate come
funzionalità rispetto al vero linguaggio originario IBM.
Ciò fece sì che, fuori dal mondo IBM, l'RPG non fosse per nulla
conosciuto, così come non era conosciuto in casa IBM a livello di
mainframe, dove era invece prevalente il COBOL o altri linguaggi di
livello superiore.
Per queste ragioni possiamo dire che c'è sempre stato un certo
"omertoso" silenzio, fuori dal mondo IBM, sulle caratteristiche di
successo (indiscutibile) che gli sviluppatori riuscivano ad ottenere
scrivendo programmi RPG.
La maggior parte delle piccole e medie aziende italiane avviate alla
elaborazione elettronica dei dati negli anni dal 1960 al 1990 ha
adottato IBM come fornitore di hardware e utilizzato software house o
consulenti informatici specializzati nell'uso proprio dell'RPG. Si parla
di 60/70.000 installazioni, che vanno dai 3 posti di lavoro alle varie
centinaia.
Come funziona l'RPG
L'RPG si distingue subito da qualsiasi altro linguaggio di
programmazione per tre caratteristiche uniche:
- per scrivere le istruzioni si devono utilizzare appositi moduli
cartacei, simili a questionari, denominati "specifiche"
- le istruzioni fornite vengono eseguite all'interno di un ciclo logico
infinito, fornito dal compilatore
- per classificare e usare le condizioni si utilizzano una specie di
switch chiamati "indicatori"
Le specifiche RPG e il ciclo logico del linguaggio
Originariamente si trattava di 7 tipi differenti di moduli prestampati,
che andavano compilati con le apposite istruzioni del programma, quindi
dai moduli si ottenevano tante schede perforate quante erano le righe
utilizzate. Le schede rappresentavano il programma sorgente. Queste
venivano quindi fatte leggere dal computer, insieme al programma
compilatore, ed alla fine, se non c'erano errori gravi, si otteneva un
nuovo pacco di schede che rappresentavano il nostro programma oggetto, o
eseguibile che dir si voglia.
Le specifiche servivano ad indicare tutto ciò che occorreva per svolgere
un completo programma di tipo batch, ed ogni tipo di modulo aveva un
codice identificativo, ovvero:
H
(header) identificava la
prima riga del programma, con alcune informazioni destinate al
compilatore
F
(files) identificava le risorse che il sistema avrebbe dovuto
riconoscere e usare (files, stampanti, console, ecc.)
E
(extension) per indicare tabelle da caricare in fase di compilazione o
di esecuzione
L
(lines) per indicare caratteristiche particolari
I
(input) per fornire le indicazioni dei dati da leggere
C
(calcolo) con le istruzioni logiche, aritmetiche e condizionali
O
(output) per indicare dove e come stampare i dati o trascriverli su
nuovi files
Ogni modulo presentava apposite fincature con l'intestazione del
contenuto che era previsto per le varie colonne.
Nel battere un programma, dunque, si dovevano riportare le istruzioni
nelle precise posizioni previste dai moduli, saltando le zone da
lasciare obbligatoriamente in bianco.
Per un programma di media complessità si potevano utilizzare una
trentina di fogli.
Ovviamente si compilavano in matita, si correggeva, si cancellava, si
aggiungevano fogli, ecc. ecc.
Tutto su carta.
C'è da dire che oggi può sembrare un metodo da età della pietra e in
effetti lo era, ma il rapporto tra programmatore e foglio di carta aveva
anche i suoi vantaggi (e il suo fascino!): un programma lo potevi
scrivere anche a lume di candela! L'attenzione era maggiormente
concentrata su ciò che scrivevi e non su comandi, video, tastiera, pc
che si blocca sul più bello, screen savers, ecc.
Eri tu davanti al tuo bel programma su carta.
Se avevi una bella scrivania, ti allungavi i fogli e con un colpo
d'occhio potevi vedere tutto ciò che avevi scritto sino a quel momento,
senza dovere scorrere nulla dentro un'angusta finestra, com'è quella del
video.
Il ciclo di elaborazione RPG
Ma torniamo ai moduli e come erano stati concepiti.
L'idea di base era che un computer dovesse agire così:
1° prendere un dato,
2° farci sopra qualcosa,
3° restituirne il risultato
ovvero: input-->calcolo-->output
...per poi ricominciare daccapo col record successivo, fino all'ultimo
record, ovviamente.
Bene, ma queste sono le esigenze classiche di qualsiasi elaborazione o
se me lo consentite, di qualsiasi attività in senso ancora molto più
ampio! Anche l'uomo riceve un'informazione, la elabora e reagisce di
conseguenza, poi passa ad una successiva informazione...e ripete il suo
ciclo.
Chi ha scritto l'RPG s'è chiesto subito se allora non valesse la pena di
automatizzare il flusso logico e di generalizzarlo, visto che alla fine
era sempre quello.
Il flusso logico ha fatto penare per decenni i programmatori di altri
linguaggi, ma non certo quelli dell'RPG, che lo avevano gratis e
perfetto.
Così in RPG definiamo le risorse che intervengono nel programma,
elenchiamo i campi da leggere, scriviamo la nostra logica, controlli,
calcoli, salti, ecc., cioè tutto ciò che fa parte dell'elaborazione e
per ultimo indichiamo dove stampare o registrare i dati in uscita. Tutto
qui.
I punti forti del linguaggio RPG
(in
comune con tutte le versioni)
- grandissima sinteticità del codice sorgente
- cicli automatici di flusso standardizzato
- estrema facilità d'apprendimento
- nessun orpello ortografico o caratteri speciali
- estrema leggibilità del sorgente
- facilità di manutenzione
- ottima gestione dei report
(solo da
RPG III in avanti)
- logica strutturata
- chiamate a programmi o semplici routine esterne con passaggio di
parametri
- miglioramento generale delle funzioni e nuovi codici operativi
- definizioni esterne dei dati di input
- tracciato libero
I punti deboli del linguaggio RPG
Ovviamente per essere imparziale (anche se il mio rapporto affettivo con
questo linguaggio non me lo consentirà completamente!), bisogna anche
parlare subito degli svantaggi:
- la stesura posizionale dei comandi implica l'uso di appositi moduli o
comunque la conoscenza delle colonne in cui ogni dato deve essere
scritto, visto che il significato di un codice è assunto dal compilatore
in base alla posizione in cui viene inserito.
In realtà è un modesto problema per il programmatore esperto, che può
fare a meno dei moduli e scrivere comunque il suo programma su carta
bianca, oppure immetterlo direttamente da tastiera, come si fa con
qualsiasi altro linguaggio, aiutato da un apposito programma
d'immissione, che oltre tutto controlla interattivamente la validità dei
dati immessi.
- il ciclo logico all'inizio era piuttosto rigido, ma poi questo
problema venne totalmente superato con istruzioni che consentivano di
saltare da una riga di calcolo all'output per poi ritornare alla riga di
calcolo successiva.
- la descrizione dell'input andava riscritta in ogni programma. Cambiare
la posizione di un campo su un tracciato record significava andare a
correggere (senza fare errori!) e ricompilare tutti i programmi
interessati dalla modifica. Diciamo subito che con l'avvento delle
definizioni esterne al programma (DDS) anche questo problema venne
risolto. Oggi i dati si descrivono una sola volta e il programma sa
sempre dove andarli a reperire. Ma oggi i dati stanno anche su database
relazionali e non più in archivi di schede o nastri o in file singoli!
- i nomi dei campi furono invece un vero tormentone: l'input consentiva
di dare nomi non più lunghi di 6 caratteri. Veramente pochi per chi
debba gestire decine o centinaia di files diversi e voglia, stando
dentro 6 caratteri, codificare in modo univoco tutti i nomi dei campi!
- un altro limite era imposto dalla barriera dei 64Kb massimi di
dimensione del programma. Programmi più grandi venivano posti in
overlay, cioè il compilatore ne teneva una parte separata, ma era una
tragedia in termini di velocità, quindi bisognava star per forza nei
limiti imposti.
Se un programma era divenuto troppo grosso bisognava trovare il sistema
per spezzarlo in due. Tutto sommato questo principio non era poi tutto
negativo! Spesso un programma era troppo grosso solo perchè scritto
male, con dispersioni a non finire. Bastava rileggerlo criticamente e
qualche soluzione più stilisticamente valida saltava fuori, senza
bisogno di spezzarlo in due. Con l'avvento della versione RPG III anche
questo problema sparì del tutto perchè era possibile fare chiamate ad
altri programmi (o routine generalizzate) dall'interno di un programma
principale, per cui tutta la struttura ne guadagnava e le routine
esterne potevano svolgere compiti generalizzati ed essere così
ampiamente riusate nell'ambito dell'intera applicazione.
Nelle prime versioni RPG era comunque possibile fare solo uscite da
calcolo a routine scritte in Assembler. Ciò era interessante per due
motivi: primo perchè l'Assembler era in grado di gestire qualsiasi cosa
che all'RPG ancora non riuscisse e secondo perchè era notevolmente più
veloce.
I programmatori più furbi scrivevano dunque tutti i programmi in RPG ed
alcune funzioni particolarmente lente o non realizzabili dall'RPG (per
esempio la gestione di una periferica particolare) le demandavano ad
apposite routine Assembler.
- infine c'era il problema degli indicatori. Si trattava di 99
condizioni che il compilatore era in grado di gestire all'interno del
programma, semplicemente indicandone il numero corrispondente. Come dire
99 flag che si potevano facilmente mettere in on/off e citare lungo
tutto il programma stesso. In più c'era tutta una serie di indicatori
speciali, che rappresentavano condizioni che venivano gestite
direttamente dal linguaggio. Per esempio un indicatore chiamato LR ti
forniva l'indicazione del raggiungimento di fine lavoro (qualcosa di
simile all' EOF di altri linguaggi, per intenderci).
Altri indicatori segnalavano automaticamente il raggiungimento della
fine del modulo (OF, cioè overflow), altri la corrispondenza di chiavi
tra due file letti sequenzialmente (MR, matching record) e via di
seguito.
Con un pò di pratica questi indicatori, una volta capito bene quando e
perchè si "accendevano o si spegnevano" e dove si potevano utilizzare,
servirono a risparmiare un sacco di codice di programma.
Però gli indicatori erano un pò come il GOTO di altri linguaggi: un'arma
a doppio taglio!
I programmatori poco esperti ci si perdevano, ne usavano a decine e in
modo caotico, fino a rendere veramente poco affidabile e di difficile
debug l'intero programma. Ma ditemi voi qual'è il linguaggio in cui un
cattivo programmatore non sappia fare danni?
In compenso l'output dell'RPG era una vera manna di semplicità. La
stampa di righe d'intestazione, la gestione delle liste e dei salti
pagina, le spaziature tra righe, la formattazione dei campi numerici,
date, ecc. e le posizioni in cui stampare i dati erano e sono di una
semplicità ineguagliabile, a mio giudizio. Sicuramente negli altri
linguaggi in cui ho programmato ho rimpianto sempre il metodo di
indicare l'output dell'RPG. Almeno fino ai sistemi di composizione
grafica, come ad esempio MS Access o Crystal Report o altri analoghi. Ma
noi non stiamo parlando del mondo grafico.
Per finire con i difetti, dunque, il flusso logico del calcolo
richiedeva dei salti da una riga a quella da cui proseguire. Questo
metodo di branching, unito all'eccessivo uso di indicatori, creava
grossi problemi di affidabilità dei programmi più complessi. Ma anche
questo aspetto fu risolto nelle più recenti versioni RPG, che ora sono
assolutamente strutturate come altri linguaggi moderni.
La mancanza di cicli if, then else o do until, do while e via dicendo
produceva le stesse "spaghettate" tipiche dei vari Basic.
Non ho spiegato il set d'istruzioni di calcolo, che è comunque completo
e valido per lavorare sulle stringhe dei dati o eseguire operazioni
logiche o aritmetiche, senza allontanarsi dalle quattro operazioni,
visto che l'RPG non ha mai avuto velleità scientifiche.
Anche qui all'inizio la gestione delle date era affidata al
programmatore, ma in seguito giunsero le istruzioni per fare
automaticamente qualsiasi tipo di operazione anche su questi tipi di
campi.
L'RPG con l'avvento dei sistemi a dischi e poi dei database relazionali,
ha sempre seguito il passo dell'evoluzione e non ha mai presentato
problemi di sorta neppure in questi casi.
Il successo dell'RPG e il futuro
Per concludere questa breve panoramica del linguaggio vorrei affermare
che il grande pregio che ha sancito di fatto la validità del linguaggio
in campo applicativo aziendale è dato dall'assoluta sinteticità del
codice sorgente e conseguente facilità di rilettura e manutenzione dei
programmi.
Sicuramente il linguaggio più facile da scrivere, visto che non presenta
alcuna regola ortografica, più veloce in termini di immissione
(pochissimi caratteri e tutti funzionali allo scopo), abbastanza facile
in fase di debug, e decisamente affidabile in termini di elaborazione.
Così come credo si possa affermare che è stato ed è tutt'ora un
linguaggio poco amato dai grandi smanettoni; che lo giudicano troppo
vincolante e banale, visto che non permette tanti giochi di fantasia,
spingendo il programmatore più ad occuparsi dei risultati finali del
programma, che non del come ottenerli.
Con l'avvento delle interfacce grafiche e dei personal computer l'RPG ha
perso terreno. Di ciò sicuramente ha colpa la IBM che a mio avviso ha
sottovalutato la portata storica del passaggio da interfaccia testo a
interfaccia grafica, pensando fosse un gioco da home computer piuttosto
che il modo più moderno di colloquio uomo-macchina e che non ha mai
voluto proporre una versione per personal computer, cosa che però hanno
fatto un paio di società indipendenti, consentendo a molte piccole
aziende di utilizzare gli stessi programmi anche in reti di pc o in
installazioni monoutente.
La distrazione verso l'apertura alle interfacce grafiche l'IBM l'ha
pagata cara ed è corsa ai ripari solo negli ultimissimi anni. Oggi
esiste anche un Visual RPG in grado di gestire schermate con finestre e
pulsanti, ma per troppi anni IBM ha ignorato l'esigenza, restando
ancorata al tradizionale mondo informatico degli schermi green a 80
colonne per 24 righe, tipiche dei vecchi terminali.
Non credo che l'RPG abbia finito il suo ciclo di produttività perchè
esistono al mondo migliaia di aziende che hanno fatto forti investimenti
applicativi utilizzando appunto questo linguaggio e che sono
perfettamente soddisfatte dei risultati che ancora ottengono.
Certamente ci sono altri sistemi di programmazione meno vincolati al
passato e più flessibili, più duttili e più potenti, ma l'RPG ha ancora
un enorme carico di lavoro da svolgere nei prossimi anni!
Ricky Spelta
Esempi di programmi RPG:
1)
Hello world
H
FSCREEN O
F 80 80
CRT
C
EXCPT
OSCREEN E
1
O
12 'HELLO WORLD!'
|
