{"id":897,"date":"1999-05-01T12:00:00","date_gmt":"1999-05-01T12:00:00","guid":{"rendered":"https:\/\/www.oikonomia.it\/?post_type=articolo&p=897"},"modified":"2026-04-12T19:10:42","modified_gmt":"2026-04-12T17:10:42","slug":"millenium-bug","status":"publish","type":"articolo","link":"https:\/\/www.oikonomia.it\/en\/1999\/maggio\/millenium-bug\/","title":{"rendered":"Millenium Bug"},"content":{"rendered":"

Introduzione\u00a0<\/strong>1<\/sup>
\n<\/strong><\/p>\n

La misura del tempo \u00e8 sempre stato per l\u2019umanit\u00e0 un problema complesso. Il tempo di rivoluzione della terra intorno al sole non corrisponde ad un numero esatto di giorni, i cicli mensili della luna e il ciclo annuale del sole non sono esattamente uguali e coincidono solo ogni 19 anni, pertanto i calendari hanno bisogno di periodici aggiustamenti per essere sincronizzati con l\u2019anno solare.<\/p>\n

L\u2019orologio atomico\u00a02<\/sup>\u00a0ed il sistema di coordinazione universale del tempo (UTC Coordinated Universal Time)\u00a03<\/sup>\u00a0mantenuto dall\u2019International Time Bureau\u00a04<\/sup>\u00a0hanno reso il sistema di misurazione del tempo il pi\u00f9 accurato di tutti i sistemi di misurazione conosciuti dalla specie umana (un secondo ogni milione di anni) ma i calcoli relativi alle date continuano ad essere problematici anche per i sistemi elettronici.<\/p>\n

Con l\u2019avvento dei computer i problemi di data e di calendario hanno improvvisamente assunto nuova rilevanza per le numerose ed importanti attivit\u00e0 umane svolte con computer: errori di data possono causare gravi danni e conseguenze incalcolabili.<\/p>\n

Sfortunatamente le potenzialit\u00e0 di velocit\u00e0 e prestazioni dei computer e del software non furono pienamente sviluppate fin dalle origini dell\u2019era informatica e per motivi di risparmio, quali gli elevati costi delle memorie\u00a05<\/sup>\u00a0venne riservato uno spazio insufficiente per la completa identificazione della data. I due metodi impiegati: il formato convenzionale di rappresentazione delle date (del tipo giorno-mese-anno) e l\u2019accumulo progressivo del numero di secondi da un punto iniziale arbitrario sono stati adeguati sino ad oggi, ma non lo sono pi\u00f9 per il prossimo futuro. Per la ridotta disponibilit\u00e0 di memoria, il campo a quattro cifre degli anni fu ridotto a due e l\u2019accumulazione dei secondi limitata a quattro byte cos\u00ec il primo sistema entrer\u00e0 in crisi entro la fine del corrente anno 1999, il secondo entro il 18 gennaio del 2038\u00a06<\/sup>.<\/p>\n

Una ulteriore complicazione \u00e8 dovuta al modo di rappresentazione a stampa delle date che \u00e8 diverso da paese a paese: negli USA il formato \u00e8 mese-giorno-anno, mentre in Europa \u00e8 giorno-mese-anno, sempre con l\u2019anno a due cifre.<\/p>\n

Per facilitare gli scambi l\u2019International Organization of Standard\u00a07<\/sup>\u00a0ha fissato uno formato, sostenuto dall\u2019ANSI (American National Standard Institute)\u00a08<\/sup>\u00a0e dal NIST (National Institute of Standard e Technology)\u00a09<\/sup>\u00a0del tipo anno-mese-giorno con l\u2019anno a quattro cifre. \u00c8 il ben noto ISO standard 8601:1988\u00a010<\/sup>\u00a0che tuttavia non \u00e8 ancora il formato pi\u00f9 comunemente usato\u00a011<\/sup>\u00a0e anch\u2019esso risente di una comune debolezza dettata dallo sforzo inconscio di risparmio.<\/p>\n

 <\/p>\n

1. Il problema dell\u2019anno 2000<\/strong><\/p>\n

Chi lavora quotidianamente con il progetto, la costruzione e il funzionamento dei computer \u00e8 abituato continuamente a dover risolvere problemi nuovi e inattesi. Il problema nel cosiddetto\u00a0Millennium Bug<\/em>\u00a0\u00e8 cos\u00ec semplice da apparire talmente banale che chiunque \u00e8 in grado di comprenderne la natura ed escogitare metodi per risoluzione\u00a012<\/sup>. Ancora pi\u00f9 semplice \u00e8 predisporre delle verifiche: basta spostare in avanti le date, inserire dei dati e vedere i risultati.<\/p>\n

Eppure oltre l\u201980% dei responsabili Edp delle aziende dichiara che il problema non solo non \u00e8 risolto, ma che in oltre il 50% dei casi non si arriver\u00e0 in tempo nonostante la disponibilit\u00e0 di strumenti tecnici specifici per analizzare e risolvere il problema e di consulenti esperti. Tutto ci\u00f2 non basta, non c\u2019\u00e8 abbastanza tempo. Infatti non basta scovare tutte le date e convertirle, occorre modificare le maschere di immissione dati, le colonne di output a video e a stampa e quanto a ci\u00f2 correlato.<\/p>\n

Il\u00a0Millennium Bug<\/em>, o\u00a0Problema dell\u2019Anno 2000<\/em>\u00a0come \u00e8 conosciuto, si riferisce all\u2019incapacit\u00e0 di taluni sistemi elettronici di lavorare e gestire correttamente date posteriori all\u2019anno 2000, ma molti dei problemi connessi al cambio di data verranno alla luce (ed alcuni hanno gi\u00e0 fatto la loro apparizione) molto prima dell\u2019inizio del nuovo millennio\u00a013<\/sup>.<\/p>\n

La seriet\u00e0 del problema non riguarda tanto il settore dell Information Technology ma piuttosto quello dell\u2019industria, del commercio, dei servizi sociali e delle istituzioni, persino – paradossalmente – di chi non usa il computer. Un\u2019organizzazione incapace di gestire efficacemente la produzione, gli ordini, le consegne, i pagamenti e i propri servizi nei tempi e nei modi necessari, subisce un grave danno, non solo economico, che poi ricade sulla societ\u00e0 civile. Il cambio di millennio \u00e8 un fatto tecnico con risvolti operativi che comportano un rischio per il business.<\/p>\n

Il problema dell\u2019Anno 2000 affonda le sue radici negli anni \u201860 quando i computer erano poco diffusi, le memorie erano assai limitate e costose e i programmatori dovevano confrontarsi con le ridotte risorse disponibili. La soluzione pi\u00f9 ovvia per rappresentare la data (che nell\u2019elaborazione dati aveva minore rilevanza che non oggi) fu, appunto, quella di usare solo due cifre per l\u2019anno anzich\u00e9 quattro\u00a014<\/sup>. Ne segue che al cambio di secolo, i computer cos\u00ec programmati potranno non essere in grado di interpretare correttamente l\u2019anno 2000\u00a015<\/sup>.\u00a0Il problema \u00e8 grave specialmente per quelle applicazioni strettamente connesse con la precisione della data; il problema \u00e8 globale perch\u00e9 riguarda potenzialmente ogni sistema basato su computer di ogni paese, cio\u00e8 interessa tutta l\u2019informatica e tutta l\u2019azienda; infine esso \u00e8 privo di una soluzione universale.<\/p>\n

Il motivo di fondo, tanto elementare quanto incompreso fino ad ora, \u00e8 che la data \u00e8 presente nei processi di elaborazione dei sistemi informatici come una classe di informazioni molto pi\u00f9 diffusa di quanto non si possa immaginare e che essa viene trattata alla stessa stregua di tutti gli altri tipi di informazione<\/em>: le date si confrontano, si ordinano, sono operandi aritmetici, sono comunemente presenti nei codici identificativi dei prodotti, sono parametri di input\/output. Pertanto la rappresentazione abbreviata dell\u2019anno con le sole ultime due cifre non consente di eseguire correttamente operazioni di ordinamento, confronto e calcolo di intervalli temporali.<\/p>\n

La risoluzione di questo problema \u00e8 poi complicata da una serie di circostanze: la mancanza di conoscenza esatta dei punti di intervento per le intricate interazioni logiche tra dati e istruzioni, l\u2019eterogeneit\u00e0 dei sistemi, la quantit\u00e0 ingente di interventi, la necessit\u00e0, dopo gli interventi, di sottoporre l\u2019intero sistema a vari livelli di test, le diverse implicazioni organizzative ed economiche connesse a tali operazioni.<\/p>\n

Inoltre nel problema dell\u2019anno 2000 sono coinvolti diversi livelli tecnologici, quali i sistemi informativi tradizionali basati su mainframe e terminali, tutti i personal computer cos\u00ec eterogenei per l\u2019hardware, il software di base e applicativo, per le diverse finalit\u00e0 di utilizzo, l\u2019elevato numero, la varia collocazione fisica e configurazione. Ad essi vanno aggiunti i cosiddetti\u00a0sistemi embedded\u00a0<\/em>16<\/sup>\u00a0(o embedded technology) cio\u00e8 quella sterminata quantit\u00e0 di microprocessori presenti nella strumentazione tecnica, nell\u2019elettronica di consumo ed in ogni apparecchio civile o industriale (elettromedicali, sistemi di controllo di processo e di produzione, robot, elettrodomestici, automobili, ascensori, distributori automatici, satelliti, centralini telefonici, fax, impianti antifurto e cos\u00ec via). Anch\u2019essi sono dei veri e propri computer che eseguono specifici programmi dei quali, in molti casi, \u00e8 praticamente impossibile sapere se e come facciano uso di parametri, collegati alla data, che possano risentire in maniera anomala, nello svolgimento dei loro processi, del cambio di secolo\u00a017<\/sup>.<\/p>\n

Stime effettuate dagli analisti individuano una quantit\u00e0 di tali sistemi compresa tra 25 e 40 miliardi, i laboratori di PcWeek hanno riscontrato errori sul 5% dei casi, ma i sistemi embedded sono nella quasi totalit\u00e0 dei casi hard-coded\u00a018<\/sup>, precludendo la possibilit\u00e0 di un intervento diretto.<\/p>\n

Un aspetto non molto evidenziato, ma di importanza strategica, \u00e8 che nella societ\u00e0 odierna sempre pi\u00f9 coinvolta nel processo di globalizzazione, il problema anno 2000 non riguarda isolatamente chi utilizza sistemi informativi. L\u2019interconnessione tra aziende esige un continuo e reciproco scambio di dati (effettuato per via telematica, o con mezzi pi\u00f9 tradizionali come dischi, nastri) che richiede una comune modalit\u00e0 di gestione delle date e una coerente risoluzione del problema. Il problema anno 2000 \u00e8 sistemico: un computer che diffonde dati errati o non coerenti pu\u00f2 indurre anomalie in altri computer, seppur correttamente configurati, ad esso connessi con effetto “domino” a meno di isolare ogni computer “non 2000 compatibile”, il che non \u00e8 possibile. Il problema ha grande rilevanza a livello economico e sociale prima ancora di essere un problema tecnico, perch\u00e9 nessuno vive isolato dal resto del mondo e tutti noi abbiamo a che fare continuamente con strutture fortemente dipendenti dai computer. Paradossalmente, anche chi non utilizza direttamente i computer potrebbe essere coinvolto pesantemente in questo problema.<\/p>\n

Il problema dell\u2019Anno 2000 non \u00e8 solo una questione tecnica, ma un problema economico di rilevanza internazionale e di potenziale gravissimo impatto a livello mondiale. Il cambio di data all\u2019anno 2000 presenta un concreto rischio di recessione economica di proporzioni pericolose, per le potenziali anomalie o interruzioni nei sistemi di pagamento, di capitalizzazione, di calcolo finanziario, insomma il tessuto sociale ed economico a livello mondiale \u00e8 ormai tutto computer-dipendente.<\/p>\n

 <\/p>\n

2. Sistemi Critici<\/strong><\/p>\n

I malfunzionamenti dei sistemi informativi relativi all\u2019anno 2000 possono provocare disservizi nei cosiddetti\u00a0sistemi critici<\/em>\u00a0che regolano la societ\u00e0 civile. Essi sono: il sistema bancario e finanziario, le assicurazioni, i trasporti, l\u2019energia, i servizi postali, i servizi di telecomunicazioni, la diffusione dell\u2019informazione radio e televisiva, la sanit\u00e0, la distribuzione delle merci, i sistemi automatici di produzione, i sistemi di controllo, la pubblica amministrazione. Secondo uno studio del governo inglese, i sistemi critici che regolano il funzionamento di un paese industrializzato, sono a loro volta costituiti da circa 60 processi di lavoro critici singoli tra loro interconnessi: tra questi alcuni sono essenziali perch\u00e9 condizionano tutti gli altri e ad essi va dedicato il massimo sforzo di adeguamento. Essi sono: l\u2019approvvigionamento, la fornitura e distribuzione dell\u2019elettricit\u00e0 (condizionano altri 56 processi), le telecomunicazioni (condizionano altri 48 processi), l\u2019approvvigionamento e distribuzione di carburanti (condizionano altri 45 processi critici), la fornitura dei servizi e delle infrastrutture autostradali (condiziona 43 ulteriori processi critici), il sistema dei pagamenti e i mercati finanziari (condizionano 31 ulteriori processi critici), la fornitura di acqua potabile o per uso industriale (condiziona altri 26 processi critici).<\/p>\n

Le aziende devono anche predisporre un piano di emergenza (contingency plain) teso ad assicurare comunque (in caso non si riesca a conseguire le necessarie conformit\u00e0 nei tempi stabiliti) la continuit\u00e0 di esercizio, cio\u00e8 delle operazioni fondamentali alla sopravvivenza e allo sviluppo. Tale piano di emergenza si compone di pi\u00f9 fasi: elaborazione del progetto teso ad assicurare la continuit\u00e0 delle operazioni (fase di inizializzazione); analisi dell\u2019impatto sul servizio e sul business dei malfunzionamenti o del blocco totale dei sistemi critici relativi ai processi fondamentali, con analisi del rischio; pianificazione delle procedure di emergenza con i modi di sviluppo concreto, con le responsabilit\u00e0 di attivazione; verifiche e collaudi della strategia definita nella prima fase, sviluppo delle procedure di emergenza e dei piani di ripristino che si devono attuare in caso di disastro.<\/p>\n

 <\/p>\n

3. Implicazioni di Ordine Legale<\/strong><\/p>\n

Un problema tecnico come quello dell\u2019anno 2000 presenta anche notevoli implicazioni di ordine legale non appena danneggia l\u2019interesse degli azionisti di una societ\u00e0 o mette a repentaglio la sicurezza delle persone. Potranno insorgere cause per danni intentate dalle aziende contro i propri dirigenti, che non hanno saputo affrontare (e risolvere) tempestivamente il problema; basti pensare al software di controllo della produzione, al software di controllo dei processi che possono essere interrotti aumentando i costi e riducendo i profitti; ai sistemi di pagamento e fatturazione che danneggiano i clienti e bloccano il flusso di cassa\u00a019<\/sup>\u00a0(cash flow); ai sistemi controllo delle strumentazioni mediche\u00a020<\/sup>, degli aerei, a servizi essenziali come centrali elettriche e sistemi telefonici con potenziali a persone. Dato che tutta l\u2019attivit\u00e0 economica dipende dall\u2019elettricit\u00e0 e dal telefono questa \u00e8 chiaramente tra le pi\u00f9 importanti aree a rischio La probabilit\u00e0 stimata che ci\u00f2 accada \u00e8 ben del 50%, mentre c\u2019\u00e8 una probabilit\u00e0 dell\u201985% che applicazioni non trattate possano causare abbastanza danni da provocare cause legali\u00a021<\/sup>.<\/p>\n

 <\/p>\n

4. Le Indagini di Settore<\/strong><\/p>\n

Le recenti indagini e rilevazioni effettuate da universit\u00e0 e societ\u00e0 di ricerche di mercato evidenziano una situazione piuttosto seria. Secondo tali statistiche\u00a022<\/sup>\u00a0(http:\/\/www.mediamente.rai.it\/home\/tv2\/mm9899\/settimanale\/990115\/s1_15.htm<\/a>), un terzo delle aziende mondiali non ha neppure iniziato a prendere in considerazione il problema del Millennium Bug ed il nostro paese, al confronto dei partner europei risulta tra i pi\u00f9 arretrati. La maggior parte delle aziende italiane sono a rischio, anche se utilizzano applicativi acquistati da terzi. Una attenta valutazione del rischio e degli interventi da effettuare non \u00e8 affatto un esercizio facile e sono molto scarse e quindi costose le risorse tecniche capaci di intervenire. Per il ritardo accumulato, tutto ci\u00f2 \u00e8 inevitabilmente destinato a peggiorare fortemente nel tempo; occorrerebbe intervenire pesantemente, con priorit\u00e0 assoluta, e con notevole dispendio di mezzi: tutti aspetti questi che, purtroppo, sono tuttora sottovalutati e disattesi.<\/p>\n

Secondo Meta Group il costo dell\u2019anno 2000 per il settore pubblico e privato ammonta per l\u2019Italia a 34 miliardi di dollari (cio\u00e8 58.000 miliardi di lire); una considerazione abbastanza diffusa e deleteria per non intraprendere nessuna seria azione sull\u2019anno 2000 consiste nel fatto che molti dirigenti pensano che i costi di adeguamento all\u2019anno 2000 saranno maggiori rispetto ai danni potenziali che il problema causer\u00e0 alle loro aziende.<\/p>\n

 <\/p>\n

5. L\u2019itinerario di Conversione e i metodi di Soluzione<\/strong><\/p>\n

L\u2019attivit\u00e0 di conversione al 2000 presuppone un processo di lavoro ben strutturato e controllato; ogni organizzazione deve intraprendere una serie di fasi: 1) inventory assessment, cio\u00e8 la creazione della consapevolezza e l\u2019inventario di tutti gli elaboratori, di tutto il software, di tutti i dispositivi con microprocessori incorporati: questa fase occupa circa il 10% del tempo e il 5% dei costi, pu\u00f2 essere automatizzata solo per l\u20198%\u00a023<\/sup>. 2) Valutazione economica, tecnica e di rischio, scelte fondamentali e creazione dell\u2019ambiente di conversione: revisione di tutti i computer e dei sistemi di rete per verificarne la conformit\u00e0 ed effettuare tutte le sostituzioni necessarie, verifica di tutti i sistemi operativi, dei linguaggi di programmazione, dei database, del software di comunicazione e delle utilities, consultando i relativi fornitori ed effettuando tutti i necessari aggiornamenti\u00a024<\/sup>. Questa fase richiede circa il 36% del tempo e il 30% dei costi, gode di un livello massimo di automazione del 60%. 3) Sviluppo del piano di intervento ed implementazione, che deve interessare anche Pc, sistemi embedded e supply chain, cio\u00e8 la rete di approvvigionamento dove informazioni, ordini, fatture viaggiano sempre pi\u00f9 spesso su supporti informatici o reti telematiche. Per tutti i programmi applicativi facenti riferimento ad una gestione non corretta della data, occorre risalire se possibile al fornitore\u00a025<\/sup>\u00a0o al programmatore che ne ha curato lo sviluppo. Nella impossibilit\u00e0 a ci\u00f2 si pu\u00f2 ricorrere a strumenti software di valutazione e di conversione che possano automatizzare in parte il lavoro, per i quali \u00e8 comunque richiesto il supporto di personale tecnico specializzato con spese non indifferenti o alla soluzione estrema di sostituire i prodotti con altri alternativi valutando attentamente i tempi\u00a026<\/sup>\u00a0necessari per la riconversione e per la formazione del personale. Questa fase occupa il 10% del tempo il 30% dei costi e pu\u00f2 godere al massimo di un livello di automazione del 50%. 4) Testing, cio\u00e8 verifica con test singoli e globali della convalida delle applicazioni rese conformi all\u2019anno 2000. Richiede circa il 39% del tempo, il 30% dei costi e pu\u00f2 godere di un livello massimo di automazione del 40%. 5) Istallazione e messa in esercizio del sistema informativo cos\u00ec reso 2000 compatibile. Occupa circa il 5% del tempo, il 5% dei costi e pu\u00f2 godere di un livello massimo di automazione del 20%.<\/p>\n

Lo stesso discorso vale per i rapporti con clienti e distribuzione. Perch\u00e9 il business di un\u2019azienda non subisca pesanti contraccolpi dopo il 31 dicembre 1999, insomma, non basta che il proprio sistema informatico sia Y2K compliant, occorre che lo siano anche quelli dei partner, dei fornitori di servizi, della pubblica amministrazione e di tutti quegli altri enti con cui si ha a che fare.<\/p>\n

Non esiste poi solo un problema di Y2K compliance, ma esso genera anche un problema di standard, perch\u00e9 esistono diverse metodologie di conversione all\u2019anno 2000\u00a027<\/sup>. \u00c8 chiaro che tutto ci\u00f2 coinvolge due aspetti ostili, il tempo ed il costo.<\/p>\n

 <\/p>\n

6. La Fase di Testing<\/strong><\/p>\n

Superate queste difficolt\u00e0, occorre poi procedere, come si \u00e8 detto, alla pianificazione delle attivit\u00e0 di test\u00a028<\/sup>\u00a0che vanno a coesistere con le attivit\u00e0 informatiche correnti e possono richiedere esigenze di capacit\u00e0 elaborativa aggiuntiva. Questi test vanno articolati in maniera assai attenta, perch\u00e9 la correzione del codice in chiave anno 2000 introdurr\u00e0 errori in altre parti delle applicazioni\u00a029<\/sup>.<\/p>\n

Pertanto occorre un test di regressione per verificare che il sistema informatico cos\u00ec aggiornato abbia almeno lo stesso livello\u00a030<\/sup>\u00a0di funzionalit\u00e0 preesistente (il che si ottiene posizionando la data del sistema al valore attuale con transazioni con date normali). Il test successivo si effettua ancora con data al valore attuale ma con transazioni oltre il 1-1-2000, quindi si passa al test della transizione 1999-2000, test particolarmente delicato perch\u00e9 il cambiamento della data di un sistema informativo centrale pu\u00f2 avere conseguenze disastrose se effettuato in modo errato; quindi backup di tutti i dati, conoscenza approfondita del sistema operativo e delle applicazioni. Poi il test di operazioni con data nel 2000 e transazioni antecedenti e successive. Ogni test va effettuato per operazioni giornaliere, chiusure mensili, trimestrali etc. Infine occorre il test dell\u2019anno 2000 come bisestile.<\/p>\n

Come \u00e8 evidente, sono test che richiedono molto tempo e la disponibilit\u00e0 degli apparati normalmente usati per le operazioni correnti, quindi sono da compiersi per lo pi\u00f9 fuori del comune orario di lavoro; in molti casi richiedono la presenza degli utenti finali, i soli a conoscere bene come funzionano le procedure e in grado di giudicare e definire eventuali errori e modifiche da apportare.<\/p>\n

Nel caso dei Personal Computer, la enorme eterogeneit\u00e0 dei sistemi rende pi\u00f9 confusa la situazione. Il primo test da effettuarsi riguarda la funzionalit\u00e0 del BIOS e dell\u2019RTC, (vedi app. A) poi si deve passare al test del sistema operativo e soprattutto delle applicazioni. Nel caso del sistema operativo pi\u00f9 diffuso, Windows 95 (o 98). la stessa Microsoft riferisce di piccole imperfezioni\u00a031 <\/sup>che difficilmente possono rappresentare un problema funzionale per gli utenti e che sono in via di risoluzione con apposite patch software; ma la messa a punto della suite Office richiede l\u2019istallazione di patch per Word, Excel e Access, con circa un\u2019ora di lavoro che moltiplicata, ad esempio, per 10.000 PC richiede circa 6 anni-uomo. Quindi la verifica sia degli applicativi di Office sia di Windows 98\u00a032<\/sup>\u00a0sta rappresentando per diverse aziende un costo crescente finora sottovalutato, mentre emergono nuovi problemi potenzialmente dannosi anche nei controlli di compatibilit\u00e0 su Windows NT 4.0\u00a033<\/sup>.<\/p>\n

Certamente il settore “embedded” \u00e8 quello pi\u00f9 enigmatico, tanto da poter essere estremamente grave per alcune organizzazioni e del tutto trascurabile per altre. Nel 1997 sono stati venduti oltre 12 miliardi di microprocessori (pi\u00f9 del doppio dell\u2019anno precedente) utilizzati praticamente ovunque: dagli orologi ai sistemi di controllo dei processi ad alta tecnologia. Qualsiasi componente di un dispositivo che ha a che fare con la data (cio\u00e8 mantiene una data o dipende dalla data per compiere delle operazioni) \u00e8 soggetto al rischio dell\u2019anno 2000. Tuttavia se la programmazione del microprocessore \u00e8 stata eseguita correttamente il problema non sussiste, ed \u00e8 qui l\u2019aspetto pi\u00f9 inquietante: non si sa. L\u2019utilizzatore, e spesso anche il produttore che ha assemblato l\u2019apparecchio, non sa niente di ci\u00f2: la programmazione \u00e8 completamente invisibile all\u2019utilizzatore. Per avere informazioni al riguardo non resta che risalire al fornitore originario, operazione assai difficile, oppure eseguire dei complessi test, lavoro altrettanto complesso e costoso.<\/p>\n

Come si \u00e8 esposto, il problema dell\u2019anno 2000 \u00e8 di natura pervasiva; esso influenza la maggior parte delle organizzazioni che sono obbligate ad effettuare modifiche ai loro sistemi o ai loro processi; queste modifiche, a loro volta, potranno influenzare i partner commerciali, come i clienti e i fornitori e cos\u00ec via. Quindi un aspetto che va curato con particolare attenzione \u00e8 quello relativo allo scambio di dati che, effettuato attraverso le reti telematiche o con il trasporto fisico di supporti comporta la convergenza di diversi algoritmi (una comune definizione del formato delle date rese conformi all\u2019anno 2000, l\u2019utilizzo di un comune sistema di codifica e conversione, la sincronizzazione temporale del passaggio ai nuovi standard, la verifica della funzionalit\u00e0 delle nuove modalit\u00e0 operative). Occorre cos\u00ec verificare con i partner commerciali il grado di compatibilit\u00e0 all\u2019anno 2000 e la coerenza della transizione verso la conformit\u00e0 dei sistemi per consentire uno scambio di dati senza interruzioni, perch\u00e9 anche utilizzando computer e programmi anno 2000 compatibili \u00e8 possibile introdurre errori con un trattamento\u00a034<\/sup>\u00a0non coerente delle date come numeri, in tal caso ogni documento prodotto (fogli di calcolo, database contenenti date etc.) deve essere verificato.<\/p>\n

 <\/p>\n

IL NETWORK YEAR 2000<\/strong><\/p>\n

La maggior parte delle preoccupazioni sugli effetti del cambio di millennio sono concentrate sull\u2019invecchiamento delle applicazioni (scritte principalmente in Cobol) mentre si \u00e8 prestata poca attenzione ai problemi delle reti.<\/p>\n

Il N2K (Network Year 2000) riguarda tutti i dispositivi di rete, quali hub, switch, router, server e Pc che interpretano codici correlati a informazioni sulla data. Questi utilizzano normalmente le informazioni sulla data contenuti negli agenti di gestione e monitoraggio istallati al loro interno. Le applicazioni di gestione utilizzano le stesse informazioni per effettuare le analisi delle prestazioni delle reti e stabilire le correlazioni tra gli eventi. Attraverso hub e router queste informazioni vengono elaborate e registrate in centinaia di dispositivi interconnessi. Tutti i dispositivi possono essere interessati dal N2K, dai desktop alle dorsali di rete. Router e switch sono dipendenti dai sistemi operativi, come i Pc e i Server i cui Bios possono presentare problemi di compatibilit\u00e0. Secondo Bell Atlantic Network Integration, uno dei maggiori system integrator mondiali, pi\u00f9 di 800 tipi di dispositivi di rete sono vulnerabili e presenteranno problemi di performance o errori dovuti al millennium bug (da test effettuati i bridge token-ring cessavano completamente di inoltrare il traffico). Un\u2019indagine effettuata da Cap Gemini America nell\u2019aprile 1998 su 128 societ\u00e0 Usa rivelava che le aziende le cui reti presentavano problemi relativi all\u2019anno 2000 erano cresciute dal 7% (dic-97) al 37% (marzo 98) mentre Gartner Group fornisce una percentuale tra il 40 e il 50% a livello mondiale.<\/p>\n

Lo scenario previsto dagli analisti non \u00e8 quello di un completo shutdown delle reti ma piuttosto una serie di inconvenienti che causeranno comunque dei fermi delle reti: firewall negheranno l\u2019accesso, sistemi di management forniranno dati errati, sistemi di posta elettronica subiranno inconvenienti\u00a035<\/sup>.<\/p>\n

I problemi maggiori nelle reti sono dovuti alla loro complessit\u00e0, essendo molti network costituiti da dispositivi e piattaforme misti.<\/p>\n

 <\/p>\n

 <\/p>\n

ALCUNI CONTRIBUTI SULL\u2019ARGOMENTO<\/strong><\/p>\n

PETER DE JAGER<\/strong><\/p>\n

Consulente informatico canadese, fu il primo, nel 1993 a suonare l\u2019allarme sul problema anno 2000. L\u2019Ufficio americano del bilancio ha previsto per la revisione generale dei computer oltre 2.300 milioni di dollari, la Gartner Group, il pi\u00f9 importante consulente al mondo per l\u2019informatica ha stimato la spesa complessiva tra 1000 e 2000 miliardi di dollari, la banca americana Morgan, abbassa la cifra a “soli” 200 miliardi di dollari e altri la alzano a 1000 miliardi per le cause legali e i contenziosi giudiziari. In Europa alcune stime sono di 300.000 miliardi di lire di cui 30.000 in l\u2019Italia per la revisione dei programmi delle aziende italiane.<\/p>\n

INDAGINE ELEUSI-HAL – Marzo 1998<\/strong><\/p>\n

Un\u2019indagine\u00a036<\/sup>\u00a0sul Millennium Bomb condotta nel marzo 1998 dal Centro Eleusi (il centro ricerche dell\u2019Universit\u00e0 Bocconi di Milano) per conto della software house milanese HAL\u00a037<\/sup>, su un campione di 350 medie imprese italiane (99-499 addetti), rappresentativo di un universo di oltre 7300 realt\u00e0 private emerse che quasi tutte (94,3%) conoscevano il problema anche se tardavano ad affrontarlo, ma un restante 5% (cio\u00e8 ben 400 imprese) dichiarava di non saperne nulla. Inoltre, il 60% di queste aziende si dichiarava ottimista e fiducioso nel fatto che, o con l\u2019intervento dei fornitori o con un intervento governativo (rottamazione del software non 2000 compatibile in cambio di software 2000 ready), la situazione si sarebbe risolta senza sforzi, mentre il restante 40% non aveva ancora pensato a nulla.<\/p>\n

 <\/p>\n

INCONTRO ANNO 2000 ED EURO<\/strong><\/p>\n

– MARZO 1998<\/strong><\/p>\n

In un incontro su “Il conflitto tra l\u2019Anno 2000 ed euro<\/em>”\u00a038<\/sup>\u00a0ebbe come partecipante Capers Jones\u00a039<\/sup>\u00a0cui si debbono i pi\u00f9 avanzati studi sulle metriche del software. Lo studioso nordamericano dichiar\u00f2 che oltre il 55% delle applicazioni in produzione sarebbero state coinvolte nel problema Anno 2000 ed oltre il 15% dalla conversione all\u2019Euro e che il 70% dei softwaristi si sarebbe trovato a dover lavorare u uno di tali problemi.<\/p>\n

Egli us\u00f2 termini come\u00a0corsa al disastro<\/em>\u00a0e defin\u00ec\u00a0una delle pi\u00f9 imprudenti e rischiose decisioni<\/em>\u00a0della Comunit\u00e0 Europea quella di pianificare il completamento della conversione delle monete nazionali in un\u2019unica moneta europea\u00a0senza riguardo al fatto che i problemi della conversione in euro e quelli relativi all\u2019anno 2000 sarebbero stati in diretta competizione tra loro, data la limitata disponibilit\u00e0 di risorse da dedicare allo sviluppo del software<\/em>. Una politica molto pi\u00f9 accorta sarebbe stata quella di rimandare la conversione della moneta unica al termine del lavoro per l\u2019anno 2000, pianificandola almeno per il 2003.<\/p>\n

Il risultato pi\u00f9 probabile di tale sovrapposizione (tra conversione in euro e soluzione del problema anno 2000), disse Capers Jones, che sarebbe stato che nel 1998 i Paesi dell\u2019Europa occidentale avrebbero dedicato tutto il loro impegno al problema Euro e solo nel 1999 avrebbero cominciato a presagire il reale rischio legato all\u2019anno 2000 varando in tutta fretta a piani di emergenza\u00a040<\/sup>. Ma non essendoci in Europa le sufficienti risorse per risolvere contemporaneamente i due problemi, egli previde che il 65% delle applicazioni informatiche non avrebbero raggiunto in tempo la conformit\u00e0 anno 2000.<\/p>\n

Certamente mancare gli obiettivi di conversione all\u2019Euro avrebbe creato notevoli problemi al mondo politico e finanziario, ma comunque sarebbero stati problemi minori rispetto a quelli che potrebbe causare l\u2019Anno 2000 nei sistemi informativi europei.<\/p>\n

La conversione all\u2019Euro si pu\u00f2 considerare un tipo di manutenzione evolutiva, quella all\u2019anno 2000 una manutenzione correttiva. L\u2019Euro \u00e8 un problema di business con implicazioni tecniche, l\u2019anno 2000 \u00e8 un problema tecnico con risvolti di business.<\/p>\n

Una valutazione dell\u2019ordine di grandezza dei tempi e dei costi necessari per gli interventi anno 2000, ad esempio, usando il metodo dell\u2019espansione del campo data, si pu\u00f2 ottenere elevando alla potenza dello 0.3 il portfolio in function point\u00a041<\/sup>\u00a0(100.000 function point danno circa 32 mesi). In Italia il software istallato ha una dimensione di circa 290 milioni di function point (circa un sesto del totale dei 15 paesi dell\u2019unione europea)\u00a042<\/sup>.<\/p>\n

Considerando un costo orario del personale di 50 dollari, il costo per function point per le applicazioni scritte in Cobol \u00e8 di 28 dollari per il Visual Basic 30 dollari, C, Pascal, Fortran etc, 35-40 dollari, assembler 80 dollari.<\/p>\n

Per una piccola azienda con un staff dedicato al software di 5 persone e un portfolio di 6.000 function point occorre prevedere un impegno di 23 mesi con un costo totale di circa 200.000 dollari (oltre 3 miliardi di lire), ossia circa 33 dollari per function point. Questo rapporto rimane valido anche per le aziende con uno staff di 50 persone ed un portfolio di 50.000 function point. Il costo aumenta a 37 dollari per function point gi\u00e0 per le aziende con 100 persone occupate nel software e un portfolio di 95.000 function point. Per le grandi aziende che hanno da 3 a 15 sedi, da 1000 a 20000 persone che si occupano del software ed un portfolio in function point da 900.000 a 18.000.000 il costo sale a 40 dollari per function point.<\/p>\n

 <\/p>\n

INDAGINE ELEUSI-HAL – Novembre 1998<\/strong><\/p>\n

Nel novembre 1998 un secondo studio “Osservatorio 2000” condotto dal centro Eleusi dell\u2019Universit\u00e0 Bocconi e dalla software house HAL sullo stato di salute delle medie imprese italiane rispetto al Millennium Bug riferisce che sulle 7300 aziende (tutta la media impresa, escluso il settore caccia e pesca e quello dell\u2019industria estrattiva) che hanno tra 99 e 499 addetti il 18,7% saranno “2000 non compliant” allo scoccare del nuovo millennio.<\/p>\n

Da marzo a novembre dunque le aziende che hanno affrontato il problema sono passate dall\u201980 al 96,4%; di esse il 44,1% dichiara di essere a posto, mentre ben 262 aziende non hanno ancora affrontato il problema e di queste l\u201911,3% (cio\u00e8 30 aziende) ha dichiarato che non intende occuparsene.<\/p>\n

Per quanto riguarda i tempi, l\u201982% delle aziende ha un ritardo di 6 mesi, il 16,5% di 12 mesi e la maggior parte delle aziende ritiene che entro il marzo del 1999 dovr\u00e0 gi\u00e0 inserire nei propri computer date successive al 31 dicembre 1999.<\/p>\n

 <\/p>\n

LE INIZIATIVE GOVERNATIVE ESTERE<\/strong><\/p>\n

Il senato americano ha istituito da tempo un apposito comitato, il Primo Ministro olandese Wim Kok invit\u00f2 il cancelliere tedesco Helmut Kohl a prendere concrete iniziative per evitare il deflagrare della bomba software. Il governo olandese con quello svedese e inglese sono stati i pi\u00f9 attivi nel sostenere iniziative pubbliche e private per affrontare il problema anno 2000\u00a043<\/sup>. Il Primo Ministro inglese Tony Blair \u00e8 stato uno dei pi\u00f9 sensibili al problema anno 2000; egli aveva reclutato oltre 20.000 tecnici (millenniun bug busters) stanziando l\u2019equivalente di oltre 200 miliardi di lire. Lo stesso Primo Ministro britannico il 15 maggio 1998 a Birminghan ha voluto un summit del G-7 (Giappone, Stati Uniti, Canada, Gran Bretagna, Germania, Francia, Italia cui si \u00e8 aggiunta la Russia) per definire un approccio globale al problema44<\/sup>\u00a0La societ\u00e0 di trasporti DHL Worldwide Express ha investito (gi\u00e0 ai primi del 1998) 25 milioni di dollari per adeguare i suoi sistemi informativi alla scadenza dell\u2019anno 2000 (oltre 20 milioni di linee di codice, 1000 server e 25.000 utenti collegati alla rete)\u00a045<\/sup>.<\/p>\n

Il presidente Clinton il 4 febbraio 1999 ha firmato un ordine esecutivo rivolto alle agenzie Federali, al Consiglio sulla conversione all\u2019anno 2000 (Year 2000 Conversion Council) ai capi agenzia e a tutti i responsabili di settore, in cui si legge che il controllo del problema Y2K richiede un forte sforzo tecnologico e manageriale e pertanto ognuno ha la responsabilit\u00e0 nel proprio ambito che il problema Y2K abbia la massima priorit\u00e0 e che sia condotto alla risoluzione con rendiconti almeno trimestrali direttamente al presidente.<\/p>\n

 <\/p>\n

LE INIZIATIVE GOVERNATIVE ITALIANE<\/strong><\/p>\n

Il gruppo di lavoro 2000 la cui presidenza \u00e8 affidata all\u2019Aipa (che sottopose dal 1996 all\u2019attenzione delle amministrazioni la problematica connessa all\u2019anno 2000) ha calcolato in circa 108 miliardi la somma che lo Stato avrebbe dovuto sostenere per la revisione dei programmi di 21 amministrazioni centrali per un totale di 205 milioni di LOC (linee di codice) pari al 75% del patrimonio della Pubblica Amministrazione stimato in circa 273 milioni di LOC, ( consuntivo 1996).<\/p>\n

La commissione governativa istituita il 6 agosto 1998 da Romano Prodi non \u00e8 mai entrata in azione e si \u00e8 riunita solo una volta nel settembre successivo poi \u00e8 stata travolta dalla crisi di governo.<\/p>\n

Il 14 gennaio 1999 il sottosegretario alla Presidenza del Consiglio Franco Bassanini ha presentato il “Comitato anno 2000” presso palazzo Chigi (e presieduto dall’ex sottosegretario alla Funzione Pubblica nel governo Prodi, Ernesto Bettinelli), ammettendo che “l’Italia \u00e8 in grave ritardo ed \u00e8 necessario accelerare i tempi” ed ha annunciato una conferenza nazionale per maggio\u00a046<\/sup>. Tra i compiti del Comitato si legge: “valutare gli effetti connessi al mancato adeguatamente dei sistemi informatici e delle apparecchiature… monitorare le realizzazioni e delle soluzioni tecniche disponibili… prevenire gli effetti negativi sull’Italia e delle possibili ripercussioni nei rapporti con gli altri Stati… evitare gli eccessivi aggravi finanziari sulle amministrazioni pubbliche e sulle imprese”. Valutare, monitorare, prevenire, evitare, ma non decidere, ordinare o risolvere: purtroppo il Comitato non sembra essere una task force o un’unit\u00e0 di crisi, come in altri Paesi e, al momento, dispone di soli 5 miliardi stanziati dalla Finanziaria con i quali si deve costruire tutto. Pochi giorni dopo, lo stesso Bettinelli lancia un grido di allarme: “Io ho accettato di dirigere questo Comitato per pura responsabilit\u00e0 politica. Ma il Governo non si rende conto del problema… Non abbiamo nulla, ci mancano gli strumenti, i poteri… non ho nemmeno uno straccio di segreteria organizzativa… e il tempo sta passando”\u00a047<\/sup>\u00a0http:\/\/www.repubblica.it\/quotidiano\/newspdocs\/19990206\/basi.html.<\/a><\/p>\n

Per altri riferimenti si pu\u00f2 fare una ricerca su Repubblica on-line (http:\/\/www.repubblica.it<\/a>) con chiave “millennium”<\/p>\n

 <\/p>\n

ALCUNE ALTRE INIZIATIVE IN ITALIA – CENNI<\/strong><\/p>\n

L\u2019Autorit\u00e0 per l\u2019Informatica nella Pubblica Amministrazione (AIPA) ha diffuso alcuni documenti sull\u2019adeguamento dei sistemi informativi automatizzati all\u2019anno 2000 fin dal 1996\u00a048<\/sup>. Essi riguardano varie “Indicazioni” sul problema dell\u2019Anno 2000″\u00a049<\/sup>.<\/p>\n

L\u2019Associazione nazionale produttori tecnologie e servizi per l\u2019informazione e la comunicazione (Assinform) ha sviluppato un\u2019azione di sensibilizzazione sul tema orientata alle associazioni industriali e alle piccole e medie imprese con incontri in varie citt\u00e0 italiane\u00a050<\/sup>.<\/p>\n

La IBM Italia ha elaborato un documento molto dettagliato: “La piccola e media industria e il problema dell’Anno 2000\u00a051<\/sup>\u00a0disponibile gratuitamente, che \u00e8 stata ripresa quasi integralmente dall\u2019Assinform. Iniziative simili sono state intraprese da pressoch\u00e9 tutte le maggiori societ\u00e0 di informatica.<\/p>\n

 <\/p>\n

CONCLUSIONE<\/strong><\/p>\n

Per il Millennium Bug non mancano le soluzioni tecniche, quello che sembra mancare \u00e8 la volont\u00e0 di affrontare con seriet\u00e0 un problema conosciuto nei pi\u00f9 piccoli particolari, forse sottovalutato perch\u00e9 scomodo o, peggio, deriso come trucco di industrie informatiche.<\/p>\n

A differenza dell\u2019Euro che nel corso del 1998 le banche e le altre strutture finanziarie avevano improntato simulazioni e si applicavano all\u2019esercizio della nuova valuta per collaudare una transizione che si voleva fosse il pi\u00f9 possibile indolore, il problema dell\u2019anno 2000 rischia di venire affrontato solo a emergenza in atto con il tentativo disperato di gestirla; come sperimentare una nuova arma il primo giorno di guerra senza sapere se sar\u00e0 in grado di sparare nella direzione voluta o se invece esploder\u00e0 in mano a chi avr\u00e0 la sfortuna di usarla.<\/p>\n

L\u2019insegnamento che ne viene \u00e8 che, nell\u2019era dei computer, le decisioni politiche determinanti massicci aggiornamenti di software non possono essere pianificate usando arbitrarie scadenze determinate solo da processi politici, trattati internazionali o decreti governativi, ma devono derivare primariamente dalla capacit\u00e0 di compiere tali aggiornamenti sul software e sui data base. La politica non ha pi\u00f9 il controllo su molti eventi.<\/p>\n

 <\/p>\n

 <\/p>\n

NOTE<\/strong><\/p>\n

1<\/sup>\u00a0Quando si parla di nuovo millennio, abitualmente si fa riferimento al 1 gennaio 2000 come data di inizio, ma in realt\u00e0 non si tratta del primo anno del terzo millennio, ma dell\u2019ultimo anno del secondo millennio. \u00c8 questa anche la posizione dell\u2019Information services department del Royal Greenwich Observatory, l\u2019ente che dal 1884 dopo la conferenza internazionale sul meridiano (Washington, DC, USA) certifica la nascita ufficiale di ogni giorno, e che rappresenta un punto di riferimento per le questioni riguardanti le date e le misure del tempo. Il nuovo millennio ufficialmente inizia il 1 gennaio 2001 a Greenwich e questa scelta deriva dal fatto che la successione degli anni tra quelli prima di Cristo e dopo Cristo non conobbe un anno zero (cio\u00e8 all\u2019anno 1 a.C. segu\u00ec immediatamente 1 d.C.) anche perch\u00e9 i romani non conoscevano un simbolo numerico per indicare il valore nullo e solo verso il sesto secolo divenne pi\u00f9 comune accettare lo zero come un numero. (Cfr.\u00a0http:\/\/millennium.greenwich2000.com\/<\/a>).<\/p>\n

2<\/sup>\u00a0Nel Sistema Internazionale (delle unit\u00e0 di misura) il secondo \u00e8 definito come la durata di 9.192.631.770 cicli di una particolare transizione allo stato fondamentale della struttura iperfina del Cesio-133. Questo definisce un tempo atomico astratto; in pratica \u00e8 necessario un dispositivo, detto orologio atomico; la media pesata degli orologi atomici di vari laboratori dislocati sulla terra definisce il Tempo Atomico Internazionale (TAI) che \u00e8 la migliore realizzazione di una scala del tempo nel Sistema Internazionale. Esso ha una precisione relativa di \u00b12 10-14. Secondo la teoria della relativit\u00e0 generale il tempo misurato dipende dalla posizione sulla terra (pi\u00f9 precisamente dall\u2019altitudine) e anche dalla velocit\u00e0 dell\u2019orologio, cos\u00ec il TAI si riferisce ad un punto, al livello del mare, che ruota con la terra ( cfr.\u00a0http:\/\/www.maa.mhn.de\/<\/a>)<\/p>\n

3<\/sup>\u00a0UTC (Coordinated Universal Time, definito in francese) ha sostituito il Greenwich Mean Time (GMT) come time-zone di riferimento. Il time-zone di riferimento \u00e8 basato sull\u2019ora locale al meridiano di Greenwich. Esso \u00e8 distribuito pubblicamente dai radio trasmettitori DCF77.<\/p>\n

4<\/sup>\u00a0Observatoire de Paris-Meudon-Nancay, (\u00a0http:\/\/www.obspm.fr<\/a>).<\/p>\n

5<\/sup>\u00a0Un megabyte di memoria nel 1963 costava 10.000 dollari, oggi ne costa 2.<\/p>\n

6<\/sup>\u00a0Il sistema operativo UNIX memorizza le date in funzione del numero di secondi accumulatisi a partire dal 1 gennaio 1970 usando un\u2019area di memoria di quattro byte che subisce un rollover dopo 232 (=4.294.967.296) secondi.<\/p>\n

7<\/sup>\u00a0http:\/\/www.iso.ch\/<\/a><\/p>\n

8<\/sup>\u00a0http:\/\/web.ansi.org\/default_js.htm<\/a><\/p>\n

9<\/sup>\u00a0http:\/\/www.nist.gov\/<\/a><\/p>\n

10<\/sup>\u00a0Incidentalmente il formato ISO standard non \u00e8 adeguato in ambito scientifico, perch\u00e9 non gestisce ere geologiche n\u00e9 tempi astronomici quindi non consente l\u2019applicazioni di tecnologie come il data mining o l\u2019on-line analytical processing (OLAP) a dati scientifici, perch\u00e9 le date oltrepassano i campi disponibili, mentre una sola cifra in pi\u00f9 avrebbe potuto essere la chiave di riconoscimento del formato usato. (Cfr.\u00a0http:\/\/www.roguewave.com\/<\/a>).<\/p>\n

11<\/sup>\u00a0I prodotti Microsoft supportano il formato ISO non lo adottano di default.<\/p>\n

12<\/sup>\u00c8 stato definito il pi\u00f9 costoso problema semplice della storia dell\u2019umanit\u00e0 per risolvere il quale occorre il pi\u00f9 ambizioso e costoso progetto tecnologico.<\/p>\n

13<\/sup>Le carte di credito emesse agli inizi del 1998, e stock di prodotti alimentari (dei magazzini Marks and Spencer) avendo la data di scadenza nel 2000 vennero considerati gi\u00e0 scaduti da 98 anni.<\/p>\n

14<\/sup>\u00a0Ernesto Hoffman, (laureato in fisica presso l\u2019Universit\u00e0 di Roma), uno dei maggiori ricercatori e programmatori dell\u2019Ibm ricorda che quando scriveva programmi abbastanza complicati gi\u00e0 a partire dalla met\u00e0 degli anni \u201860 uno dei vincoli fondamentali della programmazione di quel periodo era di scrivere programmi estremamente piccoli e compatti. La bravura del programmatore era quella di fare il programma pi\u00f9 corto possibile con una forma quasi di virtuosismo e il contrarre la data da quattro posizioni a due non venne neppure considerato un problema tanto era lontano il 2000.<\/p>\n

15<\/sup>\u00a0La cosa incredibile nella vicenda \u00e8 che ci sono ancora programmi scritti in quegli anni che nessuno sa pi\u00f9 come modificare.<\/p>\n

16<\/sup>\u00a0L\u2019industria dei semiconduttori ha prodotto finora circa 70 miliardi di chip, nel solo 1997 sono stati venduti 12 miliardi di microprocessori.<\/p>\n

17<\/sup>\u00a0Tra gli aspetti problematici dei sistemi embedded vi \u00e8 un utilizzo non convenzionale delle date effettuando la sincronizzazione non in modo assoluto ma come differenza rispetto a una data di riferimento, come nei sistemi che gestiscono i cicli di manutenzione. I problemi insorgono quando per il calcolo di un tali cicli vengono usate date assolute. Gli ascensori sono l\u2019esempio pi\u00f9 appropriato.<\/p>\n

18<\/sup>\u00a0In genere un sistema embedded non dispone di pulsanti di avvio, n\u00e9 accetta input da un computer per poter eseguire delle simulazioni e svolgere dei test.<\/p>\n

19<\/sup>\u00a0Studi del settembre 1998 (condotti da Sofware Productivity Research, (\u00a0http:\/\/www.spr.com<\/a>) evidenziano che in assenza di azioni preventive c\u2019\u00e8 l\u201985% di probabilit\u00e0 di avere problemi abbastanza gravi da determinare cause legali. Negli Stati Uniti il 35% dei dirigenti sono in una cosiddetta classe anno 2000 attiva (cio\u00e8 autorizzano in modo esecutivo strategie di adeguamento) ed il restante 65% nella classe passiva (quadri tecnici qualificati a segnalare i possibili danni anno 2000). Incrociando le percentuali, il 55% dei dirigenti passivi ed il 30% dei dirigenti attivi sarebbero esposti a cause legali. Inoltre molti contratti di outsourcing precedenti al 1995 non menzionavano neppure l’anno 2000 e l’assenza di clausole specifiche sull’anno 2000 pu\u00f2 portare a forme di contenzioso. I clienti ritengono che il problema anno 2000 rientri negli obblighi di manutenzione del software, mentre gli outsourcer ritengono che debba essere considerato in clausole speciali. Per questo motivo gi\u00e0 dal 1997 sono state intentate numerose cause legali.<\/p>\n

20<\/sup>\u00a0Recentemente (The Australian, 6 gennaio 1999) \u00e8 emerso che su un test effettuato su 26761 sistemi degli ospedali in Australia 7042, oltre un terzo) si sono rivelati non compatibili e di conseguenza il governo ha stanziato la somma di 19 milioni di dollari. (Cfr.\u00a0http:\/\/www.theaustralian.com.au\/<\/a>)<\/p>\n

21<\/sup>\u00a0Si valuta cheil 20% delle applicazioni negli USA ed il 35% negli altri paesi non saranno adeguate in tempo.<\/p>\n

22<\/sup>\u00a0Cfr. la trasmissione Mediamente in onda su Rai3 il 15-1-1999 alle ore 24.00,” Millennium Bug: uno scenario italiano”:<\/p>\n

23<\/sup>\u00a0Cfr.\u00a0http:\/\/www.anno2000.it\/temi<\/a>.<\/p>\n

24<\/sup>\u00a0un problema a parte riguarda l\u2019eventuale utilizzo di software non regolarmente licenziato.<\/p>\n

25<\/sup>\u00a0Nell\u2019indagine del centro Eleusi (Cfr. avanti) nelle medie imprese italiane circa il 91% di esse dispone di software sviluppato ad hoc con una incidenza del 55% sulle attivit\u00e0 della funzione Edp dell\u2019azienda.<\/p>\n

26<\/sup>\u00a0Esiste una lunga casistica di progetti informatici (quasi tutti) che hanno richiesto tempi di realizzazione e di messa a punto assai pi\u00f9 lunghi del previsto. Siamo oramai abituati agli annunci di nuovi prodotti da parte delle pi\u00f9 importanti societ\u00e0 di software che vengono progressivamente rinviati anche di anni.<\/p>\n

27<\/sup>\u00a0I METODI CI CONVERSIONE.
\nIl metodo di\u00a0espansione del campo data<\/em>\u00a0consiste nel modificarne il formato da due a quattro cifre, ed \u00e8 il metodo classico per risolvere il problema anno 2000, ma \u00e8 costoso e difficoltoso per molte applicazioni, perch\u00e9 talvolta le date sono indirette e nascoste, ad esempio, nel numero seriale del prodotto. Tale metodo richiede tra i 36 e i 40 mesi. Il metodo\u00a0Windowing<\/em>\u00a0o del “secolo finestra” fissa un particolare anno base, punto mediano della finestra, come “ponte” tra i due secoli ed utilizza la logica di programmi esterni per affrontare le date in questo periodo: (ad esempio le date tra 00 e 30 vengono attribuite al 2000 quelle tra 31 e 99 al 1900). Questo metodo pu\u00f2 essere terminato approssimativamente in 18 mesi, cosicch\u00e9 \u00e8 diventato uno dei metodi pi\u00f9 popolare per chi ha iniziato tardi. In ogni caso, presuppone la conoscenza precisa dei punti sui quali intervenire. Una variante utilizza una finestra scorrevole e quindi prolunga la validit\u00e0 del sistema spostando in avanti l\u2019anno di riferimento ogni anno. Il metodo\u00a0Compression<\/em>\u00a0codifica la data entro due cifre, usando una rappresentazione binaria o esadecimale anzich\u00e9 decimale; i campi data possono gestire le date per almeno qualche tempo. Il lavoro richiede meno di due anni e una conoscenza della tecnica di compressione usata da tutte le applicazioni che accedono ai dati. Una variante consiste nel rappresentare la data con un numero di sei cifre che rappresentano i giorni a partire da una data arbitraria prefissata presa come origine (codifica). Un\u2019altra variante, il sistema Stanley Mackintosh si basa sull\u2019osservazione che un campo data di sei cifre consente teoricamente 106 combinazioni, mentre il normale formato ne usa solo 36625 (da 1 a 31 per i giorni, da 1 a 12 per i mesi da 0 a 99 per gli anni); pertanto con un\u2019opportuna codifica si utilizza la capacit\u00e0 informativa disponibile nel campo mese per indicare i secoli futuri e quella disponibile nel campo giorno per indicare i secoli passati. Il metodo\u00a0Encapsulation<\/em>\u00a0si basa su tools esterni e sposta la data indietro di 28 anni (perch\u00e9 mantiene la sincronizzazione dei giorni della settimana e del calendario). \u00c8 abbastanza facile da usare e pu\u00f2 essere completato in circa un anno, la difficolt\u00e0 consiste nelle date indirette e nascoste. Il metodo del\u00a0Bridging<\/em>\u00a0\u00e8 un metodo ibrido usato per le applicazioni di database in cui un programma di utilit\u00e0 esegue la conversione da due a quattro cifre e viceversa con finestra fissa o scorrevole e encapsulation sullo stesso database. Richiede meno di due anni. Il metodo\u00a0Data duplexing<\/em>\u00a0consiste nella creazione di archivi duplicati in cui la copia ha la data con l\u2019anno a quattro cifre, richiede circa 36 mesi. Il metodo dell\u2019Object-code date interception<\/em>, usato in ambiente mainframe IBM, consiste nell\u2019intercettazione delle date nei codici degli oggetti che stanno entrando nel mercato, ma non pu\u00f2 gestire date nascoste nei numeri seriali di un prodotto. \u00c8 il metodo pi\u00f9 rapido e richiede meno di un anno, ma non \u00e8 il “silver bullet” perch\u00e9 ci sono troppe date nascoste che sarebbero trascurate.<\/p>\n

28<\/sup>\u00a0Nella gestione di un progetto software le attivit\u00e0 di test impegnano circa la met\u00e0 delle risorse di tempo e denaro.<\/p>\n

29<\/sup>\u00a0Secondo Capers Jones, il 7% dei cambiamenti introdotti nell\u2019attivit\u00e0 di correzione del codice nei progetto anno 2000 genera nuovi errori che diventano un numero preoccupante quando si ha a che fare con un portafoglio applicativo di molti milioni di linee di codice come per una grande azienda.<\/p>\n

30<\/sup>\u00a0Ora \u00e8 risaputo che tutti i sistemi in produzione contengono errori, alcuni conosciuti ma non ancora corretti, altri latenti e sconosciuti; nel caso dell\u2019anno 2000 occorre effettuare un tipo di test oggi ancora relativamente nuovo, il “baseline testing” secondo il quale occorrerebbe ripetere tutti i test finora effettuati sull\u2019applicazione (prima della modifica) per verificare che si ottenga lo stesso risultato anche dopo la modifica, cio\u00e8 gli interventi per l\u2019anno 2000 devono riprodurre, anche nelle loro componenti non corrette i comportamenti dei sistemi oggi in funzione.<\/p>\n

31<\/sup>\u00a0Un\u2019ulteriore bug riguarda il 1 aprile 2001 per un errore di programmazione della Msvcrt.dll di Windows 95\/98 che regola il cambio dell\u2019ora legale (appunto il 1-4-2001) e che andr\u00e0 sostituita.<\/p>\n

32<\/sup>La confusione riguardo alla compatibilit\u00e0 di Microsoft Office rispetto all\u2019anno 2000 riguarda soprattutto due punti, le diverse versioni della suite cambiano di volta in volta le cosiddette “date pivot” (che determinano in quale secolo calcolare il mese e l\u2019anno dell\u2019applicativo); e l\u2019utilizzo di macro (soprattutto in Excel) create dagli utenti finali che non riescono ad interpretare correttamente le date e non possono utilizzare la finestra relativa al secolo su cui si basa Excel, specie nell\u2019aggiornamento da Office 95 a Office 97 o nello scambio di dati tra le due versioni. Anche Windows 98 ha un errore, nel caso di un riavvio pochi secondi prima dell\u2019aggiornamento della data, sposta il calendario di sistema di uno o due giorni avanti o indietro.<\/p>\n

33<\/sup>\u00a0Per Windows NT 4.0 non \u00e8 vero quanto affermato da Microsoft secondo cui il sistema operativo impedirebbe l\u2019accesso diretto al real-time-clock, in questo caso Microsoft consiglia di modificare le applicazioni critiche in modo da basarsi su altre fonti standard accurate, come i servizi pubblici che forniscono l\u2019ora esatta.<\/p>\n

34<\/sup>\u00a0Anche sistemi operativi anno 2000 compatibili, possono generare incompatibilit\u00e0 se viene usata l\u2019opzione di default con l\u2019anno a due cifre e si gestisce male (occorre cio\u00e8 impostare la data gg\/mm\/yyyy cos\u00ec ogni introduzione di data a due cifre viene immediatamente trasformata a quattro cifre in modo da poter verificare subito il corretto riferimento al secolo).<\/p>\n

35<\/sup>\u00a0La maggior parte dei gateway registrano automaticamente gli identificativi dei messaggi (Ids Internet) ogni 90 giorni.<\/p>\n

36<\/sup>\u00a0Cfr. Computerworld Italia, 11 maggio 1998, p.36, “Le medie aziende italiana una realt\u00e0 sotto osservazione”.<\/p>\n

37<\/sup>\u00a0La societ\u00e0 milanese Hal Informatica, \u00e8 stata una delle prime in Europa a predisporre rimedi al millennium bug iniziandone lo studio nel 1995, e dichiar\u00f2 che la maggiore difficolt\u00e0 era quella di dover rivedere quasi tutte le applicazioni software entro una certa data, perch\u00e9 il settore del software risente particolarmente del peso degli imprevisti: quasi nessun progetto viene portato a termine entro i tempi previsti ed ben il 40% dei progetti non arriva neppure alla fine.<\/p>\n

38<\/sup>\u00a018 Marzo 1998, Museo dei Navigli, Milano, organizzato da Logicasiel societ\u00e0 del gruppo Telecom Italia-Finsiel.<\/p>\n

39<\/sup>\u00a0Capers Jones, fondatore e Chairman della Software Productivity Research (\u00a0http:\/\/www.spr.com<\/a>) specializzata nella gestione di progetti software \u00e8 considerato il padre dell\u2019Analisi Funzionale ed un pioniere nell\u2019uso dei Function Point, (una metrica di analisi del software, nata nel 1970 in casa IBM) che consente una valutazione pi\u00f9 ricca e profonda della semplice quantit\u00e0 di linee di codice (LOC). Essa fornisce degli indicatori atti a valutare un\u2019attivit\u00e0 di sviluppo e manutenzione del software, l\u2019efficienza dei programmatori e sviluppatori. Ricco di un tale bagaglio di primo ordine nelle problematiche di programmazione, il suo parere \u00e8 di grande valore nella valutazione dell\u2019effettiva consistenza del problema dell\u2019anno 2000.<\/p>\n

40<\/sup>\u00a0Il General Accounting Office (GAO) americano ha preparato una pubblicazione di guida per lo sviluppo di un piano di emergenza (contingency plans and business continuity plans)\u00a0http:\/\/www.gao.gov\/<\/a><\/p>\n

41<\/sup>\u00a0Cfr. Computerworld Italia del 14 aprile 1998, p.33.<\/p>\n

42<\/sup>\u00a0Ricordiamo pure che l\u2019adeguamento del piano applicativo dell\u2019INPS per l\u2019anno 2000 ed euro richiede il riesame di ben 12.5 milioni di linee di codice ed \u00e8 stato dato in appalto a Finsiel per soli 10 miliardi di lire e che la gara d\u2019appalto and\u00f2 quasi deserta.<\/p>\n

43<\/sup>\u00a0Cfr. Computerworld Italia del 4 maggio 1998, p.33.<\/p>\n

44<\/sup>\u00a0Cfr. Computerworld Italia del 11 maggio 1998, p.37.<\/p>\n

45<\/sup>\u00a0Ibidem, p.37.<\/p>\n

46<\/sup>\u00a0Cfr La Repubblica: Duemila, la via italiana per sconfiggere l’insetto di Annalisa Usai (14 gennaio 1999):\u00a0http:\/\/www.repubblica.it\/<\/a><\/p>\n

47<\/sup>\u00a0Cfr. La Repubblica: Millennium Bug: il capo del Comitato anno 2000 di Palazzo Chigi lancia un grido d’allarme. “E’ in gioco l’intero sistema e il Governo non l’ha capito” Bettinelli: sono a rischio gli ospedali, i trasporti e la sicurezza dei cittadini di Annalisa Usai (5 febbraio 1999)\u00a0http:\/\/www.repubblica.it\/<\/a>
\nCfr. La Repubblica: Disarmati di fronte al Millennium bug. Il cambio di data dei computer: il governo stanzia 5 miliardi, ma \u00e8 polemica (6 febbraio 1999).<\/p>\n

48<\/sup>\u00a0Cfr.\u00a0http:\/\/www.aipa.it\/11\/index.asp11\/index.asp<\/a><\/p>\n

49<\/sup>\u00a0Cfr. Indicazioni per il dimensionamento dei progetti Anno 2000 (http:\/\/www.aipa.it\/[11\/ind_all8.asp[11\/ind_all8.asp<\/a>),<\/p>\n

Indicazioni per l’acquisizione di servizi relativi ai progetti Anno 2000 (http:\/\/www.aipa.it\/[11\/ind_all10.asp[11\/ind_all10.asp<\/a>).<\/p>\n

50<\/sup>\u00a0Cfr.\u00a0http:\/\/www.assinform.it<\/a>.<\/p>\n

51<\/sup>\u00a0Cfr.\u00a0http:\/\/www.ibm.it\/<\/a>,\u00a0http:\/\/www.ibm.it\/anno2000<\/a>.<\/p>","protected":false},"template":"","meta":{"_acf_changed":false,"_lmt_disableupdate":"","_lmt_disable":""},"autori":[1011],"fascicolo":[15],"class_list":["post-897","articolo","type-articolo","status-publish","hentry","autori-gabriele-giulimondi","fascicolo-maggio"],"acf":[],"yoast_head":"\nOikonomia - Millenium Bug<\/title>\n<meta name=\"description\" content=\"Leggi l'articolo a cura di Gabriele Giulimondi, pubblicato nel numero di Maggio 1999. Disponibile in formato PDF.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.oikonomia.it\/en\/1999\/maggio\/millenium-bug\/\" \/>\n<meta property=\"og:locale\" content=\"en_GB\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Oikonomia - Millenium Bug\" \/>\n<meta property=\"og:description\" content=\"Leggi l'articolo a cura di Gabriele Giulimondi, pubblicato nel numero di Maggio 1999. Disponibile in formato PDF.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.oikonomia.it\/en\/1999\/maggio\/millenium-bug\/\" \/>\n<meta property=\"og:site_name\" content=\"Oikonomia\" \/>\n<meta property=\"article:modified_time\" content=\"2026-04-12T17:10:42+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.oikonomia.it\/wp-content\/uploads\/2026\/03\/logo_oikonomia-nero.png\" \/>\n\t<meta property=\"og:image:width\" content=\"500\" \/>\n\t<meta property=\"og:image:height\" content=\"500\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Estimated reading time\" \/>\n\t<meta name=\"twitter:data1\" content=\"39 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.oikonomia.it\\\/en\\\/1999\\\/maggio\\\/millenium-bug\\\/\",\"url\":\"https:\\\/\\\/www.oikonomia.it\\\/en\\\/1999\\\/maggio\\\/millenium-bug\\\/\",\"name\":\"Oikonomia - Millenium Bug\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.oikonomia.it\\\/en\\\/#website\"},\"datePublished\":\"1999-05-01T12:00:00+00:00\",\"dateModified\":\"2026-04-12T17:10:42+00:00\",\"description\":\"Leggi l'articolo a cura di Gabriele Giulimondi, pubblicato nel numero di Maggio 1999. Disponibile in formato PDF.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.oikonomia.it\\\/en\\\/1999\\\/maggio\\\/millenium-bug\\\/#breadcrumb\"},\"inLanguage\":\"en-GB\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.oikonomia.it\\\/en\\\/1999\\\/maggio\\\/millenium-bug\\\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.oikonomia.it\\\/en\\\/1999\\\/maggio\\\/millenium-bug\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/www.oikonomia.it\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Articoli Rivista\",\"item\":\"https:\\\/\\\/www.oikonomia.it\\\/articolo\\\/\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"Millenium Bug\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.oikonomia.it\\\/en\\\/#website\",\"url\":\"https:\\\/\\\/www.oikonomia.it\\\/en\\\/\",\"name\":\"Oikonomia\",\"description\":\"Rivista di Etica e Scienze Sociali Journal of Ethics & Social Sciences\",\"publisher\":{\"@id\":\"https:\\\/\\\/www.oikonomia.it\\\/en\\\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.oikonomia.it\\\/en\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-GB\"},{\"@type\":\"Organization\",\"@id\":\"https:\\\/\\\/www.oikonomia.it\\\/en\\\/#organization\",\"name\":\"Oikonomia - Rivista di etica e scienze sociali \\\/ Journal of Ethics & Social Sciences\",\"url\":\"https:\\\/\\\/www.oikonomia.it\\\/en\\\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-GB\",\"@id\":\"https:\\\/\\\/www.oikonomia.it\\\/en\\\/#\\\/schema\\\/logo\\\/image\\\/\",\"url\":\"https:\\\/\\\/www.oikonomia.it\\\/wp-content\\\/uploads\\\/2026\\\/03\\\/logo_oikonomia-nero.png\",\"contentUrl\":\"https:\\\/\\\/www.oikonomia.it\\\/wp-content\\\/uploads\\\/2026\\\/03\\\/logo_oikonomia-nero.png\",\"width\":500,\"height\":500,\"caption\":\"Oikonomia - Rivista di etica e scienze sociali \\\/ Journal of Ethics & Social Sciences\"},\"image\":{\"@id\":\"https:\\\/\\\/www.oikonomia.it\\\/en\\\/#\\\/schema\\\/logo\\\/image\\\/\"}}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Oikonomia - Millenium Bug","description":"Leggi l'articolo a cura di Gabriele Giulimondi, pubblicato nel numero di Maggio 1999. Disponibile in formato PDF.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.oikonomia.it\/en\/1999\/maggio\/millenium-bug\/","og_locale":"en_GB","og_type":"article","og_title":"Oikonomia - Millenium Bug","og_description":"Leggi l'articolo a cura di Gabriele Giulimondi, pubblicato nel numero di Maggio 1999. Disponibile in formato PDF.","og_url":"https:\/\/www.oikonomia.it\/en\/1999\/maggio\/millenium-bug\/","og_site_name":"Oikonomia","article_modified_time":"2026-04-12T17:10:42+00:00","og_image":[{"width":500,"height":500,"url":"https:\/\/www.oikonomia.it\/wp-content\/uploads\/2026\/03\/logo_oikonomia-nero.png","type":"image\/png"}],"twitter_card":"summary_large_image","twitter_misc":{"Estimated reading time":"39 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/www.oikonomia.it\/en\/1999\/maggio\/millenium-bug\/","url":"https:\/\/www.oikonomia.it\/en\/1999\/maggio\/millenium-bug\/","name":"Oikonomia - Millenium Bug","isPartOf":{"@id":"https:\/\/www.oikonomia.it\/en\/#website"},"datePublished":"1999-05-01T12:00:00+00:00","dateModified":"2026-04-12T17:10:42+00:00","description":"Leggi l'articolo a cura di Gabriele Giulimondi, pubblicato nel numero di Maggio 1999. Disponibile in formato PDF.","breadcrumb":{"@id":"https:\/\/www.oikonomia.it\/en\/1999\/maggio\/millenium-bug\/#breadcrumb"},"inLanguage":"en-GB","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.oikonomia.it\/en\/1999\/maggio\/millenium-bug\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.oikonomia.it\/en\/1999\/maggio\/millenium-bug\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.oikonomia.it\/"},{"@type":"ListItem","position":2,"name":"Articoli Rivista","item":"https:\/\/www.oikonomia.it\/articolo\/"},{"@type":"ListItem","position":3,"name":"Millenium Bug"}]},{"@type":"WebSite","@id":"https:\/\/www.oikonomia.it\/en\/#website","url":"https:\/\/www.oikonomia.it\/en\/","name":"Oikonomia","description":"Rivista di Etica e Scienze Sociali Journal of Ethics & Social Sciences","publisher":{"@id":"https:\/\/www.oikonomia.it\/en\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.oikonomia.it\/en\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-GB"},{"@type":"Organization","@id":"https:\/\/www.oikonomia.it\/en\/#organization","name":"Oikonomia - Rivista di etica e scienze sociali \/ Journal of Ethics & Social Sciences","url":"https:\/\/www.oikonomia.it\/en\/","logo":{"@type":"ImageObject","inLanguage":"en-GB","@id":"https:\/\/www.oikonomia.it\/en\/#\/schema\/logo\/image\/","url":"https:\/\/www.oikonomia.it\/wp-content\/uploads\/2026\/03\/logo_oikonomia-nero.png","contentUrl":"https:\/\/www.oikonomia.it\/wp-content\/uploads\/2026\/03\/logo_oikonomia-nero.png","width":500,"height":500,"caption":"Oikonomia - Rivista di etica e scienze sociali \/ Journal of Ethics & Social Sciences"},"image":{"@id":"https:\/\/www.oikonomia.it\/en\/#\/schema\/logo\/image\/"}}]}},"_links":{"self":[{"href":"https:\/\/www.oikonomia.it\/en\/wp-json\/wp\/v2\/articolo\/897","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.oikonomia.it\/en\/wp-json\/wp\/v2\/articolo"}],"about":[{"href":"https:\/\/www.oikonomia.it\/en\/wp-json\/wp\/v2\/types\/articolo"}],"wp:attachment":[{"href":"https:\/\/www.oikonomia.it\/en\/wp-json\/wp\/v2\/media?parent=897"}],"wp:term":[{"taxonomy":"autori","embeddable":true,"href":"https:\/\/www.oikonomia.it\/en\/wp-json\/wp\/v2\/autori?post=897"},{"taxonomy":"fascicolo","embeddable":true,"href":"https:\/\/www.oikonomia.it\/en\/wp-json\/wp\/v2\/fascicolo?post=897"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}