“Allerta, allerta! Tutti i sistemi informatici andranno in tilt nel passaggio tra il 31 dicembre 1999 e il 1° gennaio 2000!”: questo il messaggio di panico che girava per i grigi corridoi di tutti i dipartimenti IT della Terra, rimbalzando dai soffusi velluti e moquette dei “piani alti”, informati della grave minaccia da un certo sensazionalistico racconto dei media e strombazzato in convegni tra un tramezzino ed un prosecco.
I bravi tecnici (alcuni dei quali ancora della generazione del “camice bianco”) non si sono più di troppo agitati. Un “problema” è sempre un’opportunità per migliorare, per escogitare qualcosa di nuovo, per ottimizzare qualcosa che magari, per pigrizia si era cristallizzato nel tempo, in ossequio all’aurea regola del “se funziona, non toccarlo”.
Il “padre” delle teorie sul Millenium Bug è universalmente riconosciuto in Peter de Jeger, che, sulla rivista Computer World del 6 settembre 1993, per primo solevò 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 assessment del rischio elaborati da vari Enti ed istituzioni internazionali, del quale lascio ai più curiosi e volenterosi la lettura in lingua originale.
Questa volta però il tarlo del dubbio c’era davvero.
Qualche giorno fa, alcuni amici in un forum hanno riproposto il link al sito del “Comitato Anno 2000”, che fu istituito nel 1998 (con due DPCM ad agosto e poi a dicembre, per cambio della guardia al Governo) dalla Presidenza del Consiglio per affrontare il tema del “baco del Millennio”.
Mi si è aperta una finestrella nella memoria, ebbi a che fare con il “baco” da neo-assegnato al Servizio Informatica della Guardia di Finanza, allora in grande fermento di crescita, con una rete geografica che iniziava davvero a diffondersi anche sui Comandi più periferici e con la diffusione dei Personal Computer per la gestione del lavoro d’ufficio.
Il “bug” doveva essere affrontato sotto due aspetti: le dotazioni hardware e il codice e i programmi in uso allìAmministrazione.
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 permeabiità 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 problema maggiore risiedeva, ovviamente, nei grossi sistemi di calcolo: la tecnologia di allora, soprattutto per le PA, le banche, le assicurazioni, i grandi gruppi industriali era assestata (ma non ci siamo spostati di molto eh…) su grandi sistemi mainframe IBM con piattaforme OS390, CICS, DB2 e programmi in CSP-COBOL e assimilati.
La notoria “stratificazione” e la consolidata “pigrizia” del programmatore d’altri tempi, che preferiva non metter mano a codice funzionante (in qualsiasi modo), dopo aver profuso sinceri sforzi per ottimizzare i recordset limando all’osso ogni fronzolo inutile e ogni spreco di spazio (visto il costo della memoria a quei tempi), ha trovato molti a dover rincorrere le date memorizzate e computate a sei caratteri, senza quindi i due campi del secolo.
Da qui la rincorsa alle modifiche, ai test, alle ricompilazioni, alle simulazioni che, tutto sommato, hanno avuto successo praticamente dappertutto.
E il Comitato?
Ho memoria di riunioni oceaniche, di war room notturne per la notte di Capodanno, di grandi relazioni e censimenti, di statistiche sui KLOC di codice modificato… Alcune delle firme di infosec.news hanno fatto parte di questi team (e chissà se, eccezionalmente, volessero raccontarci qualcosa di quel periodo, vero Antonello, Umberto…?), alcuni colleghi e alcuni amici, già miei collaboratori, hanno attivamente lasciato la loro impronta su questo grande evento.
Nel nostro piccolo, sistemati i programmi sul mainframe (primo fra tutti quello per il calcolo dello stipendio, ça va sans dire!) e verificato che tutti i job girassero regolarmente, a titolo del tutto pridenziale abbiamo spento il mainframe e l’intero universo Windows intorno alle 20.00 del 31 dicembre.
Irreale il silenzio in sala macchine, ancora ricordo che si sentiva solo il rumore dei condizionatori e dei neon, senza il cupo ronzio dei dischi e l’immanente “rumore di corrente” che soltanto un grande sistema di calcolo diffonde.
Ci siamo dati appuntamento il 2 gennaio: ogni operatore e programmatore pronto alla console, IPL del sistema (il primo da anni per il nostro IBM 9021…), ritirato su l’ambiente Windows e tutto, devo dire, è andato alla perfezione.
Resta il ricordo di un momento “importante” nella storia dell’informatica, in cui la tecnica ha schiacciato l’insetto molesto, come abbiamo voluto ricordare in un quadretto che conservo tra i miei ricordi più cari trasportandolo di trasloco in trasloco.
