Newsgroup: it.lavoro.informatica
Titolo: Re: Cobol ?

 'switch' statement ;-)
lo stipendio di un programmatore COBOL e' 35,000 volte piu' alto

> If you are the COBOL programmer what would your answer be?
Io non sono un COBOL programmer, ma qualche opinione me la sono
fatta :
- In cobol non c'è da creare fantasiose infrastrutture a n livelli
comunicanti con stravaganti protocolli : quindi ci si concentra sui
dati, non sulla fuffa.
- In cobol ci sono poche cose semplici, e questo è il modo più giusto
di lavorare nei gestionali.
- Il cobol gira sui mainframe, molto molto vicino al DB, e quello è il
posto giusto dove lavorare.
- Il cobol è procedurale, ed è un bene, perchè nonostante tutti i
fanatici non tutto è un'oggetto e non servono astrazioni quando si
lavorano movimenti di conto corrente.
....

 lavorano movimenti di conto corrente.
Permettimi un'analogia: parte della strada che il sistema economico
Repubblica Italiana ha perso dagli anni 80 ad oggi nei confronti dei
paesi Europei simili, a.e. Germania, Francia e Regno Unito e Spagna, è
dovuta all'abbandono del nucleare, ed al conseguente differenziale di
costo dell'energia che i cittadini e le imprese Italiane hanno dovuto
pagare in più rispetto ai cittadini di quegli altri paesi.
Di per se, abbandonare il nucleare tout court non era un errore, lo è
diventato, economicamente parlando soprattutto per la mia generazione,
nel momento in cui non si è riusciti a sostituirlo con qualcosa di
meglio. Ovviamente ci sono tanti altri sprechi ed inefficienze che
curate avrebbero potuto controbilanciare il maggior costo
dell'energia, ma questo non è il nocciolo dell'osservazione che sto
cercando di fare.
Se la Repubblica Italiana avesse però trovato una fonte di
approvvigionamento di energia a minor costo, gli altri si sarebbero
dovuti adeguare.
Come le imprese, anche gli Stati interagiscono tra di loro, si
alleano, fanno affari, si fanno la guerra, anche senza bisogno di
soldati, e quando una serie di Stati simili usa una certa tecnologia,
sia questa il nucleare che il COBOL, c'è sempre un rischio molto
grosso ad abbandonarla per primi, ma c'è al contempo un rischio
simile, se non più grave, ad abbandonarla per ultimi.
Tu parli di conti correnti, e se pur per assurdo avessi ragione, e
cioè che la programmazione procedurale meglio si adattasse alla
gestione degli stessi rispetto alla programmazione ad oggetti, questo
rappresenterebbe una minima parte di quello che le banche moderne
gestiscono tramite l'informatica al giorno d'oggi, e ti garantisco,
perchè lo vivo quotidianamente sulla mia pelle, che per fare
determinate cose l'approccio procedurale non solo non basta, ma
garantirebbe un netto svantaggio rispetto ai concorrenti che
adottassero un approccio ad oggetti. In cosa si trasformerebbe questo
svantaggio?
BTW, il fatto che molte banche ed assicurazioni Italiane ancora usino
COBOL, è dovuto più al fatto che il mercato Italiano sia
sostanzialmente un mercato chiuso che ad un qualche vantaggio
intrinseco del COBOL. In altri mercati, dove la concorrenza è
maggiore, e dove il vantaggio di usare altre tecnologie è più
evidente, di COBOL se ne vede in giro molto meno.
--
ale
http://ale.riolo.co.uk

filippo ha scritto:

magari lo stipendio fosse 35 volte pi� alto.
sono analista programmatore e per un decennio ho lavorato in COBOL (ho 
32 anni) e ti posso garantire che gli stipendi sono al pari di java o 
altri, fa poca differenza.
il fatto sta che per assurdo di giovani che lo conoscono ce ne sono 
pochi, alch� farebbe pensare che poich� c'� scarsit� di personale 
qualificato (e quello qualificato � avanti con l'et� o siamo in pochi), 
si dovrebbe avere un miglior trattamento economico, MA, si perch� c'� un 
MA, non solo � diminuito il personale, ma anche i lavori in COBOL, 
quindi per assurdo si ha un bilanciamento tra domanda e offerta.
CIAO

 lavorano movimenti di conto corrente.
qui dici una spettacolare cazzata, perche' un conto corrente e' un
astrazione, e un movimento pure.
Ti prego, non entriamo nel territorio del procedurale vs ad oggetti.
E' una fatto chiaro da tempo che al di la delle guerre di religione
luna struttura ad oggetti facilita  crescita delle dimensioni del
programma, leggibilita', estendibilita' e facilita' di manutenzione.
La realta' e' che il cobol e' ancora popolare perche' esistono
zillionate di righe di codice di importanza fondamentale, che sarebbe
o troppo costoso riscrivere da zero o troppo rischioso. (ho visto
banche in cui si era persa completamente la conoscenza di cosa facesse
parte del codice in cobol perche' non esisteva documentazione adeguata
e gli autori del codice erano pensionati da eoni...)

 
http://ale.riolo.co.uk
il COBOL non ha vantaggi, al pi� a grosse limitazione dettate dalla sua 
et� e ambito di utilizzo.
questo per� non vuol dire che sviluppando in altre tecnologie sia 
migliore e che le nostre banche/assicurazioni/PA siano chiuse (falso dal 
momento in cui viviamo in un mondo globalizzato e restarne fuori signifa 
morire), il cobol si tiene (non solo in italia, ma anche in svizzera 
(BSI = cobol/db2 o Natural/adabas) , UK (PA) , USA (diverse banche e 
assicurazioni), questi sono esempi perche conosco gente che attualmente 
ci lavora) per la sua velocit� e semplicit�, perch� ci sono miliardi di 
linee di codice scritto e che funziona, � in simbiosi con i MAINFRAME 
(ricordo che a tutt'oggi � la maggiore infrastruttura per banche e 
assicurazioni), ma sopratutto con il cobol si manipolano dati con una 
semplicit� che altri Ambienti/linguaggi si sognano, non hai necessit� di 
crearti librerie, strati di software, strati di application server o 
altro per accedere e manipolare dati.
ho visto un programma che doveva estrarre dati( 7-8 tabelle) e creare un 
report, scritto in un ambiente J2EE, mbe c'era Tomcat, struts, hibernate 
e un tool per la gestione del report, lo stesso in cobol (era gia 
presente ma stavano convertendo il tutto) un singolo programma di circa 
1500 linee di codice, STOP.
Ciao


IMVVHO
1) programmi scritti male ne son sempre esistiti, in cobol e non...
in ambiente windows e non...
2) che poi oggi sia di moda parlare di oggetti (????), di java, Tomcat, 
struts,
hibernate, tricche e ballacche ....non vi sbagliate ... e' solo per VENDERE.
Ovvero se ti piazzo 20 aggeggi anziche' un solo compilatore cobol...ho 
sicuramente
molto piu' business fra manutenzioni, aggiornamenti e sostituzioni....idem 
per l'hardware.
Fra l'altro ti posso anche mandare una processione di 20 tecnici,
 ciascuno dei quali specializzato in UNO SOLO dei suddetti ammennicoli.
In USA c'erano negli anni 90 societ� di manutenzione che rifiutavano la 
manutenzione sui midrange Ibm,
 preferendo i server windows perche' piu' redditizi.
3) se ti affidi a delle teste di quiz (vale per ogni contesto non solo per 
l'informatica)
e' garantito che ti succhieranno un bel po' di soldi, e avrai un risultato 
modesto o nullo, anche se a parole
manderebbero avanti un mulino a vento.
Nota bene: i tecnicismi come java, xml, struts, hibernate...etc etc esistono 
pari pari in ambito midrange e
mainframe, vengono usati esattamente come sopra, per lasciare gli allocchi a 
bocca aperta.
4) il cobol e' un linguaggio primitivo, decisamente troppo prolisso: si 
ottengono gli stessi risultati che in altri linguaggi con un tempo di 
stesura molto superiore.
Ciononostante sono in uso centinaia di applicazioni scritte in 
cobol.....magari con le stampe gestite internamente ai programmi tramite le 
istruzioni PIC !!!!
Permette di differenziarsi dalla melma dei pc...perche' spesso viene usato 
in grandi aziende, il che significa  hardware, sistema operativo e database 
relativamente stabili ed affidabili.
ciao
fm

programma, leggibilita', estendibilita' e facilita' di manutenzione.
Parere tuo, che comprendo ma NON condivido.
Gli "oggetti" non sono altro che una delle tante trovate del marketting...
Quella del "millennium bug", ad esempio,  e' stata stupenda...:-)
ciao
fm 

 simile, se non più grave, ad abbandonarla per ultimi.
Qualcuno usa l'object oriented COBOL...potrebbe essere divertente.
BTW, ricordo una lezione del mio professore di ing. del software in
cui disse che al mondo il 90% del codice e' scritto in cobol, il 9.9%
in fortran e il restante in c/c++. Era il '98 i il '99.
Conoscete le percentuali odierne?


A parte il millenium bug, l'aviaria e al qaeda...
Il paradigma ad oggetti non se lo sono inventati i commerciali tutti
lampada e sole24ore. Prima di arrivare sul "mercato" e' passato per i
cervelli di un po' di persone.
I vantaggi sono quelli che ha scritto riccardo, e c'e' tutta una serie
di processi software che lo supportano.
Fosse stata una cosa di marketing avrebbe fatto la fine dei database a
oggetti:)

 Gli "oggetti" non sono altro che una delle tante trovate del marketting...
refuso-lapsus
--
FabMind

Conoscete le percentuali odierne?
la tabella esiste, e' sul sito web di una societ� lider, ma il sito e' 
sub-sub-sub-sub-sub-sub-subappaltato ad una piccolissima azienda che lo ha 
affidato ad un bimbominka per 2,99 euro al trimestre (contributi e tasse 
inclusi).
Quindi... tutte le volte che si cerca di leggere la tabella  d� errore..:-)
ciao
fm 


secondo me e' una parola che meglio descrive il concetto....
un po' come quando scrivo "assinculazioni"...
ciao
fm

 Quindi... tutte le volte che si cerca di leggere la tabella  dà errore..:-)
Per la situazione italiana ho trovato questo che ha qualche dato piu'
o meno recente: 
http://www.cnipa.gov.it/site/_contentfiles/01377400/1377499_CNIPA_QUAD_1.pdf
Ad ogni modo, spulciando qualche articolo che riportano qualche
numero, sembra che il cobol sia duro a morire.

 COBOL, è dovuto più al fatto che il mercato Italiano sia
Guarda che è ampiamente usato anche fuori d'Italia.
Comunque i problemi con il Cobol sono due: uno non c'entra nulla con
il linguaggio in sè, ma con la difficoltà di reingegnerizzare con
successo procedure vitali scritte in tale linguaggio (e secondo me si
presenterà pari pari tra 20 anni per reingegnerizzare da Java a
qualcos'altro...); il secondo è relativo alla limitatezza del supporto
"nativo" di linguaggi più moderni rispetto alle operazioni tipiche in
cui si usa il Cobol (Es: elaborazioni puramente batch; produzione di
semplici stampe; ecc.).

 un po' come quando scrivo "assinculazioni"...
qua non mi esprimo per conflitto d'interessi...
--
FabMind

 altro per accedere e manipolare dati.
Il fatto degli strati non è strettamente vero. Puoi sempre creare un
programma Java che ha un'unico metodo con dentro tutta l'elaborazione.
Certo alla fine è un aborto, il peggio del procedurale con il peggio
dell'OO.... :-)

 istruzioni PIC !!!!
Nelle stampe formattate/incolonnate è molto efficiente. Prova a farlo
con i template XLST, come i miei poveri colleghi Java.... :-)
Riguardo alla primitività, non sono d'accordo. La versione più
recente, ANSI 85, è alla pari con altri linguaggi procedurali, come il
Pascal.
Se poi vuoi a tutti i costi l'OO, ci sono anche le versioni OO di
Cobol (Fujtsu, forse Microfocus). A quel punto che je poi dì??? :-)



ok, però poi quando non si riesce ad avere un servizio su internet e si è 
costretti ad andare dall'operatore di sportello per ogni sciocchezza 
ricordiamoci di aver detto una volta che "non ci si concentra su fuffa e 
stravaganti protocolli" e "questo è il modo più giusto di lavorare nei 
gestionali".

 Conoscete le percentuali odierne?
Nel '98/'99  già vivevamo immersi da un bel pò in apparecchiature
embedded il cui codice era (ed è) scritto in C e assembler, senza
considerare VB che era usatissimo in una miriade di ambiti...bah!


Pare che informatica sia nata un po' prima del '99...
Un link di riferimento e' 
http://www.legacyj.com/cobol/FutureOfCobol.pdf
Cmq. nel 2003 il 65% del sw era in Cobol e le applicazioni in Cobol
gestivano oltre l'80% delle transazioni giornaliere (daily business
transactions)
Eliminare una tale mole di sw legacy ha dei costi enormi: perche' mai
una banca dovrebbe "sostituire" un'applicazione Cobol (collaudata e
sicura) con una Java/.Net, magari andando incontro ad n-mila problemi
di sicurezza? Solo per il gusto di usare una cutting-edge technology
(tanto per citare un precedente post su ili)? L'applicazione resta li'
as-is. Al piu' gli si mette una interfaccia Web

 oggetti:)
azz meno male che c'e' qualcuno che capisce qualcosa di storia
struttura ed evoluzione della programmazione.. stavo cominciando a
preoccuparmi seriamente...

 Quella del "millennium bug", ad esempio,  e' stata stupenda...:-)
ti prego.. dimmi che non sei un programmatore...


IMHO
Guarda che quasi sempre se non riesci ad avere un servizio su internet e' 
proprio
perche' l'utente di internet non accede alle applicazioni bancarie "core" 
( su mainfraime e scritte in cobol).
L'utente di internet lo fanno accedere alla fuffa  sopra descritta ...
soldi soldi soldi per avere poco e quel poco mal funzionante ...
All'utente finale conveniva il Cobol.
ciao
fm 

 transactions)
Sì ma di CHE software? E che peso si da a una linea di codice custom e una 
di codice "industriale"? Voglio dire, ha lo stesso valore una linea di 
codice Cobol fatta per l'applicazione X che usa solo la banca Z e una linea 
di codice C++ di Windows XP che usano milioni di persone (giusto per fare un 
esempio famoso)? Secondo me, assolutamente no, almeno dal punto di vista 
dell'importanza/diffusione del linguaggio. Dal punto di vista della 
manodopera necessaria alla manutenzione, può darsi, anche se software 
vetusto e con pochi campi d'applicazione tende ad avere meno bug e meno 
bisogno di manutenzione.
-- 
Vide

 bisogno di manutenzione.
E' un paragone inappropriato. Cobol, molto più di C++, è nato per
compiti ben precisi, e lì funziona bene.

 esempio famoso)?
Beh, magari da quella linea di codice COBOL dipendono i conti in banca di
un milione di persone!

 All'utente finale conveniva il Cobol.
ribadisco, al momento in cui ci si lamenta che si può fare poco (e male) o 
niente self-service su internet ricordiamoci di quel giorno che l'abbiamo 
chiamata "fuffa".
tutto qua.

 wrote:

http://www.tiobe.com/content/paperinfo/tpci/index.html
è molto interessante ogni tanto lo consulto

 wrote:

E' un approccio che non comprendo. Semplifichiamo la questione
1) Cobol nasce 50 anni fa, nonostante le migliorie introdotte resta
sempre inferiore ai linguaggi di ultima generazione. E su questo non
ci piove. Se dovessi scrivere un'applicazione ex-novo difficilmente
penserei al Cobol come "prima" scelta.
2) Questo non significa che il linguaggio sia da "buttare" o
soprattutto che le applicazioni ancora esistenti e scritte in Cobol
siano da buttare. Sostituire un'applicazione (qualsiasi scritta anche
in fortran) con un'altra che garantisca le stesse funzionalita' (in
qualsiasi linguaggio) costa tanto, come sviluppo, come collaudo, come
"pezzi" che si perdono quando la riscrivi, come nuovi errori
introdotti.
3) Per quanto riguarda il discorso CHE software, se e' vero (e
possiamo prenderlo per buono) che l'80% delle transazioni business
giornaliere di TUTTO IL MONDO sono gestite dal COBOL, direi che l'80%
delle transazioni valgono di piu' di Windows....ma non e' su questo
che puoi dire che un linguaggio e' migliore di un'altro


IMHO ribadisco che  pc = serverini = programmini = informatichini 
quacquaracqua = fuffa
W mainframe + cobol
ciao
fm


In cobol, nel precedente cliente, noi scrivevamo web-services, la
struttura era pressapoco :
WEB -(una mezza specie di transport layer) con XML - COBOL.
lato client ->browser (IE purtroppo)
lato server frontend -> Java -> chiamate in webserver (websphere +
CICS) -> che chiamava web-services COBOL batch che richiamava altri
programmi in cobol (che gia esistevano e che funzionano, i quali si
occupava del core delle operazioni, quest'ultima era l'architettura
intera), passandosi come dati XML.
praticamente hanno rifatto il frontend in web, ma il "core" è rimasto
uguale senza neanche una virgola di cambiamenti.
Ricordati che forse quando fai operazione sul tuo e-banking, stai
utilizzando il vetusto cobol per gestire il tuo conto corrente.
certamente il cobol non nasce per internet, ma per la pura
manipolazione dei dati, quindi niente protocolli o gestione embedded
ecc, ma penso (aime, ne sono uscito ma ...) che si parlerà di cobol
ancora mooolto a lungo.
Ciao

 dell'OO.... :-)
Tra i milioni di righe di codice della suite di applicazioni su cui
lavoro, abbiamo una libreria in Java scritta da un indiano in offshore
una decina di anni fa che è esattamente quella che descrivi (3823
righe una dietro l'altra, viene la vertigine solo a guardarla). Non fa
nulla di particolarmente centrale, anzi dubito che il 99.999% degli
utenti ci avrà mai a che fare, ed il resto è contento così com'è, per
cui manca l'incentivo a metterla a posto seriamente, ma ogni volta che
bisogna metterci mano c'è il fuggi fuggi.
L'ultima volta hanno chiesto a me di fare la code review, ho chiesto
venissero aggiunti degli unit test, se non altro per testare la
modifica che stavo esaminando, per cui ora abbiamo 30 righe di codice
di unit test per quella cosa ..
Fortunatamente, almeno qui, è un'eccezione, gran parte del codice è
ben scritto e ben pensato, ma immagino come dev'essere lavorare in
ambienti dove gran parte del codice è scritto in quella maniera ..
--
ale
http://ale.riolo.co.uk

 è molto interessante ogni tanto lo consulto
Il contenuto di quella pagina è molto più in linea con quella che è la
mia comprensione della diffusione dei vari linguaggi al giorno d'oggi
rispetto ad altre opinioni espresse nel thread.
--
ale
http://ale.riolo.co.uk

 fm
non vedo faccine, ma spero che scherzi e che non stai facendo il
talebano del cobol,
adesso dire che i programmatori che non lavorano su mainframe siano
fuffa è una stupidaggine.
io sono e rimarrò cobol (quasi un decennio di esperienza) ma dico la
verità, ne sono fuggito,
come linguaggio (tecnicamente parlando) è la morte celebrale.
quando ho incominciato a vedere altre tecnologie, mi sono sembrato un
uomo delle caverne.
è come se fuori ci fossero gli accendini e io fino a quel momento
avessi usato bastoni e pietre focaie.
Ciao

 W mainframe + cobol
va beh queste sono boutade infantili alla luc.

avessi usato bastoni e pietre focaie.
mah...se io dovessi scaldarmi ad fuoco, pena la morte per assideramento, per 
accederlo
preferirei bastoni e pietre focaie piuttosto che ... hardware cinese e 
software di melma scritto dai guga-guga di Ducalambertiana memoria...:-)
con la pietra focaia ci fai un bel falo'.....con l'altra roba clicchi su 
"fiamma" e ti esce un "server error"... se addirittura
non si pianta senza dare alcun errore.
Mi e' capitato alcuni giorni fa, con un'applicazione bancaria. Veramente 
stomachevole.
E poi ci si lamenta che il settore IT va male...
Ciao
fm 

 stomachevole.
Ma con la pietra focaia potresti pure stare tre giorni a fare scintille
tentando di accendere il fuoco senza mai riuscirci e morire prima di 
freddo...
Il problema non � l'accendino, ma chi lo costruisce a minchia!
Ai tempi ho visto fare fior di bestialit� pure con il cobol, se � in
mano ad un imbecille...

 E poi ci si lamenta che il settore IT va male...
e se ne ha ben donde. se gli addetti sono ancora saldamente aggrappati 
alle pietre focaie, spiegami te quanto freddo dovranno ancora patire gli 
utenti italiani prima di avere uno straccio di impianto di riscaldamento.

 gestionali".
Io lavoro prevalentemente in .net, ovviamente scritto OO. Questo non
mi impedisce di denunciare quanto sia ridicolo passare tra 4 strati
per leggere un dato.
Attenzione non dico che il COBOL è migliore come linguaggio, ma solo
che con quel poco che ti da non fa venire in mente a nessuno di
inventarsi l'astrazione del servizio a oggetti parametrizzato con
regular expression.  Che poi è uno dei motivi principali dei mille
progetti fallimentari degli ultimi anni.


Non paragoniamo mele con  pere.
La qualita' complessiva percepita di un impianto di riscaldamento e' molto 
superiore
dei quella di un'installazione di prodotti informatici.
Forse perche' non ci sono guga-guga e venditori di fuffa?
ciao
fm

 Non paragoniamo mele con  pere.
ecco, allora torna a sbattere le pietre focaie, stando attento a non 
stiacciarti i diti (perchï¿œ ci sta anche quello).
-- 
++ questo messaggio ï¿œ scritto in forma ridotta per venire incontro alle 
vostre capacitï¿œ mentali
http://www.elogiclab.net/blog/
http://www.flickr.com/photos/marko_po/

 Forse perche' non ci sono guga-guga e venditori di fuffa?
Certo. Come il tale che, dopo aver fatto un impianto, invece di pensare
che c'era probabilmente un vaso di espansione andato, mi ha montato una
valvola di sfiato a 7 ATM (mediamente ci va a 3, con l'impianto che
gira a 1/1,5 ATM).
Credi, la quantita di fuffa e distribuita uniformemene, non e
disomogenea per settore.
-- 
Ciao!
Luca

 per leggere un dato.
non vi � dubbio che .net e (in maggior misura) java siano maestri nella 
sovraingegnerizzazione, ma questo non toglie il succo della questione e 
cio� che cobol � *totalmente* inadatto a rispondere ad una serie di 
domande basilari (e non da oggi).
oppure ritieni il dato che va da una maschera di emulazione terminale 
vt100 a un file sequenziale e viceversa sia tutto quello che serve?
e se vogliamo essere precisi io i peggiori accrocchi (nel vero senso del 
termine) li ho visti laddove si � voluto mantenere il sistema cobol, 
integrandolo (oddio, "integrare" � una parola grossa...) con il resto 
del mondo evoluto.
-- 
++ questo messaggio � scritto in forma ridotta per venire incontro alle 
vostre capacit� mentali
http://www.elogiclab.net/blog/
http://www.flickr.com/photos/marko_po/

 vt100 a un file sequenziale e viceversa sia tutto quello che serve?
Ovviamente no, però per contro, potremmo parlare dell'xml che
(utilissimo in certe situazioni)  è assolutamente inadatto a
sostituire i file sequenziali per grosse moli di dati  (adesso viene
addirittura sostituito dall'json in ajax ).
Ora, quanto ci vuole a processare un file piatto in COBOL e in java ?
E come evitare che il primo scienziato che gira in azienda non passi 2
mesi a costruire il framework di import export flussi generico in java
(parametrizzato sempre con regex) che poi alla fine non funziona ?

 (parametrizzato sempre con regex) che poi alla fine non funziona ?
non ho capito cosa hai contro le espressioni regolari e che ci 
azzeccano, comunque non ho capito neanche tanto bene il resto domanda. 
quanto ci vuole a processare un file cobol in java? sicuramente troppo 
rispetto a qualsiasi base dati che mette a disposizione un query language.
ma il punto non � accedere ai dati che volendo in qualche modo si fa. il 
problema sono tutti i programmi cobol che vantano una robustezza 
invidiabile ma questa robustezza � dovuta ad una architettura 
assolutamente elementare, talmente elementare che per scrivere un 
programma cobol di cultura informatica ne serve praticamente zero.
appena per� nasce una piccola esigenza in pi� il cobol alza le mani, non 
si pu� fare. e qui son cazzi perch� i programmi vanno rifatti, non solo 
ma lo stesso programmatore cobol che ha fatto la maschera in una 
giornata impiega una settimana per fare un troiaio che non sta in piedi 
neanche coi fili. da qui tutta la leggenda del cobol e l'atteggiamento 
da "volpe con l'uva" nei confronti di tutto il resto apostrofato come fuffa.



Mi spiace ma non sono d'accordo.
Difficile trovare aziende o figure professionali con l'immagine cosi' 
squalificata come quella di chi lavora nell'IT.
Un vecchio adagio diceva: "Non mettete la merda nel ventilatore"
Beh, nel nostro settore e' stato fatto ...
ciao
fm

 squalificata come quella di chi lavora nell'IT.
indubbiamente, essendo un addetto it hai tutto il diritto di esprimerti 
in questi termini sul tuo lavoro.
-- 
++ questo messaggio ï¿œ scritto in forma ridotta per venire incontro alle 
vostre capacitï¿œ mentali
http://www.elogiclab.net/blog/
http://www.flickr.com/photos/marko_po/

 fm
Andrea

 fili.
Questo puo' succedere in qualunque ambiente.
Non vedo cosa c'enta il cobol , visto che si sono moltissime  applicazioni 
Cobol in funzione
da vent'anni e continuamente aggiornate.
ciao
fm

 altri ...
fammi un esempio pratico per favore, perchï¿œ non hai idea nel 2009 quanto 
sia grande e variegato il mucchio nel quale stai sparando...
-- 
++ questo messaggio ï¿œ scritto in forma ridotta per venire incontro alle 
vostre capacitï¿œ mentali
http://www.elogiclab.net/blog/
http://www.flickr.com/photos/marko_po/


Un esempio a caso:
Applicazione bancaria:  la GandeBanca A viene acquisita da GrandissimaBanca 
B,
*Promettono* (anche su internet, sul sito ufficiale) che dal giorno x di 
luglio tutto i servizi alla clientela di A
saranno pienamente disponibili grazie al sistema informatico di B.
Qualcuno ci ha creduto? io no...
Infatti, dal giorno x di luglio caos totale, non solo per le aziende ma 
anche per i numerosissimi clienti privati.
Caos totale cosa significa? mi spiego meglio:
1) non e' possibile conoscere i saldi dei conti
2) non e' possibile effettuare con certezza i bonifici a fornitori (richiama 
la banca dicendo che non ci sono i fondi, seguono proteste, richiamano dopo 
protesta dicendo che i soldi ci sono)
4) non si vedono gli insoluti
5) non si vedono i bonifici
3) non e' possibile effettuare certe operazioni sul "vecchio" home-banking 
di A, mentre altre operazioni non possono essere
eseguite sul nuovo 'home banking di B, certe operazioni non sono possibili 
ne' sull'uno ne' sull'altro
4) l'assistenza TECNICA brancola nel buio piu' completo, risposte vaghe: 
richiameremo, vedremo, forse non si puo' fare...
5) etc etc
Ad oltre 2 settimane dal giorno x non tutti i problemi sono ancora risolti.
Faccio rispettosamente notare che si tratta di *banche*... non della Pippo 
Pesce snc che ha un pc con win98
Se non e' fuffa questa...
ciao
fm
 

 Se non e' fuffa questa...
non ho capito, stai dicendo che il sistema informatico della banca "b" ï¿œ 
fuffa? ma non lo usava giï¿œ? io in questa vicenda ci vedo semplicemente 
un passaggio di sistema che poteva (o meglio doveva) essere gestito 
meglio, storia giï¿œ vista e rivista (compresi i toni ostili e le remate 
contro)


 l'antagonista del file sequenziale è la base dati.
Mi sa che non ci siamo capiti, una importante parte dell'informatica
gestionale è lo scambio di dati tra sistemi eterogenei, clienti,
fornitori, agenzia delle entrate, poste e chi più ne ha più ne metta.
Questo scambio si realizza quasi sempre con file piatti, flat file,
file di testo posizionali, chiamali come vuoi...

 fuffa? ma non lo usava gi�? io in questa vicenda ci vedo semplicemente
CUT
io ci vedo semplicemente l'opera combinata di venditori di fuffa e 
guga-guga.
Non c'e' maggior sordo di chi non vuol sentire.
ciao
fm

 l'antagonista del file sequenziale � la base dati.
Mi sa che non ci siamo capiti
CUT
capita spesso.
I guga-guga non ti possono capire perche' hanno la testa piena di
sql select, lunghe 63948 caratteri,  che non funzionano...
mentre i venditori di fuffa non ti possono capire perche' sono troppo
impegnati a preparare la vasellina per te.
ciao
fm

 Non c'e' maggior sordo di chi non vuol sentire.
io sarï¿œ sordo, ma a parte gli sfoghi pittoreschi e scomposti non leggo 
risposte alle questioni che ho posto all'inizio.
ora te lo faccio io un esempio. per rimanere in ambito bancario, l'home 
banking ï¿œ fuffa? lo puoi realizzare in cobol?


 impegnati a preparare la vasellina per te.
fai dei discorsi che sembri la versione rimbambita del ducalamberti, che 
giï¿œ di per se non ï¿œ che fosse un genio.
-- 
++ questo messaggio ï¿œ scritto in forma ridotta per venire incontro alle 
vostre capacitï¿œ mentali
http://www.elogiclab.net/blog/
http://www.flickr.com/photos/marko_po/

 file di testo posizionali, chiamali come vuoi...
ok, allora per riprendere la tua domanda:
"quanto ci vuole a processare un file piatto in COBOL e in java ?"
beh non sar� certo questo il problema che ti fa saltare un progetto. 
senza contare che in questi scambi dati (che fra l'altro esistono ancora 
proprio per compatibilit�) non puoi far finta che non ci siano altri 
strati, come appunto i file transfer, che con internet di mezzo non sono 
un argomento da mettere sottogamba.



vedo che quando ti pare svicoli e cambi argomento.
Quindi, o non capisci una beata mazza,  oppure sei un commerciale, forse
anche venditore di fuffa, e quindi in malafede.
Eccoti la risposta alle tue domande:
1) home banking e'  fuffa quando ti fanno spendere un fracco di soldi, ti 
promettono mari e monti,
non funziona invece quasi nulla, quando li cerchi spariscono...quando 
l'assistenza tecnica che cerchi perche' ci sono probleme sa rispondere solo 
"mah" "forse" "non saprei" "non di puo' fare".
2) IMHO si potrebbe realizzare benissimo in cobol
ciao
fm


Te invece  pensi di essere il piu  furbo di tutti ?
Sei un venditore di fuffa?
Ok, stai tranquillo, con me avresti vita dura ma di coglionazzi cui 
spacciare la tua melma  e' piena l'Italia.
ciao
fm

 un argomento da mettere sottogamba.
prendere, prendere sottogamba...

 utilizzando il vetusto cobol per gestire il tuo conto corrente.
indubbiamente, ma permettimi di dire che websphere+cics non � male come 
"castello" di infrastruttura (per rispondere a enricoe il quale 
sosteneva <cite>In cobol non c'� da creare fantasiose infrastrutture a n 
livelli comunicanti con stravaganti protocolli : quindi ci si concentra 
sui dati, non sulla fuffa</cite>)


 Sei un venditore di fuffa?
no, vendo tacchi, dadi e datteri. e anche i maltagliati.
http://www.youtube.com/watch?v=Ob5jUJde4NA


 
http://www.flickr.com/photos/marko_po/
 

 'switch' statement ;-)
il programmatore COBOL risponderebbe:
Il COBOL non ha nulla di simile da offrire, quindi continua pure ad usare 
Java
mentre io continuer� ad usare COBOL fino alla pensione e per questo sono
assunto a TI e percepisco 2400 euro netti al mese.
 

 e continui?...
no guarda, ti stavo rispondendo sull'altro ramo del thread ma poi mi son 
detto "ma che cazz..."
buon proseguimento.
-- 
++ questo messaggio ï¿œ scritto in forma ridotta per venire incontro alle 
vostre capacitï¿œ mentali
http://www.elogiclab.net/blog/
http://www.flickr.com/photos/marko_po/

 beh non sarà certo questo il problema che ti fa saltare un progetto.
A partire dal fatto che spesso queste cose "sono" il progetto nel
fantastico mondo del gestionale, se tu per far comunicare un cliente
ed un fornitore con un wf scolpito nella pietra con 5 file di testo
tiri su biztalk o filenet e un bello stratino custom scritto da
qualche fanatico della parametrizzazione vedi come riesci a farlo
diventare un progetto da mezzo milioncino di euro una cosa che si
faceva (e si fa con 50 giorni uomo).
E ripeto, il problema non è che il cobol è meglio, ma ha il
"vantaggio" di essere limitato, frenare la fantasia e far pensare ai
campi del file piuttosto che al contorno. Ovviamente è solo un
esempio, potremmo anche parlare di regole di validazione dei campi nei
form di input...


"non capisco" ...
"c'e' qualcosa che non ho capito?"
ciao
fm 

Il Mon, 10 Aug 2009 06:12:26 +0200, fm ha scritto:
[...]
cercati un amichetto con cui fare "guga-guga" insieme e scompisciarsi 
dalle risate, duca lamberti è un pezzo che non si vede (e magari davvero 
venisse a praticare un po' di eutanasia... :P)


Come se fosse antani anche per lei soltanto in due, oppure in quattro anche 
scribai che cofandina...
ciao
fm 

 banking è fuffa? lo puoi realizzare in cobol?
Posto che ci sono versioni "moderne" di Cobol con tutti gli accessori
(come il Fujtsu, OO Cobol, che gira in ambiente Net), la risposta è:
sì.
Per la cronaca, c'erano anche programmi "screen scraper" che in
pratica catturavano una schermata di programma on line Cobol e la
rielaboravano per farci qualunque cosa, tra cui l'invio su internet
come pagina html.



premesso che non mi sono mai inoltrato nello sviluppo di quel specifico 
ambito bancario, ma da utente vedo che due su due procedure di home 
banking che utilizzo hanno certamente un front-end java. ed è abbastanza 
evidente che non sono delle semplici proiezioni html di schermate.
in ogni caso non ero intervenuto per criticare i presunti o meno limiti 
del cobol, ma per ribattere a chi sosteneva tutto ciò che in un gestionale 
non è (sostanzialmente) pura gestione del dato è fuffa. "640K ought to be 
enough for anybody" ma almeno lui lo disse nel 1981 e non lo ripete nel 
2009 :-)

 evidente che non sono delle semplici proiezioni html di schermate.
Se ne sono inventate di tutti i colori. I prodotti più complessi
potevano rielaborare i dati delle schermate Cobol ottenendo pagine del
tutto differenti (che so, simulare la consultazione di 100 posizioni
sul sistema Cobol, catturare le 100 schermate e tirare fuori una lista
sintetica). Quindi non è facile capire se effettivamente
l'applicazione è totalmente a se stante, anche se ciò naturalmente è
probabile, visto che parliamo di cose di una decina di anni fa.
In realtà, disponendo di un normale programma di emulazione terminale
IBM (es. Attachmate Extra), con le sue API di programmazione, non è
molto difficile fare una cosa del genere, visto che la schermata Cobol
è puro testo su cui fare parsing. Ma si possono anche trasmettere
files binari.
A suo tempo, con questo sistema facemmo un'applicazione che partiva da
un'interrogazione su mainframe, recuperava e smistava sulla rete
mainframe un file immagine binario (TIFF), lo rileggeva su un pc
tramite le funzioni dell'emulatore terminale, ed alla fine
visualizzava l'immagine tramite un comune programma visualizzatore.
Siamo d'accordo che non è il sistema più limpido che esista, ma forse
in alcuni casi è molto più economico che riscrivere il software al
100%.

 evidente che non sono delle semplici proiezioni html di schermate.
La parte di front-end o l'elaborazione on-line è un 10-15 %
dell'attività IT di una banca o assicurazione.
Nella mia esperienza quasi decennale in cobol in ambito assicurativo,
il tempo che si dedicava allo sviluppo manutenzione del CICS (quelle
orrende schermate a caratteri che si vedevano anni fa) è veramente
poco.
considera che nel cliente dove ero prima, su una base di circa 20000
programmi, solo circa 4-5000 erano dedicati al CICS, il resto era
tutto BATCH, una parte di essi, 2-3000 sono spot (programmi una
tantum), il resto è il vero core.
me ne sono andato due anni fà, ma i miei colleghi che sono rimasti,
ancora lavorano in cobol è come avevo detto nel post precedente la
loro attività si basa sulla manutenzione del core, più la parte
services verso java.
rispondendo al post che Websphere + CICS (bel castello :) ), non so se
è l'unico modo di far comunicare il COBOL con l'esterno (fuori il
mainframe).
Sicuramente il costo e soprattutto il rischio è nettamente inferiore
di riscrivere tutto da capo se fatto internamente,
ti posso dire che ci sono aziende che sviluppano soluzione intere per
banche e assicurazione che rivendono sul mercato, in quel caso ho
notato che sono tutte di nuova concezione (di business) e basate su
tecnologie nuove.
Ciao

 sui dati, non sulla fuffa</cite>)
Mah, guarda, io lavoro per una ditta che vende un ERP multipiattaforma
scritto in COBOL. Il mainframe � la piattaforma principale, poi lo
stesso COBOL passa su AS/400 e poi su Linux/Unix e Windows.
Se insisti lo puoi usare anche a carattere, ma non lo fa quasi pi�
nessuno, perch� con due librerie (Java) convertiamo i flussi telnet in
XML e poi in eleganti pagine HTML.
Quindi Tomcat + java, senza tanti arzigogli, e il COBOL e' lo stesso.
L'utente, tipicamente, non si accorge che "sotto" c'� un mainframe ...
Ciao,
    Davide

 esperto...
Sono la scelta ideale (al suo prezzo, ovviamente) per chi ha bisogno di
disponibilit� (al netto delle manutenzioni pianificate) pari al 99,999 %
(cio� 1 giorno di fermo macchina imprevisto ogni 27 anni).
E carichi macchina che vengono bilanciati verso l'80 % e che reggono
bene fin quasi al 100%.
2 sistemisti e qualche operatore per 300 utenti (connessi 8h al giorno).
per machine medio - piccole (una piccola banca con 150-200 sportelli).
Se ci si accontenta di un decimo di questo uptime, con il limite del 90%
di carico "tranquillo" c'� l'AS/400.
(un mio cliente lo accendeva a settembre e lo spegneva ad agosto ...)
Se vi accontentate di un pdf proprio base :
http://download.boulder.ibm.com/ibmdl/pub/software/dw/university/student
s/Intro_Mainframe.pdf
Se volete di pi� c'�
 
www.redbooks.ibm.com
gli articoli tecnici pi� "spinti" li trovate su citeseer, da quando
hanno chiuso al pubblico i Journals tecnici di IBM.
Ciao a tutti,
    Davide
(webbizzatore di mainframe & AS/400)
--
Ing. Davide Grandi
davide...@mclink.it

 wrote:

Ehi, ci sono ancora ! Si vendono bene e ...
... mi pagano pure lo stipendio !
Poi, dal cliente, nessuno si accorge che "sotto" c'� il COBOL o persino
un mainframe ... vdeono le loro belle pagine HTML e sono tutti contenti.
Ciao,
    Davide

 100%.
... 

 un mainframe ... vdeono le loro belle pagine HTML e sono tutti contenti.
Alla fine, conta il risultato. Che è buono economicamente anche per
chi lavora in queste "nicchie"... :-)

 compiti ben precisi, e lì funziona bene.
Non sto valutando i meriti di Cobol, sto valutando il peso statistico di una 
linea di Cobol nel panorama "software mondiale". E non perchè sia Cobol in 
quanto tale ma perchè è parte di un'applicazione custom e non generica.
-- 
Vide