Giunge l'anno duemila: tutti fermi allo scoccare della mezzanotte, alcuni secondi di attesa...
Il cellulare funziona, il frigorifero funziona, le automobili sono ancora in strada, non siamo tornati all'anno mille, il pericolo è scampato!
Questo, secondo alcune campagne giornalistiche degli ultimi mesi, sarebbe dovuto essere lo scenario preoccupante nel quale il cittadino comune avrebbe dovuto attraversare la fatidica ora zero, di un anno che abbiamo deciso di contare come "2000", anche se quasi certamente il duemila non è.
In realtà, sembra avere poca importanza se Cristo sia realmente nato duemila anni fa, o invece nel 2 o nel 4 a.C., e probabilmente anche la questione dell'inesistenza dell'anno zero appartiene alle imprecisioni che abbiamo ereditato. Certamente non entreremo nel merito dei calendari che si sono succeduti nella storia della fallibile umanità, e nemmeno valuteremo se il 2000 appartiene al terzo millennio o al secondo, come indurrebbe a ritenere, per analogia, l'applicazione della regola matematica che ci indica che il numero "10" appartiene alla prima decina e non alla seconda. Tutte congetture, se il 2000 è già passato o se festeggeremo di nuovo l'inizio del millennio all'anno 2001 perché ci eravamo sbagliati: considerazioni da poco giacché abbiamo deciso di festeggiare ora l'inizio del nuovo millennio, con l'inizio dell'anno 2000. (V. anche http://www.cronologia.it)
Poco male dunque, se il nostro rigore scientifico ci lascia dubbiosi sul computo degli anni, ciò che conta è che per tutto il mondo conosciuto è iniziato il 2000 d.C.: questione di convenzioni!
Le scelte convenzionali sono quelle che permettono a chiunque agisca in
un universo diversificato di fare riferimento a regole certe, nell'ambito di uno stesso
progetto internazionale, di un settore scientifico, e di adoperare un linguaggio univoco,
un modo di procedere ed operare del tutto analogo agli altri, qualunque sia il proprio
Paese, la propria lingua, superando le singole diversità.
Se è in base a queste convenzioni che tutto il pianeta ha festeggiato l'inizio dell'anno
2000, e se è in base a convenzioni che nascono standard universali, non si
comprende per quale motivo certa stampa e certa "nuova utenza" dell'informatica
discuta le convenzioni adottate in passato in questo campo.
Viene chiamato "baco informatico" quello che in realtà un baco non è, ma è la conseguenza di una scelta adoperata validamente per un ventennio, un ventennio di progresso informatico che equivale più o meno ad ottanta anni di progresso scientifico in qualsiasi altro campo tecnologico, una conseguenza della scelta convenzionale di conservare della data le sole due cifre finali dell'anno e di porre come anno "00" il 1900, ben coscienti che al finire del secolo sarebbero stati necessari degli opportuni correttivi. Un problema, dunque, conosciuto da sempre a tutti i seri operatori del settore.
I notiziari, i giornali, le televisioni, hanno costruito favole per sciocchi, nelle quali il nome del lupo cattivo è "millennium bug" e quello del suo creatore sarebbe quello di un anonimo programmatore che aveva deciso di inserire nel software soltanto le ultime due cifre dell'anno, chissà, forse per insipienza. Barzellette, pure barzellette!
Se avete pazienza, posso raccontarvi la storia, anche se personalmente
posso iniziare soltanto raccontando quanto accadeva in Italia nel 1984.
Le aziende più importanti si avvalevano di costosissimi e complicatissimi sistemi
composti da elaboratori elettronici e macchine calcolatrici per gestire grosse mole di
dati. La videoscrittura ed il telex, ultima innovazione della telescrivente dalle strisce
perforate, era appannnaggio dei più importanti enti e delle banche. La massima
innovazione tecnologica in tema di scrittura era data dalle macchine da scrivere
elettroniche che permettevano di memorizzare frasi usate frequentemente o di ricorrere
alla cancellazione automatica usando il bianchetto a nastro. Iniziavano i primi corsi di
programmazione nei quali si insegnava il COBOL, il FORTRAND, il PASCAL, il BASIC. Windows
era soltanto una nuova ed innovativa proposta commerciale: Bill Gates, soltanto uno dei
primi a credere al microchip e l'autore del DOS; Peter Norton un piccolo genio in grado di
maneggiare dati e ricostruire file ad un livello più basso del DOS, operando direttamente
in linguaggio macchina. Oggi sono in pochi a riuscire ad immaginare cosa sia il linguaggio
macchina, o cosa significhi operare a suon di codice binario, avendo a diposizione
avanzatissimi software visuali per creare i propri applicativi in qualsiasi linguaggio.
Oggi è sufficiente procedere per tentativi, giacché i tempi morti diventano
impercettibili all'utente che dispone di macchine velocissime, allora era tutto ben
diverso: un procedimento non ottimale provocava visibili ed inammissibili secondi di
attesa.
Gli analisti era geniacci molto lontani dai tecnici, che disponevano
macro-analisi quanto mai stringate. La figura centrale della creazione di un software era
il programmatore che spesso assorbiva sia le funzioni di analisi, sia quelle, ben più
noiose, dell'inserimento del codice nella macchina, spesso delegata ad un operatore. I
programmatori procedevano innanzitutto ad un lavoro di analisi che poi schematizzavano in
diagrammi di flusso, o ricevevano diagrammi da codificare in un linguaggio applicativo. I
diagrammi di flusso sono schemi logici nei quali vengono rappresentati i singoli passi
dell'elaborazione ed i passi procedurali da svolgere a seconda del risultato conseguente
ad un confronto, o ad una determinata condizione. Oggi i linguaggi visuali permettono la
gestione di eventi, che vengono intercettati automaticamente dal software di base, mentre
allora bisogna stabilire ciascun punto del percorso in cui poteva o doveva verificarsi una
certa condizione per poterla gestire come "evento". Terminato il "flow
chart", questo veniva tradotto nel linguaggio che si intendeva utilizzare, e,
giacché si avevano sotto gli occhi tutte le variabili occorrenti alla procedura, nei
linguaggi dichiarativi si iniziava proprio da lì, per indicare nel programma tutte le
variabili che sarebbero state utilizzate e la loro tipologia, guai a sbagliare!
I programmatori COBOL utilizzavano degli appositi fogli per scrivere il codice secondo
rigide regole di incolonnamento, per dichiarare preventivamente tutte le variabili
numeriche, alfabetiche ed alfanumeriche che sarebbero state usate nel corso
dell'elaborazione, le maschere a video venivano scritte su appositi fogli onde prevedere
la loro disposizione ed evitare la sovrapposizione dei campi nel layout. Alla fine di
tanto lavoro si dava tutto in pasto al compilatore incrociando le dita nella speranza di
non aver dimenticato nulla. Se così non era si aveva come risultato un codice di errore
ed un numero di riga, nient'altro per interpretare l'inghippo!
In Italia erano stati appena commercializzati i primi "home computer": erano in diretta concorrenza il Sinclair Spectrum ed il Commodore 64. Il primo era probabilmente il più versatile per applicativi diretti alla gestione di grosse mole di dati, mentre il secondo si impose per la faciltà di gestione della grafica e per la reperibilità del software, in risposta del grosso successo commerciale. Il Commodore 64 era corredato da un interprete Basic ed entrambi erano dotati di 64k di memoria fisica e di unità a nastro o unità a disco da 5 pollici e 1/4 della capienza folle di 64 o 128Kbyte.
Il PC di quegli anni non era molto più interessante, se non per il fatto che veniva corredato da un disco rigido della capienza immensa di 10Mbyte, di unità a disco da 316 kbyte e di compilatori COBOL che traducevano una procedura di media complessità in diverse ore di elaborazione da programma sorgente a programma oggetto, cioè da un programma modificabile dal programmatore ad un programma utilizzabile dall'elaboratore. Se trascorreva una giornata di lavoro senza un "crash" od un "reset" della macchina, che costringeva al "reboot", lo si segnava sul calendario come giorno fortunato o importante progresso nella propria conoscenza.
In questo scenario si rendeva indispensabile ridurre al minimo la
quantità di dati da gestire evitando innanzitutto delle inutili ripetizioni. Ogni
ripetizione di dati già esistenti era da intendersi come una perdita di tempo
imperdonabile, quando non rischiava addirittura di compromettere l'esito delle operazioni
se il contenuto della procedura e dei dati in elaborazione superava i succitati 64 Kbyte,
provocando un irrimediabile "out of memory error".
In questo scenario, gli elementi comuni a più record venivano conservati in variabili
specifiche, e richiamati al momento opportuno, o si provvedeva a ricostruirli mediante
l'utilizzo di una serie di puntatori posizionali che permettessero di interpretare a quale
categoria appartenesse un insieme di dati. La prima ripetizione da evitare nei campi
destinati a contenere una data parve per tutti essere la prima parte dell'anno. Si decise
quindi di scomporre l'indicazione dell'anno in due parti, come avviene nella pronuncia
inglese: nynetheen "19" era inteso da sottintendere e venivano conservate
soltanto le ultime due cifre relative all'anno.
Nel calcolare il tempo intercorrente tra due date, si procedeva a delle normali operazioni
aritmetiche, per computare invece i giorni della settimana di qualsiasi giorno dell'anno
si era soliti creare un calendario perpetuo basato sull'anno 1900 dal quale calcolare ogni
volta il giorno della settimana di una data, computando adeguatamente gli anni, ivi
inclusi i bisestili, decorsi dal 1900 alla data di interesse. Questa soluzione permetteva
di occupare sole due cifre per inserire l'annualità e quindi di risparmiare 2 byte per il
campo data di ciascun record, oltre a rendere immediate le operazioni tra data, desumendo
il tempo trascorso da una semplice sottrazione.
Certo, c'era però un'altra soluzione per conservare la data: il COBOL permetteva di utilizzare un campo "FILLER" che occupava la metà dei byte richiesti più uno. Soluzione ottimale per conservare in uno spazio ridotto cifre relative alle migliaia, ai milioni o ai miliardi, se si intendeva rinunciare ai puntatori, ma nel caso della data si trattava di optare per una scelta che permetteva di ridurre i quattro byte necessari per la data estesa a soli tre byte, richiedendo però maggiori tempi di elaborazione e non rendendo compatibile la base dei dati alla consultazioni con procedure scritte in altri linguaggi. Per questi motivi la si ritenne una soluzione non vantaggiosa per la data, mentre la si usò costantemente per le cifre numeriche di una certa lunghezza.
Possibile insomma che nessuno si pose il problema del duemila??? Altroché! C'erano programmatori che utilizzavano sempre il campo filler, seppure in campi di applicazione ridotti che non compromettessero la reale fruibilità della procedura, ma questa soluzione non poté essere adottata come standard. Nel 1985 chiesi insistentemente ragguagli al mio docente Paolo Torres, durante il primo corso di programmazione che svolsi, ed egli mi rispose che non eravamo in grado di conoscere le novità dei futuri due o quattro anni e che quindi difficilmente potevamo immaginare lo scenario tecnologico che ci si sarebbe presentato nel 2000. "Al momento, questa è l'unica soluzione", concluse "il problema verrà risolto in futuro con mezzi certamente più avanzati di quelli di cui disponiamo oggi!". Aveva però un volto corrucciato, giacché lui riteneva quasi "doveroso" ricorrere alla conservazione della data utilizzando il campo filler per tutti le base di dati che sarebbero state consultate sempre e soltanto in COBOL, e non condivideva la scelta operata come standard, seppure rendesse disponibile la base dei dati a procedure scritte in altri linguaggi.
Da allora ad oggi, certamente abbiamo assistito ad una pressante evoluzione. Oggi, chiunque può equipaggiare la propria macchina con 256 MByte di memoria e masterizzare CD da 700 Mbyte, allora il progresso tecnologico raddoppiava i dischi rigidi da dieci in dischi da 20 o 40 Mbyte con tempi esponenzialmente più lunghi di quelli attuali. L'offerta del software invece era molto più ampia rispetto ad oggi: si assisteva al proliferare delle diverse soluzioni, mentre Windows era soltanto uno degli scenari possibili, lo standard della Apple una possibile alternativa e la signora e padrona dell'informatica era ancora il colosso IBM. Nel sottobosco c'era tutta una serie di multinazionali che tentavano di imporsi sul mercato (come la Commodore che fallì all'inizio degli anni '90) e di software house che personalizzavano i pacchetti software più importanti o creavano piccoli applicativi. Questa fascia vivifica di tecnologia scomparì presto, schiacciata dalla crescita del gigante Microsoft e dal progresso dell'hardware e conseguentemente del software che permette all'utente di creare, molto facilmente, fogli elettronici che ottengono gli stessi risultati senza dover ricorrere ai linguaggi allora complessi e conosciuti dai soli addetti ai lavori.
All'inizio degli anni novanta possedere un 386 a 16 Mhz con un hard disk da 40 Mbyte era una soluzione accettabile seppure spartana, ma certamente più accattivante di quella di un COMMODORE 64 con monitor, drive disk e stampante che costava la stessa cifra cinque anni prima. Oggi queste cifre risultano essere ridicole se un 586, o un Pentium se preferite, a 200 Mhz, si considera da tempo messo a riposo.
Oggi siamo alle CPU della settima generazione a 600 Mhz e più, a dischi da 8 o più Gbyte, a basi di dati su DVD da 6 Gbyte almeno, ed affrontare la questione "anno 2000" con queste macchine è stato certamente più agevole.
Il grosso equivoco che si è voluto creare è stato quello di dover scongiurare i problemi informatici all'arrivo dell'anno 2000, mentre invece i correttivi e le soluzioni fin qui adottate sulla base dei dati verranno sottoposte a verifica proprio adesso. Non è della fine del mondo che sto parlando sia ben chiaro, né di problemi irresolubili, ma piuttosto delle realtà che i titoli dei notiziari dei mass-media hanno puntalmente stravolto. Andiamo con ordine e valutiamo il problema sulla base di quanto abbiamo accennato.
Il problema, sembra assurdo parlarne ancora ma la realtà è latitante, è inerente soltanto alla data. Sono dunque da escludere tutte le CPU inserite in sistemi che non fanno riferimento all'anno di una data, e quindi tutti gli elettrodomestici e gli apparecchi che non hanno contatti con altri elaboratori. Il mio condizionatore a pompa di calore e la mia radiosveglia, ammesso che essa contenga un chip, conoscono soltanto le ventiquattrore del giorno e quindi funzioneranno in modo perpetuo senza alcun problema. Il problema rimane su tutti i sistemi integrati che monitorizzano eventi che attraversano il cambio di data e sulle base dei dati, esso può essere quindi di natura hardware o software.
Nel primo caso le preoccupazioni maggiori sono state relative alle corse dei treni ed ai voli aerei che attraversavano il cambio di data, giacché molte apparecchiature tuttora attive riconoscono "00" come 1900 e dunque non sarebbero riuscite a gestire lo scorrere del tempo e la condizione "mezzanotte del primo gennaio 2000" come evento successivo al 1999. La prima conseguenza sarebbe stata quella che i sistemi informatici avrebbero visto il veivolo partito la notte del 31 dicembre 1999 come giunto a destinazione il primo gennaio del 1900 ed avrebbero reso impossibile sovrapporre le tracce radar memorizzate nel seguire i veivoli, e quindi impossibile individuare nel tempo la collocazione fisica dei singoli apparecchi, impedendo la gestione delle rotte senza provocare incidenti.
Il fatto che siano state sospese le corse dei treni a lunga percorrenza e tutti i voli che attraversavano il cambio di data, dimostra però che non è stato operato alcun cambiamento sostanziale al funzionamento dei sistemi informatici. Se si è reso necessario evitare che un evento attraversasse il cambio di data, significa che non si era affatto in grado di gestirlo, quindi probabilmente i sistemi informatici più costosi ed imponenti anche se obsoleti, oggi stanno lavorando nuovamente con il riferimento alla data di base 1900, con un piccolo correttivo al calendario perpetuo cui ho fatto cenno. Francamente non riesco a spiegarmi il motivo di sospendere gli eventi a cavallo della mezzanotte se non dovendo accettare che nulla è cambiato in questi sistemi informativi che sono stati sospesi: si è soltanto iniziato a contare da capo per scongiurare le conseguenze di un possibile "out of range". Se infatti i chip più obsoleti non fossero riusciti a riconoscere la nuova data "00", ciascuno di essi avrebbe fatto riferimento alla propria data iniziale, cioé alla data di produzione (chi si ricorda di quando occorreva inserire la data corrente ad ogni accensione del computer?). In questo caso ciascuna delle CPU connesse in rete avrebbe letto l'evento corrente come relativo ad una data diversa dalle altre e si sarebbe provocato un errore grave che avrebbe indotto l'arresto prudenziale del sistema integrato.
I problemi relativi alle base dei dati, quindi i problemi software, iniziano invece da oggi, giacché è da oggi che bisognerà procedere ad un diverso conteggio del computo del tempo trascorso tra due date. Il problema, secondo i più esperti è tutt'altro che risolto, ma è stato soltanto rimandato per un altro ventennio, perché nella maggior parte dei casi si è provveduto alla correzione per date precedenti ad una determinata annualità con una semplice "patch di aggiornamento". Per ciascuna base dei dati si può far riferimento al primo anno non utilizzato. La soluzione in verità è quanto mai semplice, perché l'elaboratore, nato certamente dopo il 1900, può contare ben oltre il numero 99. Nelle operazioni di scomputo tra date, dunque, si è provveduto più o meno in questo modo, indicando al computer: "Se l'anno è minore di 30, (50, 70) allora aggiungi 100 al numero che hai letto". In questo modo tutti gli anni a partire dal 2000 avranno numerazione consecutiva da 100 a seguire nei calcoli tra date, e le procedure esistenti per calcolare la differenza delle date rimarranno validi anche nel nuovo millennio. (1)
**
Un'alternativa possibile sarebbe stata quelle di conservare l'anno in un campo di cinque cifre, verificare se esso contenesse spazi non significativi, e, nel caso che ciò non si verificasse, sommare le prime due cifre (19) alla terza (1) prima di visualizzare le quattro cifre dell'anno.
Questa soluzione, però, risulta tecnicamente improponibile per l'applicazione dei più elementari principi tecnici che devono rispettarsi in sede di analisi. Posto quindi che è inammissibile "piegare" la base dei dati alle esigenze elaborative, allontanandosi dalla natura stessa del dato da conservare, giacché gli anni a cinque cifre non li vedrà nessuno di noi, si è preferito procedere in modo diverso. Dapprima si è aggiunto alla base dei dati un campo di due cifre destinato a contenere il decennio; si sono poi aggiornati tutti i record esistenti inserendo le cifre "19" come contenuto del campo decennio, e si sono aggiornate le procedure in modo che leggessero e visualizzassero entrambi i campi uno a fianco all'altro, oppure che ne affiancassero il contenuto in un unico campo data.
A questo punto è sufficiente inserire "20" nel campo decennio di tutti i record nuovi per permettere la distinzione di essi da quelli precedenti.
**
Paradossale quindi che dopo aver tanto criticato una convenzione del passato, decretandola come non lungimiranza dei tecnici, si sia provveduto adottando la stessa identica soluzione di allora. Soluzioni probabilmente idonee in entrambi i casi, perché il problema è soltanto transitorio, in quanto nel breve decorrere di questo ulteriore ventennio, il progresso tecnologico cancellerà fisiologicamente tutte le apparecchiature obsolete che possano avere tuttora problemi di gestione della data, le nuove macchine renderanno ancora più semplice la gestione di eventuali problemi futuri, e nella maggior parte dei casi, si potrà tener traccia degli archivi degli ultimi vent'anni anche con l'attuale tecnologia: opportunità non troppo limitante se consideriamo oggi che sarebbe un arco di tempo superiore a quello di cui disponiamo attualmente.
Queste dunque alcune verità sul cosiddetto
"millennium bug" che baco non è, e queste le soluzioni e le prospettive per chi
tra 30 o 40 anni dovrà affrontare nuovamente il problema con mezzi tecnologici dei quali
oggi non possiamo prevedere la portata, esattamente come mi disse Paolo Torres quindici
anni fa.
Un caso quanto mai tipico di storia che si ripete, dato dalla consapevolezza del non
conosciuto e del non conoscibile, e non dall'approssimazione e dalle leggende che sono
state la fortuna di giornalisti e scrittori negli ultimi giorni o mesi o anni, basate sul
timore di un evento catastrofico causato dalle incoerenze del progresso tecnologico, che
ha prodotto frutti dei quali essi stessi si giovano, come tutti.
L'esempio più eclatante è stato quello di un telegiornale di canale 5 degli ultimi giorni dell'anno: "Con il duemila, il mondo torna al Medioevo". Occasione troppo invitante di accostare il duemila al medioevo e quanto mai distorta anche nel contenuto della notizia. "Allo scoccare dell'anno duemila i computer potrebbero tornare all'anno mille!" annuncia serio e compunto Errico Mentana. Ciò che più sorprese fu che non si trattava dell'edizione straordinaria di "Striscia la notizia" o di "Scherzi a parte", nelle quali si è soliti vedere promozionare i personaggi che lavorano in Mediaset, ma dell'edizione di un telegiornale nazionale in cui il direttore parlava allo stesso modo di questioni ben più rilevanti. Anno 1900, non anno 1000, caro Mentana privo di titoli da mettere nel promo. Certamente negli anni dei quali ho narrato, costoro erano ancora a sudare per scrivere con una bella macchina da scrivere manuale, vero strumento del giornalista e dei computer conoscevano soltanto l'aspetto fantascientifico su cui si sbizzarrì mezzo mondo in titoli cubitali da prima pagina.
Leggende che cavalcano tecnologie senza alcuna specifica conoscenza tecnica, timori ingiustificati di quanto potesse accadere all'avvento dell'anno 2000. Nulla invece è accaduto, sebbene, confesso, io stesso abbia tenuto spento il mio elaboratore la notte di capodanno, ma per tutt'altri motivi. Mi aspettavo il mitomane di turno che dopo aver creato il troiano "Chernobil" che ha distrutto con un evento scatenante "on time" le partizioni dei dischi rigidi di mezzo mondo, e dopo il celeberrimo "Melissa" che ha infettato via internet, avesse predisposto qualche procedura per diventare l'hacker più famoso del nuovo millennio. Delusi invece, tutti quelli che si aspettavano una delle follie di una "testa calda" semmai una scheggia impazzita di casa "Microsoft". Questa però è altra questione, in tema di virus e di troiani dei quali parlo altrove, in merito ai quali si alimentano costantemente altri timori troppo spesso esasperati oltre la realtà tecnica. Proprio oggi che tutti si aspettavano un evento tecnologico che spiazzasse il mondo dalla Nuova Zelanda a seguire, è iniziato soltanto un anno come gli altri, il più nominato ed il più atteso, forse l'inizio del terzo millennio.
Comunque sia, la migliore occasione per augurarsi la realizzazione dei propri più profondi desideri. Auguri!
Giulio della Valle
(1) All'indomani della pubblicazione di questo
articolo, Bill, ha annunciato i suoi timori sugli inconvenienti che ci aspettano, "Il
Mattino" annuncia che il "millennium bug" ha colpito il sito internet di
Meteo France, come se si trattasse di un virus. In questo caso sul sito viene visualizzata
la data 1/1/19100, assolutamente corretta, secondo i nostri assunti, e tutti gli altri...
hanno trattenuto soltanto le ultime due cifre: "00" della data ritoccata
"Anno 19100".
(**) Paragrafo aggiunto il 01/05/2000
Google plus
http://giuliodellaValle.altervista.org/tripod/articoli/artbug.htm
Mercoledì, 05-Gen-2000 20:44:00 CEST