Newsgroup: it.comp.aiuto
Titolo: Anno 2000 bug

Provate a pensare, mentre state leggendo, che solo 467 giorni ci
separano dal 1° gennaio dell'anno 2000. Il passaggio dal XX al
XXI secolo pone al settore dell'Information Technology una sfida di
proporzioni rilevanti senza precedenti. Con l'approssimarsi
dell'anno 2000 molti sistemi informatici stanno già cominciando ad avere
problemi ed il fenomeno crescerà esponenzialmente fino
al 1999 in cui il 90% delle applicazioni che trattano date potranno non
essere più affidabili. Non ci sarà una anomala interruzione
delle elaborazioni ma, peggio, i programmi continueranno ad operare
fornendo risultati non corretti. E' la prima volta nella storia
che una rivoluzione tecnologica rischia di vedere vanificati i propri
benefici effetti in un preciso momento per il solo effetto di una
variazione di calendario. Il problema nasce dal fatto che le
applicazioni informatiche considerano le date in un formato che
rappresenta l'anno a due cifre (96 anziché 1996), dando per implicita
l'indicazione del secolo. Questo perché quando gli elaboratori
non erano ancora molto potenti, anche il risparmio di due caratteri,
soprattutto in applicazioni gestionali con numerosi e continui
trattamenti di date, era fondamentale. Il problema del passaggio di
millennio era noto, ma si riteneva che le applicazioni scritte negli
anni dai '60 agli '80, con l'evoluzione continua della tecnologia, prima
della fine del secolo sarebbero state soppiantate da nuovi
sistemi, più efficienti e con l'anno codificato per intero. Così non è
stato ed ancora oggi quelle applicazioni continuano ad essere
utilizzate a supporto di attività aziendali spesso critiche. Il
passaggio dell'anno 2000 costituisce per tutti i sistemi/applicazioni
informatici oggi esistenti un problema che non può essere ignorato, né
affrontato con superficialità. Per quanto banale sia la causa,
estremamente complessa è la soluzione. Per ogni organizzazione che si
avvale del supporto informatico è necessario identificare
tutti i punti di trattamento date nell'ambito di decine di milioni di
istruzioni software e di decine di migliaia di programmi (per la
maggior parte non documentati, non strutturati ed ormai poco leggibili),
sviluppati su piattaforme HW/SW differenti e memorizzati
su librerie di cui non sempre si conosce il contenuto effettivo. L'unica
possibile soluzione consiste nell'affrontare il problema con
tempestività e secondo un approccio ingegnerizzato di tipo industriale.
Il ricorso a soluzioni tecnologiche (la stessa IT) è
sicuramente necessario, ma non sufficiente a garantire il successo della
soluzione. Occorre mettere a punto non solo un impianto
metodologico e tecnologico, ma anche e soprattutto organizzativo secondo
un modello industriale che sia in grado di rispondere con
efficacia ed efficienza alla complessità ed alla rilevanza dimensionale
del problema.
Se siete interessati all'argomento e volete approfondirlo o passarmi
suggerimenti, idee o altro...approfittatene, scrivetemi e vediamo se
riusciamo insieme ad attivare un gruppo di discussione sul tema.
Potremmo chiamarlo it.comp.os.anno2000bug
 Matteo


Sinceramente non penso che ci sia molto da discutere.
La soluzione non e' poi cosi' complessa, basta cambiare
i software (e probabilmente anche l'hardware), chi lo fara'
non avra' problemi, chi no se la sara' cercata.
Certo che questo significa un grande sforzo economico, ma del resto
se una azienda ha questo problema, vuol dire che negli ultimi
10/20/30 anni non ha speso una lira. O no ?
ciao
Bonf

10/20/30 anni non ha speso una lira. O no ?
Mi sa che hai una visione un po' troppo semplicistica... penso che il
problema sia più grave. Pensa solo che i tg hanno fatto dei servizi in
merito...
LuKacs  (rimuovi #NOSPAM# dall'indirizzo)
    Graditi contatti via mail!
  .:*~*:._.:*~*:._.:*~*:._.:*~*:.
In a World without walls and fences, 
who needs Windows and Gates ?
  .:*~*:._.:*~*:._.:*~*:._.:*~*:.

fore...@intercity.it
 wrote:
 >variazione di calendario. Il problema nasce dal fatto che le
 >applicazioni informatiche considerano le date in un formato che
Le tue forse... :-) Io uso unix, quindi la cosa non mi tocca.
-- 
ciao, | [Per rispondere togli "toglimi" dal mio indirizzo.]
Marco | * The Internet is full. Go away.  -- Joel Furr *

 Il passaggio dal XX al XXI secolo
Ma il XX secolo non cominciava il 1o gennaio 2001? Allora c'e'
tempo... :-)
-- 
Davide   |`. /\      
albe...@usa.NO-SPAM.net
      | PGP KeyID:
Alberani |__)~~\ 
http://members.xoom.com/alberanid/
 | 0xD0354739

merito...
Un buon motivo per considerarlo una stronzata...
Il problema e' meno grave di quel che si crede, ad avere problemi
sono, per il 99%, i vecchi mainframe (roba degli anni 60 - 70) che
molte grandi aziende (specialmente assicurazioni e banche) utilizzanop
ancora oggi. Questi macchinari si sono ampiamente ripagati in 30-40
anni di onorato servizio, ma e' ovvio che nessuno sia contento di
spendere centinaia di milioni (se non alcuni miliardi) per cambiarli.
Ho assistito all'installazione di un nuovo mainframe l'anno scorso
presso una importante compagnia di assicurazioni, il sistema nuovo
occupa solo 1 stanza invece di 6 e non richiede l'aria condizionata
per dissipare il calore (non e' uno scherzo), inoltre consuma molta
meno corrente. Insomma, hanno calcolato che se lo ripagheranno in una
quindicina d'anni solo con cio' che risparmiano, inoltre sono a posto
con le date fino al 9999... (Non ci crederete, ma un dirigente aveva
chiesto se non era possibile avere un sistema in grado di accettare
date a 5 cifre !!!!!!! Roba da matti...)
Ciao
 
Ricky !
--------------
Rimuovi NOSPAM per rispondermi in e-mail

 Potremmo chiamarlo it.comp.os.anno2000bug
Buongiorno! :-)
Chi produce software ha già le versioni conformi all'anno 2000 in fase
di rilascio, le aziende stanno già sostituendo i programmi obsoleti.
Oggi 7/10/1998 c'è poco da discutere, passeremo il tempo a scrivere "le
aziende devono sostituire i programmi obsoleti" in un loop infinito.
Chi ne discute oggi è in ritardo mostruoso. Da quì al 2000 non c'è tempo
di fare niente.
L'unica cosa che mi è piaciuta è la proposta di un "incentivo
rottamazione" per la sostituzione dei programmi. Purtroppo le ragioni
che hanno portato alla stessa iniziativa per le automobili sono assai
più "ipocrite" di quelle che sentiamo alla televisione.

Il giorno Tue, 06 Oct 1998 12:27:17 GMT lucacrb#NOSPAM#@
usa.net
 (LuKacs) ha
scritto:
-> [...]
-> Mi sa che hai una visione un po' troppo semplicistica... penso che il
-> problema sia più grave. Pensa solo che i tg hanno fatto dei servizi in
-> merito...
-> 
-> 
Non saranno certo tutte rose e fiori; non conosco tutti i differenti metodi
di archiviazione, ma se un sistema per DOS come dBase III gia' dalla meta'
degli anni '80 utilizzava quattro cifre per gli anni, considerato che tale
criterio risulta per nulla abbandonato (basta guardare in un catalogo
quanti linguaggi di programmazione di tipo dBase esistono) credo che
sistemi ben piu' complessi del dBase per PC prevedano tuttora l'uso delle
quattro cifre per archiviare le date.
Altro discorso e' l'interpretazione. Il vero problema, penso, sia quello
dei programmi - o, per lo meno, di quei programmi scritti fino ai primi
anni '90 - che, forse per leggerezza o forse perche' il cliente premeva per
avere il risultato... ieri ;-) non sempre tengono conto del secolo.
I linguaggi prettamente dBase consentono di per se stessi l'interpretazione
corretta delle date. Nei casi in cui, tuttavia, siano stati utilizzati
linguaggi di programmazione differenti, tutto andava demandato alla...
lungimiranza del programmatore.
(N.B.: ho eliminato il cross-post)
-----------------------
Per rispondere rimuovere ~NO.SPAM~ dall'indirizzo E-Mail
To reply remove ~NO.SPAM~ from E-Mail address
Name: Pierluigi Gargiulo
Address: Ancona, Italy
E-Mail: 
plg...@ntt.it
-----------------------

 ancora oggi. 
Assolutamente sbagliato.
Non sono un fautore degli allarmismi, ma le cose non stanno
assolutamente così. 
Il 99% dei problemi è dato dall'obsolescenza del SOFTWARE, non
dell'HARDWARE. Tanto per essere chiari se un programma gestisce le date
in maniera sbagliata, fa casino anche se lo metti sull'hardware più
moderno.
Inoltre tu parli di sistemi mainframe di banche e assicurazioni, queste
organizzazioni hanno già provveduto a risolvere i loro problemi o lo
stanno facendo adesso (mi viene da ridere nell'immaginare una banca che
si è fatta prendere di sorpresa dal problema, dopo tutto il rumore che
c'è stato...). C'è una marea di piccole o medie aziende che utilizzano
software per PC vecchio di un decennio, che se fanno delle registrazioni
contabili in data 2000 finiscono nel bilancio dei loro antenati.

>di rilascio, le aziende stanno già sostituendo i programmi obsoleti.
Sarei veramente interessato a stilare una classifica; ho come la
sensazione che di software house Year2000 ready, non ce ne siano
molte.
Ciao. Michele Q.

 molte.
Le software house in generale non sono molte (parlo ovviamente di chi
produce programmi di un certo target).
Tieni conto che i tools di sviluppo consentono una corretta gestione della
data già da qualche anno.

sono decisamente lunghi. Con molta certezza posso affermare che ci
Non e' richiesto di cambiarlo ogni 2/3 anni, infatti ora si deve
cambiare software di 10->30 anni fa. La prossima volta sara'
probabilmente tra 8000 (ottomila) anni, visto che molti ora 
stanno supportando le date fino al 9999.

Un buon motivo per considerarlo una stronzata...
Effettivamente solo dopo mi sono reso conto che proprio l'esempio dei
tg era il meno adatto al caso. Ma dal clamore che ha sollevato oltre
al telegiornale anche la stampa specializzata, sembra che gli
investimenti che hanno stanziato per fronteggiare il problema siano
piuttosto corposi, quindi non da sottovalutare. 


contabili in data 2000 finiscono nel bilancio dei loro antenati.
Non credo che tu sia molto ferrato in materia di sw contabile... senza
offesa... Quella marea di piccole e medie imprese di cui parli e'
costretta ad aggiornare il sw almeno tre volte all'anno per adeguarsi
alle nuove normative fiscali. Nessuno utilizza sw contabile vecchio di
10 anni... sarebbe assolutamente inutilizzabile oggi.
I problemi sono solo per archivi e database cronologici.
Inoltre e' molto + semplice aggiornarsi per una piccola o media
azienda (i produttori di sw offrono aggiornamenti dei loro programmi a
prezzi particolari, trattandosi di sw proprietario), mentre una grande
azienda/banca/assicurazione deve cambiare, oltre al sw, macchine da
centinaia e centinaia di milioni....


tempo... :-)
Il XX secolo e' iniziato nel 1900...
