Forum » Programiranje » Smiselnost in uporaba mainframov
Smiselnost in uporaba mainframov
Invictus ::
Nekaj let nazaj je bil še VAX na SKB. In en osebek zaposlen samo zanj ...
"Life is hard; it's even harder when you're stupid."
http://goo.gl/2YuS2x
http://goo.gl/2YuS2x
krneki0001 ::
Ja, sej ga je imela tudi Abanka in še par drugih bank, potem so šli pa vsi na nove tehnologije. Pa nekateri še vedno jamrajo, da je bil vax al pa mainframe zakon proti temu kar danes uporabljajo. Vsaj kar se zmogljivosti in hitrosti obdelave podatkov tiče.
Asrock X99 Extreme 4 | Intel E5-2683V4 ES | 64GB DDR4 2400MHz ECC |
Samsung 250GB M.2 | Asus 1070 TI | 850W Antec | LC Tank Buster
Samsung 250GB M.2 | Asus 1070 TI | 850W Antec | LC Tank Buster
McMallar ::
Se HIT je imel VAX, enih 8-9 let tega...
Kar se svicarskega vohanja tice, jaz tudi sedaj delam v Svici. In za vec kot povprecno placo...
Kar se svicarskega vohanja tice, jaz tudi sedaj delam v Svici. In za vec kot povprecno placo...
Why can't a programmer tell the difference between Halloween and Christmas?
Because OCT31 = DEC25
Because OCT31 = DEC25
Invictus ::
Če smo že pri arheologih, a obstaja še firma, ki dela v Clipperju in dBase?
"Life is hard; it's even harder when you're stupid."
http://goo.gl/2YuS2x
http://goo.gl/2YuS2x
Mufasa ::
Katera domena (računovodstvo, zdravstvo, JS, ...)? (Če je info delikatne narave, lahko tudi na ZS.)
Zdravstvo, JS in večji enterprise sistemi so v Slo (skoraj) izključno Java/Oracle in .net/M$. In tako bo tudi ostalo...
Ruby razen Žurnala nima večje meni znane implementacije, Python je pa bolj domena kakšnih eksotičnih moving parts startupov, Node .js je tudi hype zapustil... Največ šihtov/backendov je še vedno v Javi in nič ne kaže da bi se trend kaj obrnil. Kvečjemu Javascript dobiva na moči, saj ni več samo komplementarni ampak full stack jezik.
Pa seveda ne pozabimo na php..
"Es ist nicht genug, zu wissen, man muss auch anwenden;
es ist nicht genug, zu wollen, man muss auch tun."
- Johann Wolfgang von Goethe
es ist nicht genug, zu wollen, man muss auch tun."
- Johann Wolfgang von Goethe
Invictus ::
To je precej res. Vsi ti novi jeziki so sicer fajn v startupih, super kao reklamca (delamo v "modernih" jezikih), ampak veliki poslovni sistemi delajo na drugačnih platformah.
Javascript pa se očitno prijemlji tudi pri velikih vendorjih ala IBM kot jezik za Web in kot skriptni jezik za kostumizacijo middlewara. Očitno se ga bom moral naučiti
Javascript pa se očitno prijemlji tudi pri velikih vendorjih ala IBM kot jezik za Web in kot skriptni jezik za kostumizacijo middlewara. Očitno se ga bom moral naučiti
"Life is hard; it's even harder when you're stupid."
http://goo.gl/2YuS2x
http://goo.gl/2YuS2x
BigWhale ::
Največ šihtov/backendov je še vedno v Javi in nič ne kaže da bi se trend kaj obrnil.
A imas kaksne podatke o tem?
Pa seveda ne pozabimo na php..
Najboljs bi blo, da bi vsi takoj pozabili nanj. Najboljs. :)
BigWhale ::
To je precej res. Vsi ti novi jeziki so sicer fajn v startupih, super kao reklamca (delamo v "modernih" jezikih), ampak veliki poslovni sistemi delajo na drugačnih platformah.
Predvsem zato, ker so veliki poslovni sistemi bolj dinozavrski od samih dinozavrov. Razvoj marsicesa je precej cenejsi, hitrejsi in bolj eleganten v Pythonu ali kaksnem drugem podobnem jeziku. Pri marsikomu velja zmotno prepricanje, da je potrebno vsak vecji sistem pa napisati v nekem 'zaresnem' jeziku.
krneki0001 ::
Največ šihtov/backendov je še vedno v Javi in nič ne kaže da bi se trend kaj obrnil.
BE kode je mislim da še vedno največ v cobolu.
Invictus ::
Predvsem zato, ker so veliki poslovni sistemi bolj dinozavrski od samih dinozavrov. Razvoj marsicesa je precej cenejsi, hitrejsi in bolj eleganten v Pythonu ali kaksnem drugem podobnem jeziku. Pri marsikomu velja zmotno prepricanje, da je potrebno vsak vecji sistem pa napisati v nekem 'zaresnem' jeziku.
Veliki sistemi imajo denar, in nočejo sprememb.
Zato je programiranje v nekem obskurnem jeziku dobro plačano in ne zahteva blazno veliko znanja.
"Life is hard; it's even harder when you're stupid."
http://goo.gl/2YuS2x
http://goo.gl/2YuS2x
kunigunda ::
To je precej res. Vsi ti novi jeziki so sicer fajn v startupih, super kao reklamca (delamo v "modernih" jezikih), ampak veliki poslovni sistemi delajo na drugačnih platformah.
Predvsem zato, ker so veliki poslovni sistemi bolj dinozavrski od samih dinozavrov. Razvoj marsicesa je precej cenejsi, hitrejsi in bolj eleganten v Pythonu ali kaksnem drugem podobnem jeziku. Pri marsikomu velja zmotno prepricanje, da je potrebno vsak vecji sistem pa napisati v nekem 'zaresnem' jeziku.
Odvisno pod kaj ljudje smatrajo "vecji sistem".
sebastjan28 ::
krneki0001 je izjavil:
Največ šihtov/backendov je še vedno v Javi in nič ne kaže da bi se trend kaj obrnil.
BE kode je mislim da še vedno največ v cobolu.
V glavnih finančnih središčih že par let ne več. Večinoma prevladujeta Java in .net. WPF se tudi ogromno uporablja za interne applikacije.
Navadno se za strategijo odločijo na podlagi celotnega spektra tehnologij/funkcionalnosti, ki pridejo v paketu. Mikro prednosti/slabosti posameznega programskega jezika je v končni fazi za odločevalce dokaj nepomenbna. Za multinacionalke je precej bolj pomebnen podatek o velikosti bazena potencialnih razvijalcev in povezljivost s drugimi sistemi/orodji v podjetju.
jan_g ::
Ne gre se toliko za "velike" sisteme in neke hudo napredne in zapletene rešitve, ki zahtevajo uporabo Haskella in profesorje matematike, temveč bolj to, da imajo informacijski sistemi veliko inercijo. Ko se določeno rešitev spiše v enem ekosistemu, je zelo pogosto najceneje nadaljevati v tem istem ekosistemu. Malo je poslovnih okolij, kjer bi milisekunde odločale o delovanju poslovnih procesov, torej vplivale na prihodek podjetja. Saj ni treba daleč, da vidiš dokaz: dovolj je, da se sprehodiš do zavarovalnice, banke, upravne enote in opazuješ, koliko časa traja, da se referentki za šalterjem pojavijo podatki o stranki, pa bog ne daj, da mora kaj shraniti ;). Klikne in čaka peščeno uro ... In to so vse resne organizacije z velikimi IT sistemi.
thramos ::
Pa še hitrost, eleganca in nižja cena modernih tehnologij so v dinozavrskih sistemih in organizacijah bolj majhna spremenljivka celotnega postopka razvoja.
krneki0001 ::
sebastjan28 je izjavil:
krneki0001 je izjavil:
BE kode je mislim da še vedno največ v cobolu.
V glavnih finančnih središčih že par let ne več. Večinoma prevladujeta Java in .net. WPF se tudi ogromno uporablja za interne applikacije.
Ne bo držalo. Banke so v veliki večini še vedno na IBM maiframeih in cobolu za batch, CICSu za online kar se tiče backenda, frontendi pa so spisani v Javi in .NET-u.
Največja španska banka ima 28 paralelno vezanih IBM mainframeov (300.000 finančnih transakcij na sekundo jim recimo ne dela nobenih problemov - si zamišljaš java aplikacijo, ki sfolga 300.000 takih transakcij), skoraj vse švicarske banke so na IBM-u, nemške so nekatere šle na "sodobnejšo arhitekturo, pa so se vrnili (in sedaj iščejo nekje 15000 senior programerjev).
Glede pojma finančna transakcija mislim na zbir večih navadnih SQL transakcij (ali pa programov, odvisno kako ima kakšna banka narejeno); preverjanje komitenta , preverjanje stanja , vpis novega stanja , vpis v arhiv, ...
Nekje vsaj 7 preverjanj in par updejtov ali insertov. (torej če šteješ recimo 10 navadnih transakcij za eno finančno, je to 3 miljone SQL transakcij na sekundo - zadeva je resnično zmogljiva)
Sem v tem poslu že 19 let, zadnjih nekaj let tudi na večjih projektih v tujini tako za banke kot za zavarovalnice. In vidim koliko je še cobola za backend. Pa nič ne kaže, da bi ga java kaj dost izpodrivala. So šli nekateri na nove tehnologije, pa so po začetnih težavah nekateri prebrodili to, nekateri pa so se raje vrnili in pogoltnili izgube. Je mainframe za banke in zavarovalnice še vedno najboljši.
Druga stvar so pa borze. Tam pa ne vem in ne poznam njihovih rešitev. Bi pa rad kdaj videl, kako tam zadeve tečejo in kako so narejene.
Isotropic ::
http://www.theregister.co.uk/2011/02/25...
prej je pa imela sistem v .net/ windows, k je tut failal
sam tle je bil verjetno problem implementacije (pri obeh), ne pa "slabe" tehnologije (mislim .net, preden bo kdo kaj preveč pameten)
je kar dost napisanega na tej strani, sam se mi ne da iskat. mislim, da je delal accenture original implementacijo.
prej je pa imela sistem v .net/ windows, k je tut failal
sam tle je bil verjetno problem implementacije (pri obeh), ne pa "slabe" tehnologije (mislim .net, preden bo kdo kaj preveč pameten)
je kar dost napisanega na tej strani, sam se mi ne da iskat. mislim, da je delal accenture original implementacijo.
krneki0001 ::
Problem vseh "dinozavrov" je slaba implementacija ali pa bolane dodatne zahteve, ko je sistem že postavljen. Posledično so na takih sistemih ogromne možnosti za izboljšave. Vedno se nekaj postavi na novo in zadeva deluje briljantno. Potem se pa najde tisoč in ena dodatna zahteva uporabnikov tega sistema in ker mora to biti vse na hitro narejeno, je potem vse naštrikano na koncu.
(tako da se da iz tega kr dobre denarje potegnit, če poznaš sistem in veš kaj delaš - irci so mi plačevali za obdobje petih mesecev po 350 evrov na dan za optimizacijo kode v cobolu).
(tako da se da iz tega kr dobre denarje potegnit, če poznaš sistem in veš kaj delaš - irci so mi plačevali za obdobje petih mesecev po 350 evrov na dan za optimizacijo kode v cobolu).
kunigunda ::
krneki0001 je izjavil:
Problem vseh "dinozavrov" je slaba implementacija ali pa bolane dodatne zahteve, ko je sistem že postavljen. Posledično so na takih sistemih ogromne možnosti za izboljšave. Vedno se nekaj postavi na novo in zadeva deluje briljantno. Potem se pa najde tisoč in ena dodatna zahteva uporabnikov tega sistema in ker mora to biti vse na hitro narejeno, je potem vse naštrikano na koncu.
(tako da se da iz tega kr dobre denarje potegnit, če poznaš sistem in veš kaj delaš - irci so mi plačevali za obdobje petih mesecev po 350 evrov na dan za optimizacijo kode v cobolu).
Jest sm tud prvo kar sm pr "dinozavrih" naredu, pobrisu vse pograme v GO TO stavkih s 10000 vrsticami in naredu nove z 1000-.
Problem je glih v tem, ko so bli zacetki, in niti se ni bilo razvejanja v jeziku, if in goto, in potem so staro kodo popravljali in dodajali v
nedogled da je bila neberljiva. Cobol na velikih sistemih je sicer izredno mocen in se zdalec ni tako slab, je pa zal omejen na
single threaded zadeve (vsaj 20let nazaj je se bil na VAXih). Ce ne bi meu familije bi za 2K bug fajn lohk zasluzu po svetu ko so iskal cobolase.
krneki0001 ::
GO TO v cobolu že dolga leta ni več "dovoljen". Večinoma se ne uporablja vsaj že od leta 2000 naprej. Pa tudi iz starih programov (ki nekateri še delujejo), smo ga izločili.
med VAXom ali mainframe je danes ogromna razlika. Pa sedaj lahko več threadov združuješ za posamezne module (ki jih sprogramiraš sam) na obeh.
Če Cobol še vedno obvladaš, je delovnih mest še vedno dovolj.
med VAXom ali mainframe je danes ogromna razlika. Pa sedaj lahko več threadov združuješ za posamezne module (ki jih sprogramiraš sam) na obeh.
Če Cobol še vedno obvladaš, je delovnih mest še vedno dovolj.
Invictus ::
krneki0001 je izjavil:
Problem vseh "dinozavrov" je slaba implementacija ali pa bolane dodatne zahteve, ko je sistem že postavljen. Posledično so na takih sistemih ogromne možnosti za izboljšave. Vedno se nekaj postavi na novo in zadeva deluje briljantno. Potem se pa najde tisoč in ena dodatna zahteva uporabnikov tega sistema in ker mora to biti vse na hitro narejeno, je potem vse naštrikano na koncu.
(tako da se da iz tega kr dobre denarje potegnit, če poznaš sistem in veš kaj delaš - irci so mi plačevali za obdobje petih mesecev po 350 evrov na dan za optimizacijo kode v cobolu).
Dostikrat je pa zadeva na mainframih bolj optimalno napisana, kot jo lahko nek Linux/Windows programer napiše na clustru.
Niso vse stare zadeve avtomatsko zanič.
Zaradi rewrita kode so firme že šle zugrund ...
"Life is hard; it's even harder when you're stupid."
http://goo.gl/2YuS2x
http://goo.gl/2YuS2x
sebastjan28 ::
krneki0001 je izjavil:
sebastjan28 je izjavil:
krneki0001 je izjavil:
BE kode je mislim da še vedno največ v cobolu.
V glavnih finančnih središčih že par let ne več. Večinoma prevladujeta Java in .net. WPF se tudi ogromno uporablja za interne applikacije.
Ne bo držalo. Banke so v veliki večini še vedno na IBM maiframeih in cobolu za batch, CICSu za online kar se tiče backenda, frontendi pa so spisani v Javi in .NET-u.
Največja španska banka ima 28 paralelno vezanih IBM mainframeov (300.000 finančnih transakcij na sekundo jim recimo ne dela nobenih problemov - si zamišljaš java aplikacijo, ki sfolga 300.000 takih transakcij), skoraj vse švicarske banke so na IBM-u, nemške so nekatere šle na "sodobnejšo arhitekturo, pa so se vrnili (in sedaj iščejo nekje 15000 senior programerjev).
Glede pojma finančna transakcija mislim na zbir večih navadnih SQL transakcij (ali pa programov, odvisno kako ima kakšna banka narejeno); preverjanje komitenta , preverjanje stanja , vpis novega stanja , vpis v arhiv, ...
Nekje vsaj 7 preverjanj in par updejtov ali insertov. (torej če šteješ recimo 10 navadnih transakcij za eno finančno, je to 3 miljone SQL transakcij na sekundo - zadeva je resnično zmogljiva)
Sem v tem poslu že 19 let, zadnjih nekaj let tudi na večjih projektih v tujini tako za banke kot za zavarovalnice. In vidim koliko je še cobola za backend. Pa nič ne kaže, da bi ga java kaj dost izpodrivala. So šli nekateri na nove tehnologije, pa so po začetnih težavah nekateri prebrodili to, nekateri pa so se raje vrnili in pogoltnili izgube. Je mainframe za banke in zavarovalnice še vedno najboljši.
Druga stvar so pa borze. Tam pa ne vem in ne poznam njihovih rešitev. Bi pa rad kdaj videl, kako tam zadeve tečejo in kako so narejene.
Core procesi mogoče, samo v celotnem volumnu je to samo manjši del BackEnd dela. Večina applikacij v takšnih velikih ustanovah še vedno služi kot podpora za takšno in drugačno odločanje.
Kakšen teden nazaj sem imel pogovor na to temo s sodelavcem, ki je par let delal v Luxembourškem bančnem sektorju. Prepričal sem bil, da so Cobol programerji zelo redke, iskane in dobro plačane kreature. Po njegovih besedah, je teh mest vseeno relativno malo. Iz radovednosti, sem preveril urne postavke za contractorje na tem področju in resnično niso nič posebno visoke. Pri 350 eur se navadno postavke za senior razvijalce šele začnejo.
Mufasa ::
A imas kaksne podatke o tem?
Sure, najvec je iz izkusenj iskanja/koncepcije projektov na slo-nemskem trgu.
Se pa tut kaj tacga najde:
in pa
http://lmgtfy.com/?q=programming+jobs+l...
"Es ist nicht genug, zu wissen, man muss auch anwenden;
es ist nicht genug, zu wollen, man muss auch tun."
- Johann Wolfgang von Goethe
es ist nicht genug, zu wollen, man muss auch tun."
- Johann Wolfgang von Goethe
krneki0001 ::
sebastjan28 je izjavil:
Core procesi mogoče, samo v celotnem volumnu je to samo manjši del BackEnd dela. Večina applikacij v takšnih velikih ustanovah še vedno služi kot podpora za takšno in drugačno odločanje.
Kakšen teden nazaj sem imel pogovor na to temo s sodelavcem, ki je par let delal v Luxembourškem bančnem sektorju. Prepričal sem bil, da so Cobol programerji zelo redke, iskane in dobro plačane kreature. Po njegovih besedah, je teh mest vseeno relativno malo. Iz radovednosti, sem preveril urne postavke za contractorje na tem področju in resnično niso nič posebno visoke. Pri 350 eur se navadno postavke za senior razvijalce šele začnejo.
350€ je nekje za optimizacije. Več na Irskem niso hoteli dat. So pa tudi po 1200 na dan plačani, ampak ...
Ponavadi je Core proces kr z vsem skupaj, FrontEnd je pa v bistvu samo vmesnik brez poslovne logike, samo izgled na ekranu, BE pa vse ostalo v ozadju dela. Vsaj v velikih bankah je tako.
Če so pa poslovno logiko začeli prenašat na frontend, je pa to bolj slaba odločitev.
sebastjan28 ::
krneki0001 je izjavil:
sebastjan28 je izjavil:
Core procesi mogoče, samo v celotnem volumnu je to samo manjši del BackEnd dela. Večina applikacij v takšnih velikih ustanovah še vedno služi kot podpora za takšno in drugačno odločanje.
Kakšen teden nazaj sem imel pogovor na to temo s sodelavcem, ki je par let delal v Luxembourškem bančnem sektorju. Prepričal sem bil, da so Cobol programerji zelo redke, iskane in dobro plačane kreature. Po njegovih besedah, je teh mest vseeno relativno malo. Iz radovednosti, sem preveril urne postavke za contractorje na tem področju in resnično niso nič posebno visoke. Pri 350 eur se navadno postavke za senior razvijalce šele začnejo.
350€ je nekje za optimizacije. Več na Irskem niso hoteli dat. So pa tudi po 1200 na dan plačani, ampak ...
Ponavadi je Core proces kr z vsem skupaj, FrontEnd je pa v bistvu samo vmesnik brez poslovne logike, samo izgled na ekranu, BE pa vse ostalo v ozadju dela. Vsaj v velikih bankah je tako.
Če so pa poslovno logiko začeli prenašat na frontend, je pa to bolj slaba odločitev.
Res? Sicer ne delam konkretno v bančništvu, temveč glede na moje izkušnje je bila optimizacija(in fine tuning) poleg gole Arhitekture vedno najbolje plačano tehnično področje. Plače posameznikov, ki delajo v kakšnem investicijskem bančništvu in imajo poleg odličnega tehničnega znanja(predvsem iz kašnega multi-threadinga) tudi domensko znanje o kakšnih derivatih so seveda na popolnoma drugih nivojih. Nam navadnim smrtnikov verjetno nedosegljive:)
Govorim o BI, OLAP, Reporting, Expertnih sistemih, Sistemih za podporo odločanje, Notifikacije, Marketing, HRM, CRM.... Navadno tej sistemi asinhrono naložijo podatke v svojo relacijsko bazo in jih nato po potrebi prilagajajo(ne spreminjajo) glede na potrebe. Močno dvomim, da je to narejeno v COBOLU. V končni fazi tudi elektronsko banšništvo potrebuje na drugi strani namenske WS, ki so spisani v kakšnem .Net-u ali Javi. Tukaj imajo stranke navadno višje zahteve, kot pa interni uporabniki, ki so se prisiljeni sprijazniti s eno minutno verifikacijo vnešenih podatkov. Seveda karikiram,..
Vseeno se mi zdi odlično, da lahko še vedno ustvarite visoke prihodke,... in verjetno jih tudi boste še kakšno desetletje:)
krneki0001 ::
Bi bil presenečen, kaj vse je narejeno v zadnjih verzijah cobola oziroma kaj vse je narejeno na ZOS-u. (Z os na IBM mainframeih).
Čakamo samo še uradni izid objektnega cobola.
Čakamo samo še uradni izid objektnega cobola.
sebastjan28 ::
Zanimivo. Verjamem, da je narejeno marsikaj. Vseeno pa si ne predstavljam, kako napisati applikacije na področjih(BI, OLAP, Reporting, Expertnih sistemih, Sistemih za podporo odločanje, Notifikacije, Marketing, HRM, CRM,..), ki so zelo "grafično intenzivne".
Iz radovednosti me tudi zania še par stvari:
Kako izgledajo unit testi v takšni applikaciji?
kakšne je proces malo večje spremembe podatkovne strukture?
Kako izgleda proces vzdrževanja ob malo večjem spreminjanju poslovne logike(Npr. da se spremeni workflow določenega opravila)?
Ali ni Cobol objekten od leta 2002?
Iz radovednosti me tudi zania še par stvari:
Kako izgledajo unit testi v takšni applikaciji?
kakšne je proces malo večje spremembe podatkovne strukture?
Kako izgleda proces vzdrževanja ob malo večjem spreminjanju poslovne logike(Npr. da se spremeni workflow določenega opravila)?
Ali ni Cobol objekten od leta 2002?
Invictus ::
sebastjan28 je izjavil:
Zanimivo. Verjamem, da je narejeno marsikaj. Vseeno pa si ne predstavljam, kako napisati applikacije na področjih(BI, OLAP, Reporting, Expertnih sistemih, Sistemih za podporo odločanje, Notifikacije, Marketing, HRM, CRM,..), ki so zelo "grafično intenzivne".
Sam prikaz je "grafično intenziven". Kao. Niti ni.
Saj vse ostalo laufa v ozadju. Žal je tako, da managerji naprej padejo na lepe slikce. Sami procesi jih bolj malo brigajo. Čeprav imaš kot razvijalec tudi včasih srečo
. "Life is hard; it's even harder when you're stupid."
http://goo.gl/2YuS2x
http://goo.gl/2YuS2x
kunigunda ::
krneki0001 je izjavil:
GO TO v cobolu že dolga leta ni več "dovoljen". Večinoma se ne uporablja vsaj že od leta 2000 naprej. Pa tudi iz starih programov (ki nekateri še delujejo), smo ga izločili.
med VAXom ali mainframe je danes ogromna razlika. Pa sedaj lahko več threadov združuješ za posamezne module (ki jih sprogramiraš sam) na obeh.
Če Cobol še vedno obvladaš, je delovnih mest še vedno dovolj.
Verjetno ne bom sel nikoli vec na Cobol, ceprov mi je biu top v letih k sm delu v njem. Cist druge vode zdej.
Ampak nikoli ne reci nikoli :)
Mavrik ::
sebastjan28 je izjavil:
Iz radovednosti me tudi zania še par stvari:
Kako izgledajo unit testi v takšni applikaciji?
kakšne je proces malo večje spremembe podatkovne strukture?
Kako izgleda proces vzdrževanja ob malo večjem spreminjanju poslovne logike(Npr. da se spremeni workflow določenega opravila)?
V večini primerov? "Ne diraj ker to tako je od 1989, nahekaj novo funkcionalnost na vrhu."
Refactoring velikih sistemov (še posebej v starejših podjetjih ki ne sledijo posodobitvi poslovnih procesov) je na žalost hudo redka beštija.
The truth is rarely pure and never simple.
krneki0001 ::
sebastjan28 je izjavil:
Zanimivo. Verjamem, da je narejeno marsikaj. Vseeno pa si ne predstavljam, kako napisati applikacije na področjih(BI, OLAP, Reporting, Expertnih sistemih, Sistemih za podporo odločanje, Notifikacije, Marketing, HRM, CRM,..), ki so zelo "grafično intenzivne".
Iz radovednosti me tudi zania še par stvari:
Kako izgledajo unit testi v takšni applikaciji?
kakšne je proces malo večje spremembe podatkovne strukture?
Kako izgleda proces vzdrževanja ob malo večjem spreminjanju poslovne logike(Npr. da se spremeni workflow določenega opravila)?
Ali ni Cobol objekten od leta 2002?
Reporting laufa na cobolu brez problemov, še posebaj sedaj, ko imaš v večini mainframeov pospeševalnik za brskanje po bazah (SQL-i, ki so včasih trajali par ur, so sedaj uspešno zaključeni v parih sekundah - poišči na googlu IDAA (http://www.ibmbigdatahub.com/blog/gear-... največjo pohitritev smo imeli pri enem hudem SQL-u - 1900x hitreje se je izvedel). Napišeš dinamičen SQL, preko vnosne maske vržeš parametre, v parih sekundah imaš report nazaj (tudi če je več milard podatkov), Prikaz pa v .netu narediš in potem izvoz v pdf ali excel, če rabijo v papirnati obliki.
CRM laufa tuni na mainframeih. Spet je vmesnik za pregled dokumentov v javi ali .net, vse ostalo je na hostu. Ker je to vse v bazi, dobiš odgovore zaradi pospeševalnikov spet takoj.
unit testi delujejo tudi brez problemov. Poslovna logika se pa bolj malo spreminja, je pa itak večina zadev parametrizirana, tako da ni nekih problemov.
Sprememba podatkovne strukture je za cobol zelo majhna zadeva, ponavadi par minut dela. V bistvu so take spremembe tako majhne, da ni nekih problemov s tem. Z orodjem (tool že v samem sistemu) modul za branje ali pisanje v spremenjeno bazo popraviš in stvar dela naprej.
Sej pravim, ogromno stvari so spravili gor. To ni več tista neokretna zelena maska na ekranu, ki je bila nekoč. Ta stvar se razvija in to zelo.
Je pa še ena zadeva. IBM se je začel ukvarjat z bitcoin transakcijami, oziroma zapisom, ki ga uporablja bitcoin, da bi lahko na tak način delal "wallet" vseh transakcij - recimo glavna knjiga. Zanimivo področje in uporabno recimo za tako državo kot smo mi. Postaviš en velik mainframe gor ta software in vse slovenske transakcije morajo skozi (ni problema, ker to sfolga), v bazi imaš pa tako vse kar je šlo in in out iz vseh bank. Torej zagotavljaš sledljivost vsem transakcijam. Ni več goljufanja in transparentnost je zagotovljena.
V večini primerov? "Ne diraj ker to tako je od 1989, nahekaj novo funkcionalnost na vrhu."
Vidiš, ravno na takih primerih pa jaz služim. Stare zadeve popravljam in optimiziram ter dodajam nove funkcionalnosti. Posel zagotovljen, dela ne zmanjka.
Invictus ::
krneki0001 je izjavil:
Je pa še ena zadeva. IBM se je začel ukvarjat z bitcoin transakcijami, oziroma zapisom, ki ga uporablja bitcoin, da bi lahko na tak način delal "wallet" vseh transakcij - recimo glavna knjiga. Zanimivo področje in uporabno recimo za tako državo kot smo mi. Postaviš en velik mainframe gor ta software in vse slovenske transakcije morajo skozi (ni problema, ker to sfolga), v bazi imaš pa tako vse kar je šlo in in out iz vseh bank. Torej zagotavljaš sledljivost vsem transakcijam. Ni več goljufanja in transparentnost je zagotovljena.
Tega seveda pri nas ne bomo videli vsaj še 50 let ...
Drugače pa za ostale ... Ti "stari" sistemi, kot jih večina omenja, so daleč bolj zanesljivi kot vsaka Linux/Windows/Unix cluster zadeva. In tudi precej hitrejša. Imaš pa programska orodja praktično za vsak znan jezik.
"Life is hard; it's even harder when you're stupid."
http://goo.gl/2YuS2x
http://goo.gl/2YuS2x
jype ::
Invictus> Tega seveda pri nas ne bomo videli vsaj še 50 let ...
To smo že imeli, pa je nekdo ukinil.
Invictus> Ti "stari" sistemi, kot jih večina omenja, so daleč bolj zanesljivi kot vsaka Linux/Windows/Unix cluster zadeva.
Nope.
To smo že imeli, pa je nekdo ukinil.
Invictus> Ti "stari" sistemi, kot jih večina omenja, so daleč bolj zanesljivi kot vsaka Linux/Windows/Unix cluster zadeva.
Nope.
Veron ::
Vse lepo in prav, ampak kako zaboga sploh prideš v take "kroge"?
Ker govora je samo o strokovnjakih (recimo 10let+ izkušenj).
Ker govora je samo o strokovnjakih (recimo 10let+ izkušenj).
krneki0001 ::
NLB je imela razpis za cobol programerja. (oziroma ga ima še do 29.02.2016 - http://www.nlb.si/samostojni-razvijalec...
Prijavi se, napiši, da bi rad delal v tem, pa če te sprejmejo,...
Jype, mainframe je daleč bolj zaneljiv od vseh gor naštetih.
Prijavi se, napiši, da bi rad delal v tem, pa če te sprejmejo,...
Jype, mainframe je daleč bolj zaneljiv od vseh gor naštetih.
Invictus ::
Vse lepo in prav, ampak kako zaboga sploh prideš v take "kroge"?
Ker govora je samo o strokovnjakih (recimo 10let+ izkušenj).
Iščeš, in ko te najdejo, v 2 dneh spokaš kufre in greš. Maksimalno te čakajo 1 mesec.
Ni tukaj cincanja 3 mesece a bi, al ne bi.
"Life is hard; it's even harder when you're stupid."
http://goo.gl/2YuS2x
http://goo.gl/2YuS2x
krneki0001 ::
Jype, spet pametuješ. Lej, dejstva te postavljajo na laž. Unix ni bolj zanesljiv od ZOS-a.
IBM se že nekaj let hvali z "five nines!".
3 stvari so na mainframeih boljše.
- zaneljivost
- zaščita
- workload
Tega ne boš presegel na unixu.
Je pa unix cenejši, bolj prožen, bolj kompatibilen in "better conectivity".
IBM se že nekaj let hvali z "five nines!".
For many years Mainframes have set the standard for reliability. IBM proudly states that Mainframes can achieve “five nines” (99.999%) availability, or around 5 minutes unscheduled and scheduled downtime per year.
3 stvari so na mainframeih boljše.
- zaneljivost
- zaščita
- workload
Tega ne boš presegel na unixu.
Je pa unix cenejši, bolj prožen, bolj kompatibilen in "better conectivity".
jype ::
nebivedu> Tega ne boš presegel na unixu.
Sem že, leta nazaj. Mainframe pač nima možnosti tekmovati na področjih, ki zahtevajo visoko razpoložljivost. Komot si ga privoščiš, če si tri ure na dan odprta banka, veliko težje pa, če si 24/7 biznis, ki ga vsaka minuta nedosegljivosti stane milijone. Zanesljivost brez razpoložljivosti marsikomu ne pomeni nič.
Ja, Z mašine imajo ogromno nivojev redundance, ampak vzdrževat medsebojno sinhronizacijo parih mainframov je dražje, manj učinkovito in predvsem manj zanesljivo od nekaj stokrat močnejše gruče sodobnejših mašin, ki je že zasnovana z geografsko distribucijo v mislih.
Sem že, leta nazaj. Mainframe pač nima možnosti tekmovati na področjih, ki zahtevajo visoko razpoložljivost. Komot si ga privoščiš, če si tri ure na dan odprta banka, veliko težje pa, če si 24/7 biznis, ki ga vsaka minuta nedosegljivosti stane milijone. Zanesljivost brez razpoložljivosti marsikomu ne pomeni nič.
Ja, Z mašine imajo ogromno nivojev redundance, ampak vzdrževat medsebojno sinhronizacijo parih mainframov je dražje, manj učinkovito in predvsem manj zanesljivo od nekaj stokrat močnejše gruče sodobnejših mašin, ki je že zasnovana z geografsko distribucijo v mislih.
krneki0001 ::
Mislil sem na unix sisteme, ki so postavljeni v velikih podjetjih. Tvoj unix na 386 računalniku ne šteje.
Kaj ti misliš, da mainframe dela samo takrat, ko so vrata banke odprta? Banka ni samo biznis, ko so vrata poslovalnic odprta. Banka je 24/7 biznis. Mainframe dela pa 24/7 in ima razpoložljivost 99,999%, torej 5 minut izpada na leto.
Lahko pa dokažež, da imajo v velikih podjetjih boljše razpoložljivost od 99,999%. Daj kak link z dokazi, bomo hitro videli.
Še borze, ki imajo najbolj zanesljive mašine z unixom, imajo izpada več kot 4 ure na leto.
Kaj ti misliš, da mainframe dela samo takrat, ko so vrata banke odprta? Banka ni samo biznis, ko so vrata poslovalnic odprta. Banka je 24/7 biznis. Mainframe dela pa 24/7 in ima razpoložljivost 99,999%, torej 5 minut izpada na leto.
Lahko pa dokažež, da imajo v velikih podjetjih boljše razpoložljivost od 99,999%. Daj kak link z dokazi, bomo hitro videli.
Še borze, ki imajo najbolj zanesljive mašine z unixom, imajo izpada več kot 4 ure na leto.
jype ::
nebivedu> Kaj ti misliš, da mainframe dela samo takrat, ko so vrata banke odprta?
Ne, jaz vem, da včasih ne deluje tudi takrat, ko so vrata banke odprta. Vem tudi, da mu ni treba delat 24/7.
nebivedu> torej 5 minut izpada na leto.
Ja, kar precej več kot clustri primerljive vrednosti.
nebivedu> Še borze, ki imajo najbolj zanesljive mašine z unixom, imajo izpada več kot 4 ure na leto.
Borze, ki so na Windows, vsekakor.
nebivedu> Lahko pa dokažež, da imajo v velikih podjetjih boljše razpoložljivost od 99,999%. Daj kak link z dokazi, bomo hitro videli.
Ne rabiš pretirano velikih podjetij - ~100% globalno razpoložljivost lahko dosežeš že za par jurjev: http://www.root-servers.org/
Ne, jaz vem, da včasih ne deluje tudi takrat, ko so vrata banke odprta. Vem tudi, da mu ni treba delat 24/7.
nebivedu> torej 5 minut izpada na leto.
Ja, kar precej več kot clustri primerljive vrednosti.
nebivedu> Še borze, ki imajo najbolj zanesljive mašine z unixom, imajo izpada več kot 4 ure na leto.
Borze, ki so na Windows, vsekakor.
nebivedu> Lahko pa dokažež, da imajo v velikih podjetjih boljše razpoložljivost od 99,999%. Daj kak link z dokazi, bomo hitro videli.
Ne rabiš pretirano velikih podjetij - ~100% globalno razpoložljivost lahko dosežeš že za par jurjev: http://www.root-servers.org/
krneki0001 ::
jype> Ne, jaz vem, da včasih ne deluje tudi takrat, ko so vrata banke odprta. Vem tudi, da mu ni treba delat 24/7.
Se še ni zgodilo, da nebi deloval. O tem da ne dela ali mu nebi bilo treba delat 24/7 se pa zelo motiš. Mainframe deluje 24/7 (celo v NLB).
jype> Ja, kar precej več kot clustri primerljive vrednosti.
Namreč celo NLB ima cluster mainframeov. Torej imaš 100% zanesljivost celo v NLB. Tako da bo treba malo preverit podatke. Poglej posamezno mašino, ne clustra. V clustru prestaviš vse na enega in drugega lčahko zamenjaš, pa potem nazaj vspostaviš stanje.
jype> Borze, ki so na Windows, vsekakor.
Ja, tiste na windows imajo 4 ure izpada, ker une na unixu so dol tudi po 2 dni.
Se še ni zgodilo, da nebi deloval. O tem da ne dela ali mu nebi bilo treba delat 24/7 se pa zelo motiš. Mainframe deluje 24/7 (celo v NLB).
jype> Ja, kar precej več kot clustri primerljive vrednosti.
Namreč celo NLB ima cluster mainframeov. Torej imaš 100% zanesljivost celo v NLB. Tako da bo treba malo preverit podatke. Poglej posamezno mašino, ne clustra. V clustru prestaviš vse na enega in drugega lčahko zamenjaš, pa potem nazaj vspostaviš stanje.
jype> Borze, ki so na Windows, vsekakor.
Ja, tiste na windows imajo 4 ure izpada, ker une na unixu so dol tudi po 2 dni.
terryww ::
Da se ne bo zopet ozračje ogrelo zaradi toplega lufta - debata je analogna pc vs server mašinam. In dajmo si malo prebrat kaj je server in kaj je mainframe izven gostilniških debat.
Na kratko:
pc: strojna napaka -> bluescreen / kernel panic. Uptime: 90%
server: strojna napaka -> ECC (1 bit zna popravit, 2 bita javi). Uptime 99.9%
mainframe: x redundancy (vse se 2x procesira in rezultat primerja). Uptime 99.99999%
Zakaj so srverji nadomestili mainframe? Zato ker ob pravilno postavljeni arhitekturi presežeš uptime mainframa. Zakaj se o mainframih še danes sploh pogovarjamo? Legacy stuff. So workloadi, za katere so mainframi hitrejši? Ja. Se jih da ceneje nadomestit z x86? Ja. Zakaj potem firme plačujejo +8k za nadgradnjo na 16GB rama? Ker so CTO-ji leni/nesposobni.
Na kratko:
pc: strojna napaka -> bluescreen / kernel panic. Uptime: 90%
server: strojna napaka -> ECC (1 bit zna popravit, 2 bita javi). Uptime 99.9%
mainframe: x redundancy (vse se 2x procesira in rezultat primerja). Uptime 99.99999%
Zakaj so srverji nadomestili mainframe? Zato ker ob pravilno postavljeni arhitekturi presežeš uptime mainframa. Zakaj se o mainframih še danes sploh pogovarjamo? Legacy stuff. So workloadi, za katere so mainframi hitrejši? Ja. Se jih da ceneje nadomestit z x86? Ja. Zakaj potem firme plačujejo +8k za nadgradnjo na 16GB rama? Ker so CTO-ji leni/nesposobni.
It is the night. My body's weak.
I'm on the run. No time to sleep.
I'm on the run. No time to sleep.
kunigunda ::
krneki0001 je izjavil:
Mislil sem na unix sisteme, ki so postavljeni v velikih podjetjih. Tvoj unix na 386 računalniku ne šteje.
Kaj ti misliš, da mainframe dela samo takrat, ko so vrata banke odprta? Banka ni samo biznis, ko so vrata poslovalnic odprta. Banka je 24/7 biznis. Mainframe dela pa 24/7 in ima razpoložljivost 99,999%, torej 5 minut izpada na leto.
Lahko pa dokažež, da imajo v velikih podjetjih boljše razpoložljivost od 99,999%. Daj kak link z dokazi, bomo hitro videli.
Še borze, ki imajo najbolj zanesljive mašine z unixom, imajo izpada več kot 4 ure na leto.
Pol mam jest sreco, ker par mojih masin skupi z aplikacijami dela neprekinjeno ze 7 let ?
krneki0001 ::
Kolikokrat si kak upgrade gor dal, novejšo verzijo,...? Ni problem, če tebi en ali več računalnikov dela 24/7 več let. Se boš smejal, vendar pri moji ženi v službi dela server že nekje 15 let, pa se niti ni reštartal zadnjih 8 ali 9 let. Pentium 3 1GHz, 384MB rama, 74GB SCSI disk. Gor je pa MS server 2000, pa par programov v delphiju in baza ter client server aplikacije na računalnikih od delavcev. Zadeva deluje brez problemov, nima pa povezave v svet.
Problem je v večjih sistemih, kjer marketing hoče vedno kaj novega, novi projekti, nove zadeve, nove verzije, nove licence, ki slučajno padejo vplivnemu v ušesa, pa je potem treba postavit to na mašino, kjub temu, da jim je bilo večkrat razloženo, da ne bo nobenih pohitritev, izboljšanj,...
Problem je v večjih sistemih, kjer marketing hoče vedno kaj novega, novi projekti, nove zadeve, nove verzije, nove licence, ki slučajno padejo vplivnemu v ušesa, pa je potem treba postavit to na mašino, kjub temu, da jim je bilo večkrat razloženo, da ne bo nobenih pohitritev, izboljšanj,...
kunigunda ::
krneki0001 je izjavil:
V jedru pa ni bilo posodobitev?
Ne nc ni blo, ce je dobra verzija linuxa jo niti nikol ne upgrejdam razen ce bi ravno bug imel kernel. Glede security tud ne rabim upgrejdov. Je pa linux ze tok stara verzija bil, da je po tolkih letih bilo letos enostavneje vse skupi migrirat na nov server (novi hw, vmware, novi esx, ...). Nasploh imam fajn izkusnje glede masin zadnjih 15 let. Se pa spomnim pred tem, ko je bila glavnina Sun-iv, da so dost pogosto odpovedovali. (diski, ventilatorji, hladilniki se odlimaval itd). Res pa da ima vecino mojih BE serverjev tudi kontrolo/administracijo, tko lohk live spreminjam aplikacijem baze, pauziram threade, premikam queje med sabo itd.. Tko da se potem niti stop/start nove verzije ne pozna
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | Tudi IBM ukinja delo od doma (strani: 1 2 3 )Oddelek: Novice / Ostale najave | 33266 (27895) | Invictus |
| » | Kaj programirati?Oddelek: Programiranje | 3677 (2277) | MisterR |
| » | Prihranek v podjetju z brezplačnim softwarom (strani: 1 2 )Oddelek: Loža | 8611 (7334) | krneki0001 |
| » | NSA vohuni tudi za finančnimi transakcijamiOddelek: Novice / Zasebnost | 17227 (14167) | krneki0001 |
| » | Oracle ukinja razvoj za Itanium, Intel in HP razočaranaOddelek: Novice / Procesorji | 14496 (13168) | Poldi112 |