L'Informatica dei Miei Tempi

L'informatica dei miei tempi: ovvero ricordi di cose che non esistono più, ormai dimenticate, oggetti da museo, da libri di storia, insomma.
Eppure, sono passati meno di sessant'anni!

Appena assunto in IBM il mio lavoro è stato quello del "sistemista" ovvero dell'analista di sistemi organizzativi. Il compito era aiutare le aziende ad ammodernare i loro processi attraverso l'uso dei computer.
Vi sto parlando del '67 e '68. Allora i veri computer erano utilizzati solo nelle maggiori realtà: grandi industrie, banche, assicurazioni. Erano, invece, ancora abbastanza sconosciuti nelle medie e piccole aziende.
I miei clienti erano, appunto, tali imprese minori, che per la prima volta affrontavano il passaggio dai sistemi tradizionali, manuali o semi-manuali a quelli più moderni.

I sistemi manuali erano: registri contabili e macchine da scrivere.
Come sistemi semi-manuali c’erano dei dispositivi chiamati UR (acronimo di Unit Record), il cui prototipo risale addirittura alla fine del 1800, quando l’ingegnere statunitense Herman Hollerith costruì la sua macchina per le elezioni e i censimenti.

Quegli strumenti si sono poi evoluti e perfezionati e IBM, Univac ed altri ne erano diventati importanti produttori.
Ogni UR realizzava soltanto uno dei passi elaborativi necessari. Perciò di UR ne occorrevano diverse: duplicatrici, calcolatrici, tabulatrici, eccetera, che, attivate in serie, una dopo l'altra, completavano l’intero processo.

L'IBM mi ha assunto col contratto dei metalmeccanici. Non deve sembrarvi strano, perché le UR erano appunto macchine elettromeccaniche.
Dentro ai loro robusti telai metallici stavano racchiusi i motori, tanti cavi, relè e le loro modeste memorie in nuclei di ferrite.
Erano voluminose e pesantissime, tanto che spesso occorreva rinforzare i solai dei locali per reggerne il peso.

Le UR disponevano di un pannello rimovibile, pieno di tanti piccoli fori, in cui si infilavano decine di fili, variamente colorati, che chiudevano i circuiti delle operazioni da eseguire. Ogni pannello era, insomma, un programma per uno dei passi necessari.

Le UR non erano compito mio. Io mi dedicavo alla generazione più recente, ai veri calcolatori: i computer della serie IBM 360. Ma quelle macchine mi incuriosivano e guardavo con interesse i colleghi più anziani, che in ufficio preparavano i pannelli-programma per le aziende da loro assistite.
Quando sono andato in pensione avrei desiderato di portarmi a casa almeno uno di quei coloratissimi oggetti. Lo avrei appeso da qualche parte, come opera materica o di scultura moderna. Ma erano ormai dimenticati; li ho cercati anche nei vecchi magazzini senza successo.

I dati da elaborare sulle UR dovevano essere trasferiti su schede di cartoncino di 80 colonne e 12 righe, supporto rimasto in uso, per qualche tempo, anche sugli elaboratori che io seguivo. Conservo religiosamente, come cimelio, una di tali schede, tutta piena di strani buchini rettangolari.

Come si ottenevano le schede? Ad ogni Centro Elaborazione Dati (CED) si affiancava un grande spazio attrezzato, detto "sala di perforazione".
Era un luogo rumorosissimo, dove varie impiegate, buone dattilografe, senza fermarsi, battevano su tastiere tipo quelle delle macchine da scrivere, i dati dei documenti da elaborare. Un lavoro davvero stressante, da cambiare in meglio se e appena possibile.
Ogni gruppo di schede perforate veniva poi controllato su una macchina simile, la “verificatrice”.

Un altro strumento fondamentale era la "selezionatrice", una vera macchina infernale a vederla funzionare alla velocità di 400 schede al minuto.
Il prototipo risale ancora ad Hollerith.
Vi si impostava la prima colonna su cui eseguire l'ordinamento e le schede, alimentate da un lato, venivano sventagliate nelle 13 caselle di uscita.
A parte quella degli errori, ognuna delle altre raccoglieva un sottogruppo. Ripristinato l'intero pacco, lo si selezionava su altre colonne, fino ad ottenere l'ordinamento completo, desiderato.

Per i curiosi faccio qui l'esempio, semplificato, della fattura commerciale. I meno interessati possono passare al paragrafo successivo.
1- I dati di vendita: codice del cliente, codice dell'articolo, quantità venduta, ecc. venivano perforati e poi verificati sulle schede a 80 colonne, rispettando per ogni campo le colonne prestabilite.
2 -Attraverso una selezionatrice tutte le schede di quel ciclo di fatturazione venivano messe in ordine di codice articolo.
3 - Le schede così sistemate venivano caricate nel lettore, diciamo di sinistra, di una UR, che nell'altro suo lettore, di destra, poteva far avanzare in pari sequenza le "schede articolo" (o anagrafiche dei prodotti), per prelevarvi il prezzo unitario e perforarlo sulle schede di sinistra.
Le schede articolo, erano di un colore riconoscibile, utile in caso di inceppamenti (inevitabili); stavano sempre pronte e ordinate nei loro lunghi cassetti, da cui venivano man mano prelevate e caricate a mano, a pacchi grandi una spanna, nel lettore.
4 - Le schede completate del prezzo passavano nuovamente nella selezionatrice, per essere messe, stavolta, in ordine di cliente e di riga di documento.
5 - Una UR "calcolatrice", leggendo il pacco di schede, faceva i conti, li perforava in una nuova scheda-totale, che accodava ad ogni gruppo-fattura.
6 - Nuovamente una UR con due lettori metteva in testa a ciascun gruppo-fattura la corrispondente "scheda anagrafica cliente".
7 - Il pacco così completato veniva caricato nell'UR "tabulatrice" che finalmente stampava i documenti.
8 - Seguivano altre azioni per separare e ripristinare l'ordine delle schede anagrafiche per il giorno successivo, ecc, ecc.

La prima azienda che ho assistito era un’industria lattiero-casearia di Varese. Il mio collega DG, più anziano, aveva realizzato la migrazione dalle UR ad un sistema IBM 360/20, ma l'avviamento era ancora critico, con forti arretrati da smaltire. Il capocentro aveva chiesto all’IBM un ulteriore aiuto, così avevano mandato anche me in soccorso.

Là ho incominciato facendo cosa? Indovinate un po': mettendo in ordine i documenti da mandare in perforazione. Ma il giorno dopo, ho scritto un programmino, che ben funzionava. Poi ne ho corretto altri più complicati e via così, fino a sostituire completamente il collega DG, che mi ha ceduto tutta la responsabilità e il resto di quell’installazione.

Prima dell’assunzione avevo seguito un corso propedeutico, che oggi chiameremmo esoticamente "stage". Quella preparazione era durata 3-4 mesi, in borsa di studio, in una bellissima località: Rivoltella del Garda, alla villa Tassinara (già dimora patrizia e poi di capi del passato regime).
Durante il corso, oltre a varie nozioni economiche e gestionali, mi avevano insegnato l’RPG (Report Program Generator), un linguaggio di programmazione specifico per le problematiche che avrei dovuto seguire.

Programmare non è però il vero lavoro del sistemista, i programmi li dovrebbe fare il capocentro coi suoi programmatori, ma all'occorrenza non ci si tira indietro.
Se il programma lo facevo io, ero sicuro del risultato, facevo prima e non mi dispiaceva programmare. Per quella prima azienda di Varese ne ho scritti davvero parecchi.
I programmi più lunghi li passavo alla sala di perforazione, ma, in caso di correzioni semplici andavo là io, direttamente, a farmi le mie schede.
Entrando in quell'ufficio, con tutti quegli occhi femminili che mi seguivano, mi sentivo un po’ a disagio, quasi come se stessi entrando in un harem. E dovevo anche aggirare la capo-reparto, che mi faceva delle piccole avance; ma io ero appena sposato e mia moglie era più carina di lei.

Ogni programma andava compilato, cioè verificato e tradotto in linguaggio macchina. Anche il compilatore RPG consisteva in un pacco di schede, da alimentare prima del programma da tradurre. La sua prima scheda era una routine che diceva alla macchina: leggi e metti in memoria, una dietro l’altra, tutte le istruzioni che trovi sulle schede che ora seguono, finché non incontri quella finale (coi famosi caratteri /*) ed allora punta alla tua prima posizione di memoria ed esegui quell’istruzione.
A questo punto il compilatore era pronto a leggere il pacco delle schede da controllare e tradurre. Di tali schede produceva un “listing”, con le segnalazioni di errori “warning” e gravi. Quando di questi ultimi non ce n’erano più, perforava su schede le istruzioni in “linguaggio macchina” e stampava in coda al listato il fatidico EOJ (End Of Job).
Iniziava allora la prova del nuovo programma. Al di là di errori logici da valutare analizzando gli output, potevano esserci errori che bloccavano la macchina ed allora bisognava capire il perché. Così si “smanettava” sulla consolle del sistema, impostando sulle sue manopole in codice esadecimale le istruzioni, gli indirizzi, le correzioni o i bypass dei comandi incriminati.

Qui potete vedere l’immagine di quel modello di sistema, il 360/20, con la consolle dove si “smanettava”. Era certamente più elegante delle UR e più gradevole alla vista coi suoi pannelli colorati. Dietro a tali coperture dovete però immaginarvi un intrico di circuiti e dispositivi. Non c’erano “cabinet” semivuoti, come negli attuali PC, che hanno tutto miniaturizzato al massimo. I circuiti, le memorie e i processori di allora avevano il loro ingombro e fisicità.

Per il sistema IBM 360/20 era anche possibile scegliere il colore. Non c’era soltanto il "blu IBM" della figura, ma anche il rosso ed il giallo. Il blu, più serio, andava per la maggiore ed il rosso ogni tanto (sinistrofili?). Per il giallo mi risulta che sia stato scelto, in coerenza ai colori pontificali, nel sistema destinato alla Curia di Milano, là venduto da un collega rappresentante, il conte DVP, ben introdotto con le sue tante conoscenze in Arcivescovado.

Non c’è voluto molto perché il nuovo sistema incominciasse a dare l’accelerazione desiderata ai processi dell'azienda.
Coi suoi circuiti integrati, sufficiente memoria, le unità di I/O direttamente collegate (stampante e "multifunction"), faceva tutto meglio e molto più rapidamente delle macchine che aveva sostituito.
Esaudite le esigenze di base, sono venute man mano fuori nuove richieste e possibilità: consuntivi, statistiche, proiezioni commerciali, ecc.

Quella di Varese è stata la prima esperienza, ma subito mi sono state affidate, altre aziende da assistere, per realizzare per intero la loro conversione o meccanizzazione ad elaboratori IBM.
Di solito ne seguivo due o tre in contemporanea, per periodi di tempo di alcuni mesi. Ero quasi sempre presso di loro, dato che le analisi, le interviste dovevano avvenire in loco, negli uffici e reparti di quelle strutture, a colloquio con questo o quel dirigente, capoufficio o caporeparto.
All'analisi seguiva la progettazione, poi lo sviluppo e poi decine di test, prove e riprove fino alla messa a punto definitiva.
Il momento più critico, come ben immaginate, era quello finale, dell'avviamento, dove si scoprivano e si correggevano gli errori più imprevedibili, sempre nascosti e inevitabilmente presenti nei programmi.

Quando iniziavo con una nuova azienda, incontravo parecchia reticenza tra le persone che intervistavo. Era un riserbo giustificabile dal timore di possibile perdita di potere e dal dover cambiare un lavoro che ben conoscevano con chissà quale cosa nuova e complicata.
Ma in realtà, dopo il rodaggio del nuovo sistema, ho sempre trovato persone sorridenti e soddisfatte, capi e dirigenti contenti di rivedermi e con nuove proposte per altre innovazioni da progettare sui loro nuovi strumenti. Tappeto rosso, insomma.

Non ho mai trovato due realtà uguali né troppo somiglianti: ognuna aveva sempre qualcosa di suo proprio e specifico. Quindi: mai niente di ripetitivo, ma sempre problemi e stimoli per nuove realizzazioni e, di conseguenza, tanti buoni motivi perché io facessi volentieri quel lavoro.

Non erano mai cose semplici, c’erano sempre piccoli o grandi ostacoli da superare.
Ad esempio, tra gli altri miei primi clienti ho assistito un grande pastificio che aveva gli uffici amministrativi a Milano, in zona piazzale Loreto. L’azienda migrava dalle UR ad un piccolo 360/20, ma veramente il più piccolo possibile. Aveva infatti soltanto 4K (sic!) di memoria, cioè meno della memoria di un computer giocattolo di qualche anno fa o di un semplice, primo telefonino con l'agenda.
Pensate un po’, in soli 4K dover fare: bolle di spedizione, fatture di vendita, statistiche commerciali, contabilità, paghe e stipendi e via di seguito!
Lavorare in RPG richiedeva molta più memoria di quella installata. Perciò molte routine sono state fatte in Assembler, linguaggio più spartano, perché vicino al “linguaggio macchina”.
L’ho insegnato al capocentro. In cambio ho assorbito avidamente i segreti dei processi amministrativi e contabili che lui doveva programmare, dato che per la mia estrazione ingegneristica, con quelle cose non avevo mai avuto nulla a che fare.

All'occorrenza ho imparato anche altri linguaggi: Fortran, Cobol, Basic, ecc..
Di clienti ne ho seguiti tantissimi, specializzandomi in imprese di produzione. Non le ricordo neppure tutte.

Quello dei miei primi tempi in IBM è stato un lavoro bellissimo, che mi ha permesso di conoscere e apprendere dal vivo la realtà di tante organizzazioni e di entrare in relazione con moltissime persone che lì vi lavoravano.
Non è durato molto, perché, avanzando in carriera, ho dovuto occuparmi di ben altro: gestione dei collaboratori, management, strategie e politiche aziendali, cose del tutto diverse pur se importanti.
Ma mi è sempre rimasto un po' di rimpianto.

Fine prima parte

G.A.

Ritorno all'Archivio completo     Ritorno alla Selezione dei Racconti