Nový IBM mainframe Z16

[mikrom]

Kdo by s tím chtěl dělat dobrovolně? Ergonomie 60 let 20 století v 20 letech 21 století.

Ano je to tak, ked som bol prvykrat konfrontovany s AS/400 pred vyse 20 rokmi nechapal som, ako sa moze este tak tazkopadne pracovat. Postupne som si na to zvykol a potom cca o 10 rokov neskor ked som sa prvykrat prihlasil na mainframe som zistil, ze sposob prace na tejto platforme je este ovela ovela tazkopadnejsi ako na AS/400.
Obe tieto platformy nie su moc pritazlive na pestovanie nejakeho hobby, ale ludia na tom robia hlavne preto ze sa im za to plati.     

Co se týče vývoje softu. Existuje projekt Zowe, který i do mainframů přináší VS Code viz.
https://www.zowe.org/

Standardom je Rational Developer for System z od IBM. Je to IDE zalozene na eclipse a dost drahe. Ja mam v praci podobne IDE: Websphere Development Studio Client co je predchodca Rational System for System i. Vtedy to davala IBM este zadarmo ku kompilatorom, teraz sa za nove verzie uz plati.
Kazdopadne ked sa chces naucit s mainframe alebo AS/400 pracovat, treba zo zaciatku uprednostnovat pracu na green screen.   
 

[Reklama]

[RDa]

@mikrom - koukam ze v tom docela jedes! krasne se tohle vlakno chytlo :)

Muzes napsat neco o tom - jak se veci ladi / instaluji do produkce? Mate vzdy nejaky test-set na kterem se zkousi nova funkce, resp. provadi se tam automatizovane testy i puvodni, zda se neco nerozbilo? Predpokladam ze AS400 / Z-os vyvojar aplikaci nebude mit pristup k zivym datum uzivatele (banky/automobilky), ale nejak je prece potreba resit deployment i testovani.

A pak dalsi vec je - co vykon? kdyz nekdo nakodi neco, co ma bezet denne, ale sezere to 25 hodin.. tak to jaksi nepujde. Jak se resi takove situace?

[mikrom]

@RDa: Mam skusenosti len s IBM i (aka AS/400). Co sa tyka systemu IBM z, mal som tam konto len kratko a moc som sa s tym nestihol zoznamit. 
 

Muzes napsat neco o tom - jak se veci ladi / instaluji do produkce? Mate vzdy nejaky test-set na kterem se zkousi nova funkce, resp. provadi se tam automatizovane testy i puvodni, zda se neco nerozbilo? Predpokladam ze AS400 / Z-os vyvojar aplikaci nebude mit pristup k zivym datum uzivatele (banky/automobilky), ale nejak je prece potreba resit deployment i testovani.

Mame 3 prostredia: DEVelopment, TEST, PRODuction, ktore su na roznych strojoch.

Podla potreby (t.j. hlavne po nasadeni vacsich releasov do PROD) sa data z PROD nakopiruju do DEV a TEST a tam sa anonymizuju.

Aplikacia sa vyvija a ladi v DEV. Tu vyvojari vytvaraju nove subory a programy alebo rozsiruju existujuce.
Ked je cela aplikacia uz v prostredi DEV odladena, prenesie sa do prostredia TEST a tam ju testuju k tomu urceni testeri.
Po otestovani v TEST sa prenesie aplikacia do PROD a tam sa podla planu nasadi.

Na prenos medzi tymito prostrediami mame specializovany softver, ktory prenasa fyzicke, logicke subory a rozne typy programov. Ak sa jedna o nove subory tak ich v danom prostredi vytvori, programy (podla typu programu) bud v danom prostredi skompiluje proti danym tabulkam, alebo prenesie len binarku programu.

A pak dalsi vec je - co vykon? kdyz nekdo nakodi neco, co ma bezet denne, ale sezere to 25 hodin.. tak to jaksi nepujde. Jak se resi takove situace?

Mali sme asi len raz taky pripad par rokov dozadu, ze u nas vyvinuli batch aplikaciu v Jave ktora bezala niekolko hodin a preto bola prakticky nepouzitelna. Boli sme preto nuteni ju prepisat do COBOLu kde bezala len niekolko minut. Odvtedy take pripady nemame, lebo batche robime prioritne v COBOLe.

[Pavel Stěhule]

Mali sme asi len raz taky pripad par rokov dozadu, ze u nas vyvinuli batch aplikaciu v Jave ktora bezala niekolko hodin a preto bola prakticky nepouzitelna. Boli sme preto nuteni ju prepisat do COBOLu kde bezala len niekolko minut. Odvtedy take pripady nemame, lebo batche robime prioritne v COBOLe.

V tomhle případě má ten COBOL k datům extrémně blízko, tak to může být opravdu dost rychlé. Je to vlastně analogie uložené procedury naprogramované v C s velice low low přístupem. A vzhledem k tomu, že to je COBOL, tak si nikdo nedovolí vymýšlet nějaké špeky. A COBOL sám je velice efektivní personální filtr .

[svalvjard]

Mali sme asi len raz taky pripad par rokov dozadu, ze u nas vyvinuli batch aplikaciu v Jave ktora bezala niekolko hodin a preto bola prakticky nepouzitelna. Boli sme preto nuteni ju prepisat do COBOLu kde bezala len niekolko minut. Odvtedy take pripady nemame, lebo batche robime prioritne v COBOLe.

Ja ti nevim, ale ty aplikace v COBOLu zustavaj protoze vedeni nevi jak to prepsat (pripadne nejsou zdrojaky). Zadny jiny vyhody to fakt podle mne nema (bavime se o AS400). Jazyk jako takovej je sracka, a IDE je taky nahovno (at uz terminal nebo ten predrazenej eclipse shit od IBM).

Predpokladam ze ta Java bezela na stejnym LPARu v AIXu.

---

@Pavel.Stehule no zrovna cobol ti dovoli fakt slusny hnoje

[Reklama]

[Pavel Stěhule]

@Pavel.Stehule no zrovna cobol ti dovoli fakt slusny hnoje

U manuálu COBOLu jsem skončil na 10 stránce, a dál jsem to nedal., takže toho o COBOLu vím málo. Ale pověst ho předchází, takže jsem to myslel spíš na management, že se drží zpátky a není moc kreativní.

[mikrom]

ale ty aplikace v COBOLu zustavaj protoze vedeni nevi jak to prepsat

Prepisovanie z COBOLu do Javy je problematicke. Nejde len o prepisovanie, ale treba to aj dobre otestovat. Program bezi spolahlivo napr. 30 rokov, ludia ktori robili na to zadanie a vedeli to otestovat tu uz nie su. Bolo by to velmi drahe a riskantne. Zbytocne vyhodene peniaze a vystavovanie sa riziku ked to neprinesie ziadny profit.
Niekolko krat som musel prepisovat nejake moduly z COBOLu do Javy, ani nie tak na nahradenie COBOlu ale preto ze v Jave bolo potrebne naimplementovat tu istu biznis logiku. Mnohokrat bol zdrojak ktory v Jave vznikol este zlozitejsi ako povodny v COBOle - napr. co sa tyka databazovych pristupov a vypoctov.
Napr. COBOL ma nativne implementovanu decimal aritmetiku, je dost bolestive prepisovat nejake vypocty typu

Kód: [Vybrat]

COMPUTE bz = lf * ( ((zs - znst + zb) * bwf) / (bs / pg))
do Javy, vymyslat tam zaokruhlovanie a orezavanie, aby to v konecnom dosledku pocitalo presne ako v COBOle a testovat to. Vznikne nieco taketo:

Kód: [Vybrat]

bw = lf.multiply(((zs.add(znst.negate()).add(zb)).multiply(bwf)).divide(bs.divide(pg,BigDecimal.ROUND_DOWN),BigDecimal.ROUND_DOWN));
bw = bw.setScale(3, RoundingMode.DOWN);
.. a ked po urcitej dobe musis citat ten vypocet v Jave a povedat co to vlaste pocita ...

Java a COBOL sa vzajomne vyborne doplnaju, kazdy jazyk je dobry na nieco ine. Lepsie je Javu s COBOlom integrovat ako prepisovat z COBOlu do Javy.

[svalvjard]

ale ty aplikace v COBOLu zustavaj protoze vedeni nevi jak to prepsat

Prepisovanie z COBOLu do Javy je problematicke. Nejde len o prepisovanie, ale treba to aj dobre otestovat. Program bezi spolahlivo napr. 30 rokov, ludia ktori robili na to zadanie a vedeli to otestovat tu uz nie su. Bolo by to velmi drahe a riskantne. Zbytocne vyhodene peniaze a vystavovanie sa riziku ked to neprinesie ziadny profit.
Niekolko krat som musel prepisovat nejake moduly z COBOLu do Javy, ani nie tak na nahradenie COBOlu ale preto ze v Jave bolo potrebne naimplementovat tu istu biznis logiku. Mnohokrat bol zdrojak ktory v Jave vznikol este zlozitejsi ako povodny v COBOle - napr. co sa tyka databazovych pristupov a vypoctov.
Napr. COBOL ma nativne implementovanu decimal aritmetiku, je dost bolestive prepisovat nejake vypocty typu

Kód: [Vybrat]

COMPUTE bz = lf * ( ((zs - znst + zb) * bwf) / (bs / pg))
do Javy, vymyslat tam zaokruhlovanie a orezavanie, aby to v konecnom dosledku pocitalo presne ako v COBOle a testovat to. Vznikne nieco taketo:

Kód: [Vybrat]

bw = lf.multiply(((zs.add(znst.negate()).add(zb)).multiply(bwf)).divide(bs.divide(pg,BigDecimal.ROUND_DOWN),BigDecimal.ROUND_DOWN));
bw = bw.setScale(3, RoundingMode.DOWN);
.. a ked po urcitej dobe musis citat ten vypocet v Jave a povedat co to vlaste pocita ...

Java a COBOL sa vzajomne vyborne doplnaju, kazdy jazyk je dobry na nieco ine. Lepsie je Javu s COBOlom integrovat ako prepisovat z COBOlu do Javy.

A jsme u toho co jsem psal neni to o tom ze by COBOL byl nakej super jazyk a proto tu s nami je 70let.
Za mne je nejlepsi COBOL dat do hajzlu, protoze ty problemy jsou horsi cim dele se to odklada...

---
Abych nevypadal jak IBM hater tak jsem z/OS fanda, akorat mi prijde skoda na tom mastit COBOL kdyz ten HW toho zvladne vyrazne vice.

[svalvjard]

@Pavel.Stehule no zrovna cobol ti dovoli fakt slusny hnoje

U manuálu COBOLu jsem skončil na 10 stránce, a dál jsem to nedal., takže toho o COBOLu vím málo. Ale pověst ho předchází, takže jsem to myslel spíš na management, že se drží zpátky a není moc kreativní.

Bud rad .
Bohuzel to je obecnej problem, tezko managmentu vysvetlit ze ten prinos je longterm kdyz oni honi ctvrtletni KPIcka...

[Hawo Hawowski]

Btw, emulátor ani simulátor AIXu není,  virtuál za těźký prachy by se asi našel

V QEMU by sa mal AIX dať emulovať. Ja som skúšal len to patchnuté diagnostické CD, fungovalo (nemám momentálne poruke inštalačky)
http://aix4admins.blogspot.com/2020/04/qemu-aix-on-x86-qemu-quick-emulator-is.html
https://worthdoingbadly.com/aixqemu/

[mikrom]

A jsme u toho co jsem psal neni to o tom ze by COBOL byl nakej super jazyk a proto tu s nami je 70let.
Za mne je nejlepsi COBOL dat do hajzlu, protoze ty problemy jsou horsi cim dele se to odklada...

---
Abych nevypadal jak IBM hater tak jsem z/OS fanda, akorat mi prijde skoda na tom mastit COBOL kdyz ten HW toho zvladne vyrazne vice.

Neviem ake problemy myslis, lebo si ich nespecifikoval. Tu si ale mozes precitat niekolko racionalnych dovodov, preco sa tento jazyk este stale pouziva:
https://stackoverflow.com/questions/2025730/why-is-cobol-still-a-preferred-language-in-the-business-world

Pises ze si fanda z/OS, t.j. ako sa tu uz pisalo je operacny system s primitivnou ergonomiou pochadzajucou z 1960tych rokov. Naco vlastne ten OS potom pouzivas ked mas odpor k programovaciemu jazyku, ktory sa na nom asi najviac pouziva ?
z/OS je dodavany s niekolkymi tradicnymi kompilatormi. Okrem COBOLu ma zabudovanu decimalnu aritmetiku uz len PL/I.
Pouzivas na biznis logiku PL/I alebo  C, C++, assembler, Javu ?

[FKoudelka]

Btw, emulátor ani simulátor AIXu není,  virtuál za těźký prachy by se asi našel

V QEMU by sa mal AIX dať emulovať. Ja som skúšal len to patchnuté diagnostické CD, fungovalo (nemám momentálne poruke inštalačky)
http://aix4admins.blogspot.com/2020/04/qemu-aix-on-x86-qemu-quick-emulator-is.html
https://worthdoingbadly.com/aixqemu/

Hezky, AIX 7 jsem nezkousel. Muze to fungovat , Ale asi  by mi ten port nestal za tu namahu.

[boban23]

Nějaké drobné poznámky k těm emulátorům.
Mainframes řady S/360, 370, 390, zArchitektura velmi dobře emuluje Hercules, který je stále vyvíjen zde
https://github.com/SDL-Hercules-390/hyperion
Legálně lze na tomto emulátoru provozovat pouze MVS 3.8, který je původně z roku 1981? a umožňuje pouze 24bit adresování (max 16MB).
Základní web tohoto systému už připraveného pro Hercules je zde:
https://wotho.ethz.ch/tk4-/
Existují skupiny zjevně velmi znalých vývojářů, kteří MVS 3.8 i dnes doplňují o "fičury" vyskytující se v novějších OS, takže i přes své stáří je to stále zajímavá záležitost.

Dále IBM má svůj emulátor zPDT. To je ale placený soft.

Co se týče řady AS/400, IBM i  - procesory POWER.
Emulátor neexistuje, dle níže uvedeného textu proto, že procesory POWER v sobě mají nějaké patentované technologie, které neumožňují legální okopčení. Zjevně ten problém bude vážný (právní?? technický??), když ani nikdo neuspěl s reverzním inženýstvím.
https://www.ibm.com/mysupport/s/question/0D50z00006LKpWSCA1/power-isa-and-possible-as400-emulator?language=en_US

Operační systémy OS/400 ani AIX pro POWER tedy není možné rozjet v emulátorech protože žádný takový emulátor neexistuje.

V QEMU je údajně možné rozjet AIX pro PowerPC. Toto mám pouze vyčtené. Netuším jestli je to pravda.

Jinak, vzhledem k celkem zanedbatelným cenám za které se na ebay starší servery s architekturou POWER prodávají, nákup staršího železa by snad mohla být cesta.

Ještě jeden rozverný dodatek. :p
Kdo by chtěl mít svůj vlastní soukromý mainframe, tak na ebay jsou momentálně tyhle tři nabídky:
https://www.ebay.com/itm/383950744961
https://www.ebay.com/itm/313146096757
https://www.ebay.com/itm/313146113918

Nabídka skutečného IBM mainframu není zcela běžnou záležitostí dokonce ani na ebay.
Ty výše uvedené nabídky jsou dost drahé. Občas je možné starý mainframe koupit i výrazně levněji. :p

[a6b]

jako decko jsem vyhrabal kdovikde knizku algol-cobol-fortran a co jsem videl jsem nechapal, ale obdivoval to jako magii. no ve fortranu jsem si uz zaprogramoval, ty dva ostatni me minuly. delam v c++.

https://knihobot.cz/g/497729

[Karmelos]

Nechápem.  Čobol je prostě jenom jazyk, od ostatních jazyků se odlišuje jen takovou tou omáčkou okolo... Teda ta omáčka je výživná, ale jinak mi to příde na první dobrou jako tak nějak snesitelný.  :-)

Teda lisp je imho jiný kafe...