Newsgroup: it.lavoro.informatica
Titolo: Cultura informatica

http://www.webnews.it/2014/11/12/cobol/
 
-- 
Non mi fido di una cosa che sanguina per cinque giorni e non muore.
( Mr. Garrison )

 
http://www.webnews.it/2014/11/12/cobol/
 
 
"ISO/IEC 1989:2014 è oggi quella che da più parti viene battezzata come la
versione definitiva di COBOL, l’ultima, quella che ne sigilla le regole in
qualità di lingua morta."
 
Dice che *E'* una lingua morta. Di che si sta parlando quindi?!
 
 


Bah, dire tutto e il contrario di tutto. Nell'articolo si afferma:
"COBOL 2002 è uno standard riconosciuto e registrato come ISO/IEC 1989:2002. Tuttavia una nuova versione ha visto la luce da breve: ISO/IEC 1989:2014 è oggi quella che da più parti viene battezzata come la versione definitiva di COBOL, l'ultima, quella che ne sigilla le regole in qualità di lingua morta. COBOL 2014, potenzialmente l'ultimo, la tappa che ne chiude il percorso."
E ancora:
"Secondo analisti Forrester COBOL non morirà prima della decade 2020/2030"
Decade che inizia tra 5 anni, faccio notare.
Poi, più avanti:
"La reintroduzione di COBOL nel mondo accademico andrebbe dunque incentivata: ad auspicarlo è Giuseppe Gigante, Regional Marketing Manager di Micro Focus: 
'La risposta al gap delle conoscenze deve iniziare dai banchi di scuola. Le aziende e le università devono lavorare insieme per dimostrare che conoscere il COBOL è importante ed è essenziale per avere un futuro più promettente.'..."
 
No, momento: parliamo di uno strumento che morirà tra il 2020 e il 2030, e mi si viene a parlare di futuro promettente?
Mi sa che resto dalla parte di Python, va.
 
PS. E' normale quello sbrodolamento per scrivere 'Hello World'???
perché, in Python: print('Hello, world')
 
-- 
Ciao!
Luca

 
http://www.webnews.it/2014/11/12/cobol/
 
 
 
Dall'articolo:
COBOL è un linguaggio di programmazione noto anche per la sua grande 
stabilità tanto che, per esempio, gli applicativi scritti in passato 
hanno permesso di evitare il pericolo del temibile Millennium Bug che 
aveva minacciato tutte le infrastrutture digitali del mondo.
 
 
 
Una falsità clamorosa
Ne piu ne ne meno come in qualsiasi linguaggio
Il Millennium bug era dovuto che una data era scritta con l'anno di 2 
cifre invece che 4.
Si puo affermare che i sw scritti in COBOL erano buggati dall'inizio,una 
specie di bomba a tempo.
Naturalmente questo poteva succedere in qualunque linguaggio di 
programmazione quindi il COBOL non ha nessun merito su questo.
 
 
 


Non e' esatto. Nella classe java.util.Date l'anno non e' scritto ne' a 2 
ne' a 4 cifre. Sebbene abbia egualmente i suoi limiti, potendo esprimere 
un range di date intorno ai 300 mila anni.
 

 ne' a 4 cifre. 
 
In effetti non era manco un problema di linguaggio; il problema derivava dal come l'anno veniva scritto nelle basi dati e da come questi numero veniva interpretato. Si trattava di un problema di progettazione, insomma, non di altro.
Peraltro, dato che c'ero, ricordo che ci furono molti meno problemi di quelli che erano stati pacventati.
 
-- 
Ciao!
Luca.
 


Senza una classe date,ovviamente
Paragonando a COBOL e' come il programmatore avesse scritto lui una 
classe date
E poiche a quei tempi lo spazio in memoria era importante ecco l'anno a 
2 cifre.
Potevano ovviamente fare come unix,numero di secondi a partire da un 
epoch time,per risparmiare spazio ma poi dovevano fare le corrispettive 
routine di conversione e calcolo.
 
 


bravo! Chi lavorava sui mini, S/34 S/36 usavano le date in formato 
giuliano 5 cifre aaggg che poi lo impaccavano e portavano via solo 3 
byte. Sui mainframe 360 e 370 e successivi invece si usavano le 6 cifre 
aammgg senza packed, avevamo piu risorse a disposizione



ogni anno ha 365 gg (bisestili a parte)
quindi per conteggiare 50 anni e anche piu bastavano due byte (un 
unsigned short) se proprio si voleva risparmiare spazio a piu non posso.
La contropartita sono le routine di conversione 
(visualizzazioni,calcoli,ecc..)
 

 Si trattava di un problema di progettazione, insomma, non di altro.
Diciamo che il linguaggio aveva le sue belle colpe. In COBOL, ad 
esempio, il tipo Date non esiste, in RPG esiste nelle versioni piu' 
recenti ma i programmatori (non tutti ovviamente) si ostinano ancor oggi 
ad utilizzare un campo numerico, e quello scrivono sul db. Mentre nelle 
basi dati anche piu' datate, i tipi DATE TIME e TIMESTAMP esistono da 
tempo immemorabile.
 

 aammgg senza packed, avevamo piu risorse a disposizione
E questa sarebbe una figata?
Su S/34 e S/36 non c'era un db relazionale, con i relativi tipi DATE 
TIME e TIMESTAMP, ma sul mainframe il DB2 c'era (almeno ai tempi del 
S/36), ma ovviamente in cobol tipi DATE, TIME e TIMESTAMP non ci sono 
neanche oggi, per cui beccati aammgg.

 tipi DATE TIME e TIMESTAMP, ma sul mainframe il DB2 c'era
 
molti , anzi quasi tutti, non li usavano perchè preferivano usare un 
integer e ficcarci dentro la data numerica es: 20151220, questo per 
evitare routine di conversione in sql( tipo To_date etc etc) ma facevano 
le query direttamente col valore numerico specialmente le multinazionali 
che in questo modo evitavano problemi di geolocalizzazazione nel 
passaggio dati.
Comunque sul ManiFrame il BD2 è arrivato quasi a meta della serie 43XX
i primi 43XX usavano il DL/1 un DB gerarchico che usava cataloghi vsam, 
da li sono partiti poi per fare il DB2.


 due byte (un unsigned short)
 
non esiste...1 byte 1 carattere ! punto.



 
 
con un byte fai 256 gg,potrebbero essere (e di solito lo sono) insufficienti
 


Nulla vietava di costruirsi delle routine decenti per manipolare delle 
date e tempi.
Ma non l'hanno fatto ed il bug e' venuto fuori.
 


sai leggere? 1 byte 1 carattere
ovvero 6 byte 6 caratteri



 
nel mondo cobol sarà cosi (1 byte =>  1 char) ,nel mondo moderno non è 
detto che sia cosi.
Ma qui erano in ballo le date,che c'entrano i caratteri ?
 
 

 Ma non l'hanno fatto ed il bug e' venuto fuori.
 
Ma guarda che il cosiddetto bug non era mica prerogativa dei mainframe e Cobol, la prassi di usare l'anno di 2 caratteri era molto diffusa.
Impaccare una data trasformandola in progressivo di giorni/secondi od altro si poteva certamente fare, ma per esempio rendeva illeggibile un dump diretto di un file (e non parlo di db, il DB2 sui mainframe è comparso con una certa diffusione alla metà degli 80, ma all'epoca aveva pure numerosi difetti e non era necessariamente preferibile solo perchè aveva i tipi).  
Mi pare di ricordare che perfino alcuni Bios avevanol'anno a 2 cifre, altro che Cobol... :-)


Ma infatti. Il bug, secondo il mio modo di vedere, era legato 
soprattutto alle applicazioni. Anche un'applicazione java che non avesse 
fatto un uso corretto delle date era suscettibile del bug. Di riflesso 
anche tutte le applicazioni che facevano riferimento alla data di 
sistema prodotta da un bios, o da un kernel, bacati.

 sistema prodotta da un bios, o da un kernel, bacati.
 
Vero, un Bios con l'anno di 2 cifre scassava potenzialmente sia il s.o. sia qualunque programma ci girasse dentro, che avesse o meno il tipo data. 
Poi, continuando a parlare  del Cobol e del tipo data, non mi risulta che il C ce l'abbia (come tanti altri tipi). Eppure il Cobol è brutto e cattivo, invece il C è una perla di linguaggio... :-)


Certamente
Quello del COBOL è il caso piu eclatante ma non l'unico.
La leggibilità deve permettere bugs ?
La pigrizia per la leggibilità si.
 


Il C ha la lib std per trattare date e tempi.
Comunque anche unix/linux  32 bit ha il suo bug sui tempi attorno al 2030.
Hanno tempo per rimediare,magari passando ad un 64 bit