» »

Guverner New Jerseya urgentno išče programerje za COBOL

Guverner New Jerseya urgentno išče programerje za COBOL

Slo-Tech - Guvernerji se običajno ne ukvarjajo s programskimi jeziki, a je v New Jerseyju tamkajšnji guverner poskrbel za presenečenje, ko je na tiskovni konferenci omenil, da v krizi zaradi koronavirusa potrebujejo zdravstvene delavce in programerje kobalta. Vsem je hitro postalo jasno, da misli na programski jezik COBOL (guverner Phil Murphy je sicer nekoč delal v Goldman Sachsu, a očitno za COBOL še ni slišal). Kako se je to lahko zgodilo, da tako nujno potrebujemo programje za obskuren jezik? Predvsem zato, ker ni tako zelo obskuren, kot se zdi.

Programski jezik COBOL je resda star že več kot 60 let, a je še vedno marsikod v uporabi. Številni bančni sistemi in drugi podobni veliki sistemi so bili pred desetletji napisani v COBOL-u in so takšni tudi ostali. Sistem za nadomestila nezaposlenim v New Jerseyju je eden takšnih sistemov, ki so zaradi množičnih odpuščanj spričo širjenja koronavirusa in ustavitve gospodarstva zelo obremenjeni. Število vlog je naraslo za 15-krat. To terja vzdrževanje, a strokovnjakov primanjkuje.

COBOL pa danes ni več priljubljen jezik za učenje, zato je strokovnjakov čedalje manj, večina pa je že upokojenih. Zadnji veliki povratek so izvedli konec 90. let, ko je bilo treba te sisteme pripraviti na milenijskega hrošča in so iskali programerje tudi med upokojenimi. Odtlej pa se jih je upokojilo še več, mladi programerji pa se COBOL-a v glavnem ne učijo več.

Tako to v resnici ni zgodba o COBOL-u, temveč zgodba o nadgrajevanju sistemov. Idealnega trenutka za nadgradnjo ni nikoli, a rezultat ne sme biti sistem, za katerega začne zmanjkovati usposobljenih strokovnjakov za servisiranje. V New Jerseyju, kjer se je to zgodilo, polovica vlog za nadomestilo ni pravočasno obdelanih.

56 komentarjev

«
1
2

srus ::

Invictus je že našpičil ušesa in izjavil: "Saj sem vam rekel." Verjetno ravno preračunava urne postavke, davke in prispevke v New Jerseyu. Glede na to, da je razvpiti Delaware takoj zraven, verjetno ne bo problemov z angažmanom.

WhiteAngel ::

A je COBOL res tak bavbav, da se ga nek C++ developer ne bi mogel priučiti v nekaj mesecih, da bi bil uporaben? No, saj C++ developerjev tudi ni ravno veliko ;((

perpetum ::

WhiteAngel je izjavil:

A je COBOL res tak bavbav, da se ga nek C++ developer ne bi mogel priučiti v nekaj mesecih, da bi bil uporaben? No, saj C++ developerjev tudi ni ravno veliko ;((
Sigurno ni za vsako malenkost 10 tem na Stackoverflow.

LeQuack ::

Najbrž ponujajo mizerno plačilo, sicer bi se že našel kdo. To je tko k slovenska fora k je pomanjkanje gradbenih delavcev, ki bi delali za 200 EUR na mesec.
Quack !

Zgodovina sprememb…

  • spremenil: LeQuack ()

war-dog ::

na youtube video, se mi tolmač za neme prav smili ko mora izumljat sproti znakovni jezik...
Object reference not set to an instance of an object.

war-dog ::

WhiteAngel je izjavil:

A je COBOL res tak bavbav, da se ga nek C++ developer ne bi mogel priučiti v nekaj mesecih, da bi bil uporaben? No, saj C++ developerjev tudi ni ravno veliko ;((

Ni ravno tako trivialno, sintaxa je specifična pri COBOL. Ne rabiš C++ developerja da se nauči COBOL, dovolj je že nekdo ki mu je osnovno programiranje jasno (verjetno kdo ki na bazah procedure piše, še prej pride v poštev).
NLB, Abanka in ZZZS ima polno zalogo COBOL programerjev, ampak kot je že nekdo napisal, spadajo v rizično skupino.

https://medium.com/@yvanscher/7-cobol-e...
Object reference not set to an instance of an object.

Zgodovina sprememb…

  • spremenil: war-dog ()

WizzardOfOZ ::

Cobol ni noben bavbav. 50 ukazov, mal slovenščine, mal angleščine in mal matematike, pa vsaj osnove kako programirat in lahko delaš. Ima par trikov, pa ni prav napreden, zato porabiš 300 vrstic kode za tisto kar v C# recimo narediš z enim ukazom.


NLB, Abanka in ZZZS ima polno zalogo COBOL programerjev, ampak kot je že nekdo napisal, spadajo v rizično skupino.

Programerjev cobola, vseh skupaj v sloveniji, ki še delajo, če jih je 30, je pa veliko.

codeMonkey ::

Kot nepoznavalec se sprasujem v koliksni meri je problem v poznavanju jezika in koliko v pomanjkanju sistemskega pregleda nad problematiko na katero je apliciran. Programski jezik, ce sklepam s svojega podrocja, je le en mali del problema. Nekako dvomim, da je pri bancnih oz. financnih sistemih drugace.

Zgodovina sprememb…

WizzardOfOZ ::

Sam programski jezik niti ni problem. Lahko bi sicer vzel drug jezik, prebral kaj cobol dela in to prevedel v drug jezik.
Problem pa je, ker je IBM v vsem tem času (70 let) razvil ogromno povezanost baze in samega sistema, ter ima na istem nivoju bazo in programje, tako da so dostopi do baze reda par mikrosekund. Recimo da imaš iz jave, C# in podobnih jezikov dostop enega podatka (recimo ena vrstica iz baze) iz baze DB2 reda nekje okoli 300 mikro sekund (do ostalih baz še počasneje), cobol pa ima zaradi povezanosti z DB2 bazo dostop do podatka nekje 8 mikro sekund, torej skoraj 40x hitrejši dostop do podatkov. Kar pa ne moreš kar zamenjat. Sam program se bo v javi, C++, C# že lahko izvajal, ampak do podatka boš prišel 40x počasneje. Ker pa gre ponavadi za miljone podatkov, je dostopni čas do baze res kritičen in 40 kratno upočasnjevanje izvajanja programa lahko pomeni, da boš namesto ene ure izvajal program 2 dni. Potem pa ugotoviš, da imaš napako in ponoviš vse skupaj?


Poleg tega je zelo velik problem tudi dokumentacija samih procesov, ki so potem narejeni v Cobolu. Ker tega ni prav dosti in noben ne ve točno kako vse skupaj deluje in kaj je povezano med seboj, je potrebno imeti tudi veliko znanja o samih procesih. Da pa dobiš nekega programerja, ki zna cobol in še pozna bančne procese, je pa danes težko. Že samo programerja, ki pozna bančne procese je težko dobiti.

codeMonkey ::

Ravno to v drugem odstavku je tisto kar sem mislil. Nekatere komentarje se bere kot da je glavni problem v samem jeziku, ocitno pa je problem drugje - v poznavanju procesov in sistemov. Nekako tako kot poznavanje C programskega jezika se ne pomeni, da si kar sposoben razvijati operacijski sistem.

Zgodovina sprememb…

7982884e ::

ah ja, klasicna zgodba, ko je vedno vprasanje kaj izbrati:
a) nagradimo sistem zdaj, moznost regresij, trenutni low/mid management bo najebal v tem primeru
b) dajmo raje samo "vzdrzevat" in "fixat buge" (dejansko pa vpeljevat novo kompleksnost in nov tehnicni dolg)

ker visji management ne gleda zadost dolgorocno se pac iz leta v leto izbira moznost b) in tako iz leta v leto moznost a) prinasa vec in vecjo sanso za regresije in visji strosek

v prostem trgu taka podjetja k sreci dostikrat postanejo dinozavri ki jih pojedo manjsa, agilnejsa podjetja z novo tehnologijo, v javnem sektorju pa dobis potem razpis za urgentno iskanje visoko preplacanih starckov ki ta dinozaverski jezik se znajo

Zgodovina sprememb…

  • spremenilo: 7982884e ()

Tatamata ::

Sem mislil, da je Cobol že izumrl.

Domitunus ::

Potem noben ne priporoča da se iz 0 spraviš v učenje COBOLa in bančnih procesov itd.? V Sloveniji ni dovolj možnosti zaposlitve?

bbbbbb2015 ::

WizzardOfOZ je izjavil:

Poleg tega je zelo velik problem tudi dokumentacija samih procesov, ki so potem narejeni v Cobolu. Ker tega ni prav dosti in noben ne ve točno kako vse skupaj deluje in kaj je povezano med seboj, je potrebno imeti tudi veliko znanja o samih procesih. Da pa dobiš nekega programerja, ki zna cobol in še pozna bančne procese, je pa danes težko. Že samo programerja, ki pozna bančne procese je težko dobiti.


Kar nekaj mainframovcev poznam in oni živijo in delajo zelo v redu. Ne da bi jih primanjkovalo, to skoraj sigurno ne. Mladi se sicer zelo redko priučujejo mainframea, ker v osnovi je polje dela in zaposlitve potem zelo ozko. Pa še tehnikalija je, da rabiš dostop do mainframea za razvoj. Sicer obstaja Hercules emulator, samo nekako IBM ga ne mara.

Lahko, da je kaj nedokumentirano, samo tako iz prakse vam povem, če ste plačani dovolj, dokumentacija nenadoma postane nepotrebna. Kar koda se bere.

Večji problem, kolikor jaz vidim, so urne postavke. Verjetno, glede na to, da ti zaposlenci tega gubernatorja do sedaj niso nič investirali v nadgradnje, je jasno, da ne plačujejo z zlatom. Niti toliko ne, da bi tri študente zaposlili, da bi jim spisali nekaj v Angularju/Javi/SQLu. Ker toliko nezaposlenih pa zopet ni.

Ko bo ta gubernator razvezal mošnjo, bo dobil programerjev, kolikor češ, mladih starih, COBOL, brez COBOLa. Do takrat se pa pač naj jokca po TV. Če bo kaj pomagalo.

Zgodovina sprememb…

WizzardOfOZ ::

Domitunus je izjavil:

Potem noben ne priporoča da se iz 0 spraviš v učenje COBOLa in bančnih procesov itd.? V Sloveniji ni dovolj možnosti zaposlitve?


Ne, v Sloveniji je slabo, kar se tiče Cobola. Moraš it v tujino. V tujini pa rabijo in tudi plačajo. Plačujejo pa letno od 100k dolarjev navzgor.

WizzardOfOZ ::

7982884e je izjavil:

ah ja, klasicna zgodba, ko je vedno vprasanje kaj izbrati:
a) nagradimo sistem zdaj, moznost regresij, trenutni low/mid management bo najebal v tem primeru
b) dajmo raje samo "vzdrzevat" in "fixat buge" (dejansko pa vpeljevat novo kompleksnost in nov tehnicni dolg)

ker visji management ne gleda zadost dolgorocno se pac iz leta v leto izbira moznost b) in tako iz leta v leto moznost a) prinasa vec in vecjo sanso za regresije in visji strosek

v prostem trgu taka podjetja k sreci dostikrat postanejo dinozavri ki jih pojedo manjsa, agilnejsa podjetja z novo tehnologijo, v javnem sektorju pa dobis potem razpis za urgentno iskanje visoko preplacanih starckov ki ta dinozaverski jezik se znajo


V bančništvu in zavarovalništvu se kar se backenda tiče, zadeve ne spreminjajo iz danes na jutri, ampak gre to počasi. Izredno počasi. Projekti se vlečejo par let. Testiranja so po pol leta resnih testiranj, da slučajno ne bo kje en cent odletel ven. Pri denraju se vse konča in tam mora biti vse v nulo porihtano. Zato tudi ni potrebno da bi vsako leto menjal programje. Še manj celotne sisteme, ki morajo biti izredno zanesljivi in hkrati dovolj hitri, da lahko milijone podatkov šibajo sem in tja. In taki sistemi so izredno dragi, pa ni važno od koga so, vedno so dragi.
Če kdo misli, da lahko mainframe kar na hitro zamenjaš, se izredno moti. Gre mogoče kak posamezen del, kaj večjega pa ne. To so projekti za par let, pa še potem ne bodo čisto dokončani. Sam mainframe je v bistvu zasnova oblaka. In če hočeš zamenjat mainframe, moraš na drugi strani postavit oblak, da bo vse to delovalo vsaj približno. Ker pa gre za občutljive podatke, boš rabil pa svoj lasten cloud. Cena je pa potem tam-tam, pa še mič nisi naredil s programjem. Torej vse sprogramirat, testirat,.... Kje je pa še migracija podatkov?

bbbbbb2015 je izjavil:

Kar nekaj mainframovcev poznam in oni živijo in delajo zelo v redu. Ne da bi jih primanjkovalo, to skoraj sigurno ne.


Jih manjka. In to ogromno. Še več jih bo pa manjkalo po koroni.

Zgodovina sprememb…

BigWhale ::

WizzardOfOZ je izjavil:

Poleg tega je zelo velik problem tudi dokumentacija samih procesov, ki so potem narejeni v Cobolu. Ker tega ni prav dosti in noben ne ve točno kako vse skupaj deluje in kaj je povezano med seboj, je potrebno imeti tudi veliko znanja o samih procesih. Da pa dobiš nekega programerja, ki zna cobol in še pozna bančne procese, je pa danes težko. Že samo programerja, ki pozna bančne procese je težko dobiti.


Dej ne nakladaj no... Cobol ni nobena magija, je predvsem Completely Obsolete Business Oriented Language.

Petnajst let nazaj sem se prvic srecal z njim in ja je star in cuden in ima svoje fore ampak ni pa noben misticizem. Sami bancni procesi pa tudi ne.

WizzardOfOZ je izjavil:

Recimo da imaš iz jave, C# in podobnih jezikov dostop enega podatka (recimo ena vrstica iz baze) iz baze DB2 reda nekje okoli 300 mikro sekund (do ostalih baz še počasneje), cobol pa ima zaradi povezanosti z DB2 bazo dostop do podatka nekje 8 mikro sekund, torej skoraj 40x hitrejši dostop do podatkov. Kar pa ne moreš kar zamenjat.


URL or it didn't happen. Nehaj nakladat pa pokazi benchmarks v ustreznem okolju.

Zgodovina sprememb…

  • spremenil: BigWhale ()

thramos ::

BigWhale je izjavil:

WizzardOfOZ je izjavil:

Poleg tega je zelo velik problem tudi dokumentacija samih procesov, ki so potem narejeni v Cobolu. Ker tega ni prav dosti in noben ne ve točno kako vse skupaj deluje in kaj je povezano med seboj, je potrebno imeti tudi veliko znanja o samih procesih. Da pa dobiš nekega programerja, ki zna cobol in še pozna bančne procese, je pa danes težko. Že samo programerja, ki pozna bančne procese je težko dobiti.


Dej ne nakladaj no... Cobol ni nobena magija, je predvsem Completely Obsolete Business Oriented Language.

Petnajst let nazaj sem se prvic srecal z njim in ja je star in cuden in ima svoje fore ampak ni pa noben misticizem. Sami bancni procesi pa tudi ne.


Saj ne pravi da je Cobol magija in bančni procesi mistizicem.

Ampak da imajo banke težavo z dokumentacijo informacijskih sistemov ter samih procesov. Kar ni nobena skrivnost. Posledično se morajo zanašati na specifično znanje kadra. Da je kakršenkoli kader danes težko dobit pa tudi ni nobena skrivnost, takšnega pa še bolj.

Dodajmo še rigidno plačno strukturo, ter dejstvo, da perspektivni mladi želijo delati z seksi Kubernetes ipd., ne pa z tehnologijo, katere ukinitev TODO listi praktično povsod.

WizzardOfOZ ::

BigWhale je izjavil:

WizzardOfOZ je izjavil:

Recimo da imaš iz jave, C# in podobnih jezikov dostop enega podatka (recimo ena vrstica iz baze) iz baze DB2 reda nekje okoli 300 mikro sekund (do ostalih baz še počasneje), cobol pa ima zaradi povezanosti z DB2 bazo dostop do podatka nekje 8 mikro sekund, torej skoraj 40x hitrejši dostop do podatkov. Kar pa ne moreš kar zamenjat.


URL or it didn't happen. Nehaj nakladat pa pokazi benchmarks v ustreznem okolju.


To je splošno znano vsem ki poizkušajo "zapustiti" mainframe. In to je največji problem vseh, ki bi radi pretvorili cobol kar z generatorji v javo ali C#. Ker ti že lahko cobol pretvoriš v javo ali C#. To deluje brez problemov. Potem pa še malo optimiziraš in zadeva bo delovala hitreje kot na mainframe. Vendar dostop do baze ostaja konkretno počasnejši.

Ti bom dal benche, samo da jih najdem. So nam jih enkrat predstavili.

BigWhale je izjavil:

Dej ne nakladaj no... Cobol ni nobena magija, je predvsem Completely Obsolete Business Oriented Language.


Noben ne trdi, da je magija. Ti že prebereš kaj program dela. To je najmanjši del in trivialna zadeva. Zakaj mora pa kak status spremeniti pa ne veš, ker samega procesa nimaš popisanega. In tukaj je problematika cobola, ker stare dokumentacije ni prav veliko.

Zgodovina sprememb…

BigWhale ::

WizzardOfOZ je izjavil:

cobol pa ima zaradi povezanosti z DB2 bazo dostop do podatka nekje 8 mikro sekund.


Ker sem v izolaciji in mi je dolgcas... Sem spisal en program, ki iz MySQL baze potegne ven ene podatke in zraven izmeri cas, ki ga je porabil za to...

 ✔ ~/22 > ./a
Connecting to DB...
Getting data ...
Printing ...
1 2020-03-06 11:24:27 2020-03-06 11:24:27 NULL 1 2020-03-27 08:00:00 
4 2020-03-06 11:38:49 2020-03-06 11:38:49 NULL 1 2020-03-28 08:00:00 
5 2020-04-05 01:45:20 2020-04-05 11:12:38 NULL 1 2020-03-08 08:00:00 
Time spent: 0.000018
 ✔ ~/22 > ./a
Connecting to DB...
Getting data ...
Printing ...
1 2020-03-06 11:24:27 2020-03-06 11:24:27 NULL 1 2020-03-27 08:00:00 
4 2020-03-06 11:38:49 2020-03-06 11:38:49 NULL 1 2020-03-28 08:00:00 
5 2020-04-05 01:45:20 2020-04-05 11:12:38 NULL 1 2020-03-08 08:00:00 
Time spent: 0.000017
 ✔ ~/22 > 


To je nek bedn mysql na pet let starem i5 CPUju. :> Kolk je to? 18 mikrosekund? Not too shabby, a ne? :D Zdej pa nehi s trapastimi primerjavami in se bolj neumnimi stevilkami, ki nimajo nobenega pomena.

WizzardOfOZ ::

Baza ima pa 5 zapisov, ane. Pa vse je na isti mašino v istem ramu.
Zdej pa daj milijardo zapisov v to bazo. Naredi fetch milijona podatkov pa povej kakšen je realen čas.

Na ibm zos platformi je dostop do baze in pridobitev podatka reda 38x hitrejša brez pospeševalnika. S pospeševalnikom (natezza) pa reda 1800x.
Ti bom dal bench.

WhiteAngel ::

Vsi ti časi so za lase privlečeni. Bistvo cele zgodbe pri bazah je cache. Kar zveriži nekaj Joinov v DB2, pa da vidimo, koliko mili(!)sekund bo trajalo. Če je pa podatek na disku, si pa še nekaj 10x počasnejši. Če imaš pa podatke v L1, potem je pa mikrosekunda veliko. Pač vse skupaj okoli mainframov in cobola je samo IBMov marketing. Celoten Google je gor zrasel ob consumer-grade komponentah, pa je slovel ravno po hitrosti.

WizzardOfOZ ::

Poanta ZOS-a je da ima VMS (virtual memory system) in je vse v ramu. Tudi kompletna baza. Povprečen mainframe nima par 100GB rama, ampak par 10 TB rama v eni kišti. Če imaš paralelizem (imaš banke, ki imajo po 30 paralelno vezanih mašin in vsaka po 10TB rama. Obdelajo po 300.000 finančnih transakcij na sekundo.)
ena finančna transakcija ni isto kot ena sql transakcija, ampak skupek nekih 13 sql transakcij (poizvedba ali obstaja račun, poizvedba o stanju na računu, oduzem denarja iz računa , nakazilo na drug račun , popravek stanja)

Zgodovina sprememb…

Smurf ::

WizzardOfOZ je izjavil:

Poanta ZOS-a je da ima VMS (virtual memory system) in je vse v ramu. Tudi kompletna baza. Povprečen mainframe nima par 100GB rama, ampak par 10 TB rama v eni kišti. Če imaš paralelizem (imaš banke, ki imajo po 30 paralelno vezanih mašin in vsaka po 10TB rama. Obdelajo po 300.000 finančnih transakcij na sekundo.)
ena finančna transakcija ni isto kot ena sql transakcija, ampak skupek nekih 13 sql transakcij (poizvedba ali obstaja račun, poizvedba o stanju na računu, oduzem denarja iz računa , nakazilo na drug račun , popravek stanja)

Nic od tega kar si napisal ne utemelji zakaj bi COBOL bil v takem primeru hitrejsi od recimo c++.

WizzardOfOZ ::

A ti bo to kaj pomagalo?
IBM z13 mainframe has a processor that contains 300 percent more memory than found on most servers and 100 percent more bandwidth for speedier mobile transactions.


IBM z13 mainframe is the first system able to process 2.5 billion financial transactions a day (or the equivalent of 100 Cyber Mondays every day)


Pa ne glej mainframe kot en PC. Na enem PC-ju boš že postavil zadeve, da bodo res hitre. Kako boš pa v enterprise okolju vse postavil, ko imaš APP server ločen od podatkov, kjer nimaš vsega na enem PC-ju?

Zgodovina sprememb…

Smurf ::

WizzardOfOZ je izjavil:

A ti bo to kaj pomagalo?
IBM z13 mainframe has a processor that contains 300 percent more memory than found on most servers and 100 percent more bandwidth for speedier mobile transactions.


IBM z13 mainframe is the first system able to process 2.5 billion financial transactions a day (or the equivalent of 100 Cyber Mondays every day)

Ne, ker nisi zapisal zakaj je na tem hardwaru COBOL hitrejsi od C++.

WizzardOfOZ ::

Noben ne trdi, da je cobol hitrejši. C in C++ sta definitvno hitrejša kot cobol, assembler je še hitrejši.

Govorim pa o drugi stvari, da je dostop do baze na mainframu hitrejši. In ker ni C ali C++ native prevajalnika na ZOS platformi, si nimaš z njima kaj pomagat.

WizzardOfOZ ::

En CPU v IBM R13 mainframu:

Runs on a 5.0 GHz processor
Supports up to 141 customer-configurable LE cores
Delivers I/O and high availability through 667 dedicated cores
Supports up to 8,000 production workload capable virtual machines in a single footprint
Supports a multilevel cache subsystem and 10 TB memory
Delivers massive I/O capability that can suport 30 billion RESTful web interactions a day without fail


https://www.topgun-tech.com/products/ib...

Zgodovina sprememb…

WizzardOfOZ ::

Do konca nafilana mašina (vsi proci in jedra vklopljeni + 10TB rama) ima približno 111.000 mipsov. To mislim ena mašina.

Spura ::

To tko pisete kot da delate real-time sisteme. Noben bancni sistem ni niti priblizno real-time, imajo cele ure da naredijo transakcijo. Neki NLB nima niti priblizno potrebe po 300k transakcijah na sekundo. Transakcije imajo en kup vmesnih statusov, in imajo moznost da po avtorizaciji spodletijo zaradi premalo sredstev na racunu, in podobni fall-backi.

bbbbbb2015 ::

WizzardOfOZ je izjavil:

Poanta ZOS-a je da ima VMS (virtual memory system) in je vse v ramu. Tudi kompletna baza. Povprečen mainframe nima par 100GB rama, ampak par 10 TB rama v eni kišti. Če imaš paralelizem (imaš banke, ki imajo po 30 paralelno vezanih mašin in vsaka po 10TB rama. Obdelajo po 300.000 finančnih transakcij na sekundo.)
ena finančna transakcija ni isto kot ena sql transakcija, ampak skupek nekih 13 sql transakcij (poizvedba ali obstaja račun, poizvedba o stanju na računu, oduzem denarja iz računa , nakazilo na drug račun , popravek stanja)


Ne vem, če si ti sploh kdaj programiral sploh kakšne enterprise aplikacije. Gremo po vrsti:

1) COBOL je hitrejši na z/OS zato in izključno zato, ker compiler generira kodo, ki je točno prilagojena procesorju. Hkrati ko oni dodajajo instrukcije na procesor (ki je tipa CISC), hkrati izboljšujejo compiler za COBOL. Tule ti lepo piše:
https://share.confex.com/share/117/webp...

C/C++ je splošno namenski programski jezik, ki je sicer bolj nastajal v RISC okolju, ampak je seveda na voljo tudi na CISC (med drugim x86 in x86-64 arhitekturah). COBOL je ožjenamenski jezik, namenjen boljkone podatkovnemu procesiranju.

2) RAM seveda pospešuje procesiranje, pa to tudi na PC platformi. Mainframe ima res več RAM, PC platforme nikoli niso imele toliko RAM. Mainframe ima "drawerje" predale:


Eden od limitov, zakaj sploh ne moreš dati toliko RAM v PC je, da moraš te RAMe napajati. Napredek RAMov na PC platformi se odraža v čedalje nižji potrošnji. Tako imaš recimo stare IBM X platforme, ki so nekoč imele limit 192GB RAM, zdaj pa že imaš 256GB RAMe. Ker en modul troši manj. V PCju je memory kontroler v CPUju, v mainframe-u je izven CPUja.

3) Baze, vključno z DB2, imajo ravno tako diske, tudi SSD disk arraye. To ni nič drugače kot pri PCjih. To ti bo Esmeraldica lepo razložila:


Kar pa ima mainframe drugače, pa je, da ima večje število kanalov, med drugim, to pa so lepo pobrali od PCjev - PCI kanale, na katere imajo priklopljeno razno periferno opremo.

4) Četrti razlog, zakaj je mainframe hitrejši, je da ima asistenco procesiranju podatkov v hardveru, kanalne procesorje. To sem že malo pozabil, kako to gre. V grobem, obstaja cela vrsta hardverskih aceleratorjev, za katere plačuješ licence. Licenčni model je tako kompliciran, da imaš firme, ki ti samo okrog tega svetujejo:
https://www.value-4it.com/wp/?cat=47

5) Peti razlog, zakaj je mainframe dosti hitrejši je, da imajo na vsako stvar, diskovno enoto, kanalne procesorje nenormalno količino RAM kot keš. Vem samo, da ko je EMC prodajal drop-in zamenjavo Symmetrix, so dali RAM na pol IBMovega. Recimo tole:
EMC Symmetrix @ Wikipedia

Torej, njihove mašine imajo 16TB RAMA. Ena mašina. Ko sem še jaz delal s simetriksi, je tipično en mainframe imel dva simetriksa priklopljena.

Vse to in še več pa seveda.... Dosti stane. V Sloveniji ni takega biznisa, ki bi kaj takega sploh rabil. No, mogoče pa se motim, ker nisem bil v Sloveniji že pet let ne.

user1618 ::

To bi bilo za kakšne ABAP programerje, če bi iskali job, ali če bi iskali nekaj za višjo plačo.
"If we were supposed to talk more than listen
we would have been given two mouths and one ear"
- Mark Twain

c3p0 ::

bbbbbb2015 je izjavil:


Torej, njihove mašine imajo 16TB RAMA. Ena mašina. Ko sem še jaz delal s simetriksi, je tipično en mainframe imel dva simetriksa priklopljena.


16TB je dosti, pa RAM tudi ni vse. Ampak dandanes v en HP G10 dobiš 3TB RAMa.

EDIT: Vidim da zdaj že celo 12TB.

Zgodovina sprememb…

  • spremenil: c3p0 ()

WizzardOfOZ ::

Spura je izjavil:

To tko pisete kot da delate real-time sisteme. Noben bancni sistem ni niti priblizno real-time, imajo cele ure da naredijo transakcijo.

Banke se trudijo, da bi imele real-time sisteme za transakcije. In ni več daleč ko bodo to imele. Instant payment bo upam da še letos. In nimajo celih ur za narest transakcijo. Dvig na bankomatu je transakcija, pa upam da ne čakaš ure pred bankomati da ti ven dajo denar.

Spura je izjavil:


Neki NLB nima niti priblizno potrebe po 300k transakcijah na sekundo. Transakcije imajo en kup vmesnih statusov, in imajo moznost da po avtorizaciji spodletijo zaradi premalo sredstev na racunu, in podobni fall-backi.


Verjetno ne 300k, nekih 20k pa sigurno. Bankomati, položnice, dvigi na poslovalnicah, plačila preko klika, ostale online transakcije,... To je vsaj kak milijon transakcij na dan, ki pa niso lepo porazdeljene. Verjetno je dvigov na bankomatih več ko gredo ljudje ob 15h iz službe, pa je treba vsa stanja takoj updejtat.
Če ti dvigneš denar na bankomatu, potem pa čez 2 minuti plačaš na poslu, mora stanje štimat.

Če racunaš da ima NLB verjetno okoli milijon komitentov in ima na 18-tega v mesecu vsak po ene dva trajnika(direktne bremenitve) je to vsaj 2 milijona finančnih transakcij, ki jim mora speljati v parih minutah. In verjetno jih poleg vseh drugih transakcij. Drugače bi se ljudje že pritoževali.
Potem plače, penzije, socialna,... To se mora vse obdelati zelo hitro.

@bbbbbb2015 in kaj je VMS? Vse to kar si naštel. Vse je v ramu. In vsaka stvar vsaj potrojena z load balancerjem vred za vsako stvar.

Zgodovina sprememb…

Spura ::

Ampak zakaj rabis ne vem kak DB performance za to? Navaden commodity hardware to cisto lepo handla. Tipicno folk kupuje hardware acceleratorje ker je software shit, poznam te primere. Pac folku se ne da arhitekture pa poslovnih procesov prilagajat da so scalable, raje vse delajo na eno bazo, kot da je vse atomarno pa da so transakcije v serializable nacinu, pol pa kupujejo mainframe, da handla to. 1 mio evrov na leto za osnoven hardware pa 1 mio na leto samo licenca za zOS za dobrojutro.

To je podobna fora kot doloceni drzavni organi, ki so brihtno vse napisali v Oracle PL/SQL in da to dela z enim samim virom podatkov, in potem ko to ni moglo hendlat glomaznih queryev so se zacele debate o kupovanju pregresno dragih Oracle hardware resitev za query acceleration. Pac lazje kot pravilno zasnovat sistem, kar bi pac bilo nad nivojem lokalno dostopnih SQL majstrov.

O shardingu ni ne duha na sluha.

Zato tudi ni potrebno da bi vsako leto menjal programje.
To je tak strawman, kot da je kdo predlagal da banke menjajo software s hitrostjo povprecnega startupa. Kot da je edina alternativa temu, da gonis isti software 40 let, to da ga vsako leto menjas. Furajo 30-40 let star software in tocijo krokodilje solze da bi bilo predrago ga zamenjat. Pac raje dajo IBMu par deset miljonov na leto za to, da obstojeci shit laufa, kar je celoten poslovni model firm kot IBM in Oracle. Najprej ustvaris problem potem ga pa za velike denarje resujes.

Ne vem kako potem brez tega cobola in mainframeov tem N26, Revolut in Nubank sploh kej uspe narest, ce je to tok kljucna sestavina.

WizzardOfOZ ::

Ja, imaš prav.

sbawe64 ::

Spuraak info, akj uporabljajo Kitajci za
To je podobna fora kot doloceni drzavni organi, ki so brihtno vse napisali v Oracle PL/SQL in da to dela z enim samim virom podatkov, in potem ko to ni moglo hendlat glomaznih queryev so se zacele debate o kupovanju pregresno dragih Oracle hardware resitev za query acceleration. Pac lazje kot pravilno zasnovat sistem, kar bi pac bilo nad nivojem lokalno dostopnih SQL majstrov.

Imaš kak info, kakšne baze uporabljajo Kitajci za javno upravo, da zadostuje njihovim potrebam (pri 1.4 milijarde vs slo 2 milijona prebivalcev/strank) ?

SloKin ::

Spura je izjavil:

...

Pa ti ves zakaj so izbrali Oracle bazo?

Mddsz naj bi informacije pridobival iz 24 razlicnih baz. Pa jim zadeve baje slabo delajo. Ti pravis, da je resitev vec baz al kako?

Daj nas razsvetli kako naredis nadgradnjo baze recimo iz verzije 10.0 na 11.0 z minimal downtime? Kolk bo tvoj downtime? Ko bos povedal za eno bazo mi povej kaksen bo postopek v shardu? Kolk instanc baz bos rabil?

Btw veliko bank je ze poskusilo s prenovo in veliko jih je odnehalo... Ce mislis, da si prvi z revolucionarno idejo se motis. Pravis, da banke ne znajo racunat?

Invictus ::

Spura je izjavil:


Ne vem kako potem brez tega cobola in mainframeov tem N26, Revolut in Nubank sploh kej uspe narest, ce je to tok kljucna sestavina.

Nimajo zgodovine in malo storitev...

Zgodovina pobere 90% resourcov.

Sam tebi to ni jasno...
"Life is hard; it's even harder when you're stupid."

http://goo.gl/2YuS2x

#000000 ::

poznam tri, 1k eur na uro in vse free :)

WizzardOfOZ ::

Organizations using Microsoft SQL Server, on average, experience 4.5 times higher planned downtime
and 6.6 times higher unplanned downtime than Db2 organizations. Estimated costs of downtime for
Db2 11.1 average 78 percent less for planned outages, and 82 percent for unplanned outages,
compared to SQL Server


vir: https://www.ibm.com/downloads/cas/R53AX...

Zgodovina sprememb…

Vazelin ::

In kok da plače ta guverner?
I got 99 problems but 4 usd XTZ ain't one.

XIIT ::

Vazelin je izjavil:

In kok da plače ta guverner?

Izkušnje, referenco ter dober občutek, ker si pomagal državi v težkih časih. ;((
The only permanency in politics is permanent self interest, never fairness.

Spura ::

Invictus je izjavil:

Spura je izjavil:


Ne vem kako potem brez tega cobola in mainframeov tem N26, Revolut in Nubank sploh kej uspe narest, ce je to tok kljucna sestavina.

Nimajo zgodovine in malo storitev...

Zgodovina pobere 90% resourcov.

Sam tebi to ni jasno...

Aha, ampak argument je, da rabis mainframe da sploh lahko ta volumen transakcij sprocesiras. Kaj ima tukaj torej zgodovina? Nic.

Imas pa prav da je razlog, da nimajo zgodovine, ker ocitno gre za kontinuacijo zgodovine pri teh sistemih in je razlog da rabis mainframe to, da si do zdaj imel mainframe.

perpetum ::

Mimogrede. Imamo po novem v Sloveniji Flik, ki omogoca instant transakcije med vsemi (skoraj) bankami v Sloveniji 24h dnevno. Tako da ocitno v kameni dobi ze niso nase banke. Je pa vecino dela tukaj opravil Bankart se mi zdi. Kaksna je pa njegova vloga v Slovenskem bancnem sektorju mi pa ni cisto jasno.

Zgodovina sprememb…

  • spremenilo: perpetum ()

Invictus ::

Spura je izjavil:

Invictus je izjavil:

Spura je izjavil:


Ne vem kako potem brez tega cobola in mainframeov tem N26, Revolut in Nubank sploh kej uspe narest, ce je to tok kljucna sestavina.

Nimajo zgodovine in malo storitev...

Zgodovina pobere 90% resourcov.

Sam tebi to ni jasno...

Aha, ampak argument je, da rabis mainframe da sploh lahko ta volumen transakcij sprocesiras. Kaj ima tukaj torej zgodovina? Nic.

Imas pa prav da je razlog, da nimajo zgodovine, ker ocitno gre za kontinuacijo zgodovine pri teh sistemih in je razlog da rabis mainframe to, da si do zdaj imel mainframe.

Če je baza in cel kup zadev na mainframu, potem se tega ne dotika. Niti se ne pusti, ker so podatki VEDNO kritični za poslovanje podjetja.

Sploh ne s kakim milenijskim razvojnim timom z javascriptom ;).

Glej, so že poskusili napisati zamenjavo za mainframe. V Nemčiji na ta račun propadlo nekaj firm in tudi družin lastnikov...

Navaden PC, pa naj bo še tako hud, v ne vem kakem clustru, pade takoj na številu transakcij.

Drugače pa so banke in zavarovalnice glede obdelav dostikrat tudi zakonsko vezane. Teh obdelav transkacij pač ne daš na Amazon Cloud :D.

Saj bi ti tukaj en član foruma malo razložil, pa ste ga preveč popljuvali, da bi se še javljal.

perpetum je izjavil:

Mimogrede. Imamo po novem v Sloveniji Flik, ki omogoca instant transakcije med vsemi (skoraj) bankami v Sloveniji 24h dnevno. Tako da ocitno v kameni dobi ze niso nase banke. Je pa vecino dela tukaj opravil Bankart se mi zdi. Kaksna je pa njegova vloga v Slovenskem bancnem sektorju mi pa ni cisto jasno.

On skrbi za kartičnbo poslovanje, ne za ostale transakcije... In to je tudi njegov namen.

Kako pa delajo, pa raje ne bi...

BTW, tako slabo, da jim je 1x VISA blokirala vse slovenske VISA kartice, ker niso ustrezali PCI standardu...
"Life is hard; it's even harder when you're stupid."

http://goo.gl/2YuS2x

Zgodovina sprememb…

  • spremenil: Invictus ()

thramos ::

WizzardOfOZ je izjavil:


Če racunaš da ima NLB verjetno okoli milijon komitentov in ima na 18-tega v mesecu vsak po ene dva trajnika(direktne bremenitve) je to vsaj 2 milijona finančnih transakcij, ki jim mora speljati v parih minutah. In verjetno jih poleg vseh drugih transakcij. Drugače bi se ljudje že pritoževali.
Potem plače, penzije, socialna,... To se mora vse obdelati zelo hitro.

@bbbbbb2015 in kaj je VMS? Vse to kar si naštel. Vse je v ramu. In vsaka stvar vsaj potrojena z load balancerjem vred za vsako stvar.


Komitentov ima bistveno manj. Obdelave direktnih bremenitev pa trajajo ure :). Razen novih instant payments, ki morajo biti procesirani v sekundah, nič v slovenskih bankah ne gre hitro.

Spura je izjavil:

To je tak strawman, kot da je kdo predlagal da banke menjajo software s hitrostjo povprecnega startupa. Kot da je edina alternativa temu, da gonis isti software 40 let, to da ga vsako leto menjas. Furajo 30-40 let star software in tocijo krokodilje solze da bi bilo predrago ga zamenjat. Pac raje dajo IBMu par deset miljonov na leto za to, da obstojeci shit laufa, kar je celoten poslovni model firm kot IBM in Oracle. Najprej ustvaris problem potem ga pa za velike denarje resujes.

Ne vem kako potem brez tega cobola in mainframeov tem N26, Revolut in Nubank sploh kej uspe narest, ce je to tok kljucna sestavina.


AFAIK je NLB edina slovenska banka, ki še uporablja mainframe v takšni obliki. Tiste, ki uporabljajo software tujih mam so itak poglavje zase, ostale pa "razmeroma" dobro sledijo razvoju in so se že zdavnaj znebile COBOLov in Clipperjev.

N26 uporablja, če se ne motim, Postgres + Javo.

Zgodovina sprememb…

  • spremenil: thramos ()

thramos ::

perpetum je izjavil:

Mimogrede. Imamo po novem v Sloveniji Flik, ki omogoca instant transakcije med vsemi (skoraj) bankami v Sloveniji 24h dnevno. Tako da ocitno v kameni dobi ze niso nase banke. Je pa vecino dela tukaj opravil Bankart se mi zdi. Kaksna je pa njegova vloga v Slovenskem bancnem sektorju mi pa ni cisto jasno.


Bankart je v lasti (nekaterih) slovenskih bank in ga uporabljajo za skupni procesni center - ne samo za kartice, ampak ima svojo vlogo tudi pri direktnih bremenitvah, instant paymenti ipd. Nekaj dela res opravi namesto bank, ampak še vedno morajo sprocesirat vsaka svojo zadevo. Ampak ima Invictus spet vsaj glede nečesa prav. :))

WizzardOfOZ ::


- COBOL supports close to 90% of Fortune 500 business systems today.
- 70% of all critical business logic and information are written in COBOL.
- COBOL is 65% of active code used today; and runs 85% of all business transactions.
- 200 billion lines of COBOL code are still in use today by various industries.


thramos je izjavil:

Komitentov ima bistveno manj. Obdelave direktnih bremenitev pa trajajo ure :). Razen novih instant payments, ki morajo biti procesirani v sekundah, nič v slovenskih bankah ne gre hitro.


Ne verjamem, da bi direktne bremenitve delale več kot 10 minut, razen, če so zelo slabo napisani programi.

Pa komitentov je vsaj 1.2 milijona.

Zgodovina sprememb…

«
1
2


Vredno ogleda ...

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

Guverner New Jerseya urgentno išče programerje za COBOL (strani: 1 2 )

Oddelek: Novice / Ostala programska oprema
564658 (1707) ginekk
»

COBOL še vedno poganja precej bančnih sistemov

Oddelek: Novice / Ostala programska oprema
306377 (3593) trstenjak
»

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

Oddelek: Novice / Znanost in tehnologija
1249331 (6549) tony1
»

Nasvet glede izbire programskega jezika (strani: 1 2 )

Oddelek: Programiranje
524232 (2982) NoUse4AName

Več podobnih tem