3D-RAM Blog - Quando la tecnologia incontra la creatività

Vai ai contenuti

Un tuffo nel passato della programmazione

Quando la tecnologia incontra la creatività
Pubblicato da in Notizie ITC · 3 Febbraio 2018
Storia del linguaggio RPGL'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 edinfine 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 iSeriesL'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.

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 RPGMa 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 liberoI punti debolidel linguaggio RPGOvviamente 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 futuroPer 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!

Articolo liberamente copiato dalla rete by Ricky Spelta

Esempi di programmi RPG:1) Hello world HFSCREEN OF 80 80CRTCEXCPTOSCREEN E 1O12 'HELLO WORLD!'2) Programma RPG IIper la stampa di un prospetto

  1  H                                                                    EXAMP8   2  H*   3  H* PRINT STUDENT GRADE REPORT   4  H*   5  FSTMASTR UP  F 250 250R 7KI     2 DISK14       S   6  FRAF     IRE F5000  50  7        ETAPE         S   7  FTABLE   IT  F  80  80           ETAPE         S   8  FREPORT  O   F 132 132     OF    LPRINTER   9  E    RAF     STMASTR   10 E    TABLE           TABCNR  1 120  5  ATABCNA 51   11 LREPORT    101 6012   12 ISTMASTR AA  01   1 CA   13 I       OR   91   1 CD   14 I                                        9  43 NAME   15 I                                      136 1410CN1N            11   16 I                                      136 140 CN1   17 I                                    P 142 1442CN1G   18 I                                      145 1500CN2N            12   19 I                                      145 149 CN2   20 I                                    P 151 1532CN2G   21 I                                      154 1590CN3N            13   22 I                                      154 158 CN3   23 I                                    P 160 1622CN3G   24 I                                      163 1680CN4N            14   25 I                                      163 167 CN4   26 I                                    P 169 1712CN4G   27 I                                      172 1770CN5N            15   28 I                                      172 176 CN5   29 I                                    P 178 1802CN5G   30 I                                      181 1860CN6N            16   31 I                                      181 185 CN6   32 I                                    P 187 1892CN6G   33 I                                      190 1950CN7N            17   34 I                                      190 194 CN7   35 I                                    P 196 1982CN7G   36 I                                      199 2040CN8N            18   37 I                                      199 203 CN8   38 I                                    P 205 2072CN8G   39 I                                    P 208 2102GPA   40 C*   41 C*  FOR EACH COURSE IN THE STUDENT RECORD WHICH CONTAINS A COURSE   42 C*  NUMBER, COMPUTE EARNED GRADE POINTS AND ACCUMULATE ATTEMPTED   43 C*  HOURS AND GRADE POINTS   44 C*   45 C   01                Z-ADD0         THOURS  30   46 C   01                Z-ADD0         TGPTS   52   47 C*   48 C   01                SETOF                     21   49 C   01N11   CN1       LOKUPTABCNR    TABCNA 51      21   50 C   01 21             MOVE TABCNA    CRSHRS  10   51 C   01 21   THOURS    ADD  CRSHRS    THOURS   52 C   01 21   CN1G      MULT CRSHRS    GPTS    52   53 C   01 21   TGPTS     ADD  GPTS      TGPTS   54 C*   55 C   01                SETOF                     21   56 C   01N12   CN2       LOKUPTABCNR    TABCNA 51      21   57 C   01 21             MOVE TABCNA    CRSHRS   58 C   01 21   THOURS    ADD  CRSHRS    THOURS   59 C   01 21   CN2G      MULT CRSHRS    GPTS   60 C   01 21   TGPTS     ADD  GPTS      TGPTS   61 C*   62 C   01                SETOF                     21   63 C   01N13   CN3       LOKUPTABCNR    TABCNA 51      21   64 C   01 21             MOVE TABCNA    CRSHRS   65 C   01 21   THOURS    ADD  CRSHRS    THOURS   66 C   01 21   CN3G      MULT CRSHRS    GPTS   67 C   01 21   TGPTS     ADD  GPTS      TGPTS   68 C*   69 C   01                SETOF                     21   70 C   01N14   CN4       LOKUPTABCNR    TABCNA 51      21   71 C   01 21             MOVE TABCNA    CRSHRS   72 C   01 21   THOURS    ADD  CRSHRS    THOURS   73 C   01 21   CN4G      MULT CRSHRS    GPTS   74 C   01 21   TGPTS     ADD  GPTS      TGPTS   75 C*   76 C   01                SETOF                     21   77 C   01N15   CN5       LOKUPTABCNR    TABCNA 51      21   78 C   01 21             MOVE TABCNA    CRSHRS   79 C   01 21   THOURS    ADD  CRSHRS    THOURS   80 C   01 21   CN5G      MULT CRSHRS    GPTS   81 C   01 21   TGPTS     ADD  GPTS      TGPTS   82 C*   83 C   01                SETOF                     21   84 C   01N16   CN6       LOKUPTABCNR    TABCNA 51      21   85 C   01 21             MOVE TABCNA    CRSHRS   86 C   01 21   THOURS    ADD  CRSHRS    THOURS   87 C   01 21   CN6G      MULT CRSHRS    GPTS   88 C   01 21   TGPTS     ADD  GPTS      TGPTS   89 C*   90 C   01                SETOF                     21   91 C   01N17   CN7       LOKUPTABCNR    TABCNA 51      21   92 C   01 21             MOVE TABCNA    CRSHRS   93 C   01 21   THOURS    ADD  CRSHRS    THOURS   94 C   01 21   CN7G      MULT CRSHRS    GPTS   95 C   01 21   TGPTS     ADD  GPTS      TGPTS   96 C*   97 C   01                SETOF                     21   98 C   01N18   CN8       LOKUPTABCNR    TABCNA 51      21   99 C   01 21             MOVE TABCNA    CRSHRS  100 C   01 21   THOURS    ADD  CRSHRS    THOURS  101 C   01 21   CN8G      MULT CRSHRS    GPTS  102 C   01 21   TGPTS     ADD  GPTS      TGPTS  103 C*  104 C* COMPUTE FINAL GRADE POINT AVERAGE  105 C*  106 C   01      TGPTS     DIV  THOURS    GPA       H  107 OSTMASTR D        01  108 O                         GPA      210P  109 OREPORT  H  201   1P  110 O       OR        OF  111 O                                   34 'STUDENT GRADE REPORT'  112 O        D  1     01  113 O                         GPA       55 '  0.

'  114 O                         NAME      40
Commento: la tecnica di stesura usata in questo programma è abbastanza infantile e per nulla ottimizzata.
Lo dimostra l'uso pedante degli indicatori su ogni riga e la mancanza di uno sforzo per eliminare l'eccessiva ridondanza di istruzioni.
Una revisione del programma lo ridurrebbe facilmente ad un terzo di righe!
Un vero tuffo nel passato, almeno per mè.



Torna ai contenuti