Ingyenes COBOL képzéseket indít az IBM

HUP cikkturkáló

Many systems that process unemployment claims still run on a 60-year-old programming language that barely any coders understand.

IBM is releasing a free training course next week to teach the 60-year-old programming language COBOL to coders. It is also launching a forum where those with knowledge of the language can be matched with companies in need of help maintaining their critical systems.

The moves come in response to desperate pleas by state governors for anyone with knowledge of COBOL to volunteer their time to help keep unemployment systems functioning, a critical need as the coronavirus has resulted in an unprecedented surge in people being laid off and having to claim unemployment benefits.

Részletek itt.

  • 3226 megtekintés

( martonmiklos v | 2020. 04. 11., szo – 10:41 )

Mennyi Cobol expert van Indiában :D

( Zahy v | 2020. 04. 11., szo – 11:14 )

Ez bitang jó. Rémlett valami kék könyv. Megnéztem, a polcon még megvan a Múszaki Kiadó sorozatából pár kurrens kötet: Assembler, Algol-60, PL/1, Fortran és COBOL!!! Szóval akkor jövő héten rá kell arra a kurzusra nézni. Sajnos FreeBSD-re nincs MicroFocus Cobol, de up-to-date OpenCobol (GnuCobol) az van.

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Nem kell ehhez semmilyen kék könyv, meg Műszaki Kiadó. A neten vannak jó tananyagok meg összefoglalók COBOL-ból, amelyek tárgyalják a legutolsó COBOL14 szabványt OOP-stől meg mindenestől. Egyébként semmi baja magának a nyelvnek, tud mindent, szintaxisa is rettenet emberbarát, könnyen olvasható. Igazából csak feledésbe merült a többi nyelvhez képest. A C meg a Fortran ismert, gyakrabban használt maradt. Mindig is szimpatikus nyelv volt, de nem látom értelmét, hogy COBOL-ul megtanuljak, nem sok mindenre lehetne használni a gyakorlatban. Hobbiból lehet benne bármit írni, csak semmi előnye nem lesz egy modern nyelvben írt kódhoz képest, amihez sokkal optimalizáltabb compiler-ök vannak.

Ami gond van ezzel az IBM-es kezdeményezéssel: igen, pár ilyen mainframe-ről átmentett kód szolgál még nagyobb környezetben, és ehhez kell is embert képezni, de nagy tömeghájpot nem érdemes köré építeni, és tömegképzéseket tartani belőle, mert olyan sok embert nem tud eltartani ez a téma. Az a kevés, aki ezzel foglalkozik, annak sem a meglévő mainframe COBOL kódokat kéne karban tartania, hanem újraírni ezeket a kódokat modern nyelven. Egy nem tudom hány kompatibilitási és emulációs rétegen keresztül üzemeltetett meg nem optimalizált fordítóval készült bináris sose lesz olyan hatékony erőforrások felhasználásában mint egy modern.

Persze ez a modern nyelvre átültetés is kétélű fegyver, mert ha hívnak egy Java vagy Pyhton vagy JS Framework Magyit, az átírja olyan jól modern bloatra, hogy köszönet nem lesz benne, inkább akkor a 60 éves kód maradjon, ahogy van, és nyúljon hozzá csak olyan, aki tényleg ért is a programozáshoz, nem ilyen 24 óra alatt könyvekből meg átképzésekből átkontárosodással tanulta a szakmát.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Érdekes, itt rendszeresen előkerül, hogy egy kicsit is képzettebb programozó számára a nyelv nem kihívás, pár hét alatt túl lehet rajta lendülni, sokkal lényegesebb az éppen használandó framework megismerése. Node ezeknél a Cobol-dolgoknál az meg épp nincs.

Akkor hogy is van ez?

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Framework az nincs COBOL-nál, viszont az akkori, 60 évvel ezelőtti mainframe környezetet muszáj hozzá ismerni, anélkül nem lesz érthető a kód. Ugyanis sok olyan hekket toltak bele, ami az akkori architektúra miatt kellett bele (egyébként nem futott volna erőforrás híján), és modern gépen futó modern kódba már nem kéne. Hamarabb ezt nehezebb áttekinteni egy régi kódban, nem magát a nyelvet, meg a szintaxist.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Need az mindig van, legfeljebb lustaságból, meg ilyen vallásos, jajj, ne nyúljunk hozzá, mert nem tudjuk mi hajcsalya / if ain't broke hozzáállás miatt ignorálják. Pedig előbb-utóbb nem lehet megúszni egy produktív környezetben sem a karbantartást. Lehet halogatni, akár extrém hosszú ideig, mint ezek a 50-60 éves COBOL kódok is bizonyítják, de nagyon nem ajánlott, minél tovább várnak vele, annál kínosabb lesz modernizálni.

Azt viszont jól írja a cikk, hogy nem lehet egy egyszerű Cobol2C átfordítóval másik nyelvre átgenerálni a kódot. Ugyanis a nem fogja érteni senki, meg debugolni. Pont azért, mert a régi kódokban van egy csomó hekk, akkoriban még ilyen decimális meg oktális rendszerek is voltak, meg BCD kódolás, meg szalagos tárolók és lyukkártyák sajátosságai miatt gányolás, ami mai szemmel már nem lesz érthető, C-re vagy valami másra automatizáltan átültetve meg aztán még annyira se fejti meg senki. Ezért kínos ezekhez ma már hozzányúlni, nem azért, mert COBOL-ban vagy Fortranban vannak írva. Ezekhez a régi mainframe gépekhez egyre kevesebb szakember maradt, már ilyen múzeumoknak is gondot okoz, hogy nem találnak a karbantartására embert, nem tudják üzemképes állapotban tartani.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Jókat írsz, de rosszul látod. Ezekhez a kódokhoz folyamatosan hozzányúltak már csak azért is, mert a cobol jellemzően az pü-i, üzleti világ nyelve és a szabályozók ott változnak a legsűrűbben és legnagyobb mértékben. Ezt le kellett követni ugye és ez a változás permanens. Azok a régi hack-ek már eltűntek belőlük jórészt. A mainframe világ baromi nagyot fejlődött, olyat, amiről a pc-s világ nem is álmodhat, csak halkan, zárt körben és ez a fejlődés sok ilyen hack-et szükségtelenné tett. Lehet írni cross compilert és az átfordítás nagyját meg lehet vele oldani, kérdés, érdemes-e!? Inkább azért kínos ezekhez hozzányúlni, mert ma mindenki a divatos kétperces nyelveket tanulja, nem érkezik vagy csak ritkán olyan alak, aki képes egy nagy és komplex rendszer átlátására, a kiszolgált szektor szakmáinak megtanulására részben. Itt meg kell tanulni, hogy nyúlsz bele egy rendszerbe, nem lehet hipp-hopp újrafordítgatni és szórakozni mert 0-24-es rendszerekről beszélünk, amelyek ha leállnak, akkor akár olyan veszteségek is gyorsan előállnak, mint az életed nagyrészében felvett fizetésed többszöröse. Ehhez nyugodt, alapos és megfontolt emberek kellenek, akik értik a nem egyszerű mainframes környezetet is. A cobolt vagy a fortrant meg tudja tanulni szinte bárki elég hamar. De az iparági követelményeknek kevesen fognak megfelelni. A nyelv egyébként őrzi a szalagos tárolók, lyukkártya lyukasztók és olvasók miatt beleépített nyelvi elemeket, de ez nem teher, mert eléd sem kerül. De ha eléd kerülne, akkor sem lenne probléma, mert ezeket egyszerű utasításokkal tudod kezelni, amelyek ismerősek lesznek a filekezelés miatt. Szóval én inkább a platform nem ismeretét és emberi tényezőket sorolnékfel, ami miatt ma nehéz "beszerezni" a megfelelő szakit. 

Inkább azért kínos ezekhez hozzányúlni, mert ma mindenki a divatos kétperces nyelveket tanulja

Fogalmazzunk úgy, hogy sokan tanulják a divatos, két perces nyelveket, de azért vannak bőven nyelvek, amik már itt vannak egy ideje, bizonyítottak, és nem is mennek sehova. Amit mondasz jogos, de nem a cobol mellett érv, hanem a divatnyelvek ellen. 

Igen, így is jó. Semmiképpen nem azt akartam mondani, hogy minden rossz, ami új! Ez távol áll tőlem. Azt viszont jónak tartom, ha egy eszköz, amit a munkához használok, nem öt percenként változik, mint a java, hanem alapos tervezéssel a célhoz van igazítva, mint a cobol, rpg, c, stb. Ez utóbbiak azért is élnek meg szép kort, mert kiszámítható a használatuk, nem kell attól félni, hogy belehekkelnek egy új pixelt és máris inkompatibilis - ld. java futtató környezet - amivel azután az alkalmazás előállítója szív, mert bizonyos verzióig visszafelé kompatibilitást kell tartani - ld. nav nyomtatvány kitöltö toolja - és szív, ha az új verzió megjelenése teljesen hazavág részeket az alkalmazásban.

Szerveroldalon a mai napig a Java 8-as verziója dívik amit 2014-ben adtak ki, és 2030-ig fog extended support-ot kapni. Nem évente kellene verziót léptetni. És legyen akármilyen kritikus az a projekt, ha ennyi idő alatt nem fér bele egy kis felzárkózás annak ellenére sem, hogy a szakember és tudásbázis is szinte garantált, akkor ott nem a nyelvvel van a baj.

Az ÁNYK pedig más tészta. Az egy szoftver amit odaadsz klienseknek, akik változatos környezetben változatos JAVA verziókkal próbálják azt futtatni. 

Az alkalmazás előállítója pedig csupán a saját döntése miatt szív. Adhatna egy felhasználóbarát, támogatott JRE verziót tartalmazó telepítőt az amúgy JAVÁ-hoz egyáltalán nem értő user kezébe. Máris csak egy verziót kellene támogatni, és nem lenne kényszer az upgrade. 

Vagy mindkettő. De legyen inkább három, mert Mac-et se árt támogatni. Akinek pedig speciális igénye van, annak egy jar garanciavállalás nélkül. 

Értem, hogy azt akarod mondani, hogy az az egy verzió se egy verzió, de biztosítani 3-4 csomagot fix runtime-mal még mindig sokkal egyszerűbb, mint támogatni több platformon több architektúrán több verziót, abból is oracle és openjdk verziót.

De eddig egy programozási nyelvről beszéltünk, és arról, hogy a termékedet, ami egy szoftver mennyire kell a nyelv verzióváltozásai miatt tutujgatni.

Amire a válasz az volt, hogy meg lehet oldani anélkül is, hiszen a nyelv régebbi verzióit is karbantartják jó sokáig, a runtime-ot meg lehet az alkalmazás mellé csapni, hogy könnyen használható legyen.

A wowza esetében viszont maga a szerver a termék, és te vagy a felhasználója. Akkor is, ha hozzáfejlesztesz. A programozási nyelv változása itt érint, hiszen a moduljaidat is hozzá kell húzni, de ki mondta, hogy a Wowzát feltétlenül kell frissítened? Nincsenek biztonsági frissítések régebbi verziókhoz? Na, látod itt a hiba. 

( nullzero | 2020. 04. 11., szo – 12:35 )

Ahhoz nekik kéne fizetniük, hogy ilyet megtanuljak.

Ezt nem tudtam. Bár ha annyira hasonló a COBOL-hoz, akkor felesleges volt újra feltalálniuk a kereket új néven. Vagy csak valami jogi huzavonát akartak vele elkerülni, tipikusan amerikai szoftverszabadalmi bonyodalmakat.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( anr | 2020. 04. 11., szo – 13:47 )

egyszerűbb lenne újraíratni a rendszert olyan nyelven, amit 50+ év múlva is fognak használni

java, vagy abap :D

A FORTH-ot nem tudom, hogy fogják-e 50 év múlva használni. A FORTRAN-ról:

We don't know what language engineers will be coding in in the year 2100. However, we do know that it will be called FORTRAN.

-- C.A.R. Hoare

Eddig többnyire úgy fejlesztették tovább, hogy a régi változat benne maradt, ami régen helyes program volt, az majdnem mindig az új változatban is az.

( BandiG v | 2020. 04. 11., szo – 16:05 )

Volt regen a hup-on egy kollega, aki irt egy cobol -> C transpilert. Itt vagy meg? Mi ujsag a project-tel? Nem talaltam keresovel. (Ugy emlekszem ccc neven futott.)

( SchTamas | 2020. 04. 11., szo – 19:22 )

Most, hogy elpicsázta a sok kis tini kóder a cobol-t, ami 60 éves nyelv és még mindig rengeteg helyen, rengeteg kód él cobolban írva, vegyük már elő azokat a nyelveket, amiket ti használtok! Némelyik a harmadik szülinapját nem tudja úgy megélni, hogy ne alakulna át gyökeresen! :D Ja, én tudok cobolul! Mondjuk én kódoltam assemblyben is, fortranban is. Elég öreg vagyok. :)

A képen egyébként egy ibm 360 vagy 370-es gép van...fasza kis masina volt! Jó, ehhez kellett tudni programozni, nem volt ilyen frémvörk varázslat, hogy felbaszarintom a gombokat és elmentem a kész klikkelős cuccot teli buggal… :D Bocs! :D

Bocs szerencsecsomag, a framework miota egyenlo a gombvarrassal/klikkelessel.

A korodat nem tudom tisztelni, mert abban a korban nottel fel, amikor nem volt nagy kihivas programozonak lenni, bácsika!

Assembly, Cobol? Mi volt ezekben a nehez?
Lukasztgatni a lyukártyát?

Ma egy szaros Cobol meg Assembly az edeskevés öregem!
 

Pascalban írt programjaim még futtottak úgy R20-ason, hogy előtte lyukkártyát kellett lyukasztani, de assembly-hez már CP/M-et, majd MS-DOS-t és az újabbakat használtam. Assembly-ben az volt a nehéz, hogy mindent is nekem kellett megírnom, akkor még nem volt hozzáférhető ilyen-olyan runtime library, az volt, amit magamnak megírtam, arra lehetett támaszkodni a későbbiekben. Cserében én voltam a hülye, ha valami nem működött, akkor még nem lehetett mutogatni a libek szerzőjére :)

Assembly nélkül ma sem nagyon lehet meglenni bizonyos területeken, a programozás nem csak abból áll, amit ma képzelnek róla azok, akiket most képeznek át programozóvá Pandémiában...

Nem az a bajom a szerencsecsomaggal, hogy Cobolt meg Assemblyt emleget, hanem az, hogy ugy allitja be magat, hogy az a kor volt a kihivas, amiben o volt a programozo, es o nagyon programozo volt, mert ket ilyen kurva _meredek_ tanulasi gorbeju nyelvet kellet elsajatitania, ja, es meg szinten is kellett tartania a tudasat, ami ugye mekkora kihivas lehetett abban az idoben.

(akinek nem vilagos a meredekseg: x az ido, y a szint. Ertheto?!)

Azzal a tudassal ami neki akkor a tarsolyaban volt, egy mai programozot senkihaziaknak lehetne nevezni, nem programozonak.

Ugy kb. vegigvehetne az arc, hogy mennyi technologiat es programozasi nyelvet kell ma megtanulnia egy programozonak, es nem is kell full stacknek lennie, eleg csak egy backendet vagy frontend oldalon dolgozot megnezni.

Ja, es kozben a tudast folyamatosan fejleszteni is kell, mert technologiak/nyelvek jonnek/mennek.

Beszaras, hogy odavagytok az Assemlyert.

Most okadjam ide, hogy en is azon nottem fel. Es akkor mi van?

Szopjam le magam, mert ezelott 32 eve

- fejbol nyomtam , hogy a kulonfele mov-nak mi az utasitasciklusa,

- fejbol tudtam jo nehany utasitas gepi kodjat, es hogy melyik bit mit "csinal"?

Ez akkora nagy hype?

 

Itt van mogottem (meg mindig) a Szilassy Bertalan konyve,

odebb meg az IBM Technical Reference. Masoljak belole ide egy kis BIOS-forrast, amlyenek jo nehany reszlete meg mindig itt van a fejemben, vagy vegyem elo valamelyik regi TSR-programomat?

Akkora nagy arcomnak kellene lenni, mint a baratodnak, mert ugy nottem fel, hogy az Assembly az eletem resze volt?

Beszarok, most azonnal, ha arra gondolok, hogy azzal szorakoztam, hogy visszafejtettem a Nortons Guide-ot, lepesenkent nyomogatva a debuggert, mert nem volt internet am, "openszorsz"; en voltam az openszorsz, a ket kezemmel bontottam ki a kodot

Meg a Pana kozpont lokte be a hivasrekordokat, mikozben Win 3.akarhayban futott a Word, en meg TSR-bol pakoltam a hivarekordot a winyora; nem sokan tudtak ezt akkor bemutatni, mert nem volt affiniti bennuk. Bennem volt, es akkor most szarjam ide, hogy en mekkora negy arcz vagyok?

 

( Ha azt mondom EOI, tudod mi az? Fejbol baz`meg, nem a kiguglizve!!!

EOI, 8259 jajj, de komoly. Es ezt _en_ kovettem el, ezelott 30 éve? Jajj, de komoly, ugye. Mekkora arcz (igy cz-vel) legyek most, hogy toltam az Assemblyt, to`tam bele a TSR-t a DOS-ba, ajjajj, jottek az adatok, nem szamitott ha futott a Win. 3.akarhany, irtam a wincs-esztert, mit a szel, nem szamitott semmi, mert nagyomn ertettem az int 13-at, az isr-28-at, vagy a bant tuggya mar mit, de akkor is arcoskodnom kell, ugye , kiscsavo?

 Isr_RS232_RETURN:
        cli                     ; IT-ék letiltása
        mov     al, EOI
        out     INT_BASE, al    ; jelzi 8259-nek az IT befejezödését

        pop     dx              ; használt regiszterek helyreállítsa
        pop     ax              ;

        iret
Isr_RS232       ENDP

)

Hehe, Pana központokból még én is mentettem hívásrekordokat DOS-tól egész Windows 2000-ig. Sőt még jelszó törőt is csináltam hozzá, ami olyan gyorsan próbálta a jelszavakat, hogy nem várta meg a választ, mert rájöttem hogy ha egyszer megjön a helyes válasz, akkor csak visszafele kell lassabban végigfutni rajtuk :) Aztán persze hardvert jobban ismerők egyszerűbben megoldották. Az adatmentésre és feldolgozásra pedig jött a Taxameter.

Bakker! Te mekkora durung vagy! :D Cölöpöt lehetne leverni veled! :D De hát ilyen dos-os kis rezidens szarokat mindenki írt a vasárnapi ebéd után unalmában, ez azért nem nagy dolog. Sőt, szerintem a dos korában nem volt olyan kóder, akinek ne lett volna a kódja, ami a 9h int-re volt láncolva ilyen-olyan céllal. :) Szerintem nmi rutint is sokan írtak...ott lehetett, alig volt bonyolultabb környezet egy 8 bites mikroszámítógépnél az a pc világ.

Te nagy szerencsecsomag.

Ez nem egy kis szar rezidensbol valo kodreszlet, hanem egy olyanbol valo, ami ugy csucsult be, hogy mikozben tette a do`gat, a DOS, meg a folotte futo Windows fagyas nelkul mukodott, mikozben mindharman irtak a vinyora, egymas zavarasa nelkul, es kozben jottek az adatok hardveres megszakitason keresztul be, es ki kellet ezeket irni lemezre, mert csak...

Nem, ez nem volt trivialis, mert matematikus zseni kollegaimnak nem jott ossze a mutatvany, es nem azert mert hulyek voltak,

henem mert:

- nem ertettek a szamitogep (x86) interrupt mechanizmusat,

- nem ismertek a DOS-t melysegeben,

- es Assemblybol is pont annyit tudtak, amit az egyetemen tanultak.

Nem vagyok elszallva egyaltalan attol, hogy volt eleg tapasztalatom (gyakorlatom) x86-os Assemblyben, csak azert futottam bele ebbe a szalba, mert irrital, ha valaki nagyra van attol, hogy Assemlyben (meg Cobolban) programozott, es ettol mekkora nagy zseni.

Valahogy en nem erzem magan nagy programozonak attol, hogy megettem reggelire a matekos kollegaimat Assemblybol,

meg plane attol sem, hogy nem tudtak megitni a TSR-t, hogy ne faggyon le tole a gep, pedig _TRIVIALIS_, ha nem is annyira, mint a kis rezidens szarok, amiket ok is meg tudtak irni; akkor csorbult a fejszejuk, amikor hardveres irq-kat kellet lekezelni, es kozben irni a vinyora. Megegyszer szerencsecsomag: ez nem nagy dolog; ujjgyakorlat, de nem mindenkinek, meg akkor sem, ha matek meg Cobol/Fortran-zsenik.

Van olyan, hogy a IRET hívás maga ment egy-két regisztert és hogy a visszatérési címhez hozzáférjél, azt az egy-két regisztert le kell szedni a verem tetejéről, azért nincs push ax, push dx. Előfordul, hogy a visszatérési címet a stack pointer állításával kell előbányászni.

Nem tudom, hogy a konkrét proci így működik-e, de én már láttam ilyet. Ettől függetlenül a jrewing stílusától nem vagyok hanyattesve. Bizonyos környezetben az assembly nélkülözhetetlen és igen, speciális tudást igényel, amit a többség nem fog megszerezni és nem azért mert, képtelen lenne rá, hanem azért mert ez egy nehezebb út. És az, aki a nehezebb utat választja, az tiszteletet érdemel.

> Sol omnibus lucet.

Csak azert, mert laccik (igy ket cevel), hogy fingod _sincs_ a temahoz.

Posztolok neked, meg a tobbi nagyon okos fikazonak, hogy mikent mukodik a processzor, amire a fenti kodreszlet irodott.

Bar lehet, hogy felesleges, de tanulni sohasem keso:

"**During the interrupt response sequence further interrupts are disabled.** The enable bit is reset as part of the response to any interrupt (INTR, NMI, software interrupt or single-step), although the FLAGS register which is automatically pushed onto the stack reflects the state of the processor prior to the interrupt. Until the old FLAGS register is restored the enable bit will be zero unless specifically set by an instruction."

Csemegezhecc (szinten ket cevel):

https://course.ece.cmu.edu/~ece740/f11/lib/exe/fetch.php?media=wiki:8086-datasheet.pdf

 

Es a nagyon vakoknak vagy szelektiven latoknak:

Ez a cimke vajon hol lehet az ISR-ben, mert ezt is szinte mindenki benezte?

Isr_RS232_RETURN:

 

Az elején, kozepén, vagy netan a végen?

Nagyon nehez talalos kerdes, ugye?! A RETURN az vajon mi a banatra utalhat, hol lehet ez szegeny, szerencsetlen cimke?

 

Es mi a banatos rossebert van itt egy CLI, ha netan a vegen van, amikor a data sheet-en is az van _kobe-vesve_, hogy "The enable bit is reset as part of the response to any interrupt"?

Na, ez meg nagyobb talany, ugyebar.

 

Van ennek az ISR-nek ezek szerint kozepe is, mert eleje az van, de kozepe?

Amugy van itt valaki, aki irt mar ISR-t (rajtam kivul) x86-ra?

The enable bit is reset as part of the response to any interrupt

Pontosan. Ennek architektura-fuggetlenul igy illik mukodnie, kulonben meglehetosen furcsa dolgok tortenhetnek. Forditva lehet: ha az ISR-en belul megszuntetjuk/nyugtazzuk az adott interruptot kivalto hardver-esemenyt majd utana ujra engedelyezzuk a megszakitasokat egy SEI-vel. 

A finom reszletek persze attol is fuggnek hogy a konkret architektura hogyan is implementalja a hw interruptokat. A leheto legegyszerubb (2 orajeles) hw-stack alkalmazasatol kezdve a "csinaljunk teljes allapotmentest a sw/shared stack-re" minden lehet.

Amugy van itt valaki, aki irt mar ISR-t (rajtam kivul) x86-ra?

Hogyne! Boldog ifjukor :) 

Akkor (csak neked, mert a tobbiek ugysem ertik), itt a fenti reszlet teljes egeszeben:

;********************************************************************;
 ;* Hardware INT 0c or 0b (IRQ4 or IRQ3)
 ;*
 ;* RS-232C Interrupt Service Rutin
 ;*
Isr_RS232       PROC    FAR

        ; *** CLI -nek érvényben kell maradnia ! ***
        ;
        push    ax              ; használt regiszterek mentése
        push    dx              ;

        inc WPT recNUM          ; megszakítások számlálása
        jnz     @F
        inc WPT recNUM+2        ; long !

 @@:    mov     dx, asn_BASE
        in      al, dx          ; karakter elvétele a receive buffer-bôl
        mov     ah, al          ; save received char
        jmp     $+2             ; I/O delay

        add     dx, ASN_LST
        in      al, dx
        test    al, 00011111B   ; turn off the needless bits & set jump cond.
        mov     al, ah          ; restore received char
        jz      @F              ; no errors
        inc     errNUM          ; számlálás

 @@:    cmp     al, 0           ; 0 ?
        je      ERR_CH          ; err.
        cmp     al, 0ffH        ; FF ?
        je      ERR_CH          ; err
        cmp     al, LF          ; LF-et lenyeli !
        je      ERR_CH          ;

        call    Write_buf       ; a karaktert (AL) elhelyezi a bufferben

 ERR_CH:
 Isr_RS232_RETURN:
        cli                     ; IT-ék letiltása
        mov     al, EOI         ; End Of Interrupt
        out     INT_BASE, al    ; jelzi 8259-nek az IT befejezödését

        pop     dx              ; használt regiszterek helyreállítsa
        pop     ax              ;

        iret
Isr_RS232       ENDP

" Amugy van itt valaki, aki irt mar ISR-t (rajtam kivul) x86-ra? "

 

van. bar magat a kodot jr*.* kollegahoz hasonloan mar sajnos nemtudom elobanyaszni, mert amig letoltottem a sorkatonai akkor meg 18 honapot, addig kisse indithatatlanna valt az mfm vincsim, a backup floppy meg olvashatatlanna.

HUP te Zsiga !

Majd ha megírtál egy komplett securities trading rendszert vagy repülőgépbe pakolást vezérlő weight&balance szoftvert az akármilyen nyelven akkor fikázhatod ezeket a régi programozókat.

Azok akik ezeket a rendszereket üzemeltetik jórészt azért nem engedik oda a hozzád hasonló arcokat mert veled szemben sosem volt követelmény hogy _hibátlan_ kódot írjál. Márpedig ezek a rendszerek hibátlanul teszik a dolgukat és napi szinten eurómilliárdok és/vagy emberi életek múlnak rajtuk.

Gábriel Ákos

"repülőgépbe pakolást vezérlő weight&balance szoftvert "

Akinek ez kihivas, az menjen viragkotonek.

Erre van egy jó storym. Nagyon régen voltam egy cégnél interview-n, ahol a feladatokat megcsináltam, majd beszélgettünk. Megkérdezték hogy hogyan tetszett a robotos feladat. Mondom, hát nem nagyon szeretem az ilyen pakolós játékokat. Erre kiderült, hogy a cég automata robotokkal foglalkozik, amelyek országok és nagyobb bankok arany és pénz készleteit pakolják. :) Uhhh.. 

... mert amikor ezek az emberek kezdték akkor ők legtöbbször tudósok voltak, tipikusan matematikusok. Aztán eljutott oda a dolog hogy mérnökök is elboldogultak a rendszerekkel. Ma már iparosok a programozók, jó esetben főiskolával, kevésbé jó esetben gyorstalpalót végzett cukrász vagy pizzafutár.

Typescript, npm, my ass...

Gábriel Ákos

Typescript, npm, my ass...

Mondtál valamit, de minek? A typescript egy tök jó nyelv arra a feladatra, amire született. Az npm pedig egy csomagkezelő, nem is értem hogy jön az egész topic témájához?! (Hacsak nem az volt a cél, hogy böffents valamit gondolkodás nélkül, mert akkor sikerült)

A typescript egy tök jó nyelv arra a feladatra, amire született

Amennyiben a feladat specifikációjának tekintjük, hogy adott, hogy a browserek csak JS-t tudnak, akkor ja, valóban. De ha a feladat részének tekintjük ennek a kiválasztását/megálmodását is, na akkor ezek mind mennének a levesbe. Az egész JS-es történet a browserekben egy szégyen az IT-ra nézve.

Amennyiben a feladat specifikációjának tekintjük, hogy adott, hogy a browserek csak JS-t tudnak, akkor ja, valóban

Persze hogy annak tekintjük, hiszen a TS akkor és azért született, amikor a JS egy elmozdíthatatlan faktor volt. Lett volna esély egy más nyelvvel pótolni (dart) és korábban volt esélyes vetélytársa (visual basic) de abból senki se kért. Szóval a kiválasztással/megálmodással jönni teljesen felesleges. Valószínűleg akkoriban se te, se én, se más nem lett volna elég okos ahhoz, hogy előre lássa, hogy a dokumentumleíró markup és a hozzá kigondolt scriptnyelv a jövőben fullos multiplatform alkalmazások fejlesztésének lesz a kötelező kelléke.

Így van. De azért szar, mint látjuk. :D 60 éve masszívan őrzi a pozícióját, megfelel a mai igényeknek is ott, ahová tervezték, de szar. Hát persze. :D Ráadásul AS/400-on vaz az ibm Z gépein álom vele dolgozni az alá integrált DB2 miatt. És aki csak a PC-re kikotort DB2-t ismeri, az nem is érti miről van szó.

ami 60 éves nyelv és még mindig rengeteg helyen, rengeteg kód él cobolban írva

Értem mit mondasz, de az nem feltétlenül a nyelv érdeme, és nem feltétlenül jelent semmit a nyelvre nézve, hogy sok helyen használják. A Javascript is nagyon elterjedt, és rengeteg kód épül rá. 

Ebben az esetben a nyelv érdeme is. Abszolút mindent tud, amit ott kell tudni, ahol használják. Robusztus, egyszerű, nem kell foglalkoznod libekkel, más marhaságokkal. egyszerűen elvégzed a feladatot. A javascript arra volt jó, hogy szerintem, hogy kicsit interaktívabb weboldalt gyártsanak vele. Mást nem nagyon lehet vele megoldani minőségi módon. A java már más, de szerintem az is egy ipari hulladék kategória és az örökös változása felesleges munkát generál örökké.

( uid_17784 | 2020. 04. 11., szo – 22:18 )

Szerkesztve: 2020. 04. 11., szo – 22:19

Azert milyen erdekes az elet.

Vannak a Cobolhoz erto, _ven_ programozok, akiket most visz el ez a kibaszott virus; nagy esellyel mindegyik 60 ev folotti, a virus meg pont rajuk a legveszelyesebb.

Valaki irta itt feljebb, hogy minek Cobolt tanulni; hat ezert szervezi a nagy kék ezt a kurzust.

"mert olyan sok embert nem tud eltartani ez a téma"

A 80-as évek végén talán az utolsók között tanitották nekem a COBOL-t, de már nem dolgoztam vele.  Viszont  pl.  az as400/IOS azóta  folyamatosan és dinamikusan változik, aki azt gondolja, hogy 30 évvel ezelőtti COBOL tudás elég , mert ott nincs fejlődés  , mert ez olyan régi dolog  , azt igen nagy meglepetés érheti.  

https://blog.claryel.hu

Nos, az elmúlt évtizedeket pont as/400-on és COBOL-lal toltam le. :) És igen, óriásit fejlődött az egyébként már 30 éve sem új nyelv...bár inkább azt mondanám, hogy a környezethez alakult, amiben használták. Rengeteg specifikus változata van, amelyek szépen kihalogattak esetenként, de a mainframe környezetben a cobol olyan masszívan ott van, ahogy más nyelvek nehezen. Az ibm is tett kísérletet, hogy a java fusson a dobozain, fut is, mégsem olyan jó mint a cobol. Láttam vele kísérleteket, de valahogy nem váltották be a hozzá fűzött reményeket. Az RPG viszont bejött, az hasít.

Működik, nem csúszik el, csak semmihez nem passzol igazán. Sokkal egyszerűbb megírni cobolban vagy rpgben. Egyszerűen nincs értelme javaval vacakolni, mert hatékonyabb a többi. Egyébként a pkzip/unzip párost is megírták szépen c-ben erre a környezetre anno, mégsem hódított. :) 

Ezt láttam. Én sosem használtam. Ez hozzá tartozik az igazsághoz.

Szerintem ugyanazon, amin egy full MS-környezetben bármi, ami nem MS: egész egyszerűen nincs összeintegrálva a többi szarral, míg a vendor cuccai meg igen. Így ha bármi rendszeridegen komponenst be akarsz rakni, akkor bizony az nem fog passzolni, semmi nem úgy megy rajta, mint a rendszer maradék részén, nem ugyanazokat a protokollokat beszéli, stb. Egy kínkeserves szopás egy ilyen projekt, és még azután sem lesz seamless a végeredmény.

Ok, tehát röviden inkompatibilis, érthető.
 
Még egy dolog érdekelne. Tegyük fel hogy új bankot alapítanak, most áll fel nulláról. Vadi új központi vasat vesznek, amire tisztán java-ban programozták le a teljes szoftvert ami a pénzügyi folyamatokat ellátja.
 
Bele lehetne integrálni egy ilyet a világ globális bankrendszerébe, szót értne más régi banki gépekkel ez a zsír új, vagy mindenképpen Cobol kell a banközi kommunikációhoz (utalások pl.) ?

Tehát akkor elvi akadálya nincs annak, hogy egy új komplett központi nagy gép üzembe álljon.
 
A "kutya" ott lehet elásva, hogy a ma használt cobol programok annyira sokféle funkciót látnak el, évtizedek óta mindig tovább bővítve, hogy talán nem is létezik még erre java-s (vagy bármilyen) alternatíva. Így inkább életben tartják a régit.

Vannak Java-s alternatívák, de már meglevő rendszernél egy-egy komponenst nem éri meg lecserélni, a szívás meg a költségek jelentős része megmarad (és minden bevezetésnek jelentős pénzügyi és működési kockázatbeli tranzakciós költsége is van).

Ráadásul műszakilag sem jó poén, a Java-s megoldások arra vannak tervezve, hogy nincs alattuk mainframe, ergó olcsó vason is tudják, amit tudniuk kell - majd megcsinálja az alkalmazásréteg (alkalmazásszerver) - tehát nem éri meg drága vason futtatni őket, mert nincs hozzáadott érték.

Azaz, ha valaki Java-s megoldást akar, akkor nem akar alá mainframe-et. Ha pedig mainframe-et akar, akkor nem akar Java-s megoldást.

Megteheted, működni fog. Nem is értem a kérdést. A kommunikációt meg fogod tudni oldani, ebben a nézőpontban a bankod egy fekete doboz, ha ki tudja tolni magából a megfelelő formátumú adatsorokat és be is tudja fogadni, akkor minden rendben van. Pláne, hogy itthon a bankok elég régóta leváltották a cobol-t RPG-re, ha ibm platformot használnak. :) A többség biztos. Egyébként ha így nézzük, basic-et is használhatsz. Veszel vasat, mindent a nulláról megcsinálsz basic-ben és senkit nem fog zavarni, amíg működni tudsz.

Ami korlátozó tényező az csak az, hogy a piacon megvásárolható rendszerek adják meg az alapot a döntéshez, előírják a platformot és az ott használt eszközöket. Nagy bankok, biztosítók pedig előbb-utóbb kikötnek az ibm-nél - iseries, zseries, ilyen enterspájz dolgok - a vas skálázhatósága, megbízhatósága, ipari standard tulajdonsága miatt és akkor az integrált rendszerük is adottá válik, az eszközök palettája is adottá válik. Lehet erőltetni más eszközöket is, de általában az a cél, hogy minél hatékonyabban tudjanak dolgozni a rendszerükkel és nem az, hogy "de az régi, használjuk inkább az újat", mert ez utóbbi nem termel profitot.

A tendencia érdekel:
 
Abból indultam ki amit mondtál, hogy az IBM tolja a Java-t ezen a területen.
 
Tehát ha valaki ma iseries-t, zseries-t vesz, akkor az már gyárilag Java-s vagy RPG-s -- gondolom. De nem cobol-os.
Ha az IBM nem árul már cobol alapú új rendszert, csak java-sat / rpg-st, akkor hosszabb távon majd eltűnik a cobol ha jól értem.

Ami korlátozó tényező az csak az, hogy a piacon megvásárolható rendszerek adják meg az alapot a döntéshez, előírják a platformot és az ott használt eszközöket. Nagy bankok, biztosítók pedig előbb-utóbb kikötnek az ibm-nél - iseries, zseries, ilyen enterspájz dolgok

 

Ez régen lehet, hogy így volt. De nézz meg egy fintech céget, kizárt, hogy nagyvasak beszerzésével szórakozik. Megveszi felhőből (pl. Revolut) a szükséges compute-ot vagy épít magának DC-t ha annyira akar olcsó vasakból és fejleszt rá szoftvert magának, ahogy és amilyet akar.

Nem gondolom, hogy bármilyen új cég különösebben ragaszkodna a dobozos termékekhez és az árukapcsolt brutál árú vashoz.

Láttam bankot és biztosítót AS400-on, ami már körberakta a core legacy rendszert mindennel amivel csak tudta, hogy versenyképes maradjon. Jellemző költségek: HW ár, HW support díja, OS ár és support díja, SW fejlesztés díja, esetleges SW licensz és support díjak, bővíthetőség (mit, hogyan, milyen gyorsan és mennyiért lehet fel v. leskálázni).

Volt nekem olyan kollégám, amelyik fennen hangoztatta, hogy az nem szerver, amit ketten fel tudnak emelni aztán végig sírta az éjszakát, amikor egy ad-hoc POC során a next-next-finish-sel épített vmware vm-be a szintén nagyon professzionálisan next-next-finish -sel felrakott RHEL 4 -en futó, java-ban írt alkalmazás fossá verte teljesítményben az akkor éppen cégen belül "ennél nincs jobb" SUN-t (a jar-t 1 az 1-ben áthoztuk Solarisról RHEL-re, megkapta u.a. java verziót és hajrá).

 

Lehet erőltetni más eszközöket is, de általában az a cél, hogy minél hatékonyabban tudjanak dolgozni a rendszerükke

Pontosan.

Használd azt, ami a céljaidnak legobban megfelel és a legkevesebbe kerül. :)

Nem csúszik el. Egy csomó rendszer fut bankoknál Java-ban, akár SOA akár most már Microservice alapokon. Egyszerűen vannak olyan régi rendszerek,

melyeknek a lecserélése túl sokba kerülne, és nem is igazán lenne rá ember. Java fejlesztőből "akármennyit" fel lehet venni, viszont Cobol, vagy bármilyen

más egzotikus nyelvben tudó, és banki tapasztalattal rendelkező emberből nem nagyon van, és azt is a másik banktól lehet elszedni. Ezt meg a bankok is

tudják, ennek megfelelően fizetik meg ezeket a szakembereket.

Bár most nem aktuális, de régebben érdekelt a téma, hogy "sihederként" hogyan lehetne bekerülni pl. egy COBOL állásba? Tanulóként mainframehez jutni se volt egyszerű, csak ha nagyon utánajártál, találtál olyan spec.koll-t, aminek során láthattál ilyet testközelből (használni csak virtualizált környezetet lehetett, ha jól emlékszem). És gyakornokként kerültem még megközelíthető távolságba ilyen géphez, de ott csak a nyomtatott dokumentációhoz engedtek oda.

Fiatalon kell jól dönteni! Gyakornoki programokkal keresik az utánpótlást a cégek. De ha jelentkezel és jónak tűnsz, akkor bevállalják a betanítást is, tehát így. Megjegyzem, magához a vashoz sehol nem fogsz közel kerülni. :) Arra vigyáznak, mert érték. Az is, amit rejt. De ha bejutsz egy ilyen állásba, akkor a belső karrierutak között lesz rendszergazda is és akkor kotorhatsz benne, ha oda kűzdöd magadat. :)

Az OK, hogy fiatalon jól kell dönteni, de fiatalon szerintem még aki kicsit érdeklődik is a terület iránt, az is max. csak hallott a COBOL-ról, hogy létezik ilyen, hogy jól olvasható és kb. ennyi, egész egyszerűen nem érintkezik vele olyan szinten, hogy döntési lehetőségként felvetődjön. Én azért nézelődtem, volt, hogy aktívan kerestem anno a gyakornoki lehetőségeket is - alapvetően pénzügy felé tendáltam, ott is lyukadtam ki végül közel tíz éve (banki IG2 bevezetés volt a szakdolgozatom témája, ha jól emlékszem, pont az indulás napján volt a záróvizsgám), de még csak távoli lehetőségként sem merült fel az évek alatt, hogy ilyen irányba el tudjak mozdulni.

Ezt most nem értem, hogy hogyan függ össze a koronavírussal. Az utóbbi nem garancia, hogy az összes idősebb COBOL programozó meghal mind egy szálig, hiszen az életkor a halálozási statisztikát érinti, nem az egyes egyének sorsát. Főleg, hogy most a járvány miatt minden le van zárva és a képzést sem lehet elkezdeni, ez sem arra vall, hogy akármit is pótolni tudnának vele. Meg továbbra sem látom, hogy ez hol cáfolja, hogy nem sok embert tud eltartani ez a téma. Szerinted ilyen COBOL tudás hány embernek ad munkát? Hány olyan emberre van szükség, aki ilyen régi mainframe COBOL kódokat tart karban? Kb. egy kézen meg lehet számolni, de legyünk nagyvonalúak, vigyük fel egy nagyságrenddel, ~50 ember. Ehhez nem kell olyan nagy képzéseket tartani.

Épp ezért van, hogy a COBOL ennyire eltűnt, mert csak kevés ember dolgozott vele, a többi nem tanulta, mivel nem tudta volna hasznosítani ezt a tudást. Persze tanulni lehet hobbiból is, csak a programozás öröméért, de ilyen funkcióban is elég kevesen gondolnak arra, hogy ők majd pont ezt a nyelvet tanulják meg. Pontosan ezért írtam, hogy nem magával a nyelvvel van a probléma, hogy ne lenne alkalmas mindenre, hanem a gyakorlati hasznával.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Te háttal ülsz a moziban! :D Éppen az az aktualitása, hogy a COBOL nem tűnt el, csak az ember, aki tudja használni! A járvánnyal is így kerül pariba a téma. Az üzleti alkalmazások zöme ezen a nyelven íródott és működnek a mai napig. Oké, hozzáragasztgattak ilyen javas, c-s, stb. windowsos frontendeket, vicik-vacak cuccokat, de a lényeg a teremben, a hűvős szeles és zajos teremben a nagyvasak mélyén történik, cobol-ban. :) Nem, nem tűnt el. Sok embernek ad munkát világszerte, nem ötvennek. De még itthon sem csak ötvennek! :) És mindig az a tudás ér valamit a piacon, amit kevesen tudnak. Ilyen nagyarcú jávás kölyköt bárhol leakasztok, de cobol kódert vagy mainframes környezetben otthonosan mozgó szakit már nem. És ez bizony jobb tárgyalási pozíciót ad annak, aki cobolul is tud.

Amit én olvastam, a Munkaügyi központ USA megfelelőjében kéne felvezetni az ugrásszerűen megnőtt unemployment requesteket, illetve kiszámolni a segély mértékét és hogy hány hónapig folyósítható. Idáig eldöcögött ott egy régi webes frontend a napi pár requestet vitte szépen, de most óránként több száz requestet kéne feldolgozni, a backend pedig a hivatalokban kizárólag nagyon régi mainframe-n futó COBOL cucc. Most hirtelen ehez kéne értő szakember, legfőképpen aki javítani/gyorsítani tudna a COBOL kódon. Ha jól értem amit olvasstam erről tegnap.

R-GO nem a modern fujj fujj csilligány kattingatós csakfeldobomagombotaztjóvan kóddal van a baj, hanem a rosszul tervezett, rosszul skálázódó háttérrendszerrel.

Bár nem értek pár dolgot:

- hogy nem vitte el ezeket az idő/trend már korábban

- egy USA méretű országban (v. bármelyik államban) hogyan lehetett ennyire alulméretezni közigazgatási rendszereket

Szerintem nem rosszul tervezett, rosszul skálázódó a dolog, az sem biztos, hogy mainframe-n futó dolog. 

- A cobol létezett pc-re is - microfocus cobol, m$cobol, stb. - és ott alég elkeffentett az adatbáziskezelése, ha nem tudsz alá tenni valami jó db kezelőt.
- Te hány rendszert méreteztél úgy, hogy világjárvány esetén megsokszorozódhat a terhelése? Szerintem egyet sem. Ilyet senki nem csinált. Így lehet alulméretezni. 
 

Szerintem az elég rossz tervezés, és a skálázhatóság hiánya, hogy a hirtelen megnövekedett szakember igényre tanfolyamok szervezésével kell reagálni, és nincs szakember, akit munkába lehetne állítani.

Nekem nagyon úgy tűnik, hogy nem egy stratégiai húzás volt megtartani az öreg, és kevesek által használt nyelvet, hanem szimplán a tervezés, előrelátás és valószínűleg az anyagi források hiánya miatt tartunk itt.

- Te hány rendszert méreteztél úgy, hogy világjárvány esetén megsokszorozódhat a terhelése? Szerintem egyet sem. Ilyet senki nem csinált. Így lehet alulméretezni. 

 

Semmi szükség személyes irányba terelni a témát.

Ha csak bután elosztjuk az USA lakosságát az államok számálva, akkor durván 6 milla lakos jut egy államra (ok, NY-ban meg 8-10m-an élnek). A KV kb. 3.5m új munkanélkülit jelenett eddig. Ezt megint elosztva kb 600K új per állam (nyilván itt sokkal több, ott sokkal kevesebb). Inkább tűnne úgy, hogy a humán adminisztráció nem bírja a 600K új rekord rögzítését (de legyünk nagyvonalúak és legyen 10 rekord per fő, így kb. 6m új rekord), ami azért szerintem nem egy mennyiség.

Egyszerűen az van, hogy "jóvanazúgy" alapon nem nyúlt hozzá senki és most valószínűleg az elavult technológia és/vagy hibás tervezés miatt most nem elég további vasat alá tolni, el kell kezdeni a kódot is piszkálni.

Mondjuk talán most kellene elgondolkozni a jövőbe mutató, skálázódni képes megoldásokon, ha már hozzányúlnak a régi kódhoz (és újra megértik, megismerik azt).

Nem személyeskedni akartam, csak jelezni, hogy a helyzet most rendkívüli, erre sehol nem terveznek, hanem kezelik. Akár úgy, ahogy most kezelik ezt a helyzetet az usa-ban. Azt ugye nem tudjuk mi a baj vele, szerintem nem az adatmennyiség. Inkább az, hogy ide a rozsdás bökőt, ez valami olyan probléma lesz, hogy pc-ken rögzítgetnek, az adatokat utána valami módon összeseprik valahová, stb. Ma már nem így nézne ki, ha most csinálnák, hanem alá tolnak egy ibm vasat és kiszórnak 5000 terminál azonosítót és szépen lehet bekopogni az adatokat. A vas meg kényelmesen nyelné be. De tudni kéne a konkrét állapotot, hogy valós véleményt mondjunk. Nem tudjuk.

Ma már nem így nézne ki, ha most csinálnák

Tehát ahogy meg van csinálva, az a mai igényeknek nem megfelelő. Tudod, ez még egy valami ami nem a COBOL sara. Ha van sok jó szakember, akik elvégeznék a feladatot, és értik is, akkor a lépések az új igények irányába megtehetőek volnának. Nyilván itt a hiány az akaratból volt. 

Szerintem az egész adatmennyiség még most is peanuts egy CERN-es méréshez képest. Szerintem a probléma az lehet, hogy se a szoftver fejlesztésére, se a vas cserélgetésére nem költöttek, csak ha nagyon muszáj volt, valószínűleg valaminek az emulátorán fut, emulált lyukkártyákkal.

FYI: az ilyen modern, lenezett szarok mondjuk abban jok, hogy ha kell, ala lehet tenni nagyobb virtualis gepet - vagy ha szelteben is jol skalazhato, akkor tobbet. Idealis esetben ezt a szinten lenezett szar framework meg valamennyire segiti is. A skalazodast meg - ha arra van szukseg - szinten automatan lehet valtoztatni a terheles fuggvenyeben.

Mondjuk az en feladatom hivatalosan csak az adat belapatolasa volt (reszido, celido), de amennyire belelattam a rendszerukbe, nagyobb versenyek alatt sokkal tobben nezik meg egy sportesemeny honlapjat, mint elotte es utana. Megsem megoldhatatlan a dolog skalazasa.

A strange game. The only winning move is not to play. How about a nice game of chess?

Ugye a tipikus mainframe-es gondolkodás az, hogy van egy iszonyat  - de tényleg - erős gépünk, és ha több teljesítmény kell, akkor veszünk még licensz-t, és bekapcsolják a többi processzort is.

Erre a logikára terveztek alkalmazásokat. Ez egyébként nagyon-nagyon sok mindenre elég, de bizonyos peak terhelések ellen sajnos nem véd.

A Zseries is tudja ezt, ún. partíciókon - virtuális gép - dolgozgatnak, és ha kell még erőforrás valahová, akkor a partíciók paraméterezésével lehet segíteni. Elképesztő teljesítményről beszélünk. Alig hiszem, hogy egy ilyen peak megzavarná az életet egy ilyen vason. Azt hiszem, nem ismerve a tényleges helyzetet, hogy annak lesz igaza, aki azt írta, hogy kellemesen elműködött az a rendszer idáig, nem költötteg semmilyen upgrade-re, és most fő a fejük az elmaradt cselekvések sorozata miatt.

Van free is. De ennél sem ígérik, hogy olvasható, továbbfejleszthető kódot generál (COBOL-t sosem néztem, mintha az f2c FORTRAN-ból olvasható C-t generálna, Algol 60-ból se a marst, se a jff-algol nem generál olvasható kódot). Ha jól értem, itt a probléma a kód fejlesztése lenne.

( NevemTeve | 2020. 04. 14., k – 06:12 )

Szerkesztve: 2020. 04. 14., k – 06:13

Meta: és én még azt hittem, ~~~~~ olvtárs az önfényező sztorizgatás nagymestere a HUPon... Most úgy látom, hogy őt is messze felülmúlja itt valaki.