Newsgroup: it.lavoro.informatica
Titolo: Cià un altro bel flame - bamboccioni belli del nonno

cocchi di mamma!

http://www.csis.ul.ie/cobol/course/COBOLIntro.htm#part1




-- 

(..) la rivoluzione non è un pranzo di gala, non è una festa letteraria, 

non è un disegno o un ricamo; non si può

fare con tanta eleganza, con tanta serenità e delicatezza, con tanta 

grazia e cortesia. La rivoluzione è un atto

di violenza, è l'azione implacabile di una classe che abbatte il potere 

di un'altra classe. (Mao Tze-tung)


 cocchi di mamma!



http://youtu.be/32UGD0fV45g



> cocchi di mamma!



...e orgoglio del papa'! AAAAAA il mio bambino col commodore 64 fa il 

programmatore....ma ROTFL!



 programmatore....ma ROTFL!



forse quello di prima era poco? prova questo:



http://youtu.be/o1eHKf-dMwo




dai un occhio  qui va  
http://www.csis.ul.ie/


dovete studiaaaaareeeee bambini...dovete studiaaaare!







Pubblicità progresso per un linguaggio oramai legacy ?








 oramai legacy ?



...tua sorella è legacy!

Ma voi sapete leggere o siete quella generazione che ha voluto i manuali 

in italiano? Ma ROTFL!

Avete voluto i manuali in italiano per poi inventarsi i corsi di laurea 

in inglese?

...e non volete che vi si chiami bamboccioni!









Ma guarda un po,abbiamo il tuttologo dell' informatica

Dopo it.politica vieni anche qui a sparare le tue assurde elucubrazioni ?



Ora rispondi a questa, se ci fosse un nuovo progetto da mettere in piedi 

su un OS moderno e non su un vetusto mainframe IBM o SIEMENS  lo faresti 

in COBOL ?



Probabilmente tu si, ma ti posso assicurazione che il 99.99% degli 

informatici userebbe altro

E poichè è cosi il COBOL viene relegato tra i linguaggi legacy, viene 

usato solo per la manutenzione del codici esistente,che è molto ma 

questo non cambia la considerazione








 su un vetusto mainframe IBM



..e qui dimostri tutta la tua ignoranza



bamboccione dell'ostia



https://cis.hfcc.edu/faq/cobol




 informatici userebbe altro



Concordo. Resta pero` il fatto che se cerchi lavoro come programmatore COBOL, almeno qui in Inghilterra ti pagano un bel po`; tanto che ti verrebbe voglia di farci un pensierino :)


 Concordo. Resta pero` il fatto che se cerchi lavoro come programmatore COBOL, almeno qui in Inghilterra ti pagano un bel po`; tanto che ti verrebbe voglia di farci un pensierino :)



Però questa potrebbe essere una banale logica di mercato: poca disponibilità di tecnici adeguati, per cui se li vuoi li paghi.



vero, ma non solo. E' la " forma mentis" che è diversa. I nuovi 

informatici non sanno trattare il dato, mentre chi lavora in COBOL sa 

che il linguaggio è solo uno striumento(nel caso semplice e per cui 

affidabile) per trattare il dato, l'informazione, dare risultati di 

analisi. Ma non vorrei far partire un ulteriore flame coinvolgendo chi 

con conosce la differenza tra smanettone e informatico professionista.




non fatevi pasturare dai troll.



...bravo bamboccione , tu si che sai le cose!

http://www-03.ibm.com/systems/it/z/announcement.html




 con conosce la differenza tra smanettone e informatico professionista.



Non sono d'accordo, ma la cosa sarebbe lunga e non penso di voler entrare in una competizione COBOL VS resto del mondo.


 
http://www-03.ibm.com/systems/it/z/announcement.html




A pensarci, manco IBM contro il resto del mondo è interessante.



e sbagli, l'informatica nel mondo è IBM...tutto il resto...sono solo 

cosette!



 in COBOL ?



Attenzione che i mainframe non sono "vetusti", non è mica che li hanno comprati nel 1960 e sono ancora quelli lì :-))) L'hardware evolve e cambia abbastanza spesso.

Sul Cobol possiamo essere d'accordo, ma anche i programmi Java scritti "solo" 10-15 anni fa cominciano a mostrare chiaramente la vetustà.

Recentemente dove lavoro è stato fatto un update di un corpo di tali programmi, e la cosa ha richiesto alcuni mesi. E solo per sostituire le classi che proprio non compilavano più con il nuovo prodotto di sviluppo (IBM... :-)), lasciando inalterato tutto il restante vecchiume.





..lascia stare ...perle ai porci...



 Però questa potrebbe essere una banale logica di mercato: poca disponibilità di tecnici adeguati, per cui se li vuoi li paghi.



Infatti *e`* una banale logica di mercato. E` un settore di nicchia, quindi se vuoi la mia conoscenza di nicchia, maturata in anni in cui sono restato nella nicchia, me la paghi. I numeri che ho trovato in giro tentano :)




 Sul Cobol possiamo essere d'accordo, ma anche i programmi Java scritti "solo" 10-15 anni fa cominciano a mostrare chiaramente la vetustà.



In campo informatico, la vetusta` arriva dopo 5 anni, figuriamoci dopo 15 :)

Il problema, comunque, non e` l'evoluzione dell'hw, che avviene (anche se i costi di upgrade vanno valutati - vorrei davvero vedere chi si tiene al passo), ma quella del sw. Se nel 2015 usi RPG per sviluppare i tuoi processi di business, ti poni comunque in una situazione di svantaggio rispetto ai tuoi concorrenti: per quanto puoi riempirti l'azienda di conoscitori del sistema/linguaggio, il tuo sistema non evolvera` mai con lo stesso ritmo di un sistema concorrente, magari scritto in Java, usando tecnologie recenti. Almeno, nella mia esperienza (la mia precedente azienda era IBM-infected, da AS/400 a RPG), ho notato come la vetusta` dei metodi usati per produrre il sw incide eccome sulle capacita` e sul ritmo di evoluzione del prodotto.


 Il problema, comunque, non e` l'evoluzione dell'hw, che avviene (anche se i costi di upgrade vanno valutati - vorrei davvero vedere chi si tiene al passo), ma quella del sw. Se nel 2015 usi RPG per sviluppare i tuoi processi di business, ti poni comunque in una situazione di svantaggio rispetto ai tuoi concorrenti: per quanto puoi riempirti l'azienda di conoscitori del sistema/linguaggio, il tuo sistema non evolvera` mai con lo stesso ritmo di un sistema concorrente, magari scritto in Java, usando tecnologie recenti. Almeno, nella mia esperienza (la mia precedente azienda era IBM-infected, da AS/400 a RPG), ho notato come la vetusta` dei metodi usati per produrre il sw incide eccome sulle capacita` e sul ritmo di evoluzione del prodotto.



Ammesso e non concesso che usando altro dal mainframe i ritmi di produzione aumentino sempre e comunque (ho visto certe cose con Java.. :-), va tutto benissimo, ma quando hai centinaia di migliaia di righe di codice già scritto appositamente per la tua azienda/ente/banca/ecc., evidentemente la scelta diventa molto difficile.

Sottolineo "scritto appositamente" perchè questi grandi clienti non è che si accontentano dei pacchetti già esistenti. Talvolta non possono proprio, perchè hanno problematiche del tutto uniche. A quel punto chi se le smazza le centinaia di migliaia di righe da reingegnerizzare? 

A mio parere è questo il punto essenziale che tiene in piedi tutta la baracca-mainframe, e che si ripeterà pari pari con altre baracche via via obsolescenti.


A quel punto chi se le smazza le centinaia di migliaia di righe da reingegnerizzare? 



Infatti e` impossibile. La mia precedente azienda aveva (ed ha) un sistema sviluppato 25 anni fa, che non cambierebbe per nessun motivo al mondo. Ci faceva soldi, ci fa soldi e, per quanto possibile, continuera` a farli. Anche perche` credo (anzi, l'ho constatato), ci sono parti del sistema che funzionano ma nessuno sa come e perche` :) Il problema, alla fine, e` che non riesce a trovare sviluppatori che vogliano continuare a lavorare con un linguaggio (RPG) nato nel 1959 e rimasto per lo piu` al suo stato primordiale. Convinci un neolaureato a lavorare con iSerie ed RPG. La verita` e` che aziende del genere non sono vere e proprie software house, ma baracconi in cui un manipolo di gente continua a cambiare pannoloni ad un vecchio che caga uova d'oro :)


 Infatti e` impossibile. La mia precedente azienda aveva (ed ha) un sistema sviluppato 25 anni fa, che non cambierebbe per nessun motivo al mondo. Ci faceva soldi, ci fa soldi e, per quanto possibile, continuera` a farli. Anche perche` credo (anzi, l'ho constatato), ci sono parti del sistema che funzionano ma nessuno sa come e perche` :) Il problema, alla fine, e` che non riesce a trovare sviluppatori che vogliano continuare a lavorare con un linguaggio (RPG) nato nel 1959 e rimasto per lo piu` al suo stato primordiale. Convinci un neolaureato a lavorare con iSerie ed RPG. La verita` e` che aziende del genere non sono vere e proprie software house, ma baracconi in cui un manipolo di gente continua a cambiare pannoloni ad un vecchio che caga uova d'oro :)



Il paragone col  vecchio incontinente mi piace :-)) Ma quindi questa azienda è una sw.h. che sviluppa prodotti in RPG?

Comunque sto riflettendo che il mercato della reingegnerizzazione di vecchi accrocchi Cobol/RPG, ecc. può essere molto interessante. E mi riferisco alla realizzazione di tool di analisi automatica dei vecchi programmi, estrazione del flusso logico, traduzione verso Jvm, e cose simili.

Per un neolaureato questo potrebbe essere interessante.

Se vedi in rete quasi tutti questi prodotti sono venduti in via riservata, cioè per sapere il prezzo devi contattare l'azienda. Segno che girano tanti dobloni.. :-)




 Comunque sto riflettendo che il mercato della reingegnerizzazione di vecchi accrocchi Cobol/RPG, ecc. può essere molto interessante. E mi riferisco alla realizzazione di tool di analisi automatica dei vecchi programmi, estrazione del flusso logico, traduzione verso Jvm, e cose simili.



Interessante. Mi fai il nome di qualche prodotto?


 
http://www-03.ibm.com/systems/it/z/announcement.html






ma tu lo sai che HP ha un fatturato più alto di quello di IBM? Vorrà dire 

che HP vende più di IBM?

E lo sai che Google ha un utile netto più alto di quello di Google? Vorrà 

dire anche questo qualcosa, anche in considerazione del fatto che non 

fanno nessuno uso di tecnologie IBM? 

E lo sai che pure microsoft ha un utile netto che è doppio rispetto a 

quello di IBM e non usano prodotti IBM? 

E lo sai che Apple ha un utile netto 4 volte superiore rispetto a quello 

di IBM ed anche loro non usano prodotti IBM? 

E lo sai che Oracle ha un utile netto circa uguale a quello di IBM e che 

anche loro non usano prodotti IBM? 



ma sei proprio proprio convinto che il mondo giri veramente intorno a IBM? 



-- 

Massimiliano Adamo



Lo so, ho lavorato in passato su mainframe ibm e siemens data (bs2000)

Ma personalmente preferisco altro, pur conoscendo il COBOL molto bene

Per fortuna posso permettermi di non farne solo una questione di vil denaro





bamboccione ma lo sai che tutte le aziende che hai citato, tranne forse 

HP ma compresa Microsoft, hanno tutte quante un megamainframe IBM per la 

gestione aziendale?



BAMBOCCIONE DELL'OSTIA!!!!!!!!!




E chi ha scritto che i maninframe siano vetusti ?



Ho scritto solo vetusti mainframe, come dire un pc vetusto

Poi il java di 15 anni fa è ovvio che qualche problema con le nuove jvm 

e/o librerie potrebbe averle, è normale

Ma oramai,oggi, java è un linguaggio stabile.

Non credo che per il futuro romperanno la compatibilità,librerie 

comprese (quelle std ovviamente, fornite con il linguaggio)

La stessa cosa è oramai valida anche per il buon vecchio C e suo figlio, 

il C++














 pur conoscendo il COBOL molto bene



ROTFL! con quella testa?







Carissimo  B., i mainframe non sono certo spariti ma quelli moderni 

(come la serie Z di IBM) non usano certo vetusti OS(come il famoso MVS) 

ma degli OS tipo unix compreso linux

E gli applicativi nuovi non li faranno certo in COBOL, avendo a 

disposizione java,C,C++ pur se sono sempre disponibili COBOL,PL/I e Fortran






 compreso linux



per l'esattezza fino a 80.000 partizioni linux



 tranne forse HP



perchè dai tempi in cui inglobò digital usa quella piattaforma



 avendo a disposizione java



sotto websphere

WebSphere è il software all'avanguardia per il business on demand, che 

mette a disposizione business integration, infrastruttura di 

applicazione & transazioni

http://www-01.ibm.com/software/it/websphere/




 e Fortran



il Fortran è praticamente sparito, lo usavano gli ingegneri per calcoli 

scientifici, strutturali, etc. etc. non esistono vere e proprie 

applicazioni in fortran, veniva usato onfly per calcoli complessi oggi 

penso che usino lisp ma non ne sono certo



 vetusti OS(come il famoso MVS)



comunque non è vetusto...dipende cosa ci devi fare...il mainframe viene 

partizionato per cui per far girare "il vecchio" viene sicuramente 

creata unna o piu partizioni MVS....e poi webshere sicuramente... 

dipende dal campo applicativo



 gestione aziendale?



Un mainframe IBM con kernel e librerie scritte Cobol? :) 



-- 

Massimiliano Adamo


 reingegnerizzare?



la domanda piuttosto e' "perche'" reingegnerizzare ? la baracca funziona 

bene e grazie all'hardware migliora pure in performance (visto che quei 

software fatti 30 anni fa erano adattati per girare su hardware 

poverissimi). I requisiti evidentemente son sempre gli stessi, gli 

standard pure. Reingegnerizzare in un linguaggio "moderno" introdurrebbe 

senza dubbio problemi di performance e sicurezza che attualmente non 

hanno. 



L'unico "difetto" possiamo dire e' appunto la mancanza di nuove leve che 

sostituiscano i vetusti manutentori dei sistemi legacy. Ma anche questo 

e' un non problema: in una societa' dove manca sempre di piu' lavoro 

specializzato, si trovera' anche chi si riconverte al cobol per portare a 

casa la pagnotta, perche' no. Del resto c'e' gente che passa tutta la 

vita e guadagna pure bene su mostruosita' come SAP.



-- 

Soprano


 Un mainframe IBM con kernel e librerie scritte Cobol?:)



spiritusun!



 



Oooohhh finalmente uno che ha centrato il problema alla radice!









...finalmente è arrivato uno intelligente!



 cosette!



L'importante è esserne convinti.


 ma sei proprio proprio convinto che il mondo giri veramente intorno a IBM? 



A me scappa una domanda: cui prodest?



infatti tu mi sembri molto convinto.



 comprese (quelle std ovviamente, fornite con il linguaggio)



Never say never!




Il 07/02/2015 00.53, Max_Adamo ha scritto:


bhe!

oracle si e' comprata sun e ci fa girare java a manetta

hp si è comprata digital e ci fa girare cobol a manetta

microsoft ha mainframe e ci fa girare cobol a manetta

apple ha mainframe e ci fa girare cobol a manetta

google ha mainframe e ci fa girare cobol a manetta

facebook ha mainframe e ci fa girare cobol a manetta

etc.

etc.

siete incredibili!



 disposizione java,C,C++ pur se sono sempre disponibili COBOL,PL/I e Fortran



Ma pure linguaggi di altissimo livello (mi riferisco a Python, Ruby e compagnia).


 perchè dai tempi in cui inglobò digital usa quella piattaforma



Uhm... io ho una memoria storica che dice che fu Compaq a inglobare DEC, e che solo MOLTO dopo HP inglobò Compaq. Peraltro io ricordo che HP aveva già i suoi mainframes con HP-UX a bordo.


 bene e grazie all'hardware migliora pure in performance 



Vero. Normalmente si fa perché cambiano i requisiti. E per fortuna, perché se non succedesse chi sviluppa oggi non avrebbe più lavoro!



usati solo a scopo scientifico e/o matematico ma non gestionale



 infatti tu mi sembri molto convinto.



Vero. Io sono convinto che per ciascun problema ci sia una soluzione più adeguata, che non può essere 'sempreIBM', 'sempreMicrosoft', 'sempreLinux', 'sempre<metticiQuelCheTiPare>'.

Sai, quando si comincia ad avere qualche decina d'anni di mestiere sulle spalle, ci si rende conto che le guerre di religione, in informatica, fanno davvero ridere.


 usati solo a scopo scientifico e/o matematico ma non gestionale



Il mondo informatico non è solo gestionale. E per fortuna, aggiungo, a me far gestionale proprio non piace.



e tu di cosa ti occupi



 quando si comincia ad avere qualche decina d'anni di mestiere sulle spalle



dipende dove e come li hai fatti

c'è gente che fa due anni nel posto giusto su progetti giusti ed 

acquisisce molta piu esperienza e conoscenza di uno che ha fatto 10 anni 

con casisteche limitate e di nessun spessore professionale



 facebook ha mainframe e ci fa girare cobol a manetta





Puoi postare dei link (non pubblicità IBM) per quanto sopra?



Detto ciò, ad es. per le Telco a me non risulta ci sia in uso tutta sta 

tecnologia IBM.



Gabriele


 e tu di cosa ti occupi



Temporaneamente a spasso. Il mio campo di elezione è la supervisione di impianti industriali (collezione dati, statistica, interfacce uomo/macchina e quelle robe li). Ho però frequentato molti campi differenti, gestionale compreso (è per quello che ti dico che non mi piace...)



...ti perdono perchè capisco che non sai

Se parli di TELECOM il cervellone è ibm

se parli di VODAFONE il cervellone è ibm

se parli di WIND/infostrada sinceramente non ricordo

se parli di Fininvest/mediaset è il regno di ibm(ti ricordi il ministro 

dell'era berlusconi?)

se parli di rai NEANCHE PARLARNE è tutto IBM



voi confondete i dipartimentali col cervellone

i dipartimentali raccolgono/gestiscono ma alla fine TUTTO DEVE FINIRE 

NEL CERVELLONE....che voi difficilmente vedete




potresti cercare di inserirti nella robotica/domotica_industriale , in 

quel settore in futuro ci sarà sviluppo



 la domanda piuttosto e' "perche'" reingegnerizzare ? 



per manutenere e/o evolvere con nuove implementazioni. 

perché non è solo il problema di trovare la manodopera, ma anche che su questi

sistemi le implementazioni non ce le fai.



laddove ci sono software legacy che girano da 30 anni è anche vero che ci 

hanno dovuto costruire intorno un ecosistema per mantenere l'interoperabilità 

con il resto del mondo e non rimanere a 30 anni fa in termini di

competitività.



e anche in termini di performance e sicurezza, è tutto da dimostrare che 

complessivamente questi autentici castelli di carte fatti di trasformazioni,

trasferimenti, flussi, etc... costruiti per tenere in vita il sistema legacy 

siano davvero performanti e sicuri.


 con casisteche limitate e di nessun spessore professionale



Condivido. Ecco perché ho cercato di spostarmi il più possibile, negli anni. Mi sono occupato di elaborazione immagini, di rifiuti, di impianti industriali e di risalita, di controlli non distruttivi. Ho lavorato in C, C++, C#, nel meritatamente famigerato VB, in Java, Python, assembly, Pascal. Ho lavorato per grosse software house come per piccole realtà. Ho messo mano su molti SO diversi. Ecco perché penso che le guerre di religione siano inutili, ciascuna soluzione ha un proprio ambito applicativo, i suoi pro, i suoi contro.




un tool di analisi - progams understanding - è XAnalisys, mai utilizzato 

personalmente ma spesso citato in conference IBM.









-- 

http://www.linkedin.com/in/stefanotassi






Programming  today is  a race between software engineers  striving to

build  bigger and better idiotproof programs, and the Universe trying

to produce  bigger and better idiots. So far the Universe is winning.

(Rick Cook)


 Se parli di TELECOM il cervellone è ibm



Ti prego. Accetto tutto, ma cervellone no!


 quel settore in futuro ci sarà sviluppo



Non nell'immediato e non in Italia. E io purtroppo, per una serie di motivi, non mi posso muovere.


 la domanda piuttosto e' "perche'" reingegnerizzare ? 



Perche` i clienti potrebbero avere esigenze nuove (i requisiti non sono MAI gli stessi nel software), perche` vengono fuori leggi che ti obbligano ad implementare o cambiare certi processi, perche` se i concorrenti si aggiornano, lo devi fare anche tu. Tutto questo, con strumenti e metodologie vecchie come il cucco, diventa molto arduo. Il problema di non riuscire a trovare manodopera e` il problema di non riuscire a trovare gente che riesca a far evolvere il tuo sistema. A me non sembra proprio un problema da poco.


 il sistema legacy siano davvero performanti e sicuri.



Tutto vero. Resta pero' il fatto che 'sti castelli continuano a essere 

usati, così come pure SQL (che per molti tipi di applicazioni possiamo 

considerare obsoleto) e quant'altro. Per cui la domanda da farsi e': 

perche' ? E la risposta non puo' che essere perche' funzionano, perche' 

non sono sopraggiunti nuovi requisiti a rendere obsoleti i precedenti e 

perche' i costi/rischi di rimpiazzarli sono piu' alti di quelli di 

mantenerli.



Con questo non voglio dire che il settore bancario, che peraltro conosco 

poco, non abbia vissuto mutazioni (basta pensare all'home banking ecc.), 

ma che per un certo tipo di transazioni e applicazioni evidentemente va 

ancora bene lo status quo.



Riguardo alla sicurezza se si pensa che in un mondo dove si hackera e si 

buca qualsiasi cosa tutto sommato i cc bancari e i bancomat siano ancora 

piuttosto sicuri mi fa pensare che quei sistemi e protocolli legacy non 

erano poi così male.



-- 

Soprano


 il C++



Anche se devo ancora trovare una implementazione C++ al 100% compliant con lo standard.





beh c'e' anche il problema opposto. Il convertire in tecnologie "moderne" 

tutti quei requisiti di affidabilita' e sicurezza che sono passati da 

decenni di verifiche e fine tuning sugli strumenti "vecchi" e piu' che 

altro avere personale con conoscenze adeguate per farlo. Probabilmente e' 

complicato forse piu' che trovare esperti cobol.



-- 

Soprano


 complicato forse piu' che trovare esperti cobol.



Anche tu hai ragione. Parlare di tecnologie "moderne" effettivamente non ha molto senso (Java e` nato nel 1995, ha i suoi bei 20 anni sulle spalle). E` piu` che altro un cambio nella metodologia di sviluppo software. Non credo che ormai si possa dubitare che a un sistema sviluppato in Java possano mancare requisiti di affidabilita` e sicurezza, dopo 20 anni dalla sua nascita e dall'utilizzo massiccio in tutti gli ambiti dell'industria. Hai ragione, comunque, nel dire che portare i vecchi sistemi sul "nuovo" ha il suo costo enorme. Secondo me esistono pero` dei campanelli di allarme. Nella mia precedente azienda, si era arrivati al punto che preservare il vecchio sistema, evitare di toccarlo, correggerlo, evolverlo, aveva portato a rigettare certe richieste dei clienti perche` troppo "disruptive". Questo, secondo me, e` un problema che deve farti capire che stai sbagliando qualcosa. Per me non esiste dire "no, non si puo` fare", se un cliente mi chiede una modifica. Il cliente mi chiedeva una modifica, a me sembrava una sciocchezza da implementare, per cui gli rispondevo che sicuramente si poteva fare, poi consultavo l'architect esperto del sistema, e mi rispondeva "ahem... no, e` troppo lavoro". Dovevo tornare dal cliente in ginocchio col capo coperto di cenere. Non va bene.


Il giorno sabato 7 febbraio 2015 13:10:48 UTC+1, 
a.laf...@gmail.com
 ha scritto:



Dovevo tornare dal cliente in ginocchio col capo coperto di cenere. Non va bene.



La situazione che descrivi - a meno che non si trattasse di UN cliente in un parco clienti enorme - è un po' la certificazione della morte dell'azienda. Un'azienda che non risponde ai clienti, dai e dai, spinge il cliente a cercare alternative. E le alternative normalmente ci sono.


 La situazione che descrivi - a meno che non si trattasse di UN cliente in un parco clienti enorme - è un po' la certificazione della morte dell'azienda. 



Infatti i rapporti con certi clienti hanno cominciato a scricchiolare. Erano tutti clienti grandi e con un mucchio di soldi. Per ogni piccola modifica, dovevano sganciare quintali di sterline, e non andava proprio bene. 










Ehm, i "bancomat" li lascerei da parte come esempio!

Sono invece molto hackerati, solo che le banche non lo dicono.

Per pochi soldi puoi comprarti un bel tool basato su chiavetta USB e/o software 

da collegare via PC con Ethernet con cui scardinarne di varie marche e modelli. 

E succede che così scrivi di voler prelevare "100" e la macchinetta ne tira 

fuori "1.000" :)



Per i conti, direi che la sicurezza può derivare piuttosto dal fatto di 

lavorare con linee non accessibili al pubblico, normalmente. Ma tanto basta 

attaccare i clienti ed il gioco è fatto (alla faccia di password e OTP e 

chiavette inutili, che servono solo alla banca per pagare meno di assicurazione 

e scaricare sul cliente l'onere di proteggersi).



Gabriele


 CERVELLONE....che voi difficilmente vedete



Cervellone non vuol dire nulla.

Potrei dirti che dal mio punto di vista, per la maggior parte dei nomi da te 

citati sopra, non credo proprio che nei data center ci sia più HW IBM di altri 

(anzi) e lato software ancora di meno.

Se tu invece fai ricadere tutto alla generica voce "gestionale" allora potrebbe 

anche darsi.



Fin'ora però non è chiaro di cosa stai parlando al lato pratico.



ciao

Gabriele












Sulla serie Z non credo che esistano quelli che citi



Ho preso la lista qui:



http://www-03.ibm.com/software/products/en/category/SW780













posso capire hp,apple,M$,aziende sul mercato da molti anni



Ma secondo te facebook e google (aziende abbastanza recente) usano i 

mainframe applicativi cobol



E per fare cosa ?





Postami un link affidabile dove si afferma ciò e ti crederò










Si trovano sicuramente,specialmente quando la crisi come oggi abbonda

Purtroppo, o forse è meglio cosi,tra le nuove leve sarà sempre piu 

difficile reperire risorse di questo tipo

Vorrà dire che per i 'vecchietti' 50enni e 60enni ci sarà ancora lavoro




 



E quando accade questo scoppia un fallimento per l'azienda (che

può portare pure verso la strada del non ritorno, come dicevo in

un altro thread). Ma oltre alla magra figura di non poter accontentare

le richieste del cliente, scatta pure la beffa per la sua perdita:

una volta ottenuta quel tipo di risposta negativa, il cliente andrà da un

altro a chiedere la stessa cosa, e quest'ultimo potrebbe dire:

"Ok si può fare!". Magari poi sarà stato detto da un pasticcione

e scoppieranno altri casini, ma gli occhi del cliente quando ti

chiede: "Si può fare questa cosa?" luccicano sempre come occhi

di un bambino alla richiesta di una cosa(/giocattolo) nuova(/o)... ;)








 ha scritto:


Ecco...










 erano poi così male.



non c'è solo questo aspetto della sicurezza. 

diversi passaggi di dati avvengono tuttora tramite trasferimento file, 

perché i protocolli legacy questo prevedono. ciò è un grosso problema per

la transazionalità delle transazioni (scusa il gioco di parole). non

è rarissimo, ad esempio, che una disposizione home banking non vada a buon

fine, o che una transazione rifiutata venga addebitata lo stesso dovendo

poi aspettare giorni prima di vedere il rimborso. sono passaggi fragili

e ogni volta controllare cosa/perché non è andato a buon fine è come minimo

complicato e talvolta impossibile.


 non fatevi pasturare dai troll.



proprio ieri è passata l'ultima puntata di The Big Bang Theory 

incentrata sui troll..




 se parli di VODAFONE il cervellone è ibm



Quando ho lavorato sul sistema antifrode usato in Vodafone, a Milano, molti anni fa, il cervellone era basato su AlphaServer e Oracle in cluster.


 E quando accade questo scoppia un fallimento per l'azienda 



E infatti il fatto che quel software in particolare non fosse adeguato a risolvere i problemi dei clienti (con somme arrabbiature da parte mia e del mio team per mesi e mesi) ha fatto si` che uno di questi clienti rinunciasse ad aggiornare il sistema e, siccome si tratta di alcuni tra le principali aziende di investment management inglesi, i soldi in palio erano milioni di sterline. La notizia e` arrivata al Financial Times. Quando la notizia che un grosso stockbroker rinuncia al tuo sistema per i suoi tanti "technical glitches" arriva sulle pagine del Financial Times, sei praticamente fottuto. La conseguenza e` stata che la societa` non e` riuscita a pagare i bonus ai suoi tanti dipendenti, certe persone sono andate via, e tra le restanti si e` diffuso un enorme malcontento.



Immagina un flusso per un'ordine di acquisto/vendita titoli in borsa: immetti l'ordine, l'ordine viene approvato, passa allo stock echange, e cosi` via. Quando immetti l'ordine, ci puoi associare delle note: un testo che e` un puro riferimento per te, di nessuna rilevanza per l'esecuzione della transazione. Il cliente chiedeva di poter cambiare queste note (ripeto: di nessuna rilevanza per la transazione) anche dopo che l'ordine era stato approvato, senza che questa modifica richiedesse una nuova approvazione. Risposta: non si puo` fare. Sbattevo la testa contro il muro.




 Interessante. Mi fai il nome di qualche prodotto?



Questo è un gruppo di programmi di migrazione da Cobol a Java, opensource.



http://code.google.com/p/naca/




Questo sotto è un tool di analisi di Cobol, ovvero di "application mining" (una bella definizione):



http://www.itp-panorama.com/index.php?en_home




E ce ne sono molti altri, da quelli che estraggono il diagramma di flusso a tool molto sofisticati. Tra cui quelli di IBM/Rational, manco a dirlo :-)


 il C++

Per Cobol esistono standard Ansi, come per il C e C++. Non mi risulta che Java abbia uno standard indipendente da quello del produttore.

Senza nulla togliere alla superiore potenza e flessibilità rispetto a C e Cobol.


 hanno. 



Non solo. Penso sia molto ma molto più difficile capire il funzionamento di un codice Java vecchio ed incasinato, e non documentato, rispetto ad un corrispondente Cobol. 






 Uhm... io ho una memoria storica che dice che fu Compaq a inglobare DEC, e che solo MOLTO dopo HP inglobò Compaq. Peraltro io ricordo che HP aveva già i suoi mainframes con HP-UX a bordo.



Giusto. Dec aveva i suoi bei mini Vax e PDP, ed HP i suoi HP3000 o qualcosa di simile.


 tecnologia IBM.



Se ti riferisci a Telecom, sbagli di sicuro. Per gli altri non so, ma non mi stupirebbe che ce li abbiano anche loro i mainframe. Ben nascosti dietro pile di pc, ovviamente :-)








 Perche` i clienti potrebbero avere esigenze nuove (i requisiti non sono MAI gli stessi nel software), perche` vengono fuori leggi che ti obbligano ad implementare o cambiare certi processi, perche` se i concorrenti si aggiornano, lo devi fare anche tu. Tutto questo, con strumenti e metodologie vecchie come il cucco, diventa molto arduo. 



Mah, non è che oggi vedo strumenti molto differenti e superlativi per scrivere un software che legge un file  (oppure una tabella db), lo trasforma e ne scrive un altro in output.




 Non mi risulta che Java abbia uno standard indipendente da quello del produttore.



Esiste il Java Community Process, che e` qualcosa di molto simile ai vari committee ISO che stanno dietro a C e C++. 




 Mah, non è che oggi vedo strumenti molto differenti e superlativi per scrivere un software che legge un file  (oppure una tabella db), lo trasforma e ne scrive un altro in output.



In che senso?




ispas wrote on 07/02/15 18:53:


Allora faccio anche a te la stessa domanda: per farci cosa?

Qual è il core business di una Telco?



Gabriele




 Qual è il core business di una Telco?





La fatturazione? :-) Che vuoi che ci facciano.



Nel senso che quello fa la stragrande maggioranza dei vecchi programmi Cobol, RPG, ecc.


 Nel senso che quello fa la stragrande maggioranza dei vecchi programmi Cobol, RPG, ecc.



Be`, non esattamente. Noi avevamo un bel po` di processi di business scritti in RPG IV e interfacciati da applicazioni client. Un conto e` scrivere un sistema di ribalanciamento di un portfolio di investimenti in Java, un conto e` farlo in RPG.





Perche non serve di piu,è semplice

Le metodologie di progettazione si sono evolute per poter costruire sw 

sempre piu complessi,non per facilitare una semplice lettura di file





Capirlo è una cosa, modificare senza rompere il tutto è un altra



Il COBOL, almeno quello che gira sui manframe non ha lo stack, ma solo 

variabili globali

E' facile capire che un conto è modificare funzioni in scope locale come 

in java, un altro è seguire/ e modificare  un programa COBOL dove le 

routine non hanno parametri e tutte le variabili sono globali

Immagina di capire un sorgente cosi, neanche tanto grosso, di un 

migliaio di righe escludendo le dichiarazioni

E' una bella differenza






davvero ridere.



Mi permetto di dissentire,

quelle di questi ultimi thread non sono guerre di religione,

sono gare a chi ce l'ha piu' lungo...

Ad esempio, ho  letto la frase "HP fattura piu' di Ibm" ...



"Livello basso"....come diceva il buon Pazzaglia.



ciao

fm 






 "Livello basso"....come diceva il buon Pazzaglia.



no no no no ... non dire sciocchezze ... è solo un metodo (esemplificativo 

per un verso, ma che semplifica troppo per un altro verso) che serve solo 

per mettere in evidenza i dati di diffusione dei prodotti. 

Non c'entra assolutamente nulla con la qualità del prodotto stesso, perché 

non sono fan, ne di uno ne dell'altro monopolio. Ma ovviamente, il dato in 

oggetto, ti collega in qualche modo con il dato sulla diffusione del 

prodotto. 



IO VOLEVO SOLO DIRE, attraverso questi dati, che il mondo non è nella mani 

di IBM. E che IBM, in questo contesto (visto che ho messo insieme una 

decina di aziende), rappresenta il 10% del totale dei prodotti. 



-- 

Massimiliano Adamo


 A me scappa una domanda: cui prodest?



è un dato in qualche modo collegato con il dato di diffusione dei 

prodotti. Non ci leggere null'altro, di tecnico, di filosofico o di 

esoterico. 

Volevo solo dire, che il mondo non è nelle mani di IBM, e che IBM, come 

tanti altri, ha solo una fetta della torta. 

Ciò nonostante i prodotti di IBM, a prescindere da quel che io ho scritto, 

possono essere i peggiori o i migliori e a me non me ne frega nulla. 



In un thread precedente si era create una associazione del tipo Java = 

cacca, IBM = RPG. E io ho detto che IBM = java/Websphere, ma anche in quel 

caso non me ne frega di tessere le lodi di websphere e di java (weblogic 

secondo me è più figo, ma troppo costoso e se ti vuoi smazzare da te i 

problemi, jboss il suo sporchissimo lavoro lo fa benissimo). 



-- 

Massimiliano Adamo


 E' una bella differenza



Differenza in meglio o peggio?

Comunque di sorgenti Cobol monolitici anche di 10.000 righe ne ho letti e capiti parecchi :-)

All'epoca ti stampavi il sorgente e lo analizzavi così, senza debug, senza editor con sintassi evidenziata, ricerche, ecc.. E ti assicuro che il flusso logico si capiva bene, e si modificava altrettanto bene (ovviamente qualche bug limitato era inevitabile).

Viceversa vedo colleghi javisti che, per capire il flusso del programma, ricorrono inevitabilmente al debugger. E parlo di gente esperta, in generale ed in particolare di quella specifica applicazione.

Evidentemente non è così semplice capire il flusso direttamente dal sorgente.


 Viceversa vedo colleghi javisti che, per capire il flusso del programma, ricorrono inevitabilmente al debugger. 



Il concetto di "flusso" del programma e` legato alla vecchia programmazione procedurale. Non si ragiona piu` in termini di "flusso", ormai, ma di interazione tra componenti (che a volte possono lavorare in maniera concorrenziale). Qualunque sviluppatore Java serio, oggi, lo fa seguendo certe metodologie che rendono l'evoluzione e la manutenzione del codice relativamente semplice. Oltretutto esistono ormai metodologie di testing/design che ti consentono di individuare bug il prima possibile. Se hai bisogno del debugger per capire il codice, non sei ne` bravo, ne` esperto :)




 sono gare a chi ce l'ha piu' lungo...



Possiamo definirlo in modi differenti, il concetto astratto è quello! 



:-D



-- 

Ciao!

Luca


 di IBM. 



Max, dal mio personalissimo punto di vista già questa è una frase che fatica a stare in piedi. Quanto fa Siemens rispetto a HP o Google? Eppure, nel mondo PLC e bus collegati, Siemens la fa da padrone (a volte in modo assolutamente immeritato), qualcosa fa HP, IBM credo manco esista.

Voglio dire: i mondi in informatica sono infiniti, e prendere il solo gestionale come parametro può essere fuorviante.



-- 

Ciao!

Luca



cioè, tu credi che io credo che mi piaccia hp, più di ibm o meno di 

qualcun altro, quando in realtà me ne frega parimenti un cazzo tanto di 

tutte quante? 

Ripeto, sottolineo e ribadisco, che volevo solo far notare, che ibm non ha 

tutta la torta per se. 



lo ri-ri-ribadisco: non mi ne frega nulla di quale produttore hardware o 

software ce l'ha più lungo o più grosso. 



-- 

Massimiliano Adamo



ma allora chiudiamola qui dicendo che non ci sono fonti attendibili e 

prove provate per poter dire A piuttosto che B. 

Il resto dei pareri sono tutti basati su esperienze personali più o meno 

limitate. 



mondo PLC è in realtà solo una parta dell'informatica. Non vorrei sembrare 

pedante, ma a dimostrarlo ci sono i fatturati nel settore :) 



p.s.: comunque siemens spacca. Sei mai stato a Siemens-Stadt a Berlino? Io 

si :) Ce ne avessimo altre aziende così in europa.... abbiamo philips e SAP 

che non so se è 'sto gran colosso. 



-- 

Massimiliano Adamo


 e SAP che non so se è 'sto gran colosso.





secondo me le aziende tedesche tendono a diventare mastodontiche anche 

perché sono partecipate dallo stato. Se Volkswagen è posseduta al 25% dal 

land della Sassonia, immagino che pure Siemens abbia una proprietà 

pubblica (che non il "public company" all'americana). Chissà SAP... 





-- 

Massimiliano Adamo






non devi ragionare su quello che fanno gli altri (nel dettaglio), in 

fondo ognuno ragiona a modo suo



Tu conosci bene java e COBOL ?

Se e cosi puoi fare una comparazione anche a livello istintivo

Ma una volta fatto questo tieni conto che dipende molto dalla forma mentis

In fondo se siamo passati dalla spaghetti code alla programmazione 

procedurale e poi ai moduli ed infine alle programmazione ad oggetti e 

alla programmazione generica un motivo ci sarà

O credi che sia solo una moda ?






 cioè, tu credi che io credo 



Per quale motivo tu pensi che io stessi parlando di te? coda di paglia?


 che non so se è 'sto gran colosso. 



Guarda che non sto discutendo Siemens (a parte alcune politiche di discontinuità del supporto per le applicazioni industriali). E no, non ci sono mai stato. Ha me son girate le scatole sul serio solo quando han smesso di far telefonini (i loro erano fantastici)! :D




 O credi che sia solo una moda ?



Mah. Nella lista hai dimenticato la programmazione funzionale (esiste dagli anni 60 col Lisp) e quella logica (col Prolog dagli anni 80).

Di cui la prima ha avuto proprio recentemente un revival grazie a Clojure, Scala, F#, in parte Python, C#, Java.

Poi l'esercizio su cosa sia moda e cosa non lo è lo lascio ad altri.


 Tu conosci bene java e COBOL ?





A proposito di Cobol, curioso picco a gennaio nell'indice Tiobe:

http://www.tiobe.com/index.php/content/paperinfo/tpci/COBOL.html



 
http://www.tiobe.com/index.php/content/paperinfo/tpci/COBOL.html




Il modo in cui l'indice TIOBE e` calcolato e` semplicemente ridicolo. Del tutto inaffidabile. 





Come mai?

Hanno sbagliato i calcoli?

Hanno pubblicato dati inventati?

Ma soprattutto, dovresti spiegare perche' un indice (cioe' un numero) 

puo' o meno essere ridicolo.








Idem per me




 puo' o meno essere ridicolo.



Io ho detto che e` il metodo con cui l'indice e` calcolato ad essere ridicolo. E il metodo e` ridicolo perche` e` facilmente manipolabile. E` facile distorcere l'indice TIOBE come e` stato gia` fatto per alcuni linguaggi (vedi Delphi) mediante un "concerted effort". TIOBE e` un indice ridicolo, che non ha nessuna affidabilita`.



Mi sembrava che tu avessi detto una stupidaggine, ora ne ho la conferma. 

D'altra parte da un supponente superficiale non ci si puo' attendere di 

piu'.

Parafrasando: Cosa si puo' pretendere da un culo? Una romanza?






 Mi sembrava che tu avessi detto una stupidaggine, ora ne ho la conferma.



Uhhhh, con le tue parolacce mi hai offeso moltissimo! Cattivo!!



Parti da qui e buona lettura:



http://blog.timbunce.org/2009/05/17/tiobe-index-is-being-gamed/





 Io ho detto che e` il metodo con cui l'indice e` calcolato ad essere ridicolo. E il metodo e` ridicolo perche` e` facilmente manipolabile. E` facile distorcere l'indice TIOBE come e` stato gia` fatto per alcuni linguaggi (vedi Delphi) mediante un "concerted effort". TIOBE e` un indice ridicolo, che non ha nessuna affidabilita`.



Allora quale sarebbe un indice affidabile alternativo?




Pensi davvero che tutte le altre statistiche, analoghe a tiobe, pur 

basate su dati prelevati da web non siano ugualmente influenzabili?

D'altra parte, ogni statistica non e' scevra di analoghi innumerevoli 

difetti, siano essi dipendenti dal campione o dalla teoria sottesa. Si 

tratta solo di valutare i dati in modo intelligente.

Questo e' il problema vero, non la statistica in se'.


 Questo e' il problema vero, non la statistica in se'.



Ha poco senso valutare i dati in modo intelligente, quando i dati non sono estratti in maniera intelligente.




 Allora quale sarebbe un indice affidabile alternativo?



Se per "affidabile" intendi "che rispecchi accuratamente la realta`" non ne esistono. Comunque alla pagina 
www.langpop.com
 esistono varie alternative da prendere piu` o meno con le molle.




 Se per "affidabile" intendi "che rispecchi accuratamente la realta`" non ne esistono. Comunque alla pagina 
www.langpop.com
 esistono varie alternative da prendere piu` o meno con le molle.



Molto curioso che nella statistica del sito "Lambda the ultimate" il Cobol risulta 12o. Infatti quel sito, che qualche volta ho letto, è piuttosto inclinato sugli aspetti teorici dei linguaggi.

Si vede che il Cobol è roba da ricerche avanzate :-))


 Si vede che il Cobol è roba da ricerche avanzate :-))



Magari stanno studiando un COBOL++ :)


 Il giorno lunedì 9 febbraio 2015 20:05:57 UTC+1, 
a.laf...@gmail.com
 ha scritto:



[...]

Comunque il Visual COBOL di Microfocus non e` poi tanto male :)



http://3.bp.blogspot.com/_HUb2ygrQR50/S_VVIOBje_I/AAAAAAAAEGg/SWDEMjujU_M/s1600/VisualCOBOL-2010-1.png



 
http://3.bp.blogspot.com/_HUb2ygrQR50/S_VVIOBje_I/AAAAAAAAEGg/SWDEMjujU_M/s1600/VisualCOBOL-2010-1.png




Folgorato sulla via di Damasco, o meglio di Armonk.... :-)))))



L' ide sarà anche carino, ma il linguaggio, pur con qualche future in 

più,rimane quello

Un linguaggio nato nel 1960,che se non fosse per i vari applicativi che 

ancora vengono usati e manutenuti, dovrebbe oramai essere catalogato 

come linguaggio avente rilevanza storica e basta

E' come se oggi si volesse fare passare per must tecnologico un' 

automobile degli anni 20






 L' ide sarà anche carino[...]



Vedo che non cogli le ironie.



l' ho colta, ma volevo solo fare un appunto






Se vale l'esperienza personale...

In Telecom Italia nel 1998 o giu' di li', il sistema di gestione delle bollette

per i clienti privati, residenziali, era un mainframe IBM, la procedura di

calcolo delle bollette era in COBOL, le suddette poi venivano spedite ad alcune

tipografie per la stampa e la spedizione.

Lavorai all'epoca con un team che integrava una parte del sistema di gestione

delle centrali telefoniche (scritto in parte in c, in parte in java) per

integrare la raccolta dei dati di traffico ai fini della successiva

fatturazione...



Una delle rime decisioni assunte da Tronchetti Provera fu di rivedere il sistema

di gestone adottandone uno realizzato da SAP per la telecom Tedesca credo...


 tipografie per la stampa e la spedizione.



Visto che andiamo a memoria storica, mi ci aggiungo anch'io.

Nel 2001 avevamo alcuni server in un data center a Verona. Ci sono entrato solo una volta, e mi ha colpito come ci fossero moltissime macchine SUN (esisteva ancora), moltissime macchine DELL, e il resto fosse minoritario.


 NEL CERVELLONE....che voi difficilmente vedete



L'ultimo superstite dei server IBM lo avevo lasciato a via Cernaia, non 

so' se sia poi arrivato alla nuova sede di via Cavalli.

E' un po' che non li seguo piu', ma posso fare un paio di telefonate ...



M.

-- 

Credo che l'unica cosa da fare sia non prendersi troppo sul serio,

ridersi addosso, e sorridere spesso, così le rughe andranno nei posti 

giusti....

(A. Vincenzi)