Prijavi se z GoogleID

» »

Petdeset let COBOL-a

strani: 1 2 3 »

tony1 ::

Pa tudi nekatere banke, ki so že šle na novejšo tehnologijo, prehajajo nazaj na VMS in kobol.


Samo my two cents: moja pamet mi pravi, da je to norost. Tudi če bi trajalo še 10 let, da bi novo kodo debagirali/zoptimizirali na ravni stare (pa s sposobnim timom ljudi ne bo tako dolgo), je to boljša rešitev, ker bi potem naslednjih 20 let lahko zadevo lažje vzdrževali.

Skratka, banke, ki še vedno uporabljajo take prazgodovinske najde, kot je cobol (na mojem faksu so ga res še učili nedolgo tega), bi se morale zavedati, da to ne bo šlo večno oz. da bo vsaka sprememba sistema vedno dražja, prišla pa bo točka ko ne bo šlo več naprej.

To se bo zgodilo recimo takrat, ko bo nastopila potreba po koreniti spremembe delovanja večjega dela sistema, npr. zaradi zakonske regulative, ki bo padla z neba. In takrat se zna zgoditi sigma, in upam, da so se vse naše banke iz tega kaj naučile.

Sam bi si v normalnem svetu predstavljal nekako takšno strategijo: za vsakega programerja, ki dela primarno v cobolu, bi firma morala imeti enega (n?), ki bi delal samo na migraciji ZASTARELIH LEGACY SISTEMOV na nekaj, kar se, če drugega ne, danes uči v šolah. In se naj na dolgi rok (zaradi mene 5 ali pa 10 let) ene mainframe pomeče stran in kupi nove.

krneki0001 ::

Tony1
Tukaj nima poante prehod na nov sistem. Zakaj, če pa stari čisto v redu, zanesljivo in hitro dela. Poleg tega se ZOs razvija, cobol se nadgrajuje in se razvija naprej. Saj to ni več tisti stari cobol, ki so ga učili včasih na šolah, ko si imel 5 ukazov in par funkcij. Nekaj stvari je ostalo, se je pa večina kar dobro spremnila, pa definitivno se še razvija naprej in nadgrajuje se kr dost redno (vsake par mesecev). S cobolom brez problemov izdeluješ stored procedure (sem jih delal že 8 let nazaj v cobolu), brez problemov se povezuješ v zunanje sisteme. Seveda pa ta, ki ga na ZOs-u uporabljamo, še vedno ni primeren za izdelovanje klientov, tudi nikoli ne bo, ker ni temu namenjen. Prvotno je zadeva namenjena premetavanju podatkov sem in tja v velikih količinah. In zato je ta jezik odličen in na tem sistemu bo ostal še dolgo časa.
Niti ne vem zakaj bi migriral na nekaj novejšega? Zakonske odločbe - kar se tiče podatkov se do sedaj še ena zadeva ni naredila, ki bi imela zato probleme. Tudi ko so uvedli XML za osnovo prenosa podatkov. Parserji v cobolu (sami smo jih naredili) to vse popedenajo. Sodelavka so celo na IBM-u trdili (ameriškem, ne našem), da se nekaj ne da narest, pa jim je poslala kodo in tehnična navodila, kako se tista zadeva naredi. SO še oni debelo gledal, kaj vse lahko tukaj pri nas naredimo.

Tudi websphere v povezavi z ZOs-om lepo deluje in programiraš lahko brez problemov v cobolu na pc-ju.

Matevžk ::

Parserji v cobolu (sami smo jih naredili) to vse popedenajo. /.../ SO še oni debelo gledal, kaj vse lahko tukaj pri nas naredimo.


Vidiš, tu je problem, trdimo nekateri. Marsikaj se da marsikje nahekat, ja, morda z dobrimi (dragimi) strokovnjaki tudi prekleto hitro. Samo koliko hroščev boste pridelali tam, kjer bi ostali uporabili že močno razhroščeno knjižnico za Javo ...
lp, Matevžk

tony1 ::

nebivedu: Osnovni in najpomembnejši razlog je tale: danes se v novih sistemih dela drugače.

Za vsak resen sistem, ki potrebuje kontinuirano vzdrževanje, je tudi (bi moral biti!) izjemno resen problem, da novih izobraženih strokovnjakov za cobol ni. Tukaj bi se morala vsakemu resnemu menedžerju (ker je talanje $$$ za projekt kot je prehod na kaj drugega kot cobol odločitev menedžerjev, ne programerjev in analitikov) prižgati rdeča lampa v glavi. Dejstvo, da se jim ne, pravzaprav pove, da je z našim IT menedžmentom nekaj narobe.

Izkušnje so pokazale, da se sicer da vsak sistem flikati na dolgo in široko, ker seveda ima kot uvljavljena stvar pač svoje prednosti, ampak nekoč bo prišla točka, ko bodo spremembe potrebne, pa se jih ne bo dalo narediti (spljoh?)/ne v zahtevanem času/ne za normalne stroške. Problem pa s flikanjem sistema pravzaprav le še vsak dan postaja večji.

Predobro poznam sistem "šparati pa naj stane kar hoče", in mislim, da je tole zelo dober primer tega.

Pa tudi življenje programerjev bi bilo potem za kak %o lažje :D

fiction ::

SO še oni debelo gledal, kaj vse lahko tukaj pri nas naredimo.
Hja, napisi XML parser v assemblerju pa bodo tudi debelo gledali.
Samo ne vem, ce bo to v pozitivnem ali negativnem smislu.

COBOL je zastarel programski jezik. Kakrsnokoli hekanje ne pomaga. Lahko je kvecjemu dober kot zgled za naprej in zgodovinski spomenik. Ne vem zakaj bi kaksno novo stvar delal s tem. Drugo je, ce ze imas obstojec sistem in potem tisto flikas.

Kar se tice hitrosti: sama sintaksa jezika tukaj nima veze s hitrostjo izvajanja (bi pa rekel, da mogoce malo negativno vpliva na hitrost razvoja). Ok, mogoce je implementacija prevajalnika super in preizkusena. Ampak tudi za druge jezike imas zelo dobre resitve. Mogoce je to tvoje mnenje o tem kako COBOL hitro dela samo posledica tega, da tvoji programi potem tecejo na nekem velikem IBM mainframu (ki je spet pohekana arhitektura s casov IBM/360, ampak pustimo to).

krneki0001 ::

Pri nas ne flikamo, pri nas razvijamo na novo. Kar je starega deluje, ni treba nič flikat.

Ampak ko že tok razpravljate o šparanju, zakaj bi na vsak način šaltali na novejše tehnologije, če stare še vedno uspešno in hitro delujejo? Nekak tako kot pravljica da če greš iz ms-a na linux in openoffice. Zakaj bi šaltal, če šele po sedmih letih prideš na isto točko, potem pa šele res kaj prišparaš.

In ja prehod na novo tehnologijo je bil sigma. Zakaj bi šel na nekaj novega in si delal škodo, če pa vse deluje.

borchi ::

> Ampak ko že tok razpravljate o šparanju, zakaj bi na vsak način šaltali na novejše tehnologije, če stare še vedno uspešno in hitro delujejo?

da bi v vaši banki* končno nehali zaposleni opravljat ogromne količine dela, ki ga je mogoče avtomatizirati? da bi končno prišel ta dan, ko bi si tvoja banka zapomnila kateri je moj naslov in ne pošiljala plačilnih kartic na napačne naslove. da bi čim manjkrat moral razčiščevat bedarije na izpiskih...

* po vsem napisanem enostavno mora iti za nlb :-)
l'jga

BigWhale ::

Problem starih in zastarelih sistemov je v tem, da iz dneva v dan stanejo vec. Starejsi kot je sistem, vec stane. Microsoft ti nudi support tudi za Windows 95, se kak patch ti napisejo, ce jih to stvar primerno placas.

Banke, ki bi laufale svoje resitve na tako starih sistemih so pa cedalje redkejse. Da bi pa hodili nazaj v prehistorik, kot pravi nebivedu je pa verjetno bolj pravljica in se dogaja tam kjer 'sparajo'.

COBOL - Completely Obsolete Business Oriented Language :>

Zgodovina sprememb…

  • spremenil: BigWhale ()

sammy73 ::

Ja, ta z bankami in naslovi je res dobra. Ko sem zamenjal naslov in novega sporočil banki, sem še nekaj let različne stvari prejemal na različne naslove.

3p ::

Kaj je tako dobrega v Cobolu - optimizirane "hand-tuned-asm" knjižice ali kaj podobnega ?
Ogromna količina stare (preverjeno delujoče) kode, in ki je ponavadi tako kompleksna (oz. jo je tako veliko), da se stvari preprosto ne izplača spisati na novo.


In najbrž ne samo tako kompleksna, ampak tudi tak zaj** za vzdrževanje...

Ampak saj vemo kje bi bili, če bi bančniki mislili, kaj bo ceneje na dolgi rok, ne le do naslednjega bonusa. >:D

tony1 ::

Pri nas ne flikamo, pri nas razvijamo na novo. Kar je starega deluje, ni treba nič flikat.

Zakaj bi šaltal, če šele po sedmih letih prideš na isto točko, potem pa šele res kaj prišparaš.


Odlično, da razvijate na novo. Hudič je v tem, da pišete še vedno po glinenih ploščicah, čeprav imajo že 20 let v vsaki normalni firmi laserje. Se pa moramo vprašati zakaj? Hja, odgovor je, da zato, ker ima *** (seveda gre za našo največjo banko, sem delal tam in morda kdaj spet bom) nekje v kleti ene dva skoraj popolnoma delujoča krematorija (beri: dve peči za žganje gline). In dokler vanju ne užge strela, se bo pač pisalo na glinaste ploščice. ;)

Šaltal bi pa zato, ker boš sicer prvih 7 let garal kot norc, zato da boš naslednjih 7 let lahko delal ko človek... Skratka, lahko tudi prvih 7 let še flikaš (dela bo seveda manj kot če bi se delalo na novo), bo pa zato naslednjih 7 let še N-krat več dela. In ko bo enkrat treba vse spremeniti, te čaka še enkrat delo prejšnjih 7ih let. In že to je lahko dovolj, da človeka ta trenutek boli glava.

Spremembe bodo vedno težje, tudi zaradi tega, ker bodo mladi nadarjeni programerji raje šli delat kaj normalnejšega (tudi za boljši denar, ker so pač nadarjeni). Stari mački, ki so cel lajf čarali v cobolu bodo tudi nekoč morali v penzijo, in tista mularija, ki se bo cobola priučila bo, hočeš nočeš iz tistih povprečnimih razvijalcev (plačati jih bo še vedno treba zelo konkretno, ker jih bo vedno premalo), kvaliteta kode pa pod nivojem, prehod v 21. stol. pa komaj na meji mogočega (pravzaprav je tam že zdaj, glej tudi spodnji odstavek, čemu).

V glavnem, da bo slepi ugotovil, da je imel zaprte oči mora najprej vsaj začeti razmišljati, da bi jih lahko nekoč odprl. Trenutno še niti pri razmišljanju nismo, zato se bojim prihodnjega infarkta.

BigWhale ::


In najbrž ne samo tako kompleksna, ampak tudi tak zaj** za vzdrževanje...


Zajebanega za vzdrzevanje v tem stilu:

Q: "Zakaj je pa ta funkcija napisana tako? Jaz bi tole popravil ali pa odstranil celo funkcijo, ker je ne nucamo!"
A: "A si nor! Noben sploh ne ve kje se tale funkcija se vse uporablja! Pol bo pa cez pol leta ob koncni letni obdelavi neki crknil!!!"

Real life primer, sicer ne iz banke ampak vseeno. Tako potem zgleda vzdrzevanje takih starih preverjenih sistemov, ki so med drugim pisani tudi v Cobolu. :)

Matako ::

Razvoja "novih boljših rešitev" v COBOLu bo kaj kmalu konec, ko bodo odšli zadnji COBOL uporabniki in programerji v pokoj. Mladih to ne zanima - pa saj imajo končno celo življenje pred sabo - škoda ga je, za staro gardo je že prepozno ;)

Skoraj prepričan sem, da takrat mitska počasnost in neprimernost ostalih programskih jezikov o kateri je bilo govora nekako ne bo problem ;)

Go figure.
/\/\.K.

Zgodovina sprememb…

  • spremenil: Matako ()

Poldi112 ::

Tudi novi se učijo cobol. Ker je pač povpraševanje.

In logika, da zdaj zamenjaš, da ne boš čez 20 let na obsolete sistemu, je tudi zgrešena. Ne glede na to, na kaj greš danes, boš čez 20 let na obsolete sistemu. Ampak dokler dela dobro in so ljudje, ki to znajo vzdrževati, je stvar sprejemljiva ni navadno najbolj smiselna.
Where all think alike, no one thinks very much.
Walter Lippmann, leta 1922, o predpogoju za demokracijo.

jype ::

Mene pa zanima, kako zgledajo unit testi v cobolu.

krneki0001 ::

borchi,
s tem nima cobol nič. To se pa ti zmeni na svoji poslovalnici, da naj v aplikaciji (narejeni v javi) popravijo tvoj naslov.

Tony1,
napaka. Delamo v zadnji verziji cobola, ki je izšla letos februarja, na sistemu, ki je izšel ravno tako februarja letošnjega leta. Napaka je v tem, ko mislite da so te zadeve 20 in več let stare. Niso, razvijajo se naprej. Tudi programerjev ni težko dobit. Še vedno jih je dovolj, tudi novi prihajajo, ki so pripravljeni programirat v cobolu.
U bistvu je zadnja verzija jave starejša in bolj "glinena" kot zadnja verzija cobola za ZOs.

Šaltal bi pa zato, ker boš sicer prvih 7 let garal kot norc, zato da boš naslednjih 7 let lahko delal ko človek... Skratka, lahko tudi prvih 7 let še flikaš (dela bo seveda manj kot če bi se delalo na novo), bo pa zato naslednjih 7 let še N-krat več dela. In ko bo enkrat treba vse spremeniti, te čaka še enkrat delo prejšnjih 7ih let. In že to je lahko dovolj, da človeka ta trenutek boli glava.


Ali poznaš tisto o človeku, ki je na plaži ležal in je prišel nekdo pametovat, da bi lovil ribe, pa kupil čoln, pa s čolnom lovil ribe, pa kupil ladjo in tako naprej?

Zakaj bi sedaj 7 let garal ko norc, če že sedaj lahko 7 let delam ko človek. Tudi flikat ni treba, narediš novo aplikacijo v cobolu in jo postaviš namesto stare, brez flikanja, še vzporedno laufaš nekaj časa, da vidiš, če so rezultati isti.

Poldi,
tega ljudje ne razumejo. Kot ne razumejo tega, da iz microsofta na opensource ni tako lahko šaltat pri 5000 zaposlenih, kot so to oni doma naredili, ko so prešli na linux in openoffice.

Zgodovina sprememb…

krneki0001 ::

Mene pa zanima, kako zgledajo unit testi v cobolu.


Tako kot v c-ju.

tony1 ::

Zakaj bi sedaj 7 let garal ko norc, če že sedaj lahko 7 let delam ko človek.


Tole bo počasi ko bob ob steno in bom nehal. Zdaj, ali nisi nikoli delal nič bolj človeškega, pa ne vem. Važno je, da je človek zadovoljen, čeprav štiha vrt s krampom - ampak kako bo vedel, da je s krampom kaj narobe, če vil nima? :)

Ko se bo tam v tistem zosu (pun intended) zgodila še kakšna štala, pa tudi če bo to čez 10 let, te bom pocukal za rokav... ;)

jype ::

nebivedu> Tako kot v c-ju.

Se mi je zdel, ja :)

krneki0001 ::

Zakaj bi sedaj 7 let garal ko norc, če že sedaj lahko 7 let delam ko človek.


Tole bo počasi ko bob ob steno in bom nehal. Zdaj, ali nisi nikoli delal nič bolj človeškega, pa ne vem. Važno je, da je človek zadovoljen, čeprav štiha vrt s krampom - ampak kako bo vedel, da je s krampom kaj narobe, če vil nima? :)

Ko se bo tam v tistem zosu (pun intended) zgodila še kakšna štala, pa tudi če bo to čez 10 let, te bom pocukal za rokav... ;)


Očitno si en izmed tistih, ki trdijo, da če ni jnajnovejša tehnologija, potem je vse zanič, al nekako tako. Programiranje v cobolu je enako kot programiranje v kateremkoli drugem jeziku in je čisto človeško. Vzameš RAD ali websphere ali eclipse in pišeš kodo po cobolovi sintaksi. Nič nečloveškega.

Na zosu ni bilo nobenih problemov ali štal, če misliš na SIGMO. Tam je bila ključna napaka človeški faktor in ne programiranje. Verjemi da poznam zelo dobro celotno zadevo in vem da bi se vsemu tistemu izognili, če bi kdaj šefi poslušali tudi ljudi, ki delajo pod njimi. BTW, Programja zloglasne sigme na zosu ni bilo.

noraguta ::

vmešam se le toliko , da je problem sigme bil tudi v tem , da ni bilo tretjega mnenja, to pa zaradi relativno nepoznane tehnologije, ampak hvalabogu da je temu tako.
Pust' ot pobyedy k pobyedye vyedyot!

noraguta ::

nebivedu sam vprašal bi mimogrede , kako gre pa kaj distibuirano preračunavanje v cobolu? pojma nimam pa ziher so neke razširitve kali?
Pust' ot pobyedy k pobyedye vyedyot!

tony1 ::

Nebivedu: Jap, priznam, da sem toliko geeka, da me konstantne spremembe fascinirajo, če prinesejo (tudi samo na dolgi rok) manj dela, pa sploh... :)

Ker kot vidiš, nisem bil nikoli več kot hobby programer (in se s tem ne preživljam več), delam pa v takem delu branže, kjer je EOL vsakih 5 ali 7 let popolnoma normalna stvar... In še vsakič je bilo na koncu vzdrževanje novega sistema lažje od prejšnjega, čeprav je lahko implementacija novega sistema (zelo) kompleksna stvar...

O sigmi pa bi bilo najbolje, da se enkrat vsedemo za en kofe :) Jasno je, da je različnih vidikov zadeve cel kup, upam pa, da se stvari zdaj vsaj poskušajo početi drugače...

krneki0001 ::

Tony1, popravki so stalni iz ibm-ove strani, nadgradenj sistema je kar nekaj na leto in nismo "zastareli", kot bi nekateri radi mislili. Sistem je nadgrajen na zadnjo različico iz februarja letos, sama mašina je iz lanskega leta. Samo prehoda na drug programski jezik ne izvajamo, ker je brez potrebe. Pa tudi kr nekaj dela bi imeli. Sam imam nekaj čez 980.000 vrstic kode spisane v cobolu, ki vsakodnevno teče (napisal v 12 letih programiranja za banko) in takih programerjev nas je kar nekaj, pa še novi prihajajo.


Kar se pa stvari tiče glede nekdanje sigme in delovanja kaj drugače. Ja, je veliko več varovalk in zadeve se morajo mnogo bolj stestirat in tudi na daljši rok se testirajo, tako da takega fiaska si ne bodo več privoščili. Res se pa lahko kdaj na kako kavo vsedemo in mal predebatiramo te zadeve.


Noraguta
Hmm, imamo 4 take mašine, vsaka mislim da ima 28 procesorjev, 14Tb rama, diskovna polja pa so recimo tako velika, da rabimo dvorano 15X40m da imamo notri spravljena in vsaka mašina ima eno particijo za linux(vse teče vzporedno na mašini - mislim več sistemov hkrati na eni mašini), tako da bi pomoje lahko delovalo na njej tudi to.

Tony1 imam pa eno vprašanje:

Ali je program za prestavljanje podatkov iz enega konca na drugega ali iz ene baze v datoteko in obratno v batchu kaj drugačno in z manj dela v javi ali c-ju ali cobolu?
Jaz mislim da dokler so to samo batch izvedbe programov, da je dela za napisat program isto v vseh teh treh jezikih (mah, na splošno v vseh jezikih je približno isto dela). Če pa govorimo o vizalnih aplikacijah, kjer imaš uporabniške vmesnike, potem pa cobol nima kaj iskat proti javi. Ampak tudi ne posega v tisto področje. In tako je tudi prav.

Zgodovina sprememb…

tony1 ::

Odgovor je jasen: seveda ne. :)

Svoj problem je tudi paketna obdelava, sploh če jo vsakdo vidi že pri plačevanju položnic (ampak dajmo to v eno drugo temo, da se bom še kaj naspal...)
strani: 1 2 3 »


Vredno ogleda ...

TemaSporočilaOglediZadnje sporočilo
TemaSporočilaOglediZadnje sporočilo
»

Triger pokliče java funkcijo?

Oddelek: Programiranje
111098 (861) krneki0001
»

Petdeset let COBOL-a (strani: 1 2 3 )

Oddelek: Novice / Znanost in tehnologija
1248861 (6079) tony1
»

Najbolj iskana računalniška znanja (strani: 1 2 )

Oddelek: Loža
535940 (4363) krneki0001
»

programski jeziki

Oddelek: Programiranje
8906 (841) Sergio
»

Mobitel po novem tudi na 051!

Oddelek: Novice / Ostale najave
133912 (3912) LojzePek

Več podobnih tem