Relazione per il riconoscimento dell'attività lavorativa
Diego Cimarosa
Corso di Laurea in Scienze di Internet
Matricola 0900025311
Attualmente sono dipendente a tempo indeterminato presso l’Università di Bologna ed inquadrato come
“Collaboratore di Elaborazione Dati” presso il Dipartimento di Statistica “Paolo Fortunati” in Via Belle
Arti 41 Bologna.
Le mie esperienze lavorative in ambito I.T. iniziano nel 1982 e cercherò di riassumerle, partendo dalla
più recente e secondo le linee guida del “Modello di Relazione Attività Lavorativa”.
Questo documento è disponibile anche in formato elettronico agli indirizzi:


http://www.diegocimarosa.it/Docs/relazione_tirocinio.pdf
http://137.204.109.4:8080/diego/Tirocinio/relazione_tirocinio.pdf
1 di 31
Indice
Curriculum vitae riassuntivo ................................................................... 4
Università di Bologna ............................................................................... 5
Dati essenziali..................................................................................................................................5
Attività svolte ...................................................................................................................................5
Relazione .........................................................................................................................................6
Introduzione .................................................................................................................................6
Documenti....................................................................................................................................6
Rete del Dipartimento ..................................................................................................................8
Altre attività .................................................................................................................................8
Tecnologie utilizzate ....................................................................................................................8
Università di Parma ................................................................................ 10
Dati essenziali................................................................................................................................10
Attività svolte .................................................................................................................................10
Relazione .......................................................................................................................................10
Introduzione ...............................................................................................................................10
Documenti..................................................................................................................................11
Altre attività ...............................................................................................................................11
Tecnologie utilizzate ..................................................................................................................11
Elsag Bailey S.p.A. .................................................................................. 12
Dati essenziali................................................................................................................................12
Attività svolte .................................................................................................................................12
Relazione .......................................................................................................................................12
Sistema Informativo Elsag .........................................................................................................12
PtPostel ......................................................................................................................................13
PtFax ..........................................................................................................................................15
Corsi effettuati in Elsag/IBM.....................................................................................................15
Riferimenti.....................................................................................................................................17
Seiaf S.p.A................................................................................................ 18
Dati essenziali................................................................................................................................18
Attività svolte .................................................................................................................................18
Relazione .......................................................................................................................................18
Introduzione ...............................................................................................................................18
Principali progetti.......................................................................................................................19
Tecnologie utilizzate ..................................................................................................................25
Riferimenti.....................................................................................................................................25
Morteo Soprefin S.p.A. ........................................................................... 27
Dati essenziali................................................................................................................................27
Attività svolte .................................................................................................................................27
Relazione .......................................................................................................................................27
Introduzione ...............................................................................................................................27
Attività svolte.............................................................................................................................27
Tecnologie utilizzate ..................................................................................................................28
Riferimenti.....................................................................................................................................28
Firenze...................................................................................................... 29
Dati essenziali................................................................................................................................29
Attività svolte .................................................................................................................................29
Relazione .......................................................................................................................................29
2 di 31
Riferimenti.....................................................................................................................................31
3 di 31
Curriculum vitae riassuntivo
Informazioni
personali
Istruzione
Esperienza
professionale
Conoscenze
informatiche
Lingue
straniere
Hobbies
Stato civile: Separato
Telefono – Casa: 051.6920603
Nazionalità: Italiana
Ufficio: 051.209822
Data di nascita: 29/07/1959
Cell. : 331.4230912
Luogo di nascita: Genova
E-mail : [email protected]
Web: http://www.diegocimarosa.it/
Domicilio:
Via Caduti di Cefalonia 57
40054 Budrio (BO)
Diploma di “Perito Elettrotecnico” conseguito nel 1978/79 presso l’I.T.I.S.
“G. Giorgi” di Genova con votazione finale di 48/60
Corsi triennali inglese presso “British School of Genoa” (1976/79)
Corsi inglese interni Elsag Bailey S.p.A. Genova
Corsi professionali presso IBM Italia e Digital (Programmazione C, OOP,
Gestione DB)
Iscritto al III° anno del Corso di Laurea in “Scienze di Internet” presso l’Università
di Bologna
Dal 1/12/2003 presso il Dipartimento di Scienze Statistiche – Università di
Bologna come “Collaboratore di Elaborazione Dati”. Assistenza HW/SW a
Docenti e Personale facoltà. Supporto gestione rete e servers Dipartimento
Dal 16/10/1998 al 30/11/2003 presso la Facoltà di Giurisprudenza dell’Università
di Parma come “Collaboratore di Elaborazione Dati”. Gestione Laboratorio di
Informatica per Studenti, Assitenza HW/SW a Docenti e Personale facoltà, corsi
Informatica per studenti, gestione server web ed iscrizione esami
Dal 1995 al 15/10/1998 presso Elsag Bailey S.p.A. come analistaprogrammatore. Sviluppo e gestione SW PTPostel e PTFax su sistemi Digital per
Poste Italiane. Assistenza all’Hot Line. Sviluppo SW per procedure interne Elsag
su mainframe Siemens/BS2000
Dal 1990 al 1995 preso S.E.I.A.F. S.p.A. analista-programmatore. Sviluppo
procedure interne IBM Italia e consulenze esterne su Gestione Produzione
(COPICS/IBM). Principali clienti: Merloni Elettrodomestici, ILVA
Dal 1987 al 1990 presso Morteo Soprefin S.p.A. Genova come programmatore.
Sviluppo SW per procedure interne in ambiente IBM 4381
Dal 1983 al 1987 presso Studio Ballotta Firenze come programmatore. Sviluppo
SW per clienti in ambiente IBM/8100
Sistemi Operativi: MS-DOS, Windows, Linux, Vax/VMS, CMS, DPPX, TSO,
MVS, CICS, DB2
Linguaggi: COBOL, C, SQL, Perl, PHP, Visual Basic, Access, C++, Jscript,
VBScript, Assembler (in ordine di esperienza)
HW: PC, Reti Ethernet
Buona conoscenza Inglese per corsi privati ed esperienze lavorative
Lettura, trekking, subacquea, hw,sw
4 di 31
Università di Bologna
Dati essenziali


In servizio presso il Dipartimento di Scienze Statistiche “Paolo Fortunati” – Via Belle
Arti 41, Bologna in qualità di “Collaboratore di Elaborazione Dati” dal 1/12/2003.
Referenti:
o Prof.ssa Rosella Rettaroli (Direttore Dipartimento)
+39 051 20 9 8243
[email protected]
o Sig. Roberto Sgarbi: Responsabile Laboratorio Informatica del Dipartimento
+39 051 20 9 8231
[email protected]
Attività svolte
Il mio compito principale nel Dipartimento di Statistica è l’assistenza informatica ai docenti,
ricercatori e personale tecnico ed amministrativo, riassumibile in:











Installazione di nuovi PC con configurazioni di rete nel dominio personale.unibo.it
Installazione e configurazione software per uso “office” (Microsoft Office, Open Office,
famiglia prodotti Adobe) e per uso statistico/matematico (R, Stata, SPPS, Matlab,
Mathematica ecc.)
Gestione software per accounting stampanti
Manutenzione hw e sw: sostituzione schede e componenti PC per guasti e/o upgrades,
antivirus ecc.
Interventi sui server web, file server, backup dati, Terminal Server di Dipartimento quando
necessario
Assistenza utenti per risoluzione problematiche legate ad uso avanzato di pacchetti software
es.: macro per elaborazioni particolari in Excel, Access, Photoshop, configurazione librerie
per sviluppo in Fortran, C
Sviluppo piccole applicazioni per problematiche gestionali interne al Dipartimento (es.
Reclami utenti Biblioteca, automatizzazione stampa modulo prestiti con macro di tastiera)
Sviluppo semplici siti web per incontri e convegni organizzati dal Dipartimento
(http://www2.stat.unibo.it/moda2010/, http://nuke.stat.unibo.it/moda9/,
http://www2.stat.unibo.it/reclami/reclami.asp)
Installazione apparecchiature per conferenze e presentazioni
Preparazione preventivi per acquisti HW e SW
Documentazione tecnica
5 di 31
Relazione
Introduzione
Al Dipartimento di Statistica afferiscono circa 80 persone fra Docenti, Ricercatori, Dottorandi e
Personale Tecnico Amministrativo molte delle quali hanno in dotazione, oltre la postazione fissa,
uno o più portatili perciò il totale dei PC collegati e gestiti è di circa 130/140 macchine ai quali si
aggiungono le 12 stampanti dipartimentali.
Compito del Laboratorio Informatico è garantire agli utenti i servizi specificati nel documento
pubblicato all’indirizzo: http://www2.stat.unibo.it/qualita/MQ55All02Rev00_CartaServiziLabis.pdf
Fra i quali:
a) servizi informatici di interesse comune
b) servizi rivolti alle unità operative
c) servizi informatici individuali
d) consulenza e formazione
Il mio compito è quello di soddisfare i punti b), c) e d) ed in caso di necessità anche il punto a).
In modo più semplice, mi occupo prevalentemente dei servizi “lato client” ed occasionalmente dei
servizi “lato server” gestiti in maniera più massiccia da miei colleghi.
Documenti
Il Dipartimento nel suo complesso persegue da anni una “politica di qualità”; infatti, la Biblioteca
ha ottenuto la certificazione di qualità “UNI EN ISO 9001:2000 da Det Norske Veritas” già nel
2004 ed il resto delle strutture (Laboratorio di Informatica compreso) nel 2007.
I documenti più importanti sono disponibili sul sito ufficiale del Dipartimento,
http://www.stat.unibo.it/ScienzeStatistiche/default.htm, nel riquadro “Servizi”, voce “Carta dei
Servizi” ed in particolare la carta dei servizi del Laboratorio è disponibile nella pagina citata sopra.
Per auto-monitorarci e fornire gli opportuni indicatori di qualità, ci siamo dotati di un semplice ma
efficace strumento di rilevazione degli interventi svolti, in sostanza un piccolo applicativo basato su
MS-Access di cui riporto un screen-shot esplicativo.
6 di 31
7 di 31
Rete del Dipartimento
Ho preparato questo schema tre anni fa per cui adesso risulta un po’ obsoleto in quanto alcuni
server sono stati “pensionati”. Aspettiamo i fondi per virtualizzare il tutto su piattaforma Dell e
software Xen Open Source.
Schema logico funzionale – Rete Dipartimento di Statistica
137.204.109.2
137.204.95.203
Ostia (WEB)
MAGENTA
(E-mail
Webmail)
137.204.109.1
137.204.95.205
ELBA
(File Server
Home Utenti
Domain Controller)
CHIANTI
(Printer server
Printing Accounting
SQL
File Server)
SAMBUCA
(DNS)
137.204.109.200
DMZ4
INSIDE
CANNE
(Web
DNS
SMTP)
137.204.95.200
137.204.109.254
GALAGA’
(Banche dati)
PC Docenti e personale
PIX Firewall
137.204.95.204
SERIES
137.204.
.254
CISCO
PIX119
FIREWALL
DMZ1
137.204.95.150
ALMANET
AP3
137.204.119.1
Dottorandi
137.204.119.254
PIX Firewall
DMZ3
BAROLOCUBE
(File Server
Home Utenti
Domain Controller)
119
Via Zamboni 18
68
Palazzo Bianconcini
SE RIES
PIX 515
137.204.95.129
PIX Firewall
SE RIES
Net PC Biblioteca
GOITO
(Terminal Server
DHCP)
AP1
137.204.95.152
AP2
PIX 515
137.204.95.151
Master
Altre attività
Fra le varie attività da me svolte in Dipartimento riporto anche quelle di realizzazione di alcuni
semplici siti web per attività istituzionali:




http://www2.stat.unibo.it/moda2010/
http://nuke.stat.unibo.it/moda9
http://www2.stat.unibo.it/reclami/reclami.asp
Sito web personale: http://www.diegocimarosa.it
Sporadicamente sono coinvolto in attività “accessorie” quali la modifica/creazione di grafica per
varie esigenze ed altro (disassembler di moduli JAR usati per la stampa etichette dei libri in prestito,
modifica di shape files, ecc. …)
Tecnologie utilizzate
L’infrastruttura del Dipartimento è in lento ma continuo movimento: per esempio, nel 2006
abbiamo dismesso il servizio di posta interna gestito su server Linux Open Suse in quanto con gli
8 di 31
strumenti open-source allora disponibili non siamo stati in grado di risolvere efficacemente il
problema dello spam. Ho curato in prima persona la migrazione verso il sistema di posta di Ateneo
riconfigurando tutti i client e recuperando quando possibile i vecchi messaggi e, per molti docenti, i
relativi e preziosissimi allegati.
Ultimamente, dopo accurato studio sui costi-benefici, abbiamo deciso di abbandonare il dominio
STATISTICA ed abbiamo migrato tutti i client sul dominio PERSONALE (non sempre in modo
indolore!). All’atto pratico, questa migrazione, effettuata anche con la collaborazione del Cesia, ha
comportato la riconfigurazione di ogni singolo client e la modifica dei permessi di ogni oggetto
tramite tools di conversione.
Da qualche mese abbiamo iniziato un progetto per la virtualizzazione di quasi tutti i servizi rimasti:
Web Server, File Server, Printer Server, Backup Server attualmente gestiti in ambito Windows 2003
Server, ma, come accennato prima siamo ancora in attesa di fondi.
Per le varie attività in cui sono coinvolto ho utilizzato ed utilizzo varie tecnologie e strumenti
software:




Microsoft Windows
Server 2003, DevStudio 2005 e 2008, Sql Server, IIS 6, Office 2003/2007
Linux (Red Hat/OpenSuse)
Apache, Perl
9 di 31
Università di Parma
Dati essenziali


In servizio presso la Presidenza della Facoltà di Giurisprudenza dell’Università di
Parma – Via Università 12 Parma, dal 16/10/1998 al 30/11/2003
Referenti:
o Posso indicare la Dott.ssa Ceccato, responsabile della Biblioteca Centrale di
Giurisprudenza 0521/034599 e-mail: [email protected] in quanto non conosco il
Preside ed il Segretario attuali
Attività svolte






Gestione Laboratorio di Informatica per Studenti Tesisti
Assistenza HW/SE al personale di Facoltà
Gestione server Web Biblioteca e Laboratorio
Gestione prenotazione liste esami
Gestione banche dati giuridiche
Corsi di Informatica per studenti
Relazione
Introduzione
Non posso descrivere in dettaglio 5 anni di attività ma riassumendo posso scrivere di aver avuto il
privilegio e senza falsa modestia, il merito, di aver contribuito in modo sostanziale
all’alfabetizzazione informatica della Facoltà. All’epoca, sto parlando del 1998, l’I.T. era ben
diversa da quella attuale. Il Web era per molti una parola sconosciuta, Microsoft, reduce dal
clamoroso successo di Windows 95 aveva appena rilasciato Windows 98 che, notoriamente, non è
stato un sistema operativo “robusto”. Se non vado errato, Windows NT Server 4.0 costava, nel
1998, circa 4 milioni di Lire che confrontati con i circa 2 milioni di un PC Acer con 128Mb RAM e
4.3 Gb, all’avanguardia per quell’epoca1, era assolutamente improponibile per le finanze della
Facoltà. Per sopperire a questa mancanza installai un server Linux Red Hat iniziando a fornire
servizi di rete quali FTP, HTTP, GOPHER ed autenticazione client Windows 98 attraverso Samba.
I siti Web si scrivevano all’epoca con Vi e ricordo con piacere alcune corrispondenze tecniche
proprio con gli autori di questo eccezionale software di condivisione2. Era normale poi ricompilare
il kernel Linux almeno due/tre volte al mese per tenerlo aggiornato … e funzionante!
Un altro servizio web da me curato, in collaborazione con un docente di Informatica, è stata la
prenotazione esami; applicazione web scritta in Perl.
1
2
Che tenerezza … !
http://lists.samba.org/archive/samba-docs/2002-May/000184.html
10 di 31
Ho tenuto alcuni corsi di informatica rivolti agli studenti laureandi visto che molti di loro hanno
utilizzato per la prima volta un pc nel laboratorio che gestivo.
Successivamente ho usato la rete dei 27 PC come piattaforma di banche dati giuridiche superando
non poche problematiche relative agli aggiornamenti ed alla condivisione. Dal 2002 questo servizio
era diventato ingestibile e fortunatamente riuscii a convincere i responsabili della struttura ad
attivare un servizio centralizzato basato su piattaforma Citrix Metaframe.
Nel poco tempo disponibile riuscivo anche ad “assistere” il personale docente ed amministrativo
(circa un centinaio in totale). L’assistenza variava dall’installazione di nuovi pc alla scrittura di
software per l’estrapolazione di dati dalle banche dati giuridiche o di software per l’inventario e gli
acquisti della Biblioteca più, ovviamente, tutte le problematiche nell’uso comune di un sistema
operativo, ripeto, instabile come Windows 98.
Documenti
Allego fotocopie di fogli di servizio rilasciati dalla Presidenza della Facoltà di Giurisprudenza e dal
Responsabile della Biblioteca Centrale della Facoltà di Giurisprudenza dell’Università di Parma
Altre attività
Riporto in questo paragrafo un corso da me tenuto relativo alla “Sicurezza Informatica” per conto
IPSOA e Regione Emilia Romagna nel quadro di un corso di 800 ore per la formazione
professionale di giovani disoccupati ed alcune consulenze in ambito bancario su mainframe IBM
per l’azienda di servizi Cedacri Nord di Parma.
Tecnologie utilizzate
Come riportato sopra le principali tecnologie da me utilizzate in questo periodo sono state:
 Windows 98, Citrix Metaframe
 Linux Red Hat, Apache, Perl, MySql
e, come consulente esterno:
 IBM MVS, DB2/CICS, Cobol
11 di 31
Elsag Bailey S.p.A.
Era una società del gruppo Finmeccanica, oggi Elsag Datamat. Storicamente ha rappresentato, sin
dal 1905, una tassello fondamentale dell’industria genovese e quindi con il gruppo Ansaldo, di
quella italiana.
Dati essenziali


In servizio in qualità di analista-programmatore dal 1995 al 15/10/1998
Referenti: le uniche persone che conoscevo di cui ho ritrovato traccia sono:
o Dott. Giuseep Saracini – Referente Elsag Datamat per il Settore Informatica
[email protected]
tel. +39 348 3675317 (Genova)
o Dott. Franco Cavagnaro – Direttore Strategie e Sviluppo Tecnologie Elsag Datamat
http://it.linkedin.com/pub/franco-cavagnaro/8/7a7/a52
Attività svolte



Sviluppo sw per contabilità e gestione magazzini Elsag su sistema Siemens-Fujitsu
BS2000/OSD con database Cognos/SESAM
Sviluppo sw per contabilità, fatturazione, clienti PtPostel, PtFax su sistemi Vax/Vms
Gestione rete PtFax su sistemi Unix distribuiti
Relazione
In Elsag S.p.A. ero un programmatore-analista ed ho, nel primo anno, sviluppato software per il
Sistema Informativo della società che utilizzava all’epoca un mainframe Siemens con S.O. BS2000.
In pratica un “clone” del mainframe ES/9000 di IBM.
Sistema Informativo Elsag
La particolarità di questo sistema era il database COGNOS/SESAM di tipo reticolare che univa le
funzionalità dei due maggiori database utilizzati allora sui mainframes IBM: il DL/1 di tipo
gerarchico ed il DB2 di tipo relazionale. All’epoca la società aveva vari settori di produzione: dal
militare (sistemi di puntamento arma, guida elettro-meccanica missili, radar) al postale
(smistamento automatico corrispondenza, riconoscimento ottico indirizzi) passando per la
componentistica navale ed altro. Il tutto faceva riferimento alla Distinta Base (fondamentale nel
settore manifatturiero) ed alla sua gestione in quanto perno sul quale ruotava la progettazione, la
produzione, l’assemblaggio, la vendita e la contabilità. Nel corso degli anni e di varie
ristrutturazioni aziendali con acquisizioni, fusioni e rimescolamenti contabili, si era creata una
situazione ingestibile; in sostanza i magazzinieri non sapevano più come e su quali commesse
attribuire i vari assemblati e le linee di produzione su quali commesse “caricare” le lavorazioni. Su
richiesta del Direttore dei Sistemi Informativi ho effettuato una revisione completa delle codifiche
di alcuni milioni di pezzi ridisegnando una bella fetta dello schema del database e scrivendo exnovo diversi e complicati programmi. Ricordo con sgomento la prima volta che vidi lo schema
generale del database: sembrava quello di una centrale nucleare. Ogni singolo rettangolino di 2x3
cm rappresentava una struttura dati attinente a qualche funzionalità del Sistema ed il tutto si
sviluppava su un foglio di 2 metri per 1.50 circa … Quel Sistema Informativo aveva avuto,
ovviamente una storia assai travagliata: in origine era un COPICS/IBM su architettura gerarchica e
riscritto da consociate americane in visione reticolare. La riconversione che ho effettuato portò
12 di 31
come “effetto secondario” un recupero contabile di più di 300milioni di lire dell’epoca per via di
ammortamenti fiscali altrimenti impossibili da fare manualmente. L’”effetto primario” è stato
quello di permettere ai magazzinieri di eseguire i corretti abbinamenti fra i pezzi e le commesse …
PtPostel
Finita questa faticosa riconversione sono passato al reparto PtPostel e successivamente a PtFax.
Uno dei primi problemi che mi furono sottoposti era legato alla lentezza delle operazioni legate alla
fatturazione del servizio che riassumo qui in poche righe:
Le Poste e le Ferrovie sono senza alcun dubbio la spina dorsale di un paese moderno. Se ricordiamo
la situazione italiana degli anni ’80 e ’90 non credo che possiamo gioire molto. Per sopperire al caso
creatosi in seguito a scioperi del personale e ad arretratezza tecnologica le Poste Italiane iniziano
intorno al 1970 un percorso di ammodernamento con l’introduzione del CAP e via via con apparati
elettro-meccanici ed elettronici per la gestione della corrispondenza.Oltre ad Olivetti, un altro attore
principale fu, e continua ad esserlo, il gruppo Ansaldo che demandò ad Elsag la risoluzione del
problema.
Con l’introduzione nel 1975 del microprocessore MOS 6502 fu possibile per i tecnici Elsag ed
Ansaldo sviluppare un sistema di riconoscimento della scrittura manuale basato sull’uso in parallelo
di questi micro.
Questo portò alla meccanizzazione postale riassumibile nella sigla CMP: Centro di
Meccanizzazione Postale. A Bologna Corticella ce ne è uno dei più grandi di Italia dopo quello di
Roma Fiumicino.
Un CMP è essenzialmente un capannone di alcune centinaia di metri con un lungo nastro
trasportatore sul quale viene riversata la corrispondenza raccolta da Poste Italiane. Per mezzo di
svariati meccanismi le buste, cartoline ed altro vengono raddrizzate e fatte scorrere ad alta velocità
sotto una serie di lettori ottici gestiti dai micro-processori ricordati poco sopra. Il software riesce in
tempo reale a decodificare il CAP letto dalla corrispondenza ed a comandare l’apertura di un sacco
postale per la raccolta e la distribuzione finale all’ufficio di competenza. Il tutto avviene con una
percentuale di successo prossima al 100% per gli stampanti e con un errore del 3 per 10000 per la
scrittura manuale.
Tutti gli apparati, elettrici, elettronici e software sono stati sviluppati e realizzati nello stabilmento
di Genova-Sestri Ponente anche in collaborazione con l’Università di Genova.
In seguito al successo tecnologico e commerciale di questi sistemi e l’avvento di sistemi di
elaborazione via via più economici (almeno per le imprese), il Dott. Cavagnaro propose l’idea di un
sistema di raccolta dati e stampa della corrispondenza riservato a grossi enti ed aziende. Il segmento
di mercato individuato fu quello della stampa di fatture per servizi domestici, conti bancari ecc. In
sostanza, enti quali Enel, enti comunali per la fornitura di gas o acqua, consegnavano ai centri di
raccolta i nastri contenenti i dati di fatturazione dei loro clienti e nei centri di stampa sorti a
corollario dei CMP venivano stampate ed imbustate le fatture poi inoltrate nel centro di
smistamento.
Anche questa fu un’innovazione che ebbe molto successo e che portò nel corso degli anni ’80 e ’90
alla creazione di una rete di raccolta e stampa piuttosto articolata sul territorio nazionale.
13 di 31
Nel 1993 il sistema PtPostel contava più di 20.000 grandi clienti, utilizzatori del servizio di Posta
Massiva ed alcune migliaia di “piccoli” clienti. Ogni mese venivano complessivamente stampate
decine di milioni di fatture, lettere, opuscoli e quant’altro, tutto inoltrato al CMP di competenza.
Ovviamente, tutto questo traffico doveva essere contabilizzato prima di generare forti introiti per la
società e qui entro in “scena” io.
All’epoca, in ambito informatico, i PC erano abbastanza diffusi ma non come oggi essenzialmente
per i costi elevati e le scarse capacità elaborative. In ambito professionale c’erano tre grosse realtà
che si parlavano poco e male: il mondo Unix con le WorkStation scientifiche, il mondo IBM con i
mainframes “per i conti” ed il mondo Vax per i processi industriali.
Per cultura, tradizione, storia e formazione tecnica, in Elsag erano predominanti i sistemi Vax e su
questa piattaforma, Digital VAX/6000 fu sviluppato, con un linguaggio assolutamente innovativo
per l’epoca, il PowerHouse, il sistema di contabilizzazione del servizio PtPostel.
Fui chiamato a risolvere un “piccolo” problema di prestazioni: la procedura di fatturazione durava
“mediamente” 8/9 … giorni con punte di 14 !!!! Considerando che per esigenze contabili era
necessario fare un “giro” di prova sulla base del quale i contabili effettuavano dei campionamenti
verificando manualmente alcune fatture si capisce che un intoppo poteva portare ad una mancata
fatturazione mensile con serie ripercussioni contabili [scenario già occorso in passato].
Dopo pochi giorni di auto-istruzione sull’RMS, il file system del Vax/VMS, scoprii che il problema
poteva essere dovuto al fattore di riempimento del blocco dati nella definizione dei dataset in
quanto, per default, prevedeva l’utilizzo del 100% dello spazio.
Se questi dati fossero stati dei semplici files sequenziali questo non avrebbe avuto alcuna influenza
ma essendo indicizzati ebbe una clamorosa ripercussione in fase di elaborazione della fatture in
quanto ogni nuova chiave, per essere “sistemata” nella giusta sequenza comportava la riscrittura di
moltissimi blocchi. In sostanza, i vantaggi dell’indicizzazione dei dati venivano annullati dal costo
di creazione di una struttura totalmente sbilanciata con costi computazionali dell’ordine di
O  n 2  anziché del voluto O  log  n   .
Dopo aver scaricato i dati, ridefinito i datasets, e ricaricato i dati [e col terrore negli occhi da parte
dei miei superiori … ] rilanciai l’applicazione, che stava frullando da 14 giorni e dopo 2h e 40’
consegnai ai contabili il tabulato delle fatture … non male per aver modificato una riga di codice
nella definizione dei dati!
Nei successivi sei mesi, oltre ad implementare numerose altre funzionalità al sistema contabile
“giocai” con l’RMS ed il tempo finale scese ad 1h e 40’. Forse fu per questo che il mio “capetto” di
allora se la prese male tanto che fui costretto dopo poco tempo a cambiare reparto …
A distanza di anni, ripensando ai quei fatti continuo a sostenere che un sistema come il Vax/6000
non era progettato per la gestione dati; un IBM/3090 “medio” dell’epoca non avrebbe impiegato più
di qualche decina di millisecondi di CPU con un tempo complessivo, in funzione del carico batch,
di al massimo 3-4 minuti; tempi che mi aspetterei da un moderno e potente pc multicore attuale.
14 di 31
PtFax
Come riportato sopra, dopo poco tempo cambiai reparto e mi occupai della gestione del nascente
servizio PtFax. In sostanza, gli abbonati al servizio, aventi l’esigenza di inviare un alto numero di
fax a clienti od altri utenti, chiamavano uno dei 18 centri di distribuzione (in pratica uno per regione
– all’epoca c’era ancora la teleselezione Telecom) in cui un risponditore automatico, previa verifica
dei codici di accesso, richiedeva il codice della lista di distribuzione precedentemente inviata e
quindi il fax da abbinare. Il sistema, hw & sw, acquistato dalla Marconi International americana
richiese diverso tempo per la messa a punto con l’intervento dei tecnici americani ed inglesi per la
riconversione della gestione dei segnali telefonici. Alcuni segnali infatti non erano interamente
compatibili con lo standard Telecom. Sono stato circa due mesi al CMP di Roma Fiumicino per
aiutare i tecnici Marconi per l’installazione di tutto il sw di gestione della rete e di
contabilizzazione. Il software acquistato, scritto in C, era senza codice sorgente ed ogni modifica
richiesta per adattarlo ai nostri sistemi contabili aveva costi esorbitanti. Dopo aver “scoperto” il
linguaggio Perl mi accorsi e riuscii con alcuni scripts a ricreare tutti i dati necessari alla
contabilizzazione semplicemente esaminando il file di log prodotto in real-time dal sistema
Marconi. Il mio compito principale era però di tipo sistemistico: dovevo far funzionare la rete dei
18 nodi Unix e monitorare lo stato di lavorazione dei fax. In quest’ottica ero anche il supporto
tecnico dell’HotLine telefonica attivata per il supporto utenti PtFax., che, per mia fortuna, non ha
mai avuto un successo esplosivo (circa 8000 clienti al suo massimo splendore). Il problema tecnico
era il sostanziale sottodimensionamento delle apparecchiature: era stato sviluppato per le esigenze
interne di inoltro fax di Marconi International che aveva alcune decine di sedi sparse per il mondo.
Si cercava di farlo funzionare per un volume di traffico di 3 ordini di grandezza superiori. Capitò
che, senza nemmeno avvertire, Microsoft Italia schedulò un invio di circa 15000 fax pubblicitari a
potenziali clienti per una convention. Non si trattò più di “amministrazione di sistemi Unix” ma di
un vero e proprio incontro di catch per far funzionare il tutto. Infatti, per essere remunerativo,
l’inoltro dei fax su linea Telecom doveva avvenire in ambito urbano per evitare la tariffazione a
tempo interurbana e costosa dell’epoca. Adesso è comune scaricare una foto di 1Mb da un sito
internet ma nel 1993 non era così. Il Web era uscito dai laboratori del Cern solo due anni prima e le
aziende, fra le quali Elsag, usavano reti affittate per la trasmissione dati quali ITAPAC. Ricordo che
quella rete, per gli utenti “normali” non superava i 2400 baud e per quelli “professionali” i 9600 baud
corrispondenti ai 57.5 Kb/sec massimi delle comunicazioni su rete telefonica pubblica. Considerando che il
sistema Marconi prevedeva l’inoltro con uucp si può capire le nottate passate in ufficio a far funzionare il
tutto …
Corsi effettuati in Elsag/IBM
La società, abituata da sempre ad una visione internazionali “obbligava” 3 i suoi dipendenti a
seguire corsi di mantenimento e perfezionamento; personalmente ho partecipato ai seguenti :



3
Lingua inglese: come corso scolastico annuale, durata 3 anni
Progettazione Data Base DB2: presso IBM Vimercate, durata 40 ore
Progettazione Data Base RMS: sede Elsag tenuto da Digital Italia durata 40 ore
Pena la fustigazione in sala mensa … 
15 di 31


Progettazione OOP: sede Elsag tenuto da IBM, durata 40 ore
Linguaggio C: presso IBM Vimercate, durata 40 ore
16 di 31
Riferimenti
http://www.elsagdatamat.com/Home.htm
http://it.wikipedia.org/wiki/Elsag
http://archiviostorico.corriere.it/1992/marzo/31/ELSAG_BAILEY_1991_crescita_co_0_920331187
7.shtml
http://en.wikipedia.org/wiki/BS2000
http://ts.fujitsu.com/products/bs2000/index.html
http://en.wikipedia.org/wiki/VAX
http://en.wikipedia.org/wiki/PowerHouse_(programming_language)
http://de.wikipedia.org/wiki/SESAM
http://it.wikipedia.org/wiki/Distinta_base
http://www.fredrickgroup.com/s1/dbgo1mst.htm
http://it.wikipedia.org/wiki/Centro_di_Meccanizzazione_Postale
http://it.wikipedia.org/wiki/MOS_6502
http://en.wikipedia.org/wiki/VAX_6000
http://it.wikipedia.org/wiki/ITAPAC
http://it.wikipedia.org/wiki/Baud
http://it.wikipedia.org/wiki/UUCP
17 di 31
Seiaf S.p.A.
Società fondata nel 1984 come partnership fra Elsag ed IBM Italia mirata all’automazione di
fabbrica: Sistemi Elettronici ed Informatici per l’Automazione di Fabbrica
Dati essenziali


Dal 1990 al 1995 come analista-programmatore
Referenti: nessuno; società sciolta
(Potrei indicare l’Ing. Alberto Lina all’epoca amministratore delegato di SEIAF, col quale
ebbi uno “scambio di vedute” piuttosto burrascoso durante un periodo di cassa integrazione
di metà del personale per questione legate alla gestione dell’unico progetto [descritto più
avanti] che creava flusso di cassa per la società ma onestamente non penso che si possa
ricordare di me)
Attività svolte


Programmazione in Pl/1, DB2 in ambiente IBM MVS/TSO per sviluppo procedure interne
IBM/Italia
Consulenze esterne come analista-programmatore in ambito “gestione produzione” per
grandi aziende italiane su piattaforme IBM ES/9000 MVS/TSO
Relazione
Introduzione
La società nacque sulla base di previsioni di sviluppo economico a mio giudizio errate tant’è che
dopo 11 anni il consorzio fu sciolto. Le cause, a mio avviso, furono queste:


Differente “visione” del business: modello americano incompatibile con la visione
“genovese”
Tecnologia carente: IBM voleva affermare il suo Token Ring che fallì in una “prova” per
noi fondamentale: la Pirelli England affidò a SEIAF il compito di automatizzare
completamente una fabbrica di cavi in fibra ottica che doveva sorgere a nord di Londra.
Quando il sistema fu pronto ed installato in fabbrica funzionava fino a 100/110 bobinatrici
collegate poi diventava instabile ed inaffidabile. IBM mandò per mesi alcuni fra i suoi
tecnici migliori che non riuscirono a risolvere il problema perchè, a detta dei “nostri” era
dovuto a “manchevolezze intrinseche nel protocollo Token Ring”. Iniziò una disputa ed un
rimpallo di responsabilità che allontanò sempre più l’obiettivo di automazione, core
business, della società (nel frattempo Pirelli England affidò ad un società americana la reimplementazione del sistema, questa volta con Ethernet …)
Questo portò ad un “cambio di rotta” e per far quadrare i bilanci il core business si spostò sempre di
più in ambito “commerciale” pur restando nel confine del software legato alla produzione
industriale.
18 di 31
Principali progetti
Riporto qui sinteticamente i progetti ai quali ho partecipato

Controllo qualità schede memoria mainframe – IBM
IBM Semea costruiva le schede di memoria utilizzando vari stabilimenti sparsi in Europa
ma non si era ancora dotata di un sistema centralizzato di monitoraggio. Su specifiche
dettagliate sviluppammo un sistema di analisi e tracciabilità difetti di ogni singolo
componente che raccoglieva dati dalle varie fonti coinvolti. Il tutto fu sviluppato secondo i
rigorosissimi standards interni di progettazione, sviluppo, test e documentazione di IBM
utilizzando il linguaggio PL/1 ed il supporto del monitor ISPF/TSO sotto MVS con database
DB2. La logica di sviluppo adottata si potrebbe definire di “micro moduli”: non si dovevano
superare le 100 righe di codice per realizzare una particolare funzione in modo da
minimizzare la possibilità di errore nel singolo modulo. Era comune all’epoca, in ambito
IBM, sostenere che un “programmatore esperto” non poteva rilasciare più di 40 linee di
codice, esenti da errore, al giorno. Se ricordo bene, il progetto consegnato, superava le
200.000 righe per 4 programmatori ed un anno di lavoro. La parte “difficile” era legata
essenzialmente all’ambiente di sviluppo: in remoto su un server emulato su connessione
dial-up a 9600 baud. Il risultato era che col terminale 3270, ogni volta che si premeva
“Enter” per la scrittura, modifica, esecuzione di un programma, si aspettava, orologio alla
mano, 15 minuti per la risposta. Traducendo: era vietato sbagliare!
La fase di debug e test fu però molto, molto istruttiva:
Tecnici IBM, appositamente preparati, esaminavano il codice riga per riga, facendo le pulci
ad ogni singola variabile o system call ed ogni volta che firmavano il tabulato per
approvazione era un “olà!”.
Una particolarità tecnica legata allo sviluppo, ed in particolare alle query in linguaggio SQL,
fu quella dell’impossibilità di utilizzare l’SQL-Optimizer semplicemente perché ci fu
bloccata con opportune policies l’accesso dai nostri terminali.
Considerando che il sistema doveva elaborare i dati prodotti da macchine che testavano ogni
singolo componente il volume totale delle righe nella tabella principale superava
abbondantemente il centinaio di milioni. Per specifiche “contrattuali” era richiesto un tempo
di risposta “massimo” inferiore ai 3 secondi per ogni funzionalità implementata.
Ricordo che, svariate volte, durante lo sviluppo, per una query non perfetta, il terminale si
inchiodava, cioè il sistema centrale declassava automaticamente alla priorità minima le
query che superavano una quota prefissata di tempo e/o spazio temporaneo per cui in pratica
l’interrogazione non finiva più e non restava altro da fare che chiamare il sistemista di
Vimercate per farci stoppare il task e ripartire dopo verifiche e correzioni.
Quando però il sistema fu installato su un server di test con i dati “reali” superò senza
problemi le prove di performance richieste.
19 di 31

Recupero Crediti Clienti IBM Italia
Dopo questo primo progetto, rilasciato con anticipo sulla data di “cut-over”4 ce ne fu
affidato uno decisamente più “critico”: recupero crediti clienti. A livello contabile si
dovevano incrociare i dati di vendita, dei magazzini, della fatturazione ecc. … il tutto per
“scovare” i clienti che pagavano in ritardo o che non pagavano affato i canoni di affitto
software, hardware e/o servizi. L’ambiente era lo stesso del precedente progetto ma con una
mole di dati decisamente maggiore: per provare alcune funzionalità avevo popolato con
20.000 righe alcune tabelle contabili non potendo immaginare che nell’ambiente di
produzione si parlava di più di 200.000.000 di movimenti contabili …
In questo progetto era preponderante l’elaborazione batch dei dati rispetto alle interrogazioni
on-line.. La parte più importante della procedura consisteva nel scaricare su file sequenziali
le varie tabelle del database e tramite programmi di “bilanciamento” scrivere in output le
nuove versioni dei files dai quali poi alla fine si sarebbe ricreato il nuovo database la cui
struttura era ottimizzata e pensata essenzialmente per interrogazioni on-line. Questo
richiedeva l’uso di numerose fasi di sort prima di ogni “bilanciamento”. Nei nostri test, una
chiusura contabile durava circa 20 minuti con nostra grande soddisfazione. Quando andai al
centro di calcolo IBM di Vimercate per l’installazione sui server di produzione ebbi però
una sorpresa: il sistemista mi permise di accedere ad una console per il lancio del job per
cui, dopo aver modificato la JCL per adattarla ai nuovi volumi lanciai il task con un tasto
“Enter” grosso il triplo di uno normale …
Sentii solo un beep e non successe nient’altro; fui sorpreso … come sarebbe a dire? Dopo tre
mesi di test non funziona nulla? Secondo invio e secondo beep … terzo invio e terzo beep!
Incominciai a sudare freddo … vedevo naufragare nel nulla il lavoro di un anno!
Poi il sistemista mi chiese: perché hai lanciato tre volte il task? Hai riempito la coda di
SYSOUT, guarda il log! Il beep era durato un battito di ciglia, ed in quella frazione di
secondo il 3090 aveva schedulato il mio job insieme a qualche centinaio di altri, aveva
eseguito la catena di 30 programmi inframmezzati da una decina di sort; il risultato finale,
che avevo scritto per controllo, riportava sul log: “letti 220.milioni e spiccioli di records,
scritti 220.milioni e spiccioli di records … controllo OK”.
Ammetto di essermi sentito come il bambino che vede per la prima volta ET …
Il sistemista mi stese con questa uscita: “Eh sì … 40 millisecondi di elapsed-time … un po’
lento oggi … sai … cosa ci vuoi fare, ci sono quasi 11.000 terminali collegati … “
SENZA PAROLE …
4
Secondo specifiche contrattuali, non erano previste penali nel ritardo di consegna. Semplicemente non era ammissibile
alcun ritardo in quanto il pagamento del progetto era “dopo accettazione”.
20 di 31
Mi fu chiaro in un istante il paragone fra il motoscafo e la nave da crociera: forse, per brevi
tratti il motoscafo è più veloce della nave; peccato però che non possa trasportare migliaia di
passeggeri su e giù per i sette mari …
In quest’ottica vorrei aggiungere che il Job Control Language è propedeutico a qualunque
mansione in ambito informatico, nel senso che se uno riesce a “sopravvivere” ad esso può
affrontare tranquillamente qualunque altro sistema, linguaggio, tecnologia informatica di
sorta.
Perché affermo questo?
Perché, essendo un linguaggio progettato negli anni ’60 è “affilato e tagliente” che di più
non si può. In pratica ha solo delle macro di definizione dei dati e poche altre cose ancora.
Peccato che queste macro accettano un’enormità di parametri in funzione dei devices che
devono collegare. Riporto a titolo esemplificativo una JCL di esempio:
/PDSCRTJ4 JOB SIMOTIME,ACCOUNT,CLASS=1,MSGCLASS=0,NOTIFY=CSIP1
//* *******************************************************************
//*
This program is provided by:
*
//*
SimoTime Enterprises, LLC
*
//*
(C) Copyright 1987-2010 All Rights Reserved
*
//*
*
//*
Web Site URL:
http://www.simotime.com
*
//*
e-mail:
[email protected]
*
//* *******************************************************************
//*
//* Subject: Define a PDS using the IEFBR14 with a DD Statement
//* Author: SimoTime Enterprises
//* Date:
January 1,1998
//*
//* The JCL member executes the instream PROC called PDSCRTP3 and
//* passes a fully qualified data set name (DSN) via the symbolic name
//* called DSNAME and referenced in the PROC as &DSNAME.
//*
//*********************************************************************
//* The instream PROC for creating a PDS. The Data Set Name (&DSNAME)
//* is provided by the job step that calls the PROC.
//*
//PDSCRTP3 PROC
//PDSCRTS1 EXEC PGM=IEFBR14
//TEMPLIB1 DD DISP=(NEW,CATLG),DSN=&DSNAME,
//
STORCLAS=MFI,
//
SPACE=(TRK,(45,15,50)),
//
DCB=(RECFM=FB,LRECL=80,BLKSIZE=800,DSORG=PO)
//
PEND
//*
//* *******************************************************************
//* Step
1 of 3 Create a PDS using SET and EXEC
//*
//
SET DSNAME=SIMOTIME.DEMO.TEMP01
//STEPJ41 EXEC PDSCRTP3
//*
//* *******************************************************************
//* Step
2 of 3 Create a PDS using EXEC and DSNAME substitution
//*
//STEPJ42 EXEC PDSCRTP3,DSNAME=SIMOTIME.DEMO.TEMP02
//*
//* *******************************************************************
//* Step
3 of 3 Create a PDS using EXEC and DSNAME substitution
21 di 31
//*
//STEPJ43
//*
EXEC PDSCRTP3,DSNAME=SIMOTIME.DEMO.TEMP03
Quando un task di chiusura contabile prevede una cinquantina di programmi in PL/1 per
essere eseguito e deve essere a prova di errore, cioè in grado ripartire in modo automatico, a
prescindere da “qualunque” errore possa capitare, la JCL risultante è a sua volta un
programma più complicato dei programmi stessi!
Infatti, nei grossi centri di calcolo, la preparazione dei task è compito di specialisti … ma
noi non eravamo un “grosso” centro di calcolo …
Un altro aspetto è quello di dover conoscere a fondo l’ambiente in cui operi: nel senso che
per eseguire un programma che, ad esempio, legge un file con tipi records diversi ed in base
al tipo record scrive altrettanti files, bisogna definire nella JCL una scheda per ogni file
specificando l’organizzazione, le estensioni, se contiguo o meno, il numero di tracce del
disco, la dimensione del settore, il numero di testine di lettura, ecc. ecc. ecc. …
La cosa, secondo me, molto buffa è che quando ci si collega oggi ad un “moderno” sito web
di una banca, assicurazione, forse prenotazione voli o quant’altro, dietro molto spesso ci può
essere ancora questo mondo anni ’60 che, come questo schema del 2009, estratto dalla
pagina dei seminari del sito web del corso di Laurea Specialistica in Ingegneria Informatica
e dell’Automazione dell’Università di Ferrara http://www.unife.it/ing/ls.infoauto/sistemiinformativi/seminari, ci ricorda:
22 di 31
Il relatore, l’Ing. David Pilati, di Intesa Sanpaolo, pone al centro della figura un oggetto che
è praticamente sconosciuto alla maggioranza degli studenti di informatica e scienze
collegate e/o annesse. A mio modesto parere è una manchevolezza formativa.
Certamente, nel corso degli anni, i mainframes con i
condizionatori sul tetto per raffreddare i moduli di memoria sono
andati in pensione sostituiti da macchine più maneggevoli e
diventa difficile pensare alla potenza elaborativa di cui oggi sono
capaci “armadi” come questo. Non ci starebbe bene nel
laboratorio di Mura Anteo Zamboni? Ho l’idea che costi meno e
sia più affidabile del cluster di 100.000 o più PC che usa Google,
ma, ovviamente, meno divertente di un Pinguino tuttofare.

Consulenze esterne
Buona parte della mia permanenza in Seiaf riguardò poi l’attività di consulenza per
importanti aziende italiane, fra le quali. Acciaieria Ilva di Genova e Gruppo Merloni
Elettrodomestici presso le quali sviluppai, analizzando le richieste dei clienti, vari moduli
integrativi ai sistemi di gestione della produzione COPICS già installati ed operativi.
Fu interessante scoprire quanto è
complessa
la
tecnologia
di
produzione dell’acciaio per cui, ad
esempio, una singola bramma, dalla
cui successiva lavorazione a freddo
si ottiene, per esempio, la portiera di
una BMW piuttosto che il parafango
di una Punto, sia definita da più di
600 parametri tecnici, ognuno dei
quali incideva, per tempi, metodi,
attrezzaggio ecc. ecc. nel costo
finale di vendita. Avendo sviluppato
materialmente buona parte della
procedura di Gestioni Ordini in ambito relazionale (database DB2), gestita fin al quel
momento su un sistema Univac del 1962 (!!!) 5 fui non poco sorpreso nel scoprire che dagli
stabilimenti di Genova, Taranto e Piombino uscivano rotoli di lamiera destinate alle
5
Quando si dice dei genovesi … prima di buttare via qualcosa ! Fu il secondo computer italiano, primo per scopi
commerciali e credo 4° o 5° in Europa …archittettura a 36 bit! All’inizio per memorizzare i dati (pochi Kbytes)
utilizzava dei cilindri ricoperti di materiale magnetico. Spero che l’abbiano conservato per sistemarlo in un museo
23 di 31
fabbriche Mercedes, BMW, Fiat ecc. ecc. e che l’acciaio prodotto, a detta dei clienti
tedeschi era il migliore possibile. La Fiat, ovviamente, richiedeva prodotti più economici …
Tecnicamente fu interessante anche il porting dell’applicazione in sé stesso: dal mondo
Univac con bytes a 9 bits (word di 36 bits) al mondo IBM la conversione dati non fu
semplice. Il database in sé, la cui struttura fu progettata dai tecnici IBM, non era
particolarmente complesso (meno di un centinaio di tabelle) ma la riconversione dei dati con
scrittura e rilettura su nastri di formato diverso e con alfabeti diversi lo fu eccome! Anche il
software che sviluppai per l’on-line, non era proprio una bazzecola: per questioni di
performance le tabelle principali non avevano una struttura “orizzontale” nel senso che per
identificare una bramma (e tutti gli altri prodotti di altoforno) la tupla dei dati non era
formata dalle 600 e più colonne in quanto sarebbe stato altamente inefficiente pensare alla
struttura “massima” di produzione perché, per molte lavorazioni, bastavano 100/200
attributi. Perciò le tabelle furono definite “in verticale”, ovvero con tuple di 6/7 colonne
contenenti la chiave di accesso, il codice dell’attributo ed i parametri numerici essenziali.
Se questa scelta semplificò notevolmente la lettura/scrittura dei dati pose non pochi
problemi di tipo prestazionale; ogni “videata” di un ordine cliente, per essere presentata,
richiedeva la lettura di migliaia di records dal database con queries notevolmente complesse.
Ricordo, con estremo piacere, di essere stato “affiancato” da un tecnico IBM
particolarmente esperto dell’ottimizzazione delle queries stesse; l’ing. Pacifico. La
particolarità di questa persona era il fatto di essere un non vedente. Ora, immagino che pochi
abbiano pratica di sviluppo in COBOL/CICS/DB2; in questo contesto è normale che un
programma sia composto da 2/3000 o più righe di codice, vuoi per la complessità intrinseca
della funzione, vuoi per la complessità dei dati che deve trattare, vuoi, soprattutto, per la
prolissità intrinseca del COBOL. L’ing. Pacifico, come ripeto, non vedente dalla nascita, era
in grado in pratica di memorizzare un codice del genere e di indicare, dopo che qualcuno gli
avesse riportato i codici di ABEND ed altre informazioni e con pochissimi errori, la riga
esatta che aveva generato l’errore 6.
dell’informatica.
6
ABnormal END of program: il famigerato “ABEND ASRA in XXXX …”. Il task viene abortito con un messaggio a
console che indica, al 99,99% un errore di un istruzione “MOVE” di un dato non numerico in un campo numerico.
24 di 31
Aveva però un grosso difetto: era milanista!
Mi permetto di scherzarci su, ma, a distanza di anni, non ho mai conosciuto nessuno con
una tale capacità di memoria. Il suo grave handicap svaniva dopo pochi minuti dalla sua
conoscenza e le sue spiegazioni sulla gestione interna del CICS e del DB2 erano un vero
spettacolo.
A tal proposito mi voglio soffermare un attimo sugli aspetti di documentazione di un S.O.;
oggi ad esempio, se Windows termina in modo anomalo “sputa” (non sempre …!) una
schermata blu con una serie di codici esadecimali che dovrebbero aiutare i tecnici a capire
cosa è successo. Mi son fatto l’idea che nessuno al mondo li conosce in dettaglio, nemmeno
Bill Gates … scavando con Google si riesce a volte a trovare qualche informazione di
seconda o terza mano su un certo errore comune ma niente di più. Nel mondo IBM la
musica è diversa: buona parte della libreria tecnica alle spalle di una postazione di lavoro, è
piena di manuali di errori e di procedure per la loro risoluzione. Basta solo avere la pazienza
di stampare il dump della memoria (un 200 pagine di quei fogli con i bordi traforati ai lati,
con righe azzurrine e bianche, 132 colonne …) e seguendo le istruzioni della manualistica, si
risale, decodificando i vari indirizzi delle aree di memoria occupate all’istante dell’errore,
alla riga del programma sorgente che ha provocato l’errore stesso. Un’altra tecnica di debug
che utilizzavo spesso nei programmi batch, era quella più semplice di “infarcire” il codice
con istruzioni di output dei valori delle variabili; ma se il mio programma doveva utilizzare
moduli già scritti da altri, ed era comune avere “catene” di 30, 40 o più moduli in cascata,
questa tecnica non era percorribile. Non restava altro che munirsi di un termos di caffè ed
analizzare le 200 pagine del dump …
Altrettanto interessante fu lo sviluppo di applicazioni sw, sempre legati a Gestione Ordini e
Magazzino, per conto della Merloni Elettrodomestici. In particolare, la prezzatura dei
prodotti in base alla distinta di produzione ed alla marca finale e l’ottimizzazione
dell’attrezzaggio per alcune lavorazioni. La fase finale di montaggio di una lavatrice,
frigorifero od altro elettrodomestico “bianco” consiste infatti nelle “rifiniture” quali il top, le
targhette con la marca e l’inserimento dei pomelli/pulsanti di comando. Impressionante
vedere tramite query sul database, che i prezzi variavano anche del 30-40% in base alla
targhetta appiccicata: AEG, Indesit, Candy ecc. ecc. …
Tecnologie utilizzate
Essendo una società legata a filo doppio ad IBM, era logico e naturale che le tecnologie fossero
IBM; quindi:





MVS, VSE, VM per i sistemi operativi
TSO, CICS, CMS per i monitor degli stessi
ISPF, JCL, Rexx per i linguaggi di controllo
PL/1, COBOL per i linguaggi applicativi
VSAM, ISAM, OSAM, QSAM, DB2, Dl/1 per la gestione dati
Riferimenti


http://ricerca.repubblica.it/repubblica/archivio/repubblica/1985/10/01/accordo-ibm-elsagnasce-la-seiaf.html
http://en.wikipedia.org/wiki/Pl/1
25 di 31












http://en.wikipedia.org/wiki/ISPF
http://en.wikipedia.org/wiki/Time_Sharing_Option
http://en.wikipedia.org/wiki/MVS
http://it.wikipedia.org/wiki/Job_Control_Language
http://en.wikipedia.org/wiki/IBM_System_z
http://it.wikipedia.org/wiki/UNIVAC_I
http://en.wikipedia.org/wiki/UNIVAC_1100/2200_series
http://it.wikipedia.org/wiki/ISAM
http://it.wikipedia.org/wiki/OSAM
http://it.wikipedia.org/wiki/VSAM
http://it.wikipedia.org/wiki/DB2
http://it.wikipedia.org/wiki/Alberto_Lina
26 di 31
Morteo Soprefin S.p.A.
Era una società del gruppo I.R.I con sede in Genova che si occupava di metallurgia leggera. Dagli
stabilimenti di Pozzolo Formigaro e di Sessa Aurunca uscivano prodotti quali:





Containers: semplici ed “attrezzati” (frigoriferi, case mobili)
Travature per capannoni industriali, tetti
Guard-rails
Cassonetti immondizia
Progettazione varia in ambito metallurgico/civile
Dati essenziali


Dal 1987 al 1990 come analista-programmatore in ambiente IBM VM/4381/DL-1
Referenti: nessuno; società sciolta
Attività svolte

Programmazione in COBOL/CICS/DL-1/VSAM per sviluppo procedure interne
Relazione
Introduzione
La società produceva i suoi manufatti solo su commessa cliente e di conseguenza tutto il Sistema
Informativo ruotava sul concetto di “commessa”. Al centro di calcolo presso il quale lavoravo, nel
centro di Genova, erano collegati circa 230 terminali, una ventina di stampanti, unità nastro ed altre
periferiche suddivise fra i due stabilimenti, la sede centrale di Genova ed alcuni importanti cantieri
del nord Italia. Il software per la gestione delle commesse era il COPICS IBM, standard industriale
per quell’epoca, con database gerarchico DL/1.
Attività svolte
Il mio compito era quello di sviluppare nuovi programmi soprattutto per le esigenze della
contabilità e del magazzino, in quanto nel “pacchetto” IBM acquistato non erano presenti questi
moduli. Rammento che all’epoca, il software per i mainframes non era acquistabile ma si pagava
annualmente un canone (salatissimo) di utilizzo. Era logico, da un punto di vista economico,
affittare solo i moduli essenziali per la gestione della produzione ed automatizzare nel tempo i vari
uffici amministrativi e contabili con procedure ad hoc.
Ricordo di aver visto una fattura di un upgrade del sistema centrale da 8 a 16 MegaBytes
di memoria (Mb, NON Gb) per un importo di 8.000.000 di lire dell’epoca. Il tecnico IBM che
montò la scheda sembrava un marziano: tappeto antistatico a terra, tuta di non so quale materiale
riflettente, casco con visiera, guantoni collegati con un cavo di rame da ½ pollice alla massa:
insomma più o meno come in “2001 – Odissea nello spazio”, il capolavoro di Kubrick. Pochi giorni
fa ho letto di un chip Kingston da 24 GIGA bytes a meno di 1000€ .
Oltre alla procedura Ordini Cliente, sviluppai completamente anche le Bolle di Consegna
permettendo una drastica riduzione dei tempi di attesa degli autotrasportatori dal momento di carico
al magazzino all’uscita dallo stabilimento. Era prassi all’epoca che il capo-piazzale dovesse
27 di 31
interrogare via terminale numerosi archivi fra loro non collegati, scartabellare su voluminosi tomi
con i codici dei prodotti riportando e ricalcolando i prezzi a suo tempo trasmessi via fax dagli uffici
centrali per produrre manualmente la bolla di accompagnamento merci.
Un altro progetto nel quale fui coinvolto fu quello di ricreare la distinta base, partendo dall’analisi
dei disegni tecnici in Autocad. A raccontarlo adesso mi sembra fantascienza … :
I pochi e costosi PC dell’epoca erano utilizzati solo per scopi realmente importanti: su un PC 386 fu
installata una versione di Autocad che permise ai progettisti un notevole salto qualitativo. Il
problema gestionale era però quello di creare o ricreare la distinta base del prodotto partendo dal
disegno. Si può facilmente intuire che per un prodotto semplice quale un cassonetto
dell’immondizia composto da poche parti non si abbiano grossi problemi, ma con una casa mobile
con centinaia se non migliaia di componenti?
D’altro canto se era possibile con il LISP estrarre il codice dell’oggetto grafico dal file DWG, come
inviarlo al mainframe? All’epoca, far “parlare” un PC con la rete SNA non era impresa da poco.
IBM rilasciò solo nel 1983 (in USA …) un’utility chiamata IND$FILE dal funzionamento un po’
troppo macchinoso e comunque, ammesso e non concesso che il trasferimento dei dati dal PC al
mainframe avesse avuto successo, sarebbe rimasto il problema di caricare gli archivi; cosa che,
tenendo conto della complessità, dei vincoli e dei controlli necessari sconsigliava la scrittura di
nuovi programmi.
Mi venne l’idea di utilizzare la scheda IRMA/3270 usata per l’emulazione del terminale sul PC
scrivendo delle routines in assembler e BASIC che simulavano il lavoro dell’operatore: con il LISP
estraevo i dati da Autocad, con il Basic preparavo un buffer di dati che simulava la memoria video
del terminale, con l’assembler lo caricavo nella memoria della scheda ed infine pilotando le
opportune porte di I/O della scheda simulavo la pressione del tasto “Enter”. Il tutto per ogni oggetto
grafico presente nel disegno originale. Utilizzavo cioè i programmi on-line già sviluppati per la
gestione della distinta base facendo fare alla scheda di emulazione il lavoro ripetitivo di data-entry.
Assolutamente divertente!
Tecnologie utilizzate
Anche in questa azienda il sistema centrale era IBM ma ebbi modo anche di “giocare” con il
PC/DOS:




VM/CMS e PC/DOS come sistemi operativi
CICS come monitor
VSAM, ISAM, Dl/1 come database
COBOL, Basic, Assembler/370 (per le maschere video), Assembler/386 come linguaggi di
programmazione
Riferimenti
http://gsf-soft.com/Documents/IND$FILE.shtml
http://en.wikipedia.org/wiki/Irma_board
http://en.wikipedia.org/wiki/Lisp
http://en.wikipedia.org/wiki/Autocad
28 di 31
http://cicswiki.org/cicswiki1/index.php?title=History
Firenze
Come riportato nel curriculum vitae riassuntivo, dal 1983 al 1987 lavorai presso lo studio Dr.
Ballotta a Firenze come programmatore per sviluppo SW per clienti in ambiente IBM/8100,
Dati essenziali
Era un piccolo studio professionale di 6 persone il cui fondatore aveva ottenuto un’importante
commessa per consulenza software per le aziende manifatturiere del Gruppo Lanerossi, all’epoca il
più importante gruppo tessile italiano entrato nell’orbita del Gruppo Eni..
Attività svolte



Sviluppo applicazioni in COBOL in ambiente IBM 8100/DTMS
Sviluppo applicazioni in RPG in ambiente IBM S/34, 36, 38
Sviluppo applicazioni in Gwbasic/Clipper in ambiente PC/DOS
Relazione
Approdai a Firenze, presso lo studio Ballotta, in seguito al mio desiderio di imparare il più possibile
nell’ambito informatico. A Genova avevo frequentato un corso di programmazione in Basic su un
Olivetti M-24 tenuto da una società di Firenze, se non ricordo male: IDS. Il corso, privato e
piuttosto caro, non fu all’altezza delle mie aspettative, tant’è che, con altri ragazzi, ci rivolgemmo
ad un avvocato per sollecitare la revisione e l’approfondimento “professionale” come promesso. Il
corso fu esteso gratuitamente di altri 4 mesi e soprattutto fu cambiato l’istruttore. Nel 1982 non
esistevano scuole “ufficiali” di informatica, non c’erano corsi universitari o quant’altro. Non è
difficile immaginare perché: un PC IBM/XT costava nel 1983 più di una Fiat Uno e i mainframe si
vedevano solo nei films di fantascienza. Così, tramite quella società di Firenze, inoltrai una
domanda al Dr. Ballotta che acconsentì ad un periodo di addestramento di due o tre mesi a titolo
gratuito. I tre mesi diventarono quattro anni a partita IVA …
Incomincia, poco alla volta, ad entrare nelle problematiche delle grandi aziende, e realizzai
(onestamente non so con quale qualità …) diversi programmi per i vari settori produttivi ed
amministrativi: Contabilità, Magazzino, Paghe.Produzione.
Per le aziende Lanerossi, completai con gli altri ragazzi dello studio, un software, denominato
“Taylor” che permetteva l’ottimizzazione del “lancio in produzione”, cioè dell’accorpamento e
taglio del cosiddetto “materasso”. Le sartorie industriali, infatti, lavorando su commessa, cercano di
concentrare le fasi di taglio delle stoffe per la produzione di abiti nel più breve periodo possibile per
poi cucire e completare gli abiti nei mesi successivi. Per ottimizzare i tempi usano dei tavoloni
larghi una decina di metri e lunghi 20/30 sui quali stendono i vari rotoli delle stoffe. Qui iniziano i
29 di 31
problemi in quanto i vari tipi di cardatura e rifinitura della stoffe implicavano una maggiore o
minore propensione al taglio; poi, con stoffe a quadretti, righe ecc. il posizionamento delle
maschere per il taglio7 era un’operazione estremamente complessa.
Il software da noi sviluppato aiutava gli operatori in questa delicata fase: dal reparto progettazione
arrivava alla produzione un file con dati dei i poligoni relativi alle singole pezze che avrebbero
formato l’abito e, dopo varie ore di elaborazione, produceva un tabulato a mo’ di griglia riportando
per ogni cella il codice identificativo della pezza da tagliare alla quale era associata la propria
maschera di taglio.
Successivamente al taglio, il software procedeva alla creazione delle etichette per ogni singola
pezza per permetterne poi il riassemblaggio in un prodotto finito tenendo conto dei tempi di
lavorazione che andavano conteggiati e calcolati come costi.
Tutti questi dati, ai quali venivano aggiunte le rilevazioni dei tempi di lavorazione, finivano per
alimentare archivi che a loro volta erano la base per la contabilità industriale ed altre procedure.
Esclusa la procedura di paghe e stipendi, che fu sviluppata da altre ditte e da noi solo
personalizzata, gestivamo in pratica l’intera attività di un gruppo che aveva all’epoca più di 8000
dipendenti sparsi su una ventina di stabilimenti con varie competenze e specializzazioni in Italia.
Mi ricordo, ad esempio, che dallo stabilimento di Maratea uscivano le divise per i dipendenti delle
Ferrovie dello Stato, a detta di sarti espertissimi, di eccezionale qualità così come erano di alta
qualità gli abiti a marchio “Lebole” prodotti a Filottrano (AN) ed altri.
Fra i vari programmi che sviluppai, ce ne erano diversi per la prezzatura e gli ordini di vendita:
verificai in un negozio di Genova che un abito da uomo classico, uscito dalla fabbrica a 87.000 Lire
veniva proposto al prezzo di 380.000. Decisi che era meglio acquistare allo spaccio aziendale a
60.000 lire …!
Oltre a questa attività preminente per la Lanerossi, mi capitò di installare da zero alcuni sistemi
IBM S/36 con lo “standard” gestionale dell’epoca: ACG - Applicazioni Contabili Gestionali scritte
in RPG, linguaggio che non riuscii mai a “digerire” completamente in quanto legato ad un
posizionamento rigido e molto schematico soprattutto per la parte di stampa (nasce infatti su sistemi
a schede perforate essenzialmente per la reportistica: Report Program Generator).
Rammento che all’epoca, questo tipo di mini-computer era quello più diffuso in Italia con più di
40.000 installazioni nelle varie versioni S/34, S/36 e S/38.
L’IBM all’epoca proponeva questi tre sistemi alle aziende manifatturiere in funzione del numero di
utilizzatori e volume presunto dei dati fornendo in “bundle” le ACG per la gestione aziendale. In
7
Non esisteva ancora il taglio completamente automatico: gli operatori dovevano dapprima sistemare maschere in
cartone sulla pila delle stoffe, contornarlo con il gesso e poi procedere al taglio vero e proprio
30 di 31
effetti non erano obbligatorie ma nessuno si azzardava a non acquisitarle in quanto in pratica era
l’unico ERP allora disponibile per quella classe di hardware.
Il “pacchetto” ACG completo superava abbondantemente i 2000 programmi suddivisi in vari
moduli corrispondenti ai vari settori aziendali. IBM demandava ai business-partner il compito di
personalizzazione e manutenzione dei moduli stessi.
La cosa più difficile che ricordo era quella di far capire ai clienti che metà del costo di un progetto
(almeno!) era legato alla progettazione, test e documentazione del software prodotto;
semplicemente nessuno o quasi voleva pagare per cose che ritenevano “costi aggiuntivi”.
Riferimenti










http://www.marzotto.it/filati_lanerossi.html
http://it.wikipedia.org/wiki/Lanerossi
http://it.wikipedia.org/wiki/Eni#I_salvataggi:_Pignone_Lanerossi_e_Sir
http://en.wikipedia.org/wiki/IBM_8100
http://en.wikipedia.org/wiki/IBM_System/36
http://www.acginfo.it/
http://it.wikipedia.org/wiki/RPG_(linguaggio_di_programmazione)
http://en.wikipedia.org/wiki/IBM_System/34
http://en.wikipedia.org/wiki/S/36
http://en.wikipedia.org/wiki/S/38
31 di 31