Newsgroup: it.comp.os.dibattiti
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 ?
  .:*~*:._.:*~*:._.:*~*:._.:*~*:.

Potremmo chiamarlo it.comp.os.anno2000bug
Adesso??? sei in ritardo di almeno due -tre anni. E, aparte tutte le
imprecisioni che hai citato (una per tutte: l'anno a due cifre per
velocita' di elaborazione, quando si dimostra banalmente che e' vero
il contrario...), dubito che il 90% delle appllicazioni siano fuori
standard, anzi, da due anailisi fatte, e' piu' probabile che il 90%
(come mole di dati...) siano 'in'...
Obelix

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.

 Le tue forse... :-) Io uso unix, quindi la cosa non mi tocca.
Perchč sei cosě sicuro?
Abbiamo appena constatato come Oracle 7.3 (su Aix) faccia un bel casino
quando effettua alcune conversioni di data > 2000.

 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.

Marco Sarti (
marco...@plangroup.it
) wrote:


La data critica per gli Unix a 32 bit e' il 19 gennaio 2038 (2^31 secondi
dal 1 gennaio 1970, data che e' presa come base per i calcoli temporali
da (quasi ?) tutte le librerie standard).
Il problema di Oracle e', appunto, un problema di Oracle ;). Su Byte Italia
n. 7 (Luglio/Agosto 98), in un articolo dedicato al problema dell'anno 2000,
a proposito di Oracle si dice che l'8 e' compatibile mentre il 7 deve essere 
aggiornato (pag. 34).
 
Ciao ciao
Andrea
-- 
"...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and 
 the Ugly)."
(by Matt Welsh)

 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.

 aggiornato (pag. 34).
Si, infatti io sostenenevo che spesso e volentieri il problema non è del sistema
operativo. Tutti i sistemi operativi sono di fatto compatibili con l'hanno 2000.
Il problema sono gli applicativi. Tu dici che il problema di Oracle è un
problema di Oracle... io sostengo che il problema di Oracle è un problema
dell'utente :-) sia questo Unix che NT. Anzi, è un fottuto problema di noi
programmers, che dobbiamo districarsi fra queste trappole (l'errore che ti
dicevo viene dalla doppia conversione data->stringa->data all'interno di
oracle).
Era questo quello che volevo dire. Avere Unix non fa necessariamente dormire
sonni tranquilli.

marco...@plangroup.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.
 >Perchč sei cosě sicuro?
Perche` la data dei sistemi unix e` il numero di secondi a partire dalla
mezzanotte del 1/1/1970. Viene messa in un long e quindi fino al 2038
siamo a posto. A quel punto i long saranno diventati a 64 bit gia` da
tempo, fornendo spazio in abbondanza.
Ribadisco che attualmente la mia preoccupazione principale in vista del
1/1/2000 e` trovare abbastanza alcool e compagni di baldorie.
 >Abbiamo appena constatato come Oracle 7.3 (su Aix) faccia un bel casino
 >quando effettua alcune conversioni di data > 2000.
Questo e` un bug di Oracle. Non nego che anche alcuni programmi per unix
siano buggati, ma sono un numero molto piccolo.


Ma il XX secolo non cominciava il 1o gennaio 2001?
se e' per quello, il problema e' Y2K, quindi inizia dal 2048  :-)))
Obelix

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. 


piuttosto corposi, quindi non da sottovalutare. 
Guarda che il panico, notoriamente, puo' essere indotto anche senza reali 
motivi di preoccupazione 8^) !
"Il senno di poi e' una scienza esatta
nello stabilire cosa _non_ si doveva fare"
Murdock Myst
Doc. Linux: 
http://www.pluto.linux.it/ildp
 , 
http://sunsite.unc.edu/LDP
Segnalate la vostra esistenza al Linux Counter: 
http://counter.li.org/

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....


 se e' per quello, il problema e' Y2K, quindi inizia dal 2048  :-)))
Che poi, noi ci lamentiamo dell'anno 2000, ma sai i casini che
devono essere successi ai computer nell'anno zero?!? :-)))
-3, -2, -1...,
-- 
Davide   |`. /\      
albe...@usa.NO-SPAM.net
      | PGP KeyID:
Alberani |__)~~\ 
http://members.xoom.com/alberanid/
 | 0xD0354739
      - [ Membro dell'Emilia Romagna Linux Users Group ] -

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

lontano da un ascensore (per esempio). :))
Perche'???
Obelix

tempo, fornendo spazio in abbondanza.
Credo che questa sia stata la tesi per cui, 20-30 anni fa, si mise
l'anno a 2 cifre. 'Tanto, per il 2000 sara' cambiato tutto'....
Obelix

che codifichi gli anni con 4 cifre anziche' 2.
Uh?????
Obelix

Il XX secolo e' iniziato nel 1900...
il primo gennaio 1901, semmai...
Obelix

nbr...@box.seven.it
 wrote:
 >> A quel punto i long saranno diventati a 64 bit gia` da
 >>tempo, fornendo spazio in abbondanza.
 >Credo che questa sia stata la tesi per cui, 20-30 anni fa, si mise
 >l'anno a 2 cifre. 'Tanto, per il 2000 sara' cambiato tutto'....
Non confondere due cose che non c'entrano niente. Merced per esempio
sara` un processore a 64 bit. Una volta arrivati quelli bastera`
ricompilare i programmi (cosa che comunque bisogna fare) per avere
abbastanza spazio per le date.
Il passaggio da due a quattro caratteri per l'anno richiede modifiche al
codice.


sonni tranquilli.
Ma come? Non sai che Unix (e Linux su tutti) cambia da solo le date dei
programmi, anche quelle
in cui il codice prevede espressamente la data nel formato AAMMGG?
Seriamente, affermazioni del tipo "Io uso unix, quindi la cosa non mi
tocca." non le capisco.
Certamente il sistema operativo (se recente) non avrà problemi, gli
applicativi forse si.....
--
Che il Bubuti Bauontico sia con Voi....
Gabriele Del Giovine
mc6491@_
sonoqui_mclink.it
Togliere _sonoqui_ per le risposte in e-mail
Please remove _sonoqui_ for e-mail reply

siano buggati, ma sono un numero molto piccolo.
Non tutte le applicazioni funzionanti in Unix sono scritte in C, ed anche in
quelle
scritte in C non sempre si usano le funzioni standard di gestione del
tempo....
Bye Bye


Non confondere due cose che non c'entrano niente. 
Io non confondevo le due cose: facevo noatre come il principio 'tanto
per allora sara' gia' cambiato tutto' sia stato alla base dei problemi
attuali Y2K. e che la tua affermazione lo ricalca fedelmente.
poi, magari per quella data avremmo processori a 256bit...
Obelix

Le tue forse... :-) Io uso unix, quindi la cosa non mi tocca.
Hai già provato !
Dalle prove che ho fatto, alcuni sistemi UNIX cambiano correttamente la data da 1999 a 2000 ma al
31.12.2000 vanno in bug poiché la data diventa 1.1.2010.
Inoltre alcuni sistemi vecchi (Xenix e Unix 3.2.4.2. di SCO) non consentono, con le utility standard
di gestire la data 2000. Asktime per esempio se gli digiti 01.01.2000 ti spara in ritorno 01.01.80.
Sono comunque disponibili sul sito di sco delle bug.fix che risolvono il problema

mc6491@_
sonoqui_mclink.it
 wrote:
 >Seriamente, affermazioni del tipo "Io uso unix, quindi la cosa non mi
 >tocca." non le capisco.
 >Certamente il sistema operativo (se recente) non avrà problemi, gli
 >applicativi forse si.....
Gli applicativi usano anche loro un long per immagazzinare la data.
Chi avra` problemi sono i DBA, ma non e` il mio lavoro. :-)


Chi avra` problemi sono i DBA, ma non e` il mio lavoro. :-)
Si era capito.
Saluti