Appartengo alla generazione che ha vissuto “professionalmente” il Millenium Bug, ovvero Y2K Bug.
Molti di voi lo ricorderanno, per i meno anziani diremo che il 31 dicembre 1999 23:59:59 fu un istante in cui molti trattennero il respiro, e non per l’attesa della sciabolata alla bottiglia.
Il “bug” doveva essere affrontato sotto due aspetti: le dotazioni hardware e il codice e i programmi in uso.
Il primo aspetto era abbastanza oggettivo: sembrava assodato che alcuni PC avessero dotazioni harware (parliamo di processori o di schede logiche) che non supportavano le date a otto cifre, e che pertanto, allo scoccare della mezzanotte, avrebbero fatto “tornare indietro” il loro clock interno alla data 01/01/00. Tutto ciò avrebbe potuto impattare sul funzionamento dei programmi e degli stessi sistemi operativi, che al tempo (forse più di oggi) si basavano sul clock di macchina per innumerevoli funzioni.
SI diffusero numerosi programmini di test per verificare l’eventuale permeabilità al baco, nonché varie “chincaglierie”, anche hardware, per ovviare all’inconveniente, soprattutto mediante l’installazione di schede PCI aggiuntive per la correzione dell’errore (a prezzi da vero furto, ovviamente). Conservo ancora gelosamente una di queste schede: chissà se avrebbe davvero funzionato?
Il “padre” delle teorie sul Millenium Bug è universalmente riconosciuto in Peter de Jeger, che, sulla rivista Computer World del 6 settembre 1993, per primo sollevò la questione Y2K con un articolo dal titolo “Doomsday 2000”. Una curiosità: nelle chat BBS e usenet del tempo, tra gli “addetti ai lavori” della prima ora, il problema era definito con l’acronimo TEOTWAWKI, ovvero The End Of The World As We Know It
Interessante questo articolo pubblicato da Metroactive, rivista settimanale della Silicon Valley, nel numero di metà novembre 1999 e recuperato nei meandri del web, con alcuni stralci dai vari documenti di risk assessment elaborati da vari Enti ed istituzioni internazionali, del quale lascio ai più curiosi e volenterosi la lettura in lingua originale.
In ambito nazionale, nel 1998, fu istituito dalla Presidenza del Consiglio il “Comitato Anno 2000”, per affrontare il tema del “baco del Millennio”. Riunioni oceaniche, war room notturne per la notte di Capodanno, grandi relazioni e censimenti, statistiche sui KLOC di codice modificato… Alcune delle firme di GIANO.news hanno fatto parte di questi team (e chissà se, eccezionalmente, volessero raccontarci qualcosa di quel periodo, vero Umberto…?), alcuni colleghi e alcuni amici, già miei collaboratori, hanno attivamente lasciato la loro impronta su questo grande evento.
SI RIPROPONE
Qualche giorno fa, in un post su Facebook, ho avuto un flash: di nuovo, su un computer, la caratteristica “etichetta gialla” (ormai diventata quasi un’icona in ambiente IT), ma questa volta con una nuova data: il 19 gennaio 2038, ore 03:14:07
Ho pensato subito ad uno scherzo ma… ho fatto male: veramente esiste un Y2K38 Superbug, stavolta battezzato “Epochalipse”. Lascio ai più curiosi un approfondimento delle cause “tecniche” legate al calcolo del tempo basato sui secondi trascorsi dopo lo UNIX Epoch (01/01/1970 00:00:00 UTC).
Tecnicamente, tuttavia, non si tratta di un vero e proprio “bug”: viene definito come “problema”, proprio perché ampiamente previsto e calcolato. E a partire dal 1975 fino all’anno 292.277.026.596 (!!) sono ampiamente fornite spiegazioni e rimedi.
Forse il più preoccupante è quello del 2036, che investirà il protocollo NTP (Network Time Protocol), universalmente utilizzato sulle reti per la sincronizzazione dell’orario fra tutti gli apparati. Ma una soluzione la troveranno… per tempo.
Spero (e lo dico toccando il cornetto di cui parla Umberto Rapetto nel suo ultimo libro) di poter vedere il bug per i sistemi IBM S/370 e zSeries del 2042, magari anche quello del 2048 per i sistemi SAP S/4HANA.
Su quello del 2069, a 101 anni, ho qualche legittimo dubbio di poterci arrivare…anche se già abbiamo passato indenni anche la temutissima “fine del mondo” dei Maya…
