Názory k článku
Programování mainframů: COBOL

CODASYL, to bylo vzdycky synonymum vseho nizkeho a mrskeho. Vse, nad cim duse place a co zabiji ducha.

…why women hate periods.

dost dobry

70% dnes běžících transakčních systémů je v Cobolu – není slušná část toho spíš v CICS makrech do Cobolu expandovaných?

Ano, pravdepodobne hodne velka cast budou skripty transakcniho serveru CICS, ale Gartneri ta svoje cisla nijak dal nerozvadeji.

Předpokládám, že data byla na média ukládána binárně a v případě změny formátu (datového modelu) nešly jednoduše načíst a musely se převádět?

Ak boli data ulozene COBOLovskym programom v nejakom vlastnom pseudo-formate a program uz nie je k dispozicii, byva s dekodovanim dost problem – vid napriklad tieto thready:
http://www.tek-tips.com/viewthread.cfm?…
http://www.tek-tips.com/viewthread.cfm?…

Koukam, ze Cobol je jen o trochu horsi, nez ABAP (Advanced Business Application Programming). Brrr.

ABAP/4 se COBOLu zatraceně podobá. Jako vejce vejci. Všechno má svoje, i na tohle se dá zvyknout, ale začátky jsou holt těžké: http://www.jaros.in/…sapem-1-cast

ABAP urcite vychadzal z COBOLu. Mne pripada ako vylepseny COBOL s integrovanym SQL.
COBOL sice umoznuje pouzivat ESQL, ale vsetky premenne v programe su globalne a neumoznuje standardne ani rekurziu. Pretoze som mal skusenosti s COBOLom programovanie v ABAPe sa mi zdalo ovela lahsie ako v COBOLe – ale s ABAPom nemam zase moc skusenosti, pretoze som som ho skusal len niekolko dni. Nejake zdrojaky som si ale odlozil – napriklad, vypocet faktorialu pomocou rekurzie je v ABAPe celkom prirodzeny, ale v COBOLe to az tak jednoduche nie je a je to pracnejsie:

ABAP:

REPORT  zrm071.
PARAMETERS: nummer TYPE i DEFAULT 5.
DATA: fak_ergebnis TYPE f,
      result TYPE p,
      n TYPE i.

START-OF-SELECTION.

n = 1.
WHILE n <= nummer.
  PERFORM faktorial USING n CHANGING fak_ergebnis.
  result = fak_ergebnis.
  WRITE: / 'Faktorial(', n, ') = ', result.
  n = n + 1.
ENDWHILE.

FORM faktorial USING value(n) TYPE i CHANGING fak TYPE f.
  DATA: n_1 TYPE i,
        fak_n_1 TYPE f.

  IF n <= 0.
    fak = 1.
  ELSE.
    n_1 = n - 1.
    PERFORM faktorial USING n_1 CHANGING fak_n_1.
    fak = n * fak_n_1.
  ENDIF.
ENDFORM.

END-OF-SELECTION.

COBOL:

Program sa musi specialne deklarovat ako RECURSIVE
1. sposob je pouzit LOCAL-STORAGE SECTION:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. FACTORIAL RECURSIVE.

       ENVIRONMENT DIVISION.
       CONFIGURATION SECTION.
          SOURCE-COMPUTER. IBM-ISERIES.
          OBJECT-COMPUTER. IBM-ISERIES.

       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01 NUMB PIC 9(4) VALUE 5.
       01 FACT PIC 9(8) VALUE 0.

       LOCAL-STORAGE SECTION.
       01 NUM PIC 9(4).

       PROCEDURE DIVISION.
           MOVE NUMB TO NUM.
           IF NUMB = 0
             MOVE 1 TO FACT
           ELSE
             SUBTRACT 1 FROM NUMB
             CALL "FACTORIAL"
             MULTIPLY NUM BY FACT
           END-IF.
           DISPLAY NUM "! = " FACT.
           GOBACK.
       END PROGRAM FACTORIAL.

2. sposob je elegantnejsi ale zrejme specificky pre ILE COBOL na AS/400 (pouzit CALL PROCEDURE)

       IDENTIFICATION DIVISION.
       PROGRAM-ID. FACTORIAL RECURSIVE.
       ENVIRONMENT DIVISION.
       CONFIGURATION SECTION.
       SOURCE-COMPUTER. IBM-AS400.
       OBJECT-COMPUTER. IBM-AS400.
       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01 RESULT       PIC 9(20).
       01 CALL-RESULT  PIC 9(20).
       01 N-MINUS-1    PIC 9(4).
       LINKAGE SECTION.
       01 N            PIC 9(4).

       PROCEDURE DIVISION USING BY VALUE N RETURNING RESULT.
           IF N = 0
              COMPUTE RESULT = 1
           ELSE
              COMPUTE N-MINUS-1 = N - 1
              CALL PROCEDURE 'FACTORIAL'
                   USING BY VALUE N-MINUS-1
                   RETURNING INTO CALL-RESULT
              COMPUTE  RESULT = N * CALL-RESULT
           END-IF.
           GOBACK.

a tu je volajuci program:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. RECURTEST.
       ENVIRONMENT DIVISION.
       CONFIGURATION SECTION.
       SOURCE-COMPUTER. IBM-AS400.
       OBJECT-COMPUTER. IBM-AS400.
       SPECIAL-NAMES.
       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01 N           PIC 9(4).
       01 RESULT      PIC 9(20).
       LINKAGE SECTION.
       PROCEDURE DIVISION.
           PERFORM VARYING N FROM 0 BY 1 UNTIL N = 21
             CALL PROCEDURE 'FACTORIAL'
                  USING BY VALUE N
                  RETURNING INTO RESULT
             DISPLAY N "! = " RESULT
           END-PERFORM.
       GOBACK.

Ani skompilovat a zlinkovat to nie je jednoduche – o tom si mozete precitat napriklad v tomto threade: Back with recursion in COBOL again! a sami si to aj mozete prakticky vyskusat ak si vytvorite konto na free AS/400

Kazdopadne ABAP ani COBOl nie su jazyky navrhnute primarne na implementaciu nejakych komplikovanych algoritmov ale na pracu s datami.

OpenCOBOL rekurzi zvlada a mam dojem, ze posledni verze COBOLu se o ni taky zminuje (jen jsem to letmo zahledl, COBOL neni muj oblibeny jazyk :-), takze jsem ten standard jen proletl)

OpenCobol som nikdy neskusal. Neviem ci vobec tento projekt este zije. Rekurzia je podporovana zrejme v standarde COBOL 85. pouzitim klucoveho slova RECURSIVE.
Takisto COBOL nie je moje hobby, pouzivam ho len v praci ked je to nutne. Okrem Open COBOL a Tiny COBOL sa daju stiahnut este volne COBOL-IT a MF Net Express. Netexpress je ale obmedzeny na 2200 risdkov kodu a takisto neviem, ci skusobna verzia COBOL-IT nie je crippleware.
Doporucujem ale radsej vytvorit si konto na free AS/400 kde jek dispozicii enterprise class compiler a 50 MB diskoveho priestoru zadara: Holger Scherer.
Mimochodom nepoznate niekto nejaky mainframe so z/OS,kde by som mohol ziskat konto zadarmo? Moc by ma to zaujimalo.

zkus http://www.efglobe.com/…ame/mainuser

Diky moc uz som tam! Len zatial neviem ako:
vytvorit zdrojak
skompilovat
spustit

nejjednodussi je pouzit IGYWCG (compile and go) proceduru, viz. JCL:

//COBOLC   JOB (12345678),PRG,MSGCLASS=H,
//         MSGLEVEL=(1,1),CLASS=A,NOTIFY=&SYSUID
//STEPA    EXEC PROC=IGYWCG
//COBOL.SYSIN DD *
       IDENTIFICATION DIVISION.
       PROGRAM-ID. HELLO.
       PROCEDURE DIVISION.
           DISPLAY "HELLO, WORLD!".
           STOP RUN.

pro zakladni informace doporucuji http://www.redbooks.ibm.com/…g246366.html

Dakujem

ano ABAP se COBOLem dost inspiroval, nekteri programatori se dokonce explicitne snazi, aby jejich ABAPovske zdrojaky vypadaly co nejvic jako COBOL :-) Ale mam dojem, ze ABAP vznikl na zaklade nejakeho skriptovaciho jazyka z R/2 a teprve tento jazyk byl inspirovan COBOLem.

Ac jsem programator mainframu, a s COBOLem se obcas setkam (nastesti ne denne), ta cisla mi nejak nesedi. Zahraji si na dablova advokata:

1. Radek programu v COBOLu je 80%, radek programu v Jave a C je 20%.
2. Programatoru v COBOLu je 50%, programatoru v Jave a C je 50%.

Drive bylo programatoru radove mene. Presto mensi mnozstvi programatoru vyprodukovalo vice radek COBOLu. Neni tedy COBOL dobry jazyk, v kterem se programuje efektivneji nez v Jave nebo C?

Meradlom dobreho jazyka su aj tie riadky, co sa nemuseli nakodit. Takze pisat viac neznamena lepsie programovat :)

V idelanom jazyku by stacilo 0 riadkov a pocitac by si sam domyslel :)

Řádků musí být vždy více jak 0, aby se tam vešel aspoň jeden bug :-)

Jak rika klasik, program s nula radky ma tu nejhorsi chybu na svete – je nanic :-)

Ale mate pravdu v tom, ze COBOLovsky program s nula radky je chybny, protoze v nem chybi vyzadovane oddily :-)

Mimochodem, zajimavy je, jak cecko (gcc) prelozi prazdny soubor – objektovy file ma neco pres 600 bajtu a po stripovani cca 400 bajtu…

Méně řádek neznamená větší efektivitu ;-)

Neznamena (a ja to vim moc dobre, znam Common Lisp). Napsal jsem to jako dabluv advokat. Proste tem cislum neverim, protoze takhle z nich vyplyva, ze programatori v COBOLu mohou (za jednotku casu) napsat mnohem vic radek nez lide v ostatnich jazycich. Nesedi mi to dokonce ani kdybychom prijali, ze je COBOL (o neco) ukecanejsi.

Problém je od začátku v tom, že počet LOC je dost nesmyslná metrika. Důležité je, co daný program umí, což lze pojmout jako množství implementovaných vlastností nebo užitnou hodnotu programu vytvořené za jednotku času. Což samozřejmě není totéž a neplatí mezi tím nutně ani přímá úměra. A ani jedna z těch metrik není závislá jenom na jazyku, ale i na knihovnách apod.

Souhlas, LOC ma (krome porovnani „ukecanosti“ jazyka) smysl jen v nekterych firmach, ktere takto „meri“ produktivitu programatoru, coz je vsak docela nesmyslne a vede to ke zbytecne nabobtnalym zdrojakum, kopiim kodu atd.

To jestli je ukecanejsi, zalezi na resenem problemu, to se tezko obecne porovnava (stejne jako efektivita prekladace na netrivialnich prikladech). Treba typicke one-linery se v COBOLu musi rozepsat treba na 30 radku – viz napriklad vyse uvedeny vypocet faktorialu, na druhou stranu nejaka vysokourovnova prace s daty (ala SQL) by v COBOLu mohla vyjit jako docela kratky program.

Mozna je to tak, ze COBOListi „musi“ napsat vice radku kodu aby udelali stejnou praci jako v jinych jazycich. No, priste si ukazeme APL, ten na to jde presne opacne nez COBOL – zadna klicova slova, pouze symboly :-)

> Mozna je to tak, ze COBOListi „musi“ napsat vice radku kodu aby udelali stejnou praci jako v jinych jazycich.
Ano presne toto je moj nazor …v COBOLe robim od r. 2002 :-)

> … vyplyva, ze programatori v COBOLu mohou (za jednotku casu) napsat mnohem vic radek nez lide v ostatnich jazycich.
Preco nie? Predpokladajme, ze programator bez ohladu na jazyk vymysli algoritmus za rovnaky cas. Programator vo FORTRANe ho ale implementuje napriklad za pol hodinu a dalsiu pol hodinu potom relaxuje. Programator v COBOLe nema ale cas na relaxaciu, pretoze na implementaciu toho isteho algoritmu musi napisat viac riadkov. Takze mu implementacia zaberie celu hodinu a za tuto hodinu vyprodukuje 2-krat tolko riadkov ako programator vo FORTRANe. To ale neznamena, ze by bol COBOL, alebo programator v COBOLe produktivnejsi. Oba programy (v COBOLe a vo FORTRANe) predsa robia to iste, akurat ze implementacia v COBOLe je pracnejsia.

„Neni tedy COBOL dobry jazyk, v kterem se programuje efektivneji nez v Jave nebo C?“

Snad v každém jazyku se programuje efektivněji než v Javě nebo C (pochopitelně krom C-like jazyků). Ovšem s tím, jestli COBOL je nebo není dobrý jazyk, to nesouvisí.

Co myslite tim „efektivne“? Pokud cas od zadani k vysledku, tak to hodne zavisi na konkretnim problemu. Jednak jak moc je pro nej jazyk vhodny svym principem imperativni vs jiny a jednak jak moc je pro nej knihoven. A zrovna v tomhle jsou na tom Java i C ve vetsine oblasti docela dobre :-)

Pokud to myslite na „delku kodu“, tak tam je dulezita i citelnost kodu a v tomhle jsou na tom Java i C opet pomerne dobre.

S tou prehlednosti v C doporucuji se podivat na http://www.ioccc.org/

„There is no computer language in which you could not write a bad program“. Samozrejme kdyz je programator prase (nebo chce psat schvalne necitelne), jazyk to moc nevytrhne ;-)

V dobách kralování mainframů jsem programoval v jazyce PL/1, který pro svojí nepřenositelnost už v podstatě zanikl. Na co mi stačilo deset řádků, nestačilo kolegům cobolistům ani deset stránek. Zvláště pak v deklaracích, které tvořily asi tak 80% programu, šlo o mechanické opisování téhož v podstatě do blba. V historii neexistoval ukecanější jazyk a cobolisti byli snadno k rozpoznání podle tenisového lokte. Nikdy jsem nechápal, jak vůbec mohl tak příšerný jazyk vzniknout.(V jedné porovnávací studii programovacích jazyků autor napsal, že COBOl je určen těm, kteří chápou, co znamení vezmi a, přičti k němu b a výsledek ulož do c, ale nikdy by nepochopili příkaz c=a+b). Teprve tento článek mi osvětlil, že je to kvůli managementu.

Tak velké množství řádů bylo nutno napsat právě proto, že COBOL je zoufale neproduktivní. A nejhorší bylo, že že většina z nich je mechanické opisování bez nároků na intelekt. Řekl bych, že cobolisti díky tomu moc radosti z tvůrčí práce nezažili.

Jakožto bývalý aktivní COBOLista (čtyři roky skladový subsystém pro velkého tuzemského výrobce) se vším výše uvedeným naprosto souhlasím.

Jen dodám, že u nás měl každý COBOLista v šuplíku lahev becherovky nebo fernetu – po prvních pár týdnech jsem si ji pořídil taky :-)

Tiez mam par rokov odprogramovanych v COBOL-e na SMEP-ke a nikdy nezabudnem na tie dlhe hodiny plne rozhovorov s kolegami kym sme cakali na compilaciu programu a prvy vypis chyb. My sme mali na COBOL-e postaveny cely ASRP a cuduj sa svete, skutocne to fungovalo. A flias sme mali plnu skrinu :)

Inak praca programatora v COBOL-e je jedna zo siedmych najhorsich prac okolo pocitacov. :)

Ano praca v COBOLe nie je jednoducha a preto to malokto chce robit. A preto je COBOListov malo :-)

Neviem porovnat COBOL s PL/I, lebo v tom som nikdy neprogramoval. COBOL sa na zlozitejsie vypocty nehodi, je na manipulaciu s datami. Produktivita zavisi aj od prostredia. Napriklad na PC by som nikdy nepisal v COBOLe, ale na AS/400 napisem batchovy program rychlejsie v COBOLe ako v C.

Myslim, ze su to akademicke predsudky, ze vacsina COBOListov nemusi rozmyslat. Pre mnoho z tych co poznam ja tvori COBOL len jeden z mnoha jazykov, ktore pouzivaju. Velke percento prace COBOListov totiz tvori sklbenie stareho a noveho sveta, t.j. volanie COBOLovskych programov z webovych aplikacii a maintenance + troubleshooting, takze su hladani hlavne ludia, ktori ovladaju nove technologie a COBOL este k tomu.
Nechcem tym ale nijako COBOL obhajovat – je to z dnesneho hladiska kuriozne sice navrhnuty jazyk ale predsa tu mame aj podobne novsie varianty ako SQL a ABAP.

Nebyla by pls k dispozici ta porovnavaci studie? Nebo alespon klicova slova, zkusil bych si to dohledat. Diky.

Preco sa produkuje v COBOLe viac riadkov ako v inom jazyku?

Pokusim sa to objasnit, ako mozno jediny aktivny COBOLista tu na roote :-)
Je to preto ze COBOL je ukecanejsi a a vsetky premenne v jednom programe su globalne. Kedze premenne su globalne, tak aby sa udrzal nejaky poriadok je zavedena urcita stabna kultura. Napriklad ak ma COBOLOvsky podprogram (tzv. paragraf) SUBR vstupne argumenty ARG1, ARG2,…,ARGn a dava vysledky VYSL1, VYSL2,..,VYSLm tak pred zavolanim SUBR sa najprv naplnia hodnoty globalnych premennych do argumentov a po zavolani sa zase nakopiruju vysledky do globalnych premennych, napr. takto (WS = Working Storage):

MOVE WS-VAR1 TO SUBR-ARG1
MOVE WS-VAR2 TO SUBR-ARG2
...
MOVE WS-VARn TO SUBR-ARGn

PERFORM SUBR

MOVE SUBR-VYSL1 TO WS-VYSL1
MOVE SUBR-VYSL2 TO WS-VYSL2
...
MOVE SUBR-VYSLm TO WS-VYSLm

Naproti tomu napriklad vo FORTRANe staci zavolat podprogram SUBR jednoducho nahradenim formalnych argumentov skutocnymi takto:

CALL SUBR(SUBR-ARG1,SUBR-ARG2,..,SUBR-ARGn,SUBR-VYSL1,SUBR-VYSL2,..,SUBR-VYSLm)

Z toho vyplyva, ze volanie subrutiny moze byt v COBOLe o m+n riadkov vacsie ako vo Fortrane. Okrem toho COBOL ma vacsi overhead – treba deklarovat 4 divisions a zapis aritmetickych vyrazov je tiez dlhsi, takze zrejme aj implementacia SUBR bude mat v COBOLe viac riadkov ako vo FORTRANe.

Okrem toho existuju prikazy ktore sa zvyknu pisat na viac riadkov, napr. spujenie viacerych substringov do jedneho stringu

STRING SUBSTR1 DELIMITED BY SIZE
       SUBSTR2 DELIMITED BY SIZE
       ....
       SUBSTRn DELIMITED BY SPACE
  INTO VYSLEDNY-STRING
END-STRING

Dalej je to pouzivanie copybookov, t.j. cele casti zdrojoveho kodu (hlavne deklaracie premennych) ktore sa vytvoria v jednom zdrojovom subore a kopiruju do inych zdrojakov.

IMHO, vacsi pocet riadkov a produktivita az tak moc nesuvisia. Programator v COBOLe musi tak isto dlho rozmyslat nad nejakym algoritmom ako napriklad programator vo Fortrane, ale okrem toho si to este musi odmakat aj manualne, pretoze na implementaciu podobneho algoritmu musi napisat ovela viac riadkov kodu. To sa da vsak aj zoptimalizovat napr. vyskladnenim opajucich sa casti kodu do separatnych zdrojakov tzv. copybookov a ich kopirovanim do inych zdrojakov (prikaz COPY) a pripadne aj pouzitim dobreho editoru a Copy+Replace.

Aj ked sam ako matematik si vazim osobnost ako E. W. Dijkstra v ziadnom pripade nesuhlasim s jeho tvrdenim, ze: „The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense.“
To ze Dijkstra toto povedal potvrdzuje iba to, ze v tomto jazyku nikdy vazne neprogarmoval. Je to prave naopak: Pretoze COBOL je dost zastaraly a na rozdiel od Javy alebo C#, kde su na vsetko metody v standardnej kniznici, alebo sa daju stiahnut zadarmo, v COBOLe nie je nic podobneho, je tam niekolko tzv. INTRINSIC FUCTIONS a inac si programator musi vsetko vymysliet sam, takze programatorov mozog zatazuje COBOL asi viac ako Java alebo C#. Mozno preto v COBOLe neradi ludia programuju. Na druhej strane asi preto sa za COBOL plati lepsie ako za main stream jazyky :-)

Too som pisal ja, len som sazabudol podpisat :-)

Mal som tu cest „programovat“ v ATLASe a ako pozeram je to velmi podobny COBOLu. ATLAS sa pouziva na automaticke testovanie v avionike.

http://en.wikipedia.org/…_All_Systems

na velke projekty je to nevhodne, ale jako scriptovaci jazyk do CICS bych ho neodsuzoval.

na z/os je out of box supported
* Assembler
* COBOL
* PL/I
* C/C++
* Java
* CLIST
* REXX™
* JCL

Horsi nez cobol je urcite RPG (a LISP).

Pokud by nekdo chtel behat linux na zOS tak ceny jsou zhruba nasledujici:

1 GB RAM pro zOS linux – $2,25k pro BC z10. 1 GB ram pro z/os stoji $6k
IFL (procesor na kterem bude behat linux) $47,5k pro BC a $75k pro EC z10 (qcore procesor 3,5GHz, je i 4,5GHz varianta)

Ono to vypada drahe ale pro BC z10 jsou ty ceny zhruba stejne jako pro POWER6. A je lepsi honit ten linux na z10 nez na System p protoze to ma znatelne vice featur a je to lepsi hardware. Obvykle zakaznici premigruji vsechen svuj dulezity x86/linux workload na z/Linux a pochvaluji si to. Jeden mainframe nahradi i stovky x86 serveru, on ma bezny x86 server docela male vyuziti cpu – jako prumer se udava 15–20%.

„Horsi nez cobol je urcite RPG (a LISP).“

Jsou holt jazyky pro průměrně inteligentní lidi, pro podprůměrně inteligentní lidi a pro nadprůměrně inteligentní lidi. Je zřejmé, že průměrně inteligentní člověk bude za hrozné považovat jak jazyky pro podprůměrně inteligentní, tak pro nadprůměrně inteligentní.

Neříkejte, že LISP je hrozný jazyk, když to pouze vaše intelektuální schopnosti jsou omezené natolik, že ho nedokáží vstřebat. ;-)

Myslim, ze LISP je natolko syntakticky jednoduchy, ze naucit sa ho pouzivat na take veci ako sa pouziva COBOL (t.j. praca s databazou) je ovela zlozitejsie ako sa naucit syntakticky zlozitejsi COBOL.
Druha vec je, ze COBOL je samodokumentujuci, co sa o LISPe neda povedat, takze udrzovat stare LISPovske programy je asi horsie ako udrzovat stare COBOLovske programy.
Nemyslim, ze to ci niekto pouziva COBOL alebo LISP suvisi priamo s jeho inteligenciou. COBOL sa pouziva v bankach, kde sa staraju o Vase peniaze inteligentni ludia – LISP nie je v bankach rozsireny. Zrejme preto, ze je povazovany za jazyk nevhodny na dane pouzitie.
U IBM patri COBOL k standardne dodavanym kompilatorom na systemoch iSeries a zSeries. O LISPe som nepocul, ze by ho IBM vobec dodavala. Zrejme preto ze v biznise nie je on zaujem.

Kto z nejakych ciste intelektualnych dovodov chce programovat iba v LISPe, najde uplatnenie akurat v nejakej akademickej institucii. Kto je pragmatickejsi a je ochotny naucit sa aj COBOL, moze si s nim celkom dobre zarobit.

„v bankach, kde sa staraju o Vase peniaze inteligentni ludia“

LOL!!! :-D Že by vtip měsíce? Smál bych se, i kdybych o tom nic nevěděl. Ale že jsem o to už taky zavadil osobně, směju se ještě víc!

Jasne, ze bol to vtip :-)
Teoreticky by mali byt inteligentni, ked sa staraju o peniaze, ale samozrejme ako vsade aj tam je dost vynimiek. Tiez som uz parkrat o to zavadil.

Chcel som len urobit narazku na suvislost medzi inteligenciou a pouzivanym jazykom :-)

Provokaci s Lispem nebudu komentovat.

Co se týče ceny, viděl jsem jako motivaci pro migraci Linuxu na z/OS i to, že licenční metrika pro jistý drahý produkt byla per CPU.

RPG je asi jediny jazyk, na ktory som potreboval skolenie.
Pripominalo mi to na zaciatku assembler, ale aj ked som sa ucil kedysi uz asi 2 assemblery to RPG sa mi nedalo vstrebat.
Teraz si ale myslim, ze ked sa v RPG clovek zabehne, tak je to este produktivnejsi jazyk ako COBOL, hlavne sucasne free-form RPG IV sa uz celkom podoba inym beznym jazykom. Hlavne na AS/400 je RPG stale Number 1.