Az IBM COBOL fordítót készített x86-on futó Linuxra

IBM, Lenovo

IBM® COBOL for Linux® on x86 1.1 brings IBM's COBOL compilation technologies and capabilities to the Linux on x86 environment.

Főbb funkciók, jellemzők:

  • IBM COBOL optimizing compiler and runtime library for the Linux on x86 environment
  • Interoperability with IBM TXSeries® for Multiplatforms
  • Interoperability with IBM Db2® for Linux, UNIX®, and Windows™
  • Unicode support to enable COBOL applications to directly process Unicode data
  • Native support for XML, which enables COBOL applications to parse incoming and generate outgoing XML messages
  • Compatibility with IBM Enterprise COBOL for z/OS® and IBM COBOL for AIX®
  • Source conversion utility (scu) to aid in migrating COBOL source code developed with non-IBM COBOL compilers

Alapvető rendszerkövetelmények:

An x86-64 server that supports one of the following operating systems:

  • Red Hat® Enterprise Linux 7.8, or later
  • Ubuntu Server 16.04 LTS, 18.04 LTS, or later

Memory requirements are as follows:

  • Minimum of 250 MB for product packages

Részletek a bejelentésben. 

( trey | 2021. 04. 08., cs – 10:00 )

Aki megtalálja a "miért"-re a választ a bejelentésben, jelezze! :D

trey @ gépház

Nem teljesen. Cobol-ban még abban az időszakban írtak programokat, amikor az örökkévalóságnak készültek a szoftverek. Amikor készen volt valóban készen volt. Az IBM Mainframe gépekben levő mérnöki munkát dicséri, hogy sok program mára túlélte a programozóját és a túlélés itt napi aktív használatot jelent. 

A történek másik oldala, hogy nagyon megkérték mindig is ezeknek a mainframe rendszereknek az árát. Így többnyire azok lettek ügyfelek, akiknek nagyon kellett. Az utóbbi 2 évtizedben ez már szerintem csak belső szabályzatba kódolt korábbi megszokás. Az első nagy "Cobol krízis" a y2k bug miatt volt. Már akkor a golfpályákról toborozták vissza a nyugdíjas programozókat. Mostanra valószínűleg alig maradt olyan Cobol programozó, akinek ez volt a fő programnyelve és nem csak hobbiból használta hanem ebből élt meg. Szóval a cél szerintem elég nyilvánvalóan a következő generáció. Ahhoz, hogy bármilyen célból valaki ma megtanuljon profi szintem Cobol-ban programozni teljesen ingyenesen elérhetővé kell tenni mindent hozzá. A Linux támogatása nem is kérdés. Valószínűleg nem az Egyesült Államokból fognak kikerülni a jövő Cobol programozói. 
Egyébként szintén ingyen kiadott az IBM egy Hercules mainframe emulátort is, a cél itt is nyilván az utókor gondozása. 

Arra tippelek a Cobol programok még mindig működni fognak, amikor a Delphi tákolmány kihalási jelenség miatt kegyetlenül összeomlik és brutálisan beleáll a földbe. :)

"Nem teljesen. Cobol-ban még abban az időszakban írtak programokat, amikor az örökkévalóságnak készültek a szoftverek. Amikor készen volt valóban készen volt."

Ez is csak egy mítosz. A "készen volt" az pont úgy egy -akár hibákat is tartalmazó állapot- volt akkor is, mint a mai szoftvereknél. Csak akkor rámondták, hogy kész és nem jött több OTA frissítés :) 

Tekintve, hogy anno milyen gépekre, milyen környezetre készültek ezek a szoftverek, lehet rájuk mondani, hogy egyszer kellett jól megírni, és utána sok-sok évig nem kellett hozzányúlni. Nem kellett pár évente update-elni, újraírni azért, mert frissült a futtatókörnyezet vagy az oprendszer. Nem kellett hetvenféle grafikus környezetre optimalizálni, hanem csak a kliensen kellett a terminál emulációt egyszer helyesen konfigurálni.

Természetesen mindegyik szoftver tartalmaz hibát (talán a Helo World kivételével, de az sem biztos). Viszont mivel akkoriban egy kiadott szoftver esetén a hibajavítás sokkal nehézkesebb volt, kiadás előtt némileg alaposabban tesztelték a szoftvereket. Na meg tegyük hozzá: egyszerűbbek is voltak, így összességében egy akkoriban kiadott szoftver általában kevesebb bugot tartalmazott.

Regi klasszikus:

A Cobol programmer made so much money doing Y2K remediation that he was able to have himself cryogenically frozen when he died. One day in the future, he was unexpectedly resurrected.
When he asked why he was unfrozen, he was told: "It's the year 9999 - and you know Cobol".

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

Sajnos nem mondhatom meg, de az egyik legnagyobb légiközlekedésben érdekelt cég is használ COBOL-ban írt programot.
Bár azt is meg kell jegyezzem, hogy évekkel ezelött egy hiba miatt vissza kelett hívni egy 82 éves programozó matematikust, hogy egy hibát ki tudjanak javítani.

Egy nap 24 óra, plusz az éjszaka!

Azért azt megjegyezném, hogy az idézett szövegben a ,,hátulgombolósok'' vagy PASCAL-ban, esetleg ADA-ban való munkája szerepel szövegszerűen, a COBOL-lal kapcsolatban ez a minősítés nem fordul elő.

(Magam is a programozást ..hátulgombolós'' nyelveken tanultam...)

"Share what you know. Learn what you don't."

Ez a "senki nem bízna egy Mars felszíne fölött 80 +/- 3 km-mel elsuhanó szondát egy Pascal programozóra" duma addig volt "vicces", amíg az igazi programozók össze nem keverték a birodalmi és a metrikus mértékegységeket, és emiatt a Mars Climate Orbiter át nem alakult egy csinos kráterré Mars felszínén. Azóta nem ildomos jobb körökben ezzel kérkedni.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Nem a nyelv a fontos. Az évek során találkoztam pár olyan sráccal, akik bármiben IS tudtak jó kódot írni. Mert a fikázás meg szarozás helyett a nyelv adottságaira figyeltek és annak szellemében kódoltak.

Ellenben találkoztam már sok C-fikázóval, akikről hamar kiderült, hogy igazából fingjuk sincs a memóriakezelésről, sokszor már a pointer intézménye is egy misztikus valami volt számukra. Az ilyennek tényleg nem kellene C-ben programozni, de lehet, hogy inkább semmibe' se. Mert sajnos a memóriakezelési hibák nagyrészét nem egyébként hozzáértő emberek ejtik véletlenül (persze erre is van példa), hanem sarlatánok, akik eleve balfaszok az egészhez és lehet, hogy inkább hidakat kellene építeniük vagy alagutakat tervezni, mert az egyébként tök jól menne.

( SkyNET | 2021. 04. 08., cs – 10:53 )

00001 IDENTIFICATION DIVISION.
00002 PROGRAM-ID. HELLOW.
00003 AUTHOR. SKYNET.
00004 DATE-WRITTEN. 2021-APR-08.
00005 PROCEDURE DIVISION.
00006 DISPLAY "Hello world!".
00007 END PROGRAM HELLOW.

Ügyviteli adminisztráció DSL-ként teljesen rendben van. Ilyen portolásokkal a korszerű IT infrastruktúrába is bevonható. A "miért" sem bonyolult, van rá fizetőképes kereslet, USA, Távol-Kelet, valamennyire még Nyugat-Európa is. Nem minden szakterületen pörögnek úgy az események, mint a frontend javascript framework-ök világában. Nem olyan rég volt hogy nyolcvanas években készült, ASC X12 FIN üzenetfeldolgozókat kellett átírni perlből javaba közismert usa távközlési cég és northeast régió viszonteladói kapcsolattartásában, a konkrét projektben. Az X12 maradt, a következő technikai átírás szerintem majd a 2030-as években lesz.

Ja, mert egy compilerhez tényleg rengeteg support kell. Főleg egy 70 éves nyelvhez. Aki ilyet piszkál még, az általában ért hozzá.

Egyébként nekem nincs bajom, hogy valaki foglalkozik még ilyennel, és lesz hozzá egy +1. fordító. Tőlem elfér, akinek fontos, annak lesz egy plusz alternatíva. Csak a miértjét nem értem én se, hogy mi nem volt jó a gnucobolban. Annak én csak egy korlátját tudok, hogy a legújabb, 2014-es COBOL szabványt nem tudja, vagyis reklámozza, de igazából nem. A leírásából ítélve ez a fordító is csak azt írja, hogy selected features.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

( rpsoft v | 2021. 04. 08., cs – 14:03 )

Gondolom a mainframe -> (remélhetőleg ibm) cloud migrációt is akarják vele könnyíteni. Vajon csinálnak PL/I-t is? (Mondjuk nem láttam még élő PL/I programot, de a PL/I helyzet még rosszabb: ahhoz nincs open source compiler, csak MULTICS-ra.)

A MicroFocus-nak van PL/I compilere és mainframe emulációs runtime-ja Linuxra már egy ideje. Szerintem COBOL-t is tud a cucc. A PL/I-ben (és szerintem a COBOL-ban is) írt rendszerekben szerintem nem is maga a nyelv a lényeges, hanem a mainframe környezet, és nem azért nehéz migrálni róluk, mert már senki nem ért a nyelvekhez, hanem mert a teljes ökoszisztémát figyelembe kell venni.

( asm v | 2021. 04. 08., cs – 22:20 )

Ha IBM COBOL for AIX®-ra mar letezett ez a compiler, akkor nem gondolnam, hogy nagy effortot igenyelt linuxra is buildelni es kiadni.

Egyebkent ezt a COBOL forditot milyen nyelven irtak? C-ben?

( solt87 | 2021. 04. 11., v – 07:36 )

Eme hír hallatán még Hamlet is megnyalná mind a tíz ujját: "Én coboly köntöst csináltatok." #rosszszóviccek

( ddmb | 2021. 04. 15., cs – 16:18 )

Valaki tudna egy konkrét esetet mondani, hogy miért ragaszkodnak egy ilyen nyelvhez (illetve ebben a nyelvben íródott programhoz) a mai napig? Egyszerűen nem tudom megérteni...

Mi lassan 10 éve fejlesztünk egy SAP-ra épülő megoldást, backend-middleware-frontend scratchről felépítve, jelenleg 13 gyár használja azt stabilan. 5 fős a teamünk, régebben ez volt több is kevesebb is. Benne van több tízezer óra munka részünkről, rengeteg pénz, de tudom, hogy ha jön egy döntés föntről akkor egy szempillantás alatt kidobják az egészet a szemétbe, és lefejlesztetnek egy másikat, más toolokkal.

Nem feltétlenül volt ez helytelen elvi döntés. Volt egy régi motoros kollégám egy munkánál aki a mindent C++ban kell írni elvet képviselte. Sok user sok session számít mennyi erőforrást fogyasztanak az őket kiszolgáló szálak. Az eredmény a teljes szerver memóriáját felzabáló szoftver még kevés userszámnál is. Valószínűleg megfeledkezett egy destruktorról. Újra lett írva Java-ban. :)

Jujj. Memory leak-re nekünk külön tesztprotokollunk volt. Nem is értem, hogy egy szerveren futó programnál ez hogy fordulhatott elő.
Éjszakára mindig otthagytam a durván utilizált kódot, memóriahasználat logolással és másnap reggel kerestük a hízást és az esetleges furcsa mintákat.
A kódjaimban általában volt memóriakezelés bőven. A futási sebesség miatt kapásból parsolódott minden különféle dinamikus fákba, fésűkbe, amik aztán élték az életüket, leveleket (vagy teljes ágakat) létrehozva és hullatva.
Megfelelő szabályokkal, odafigyeléssel és teszteléssel mégis mindig meg tudtuk oldani. Amikor leak volt, azt általában hamar meg is találtam.
De nem csak a saját kódunkban fordult elő hiba. Találtunk pl. fájlrendszer-bugot is: nem szabadultak fel az inode-ok. Az egyik ilyen memória-egységtesztnél derült ki, mert a durva utilizálás miatt így egy-két napon belül elfogytak és nem jöttek létre onnantól a fájlok, ami a rendszert is leültette. Először nem értettük, mi van. De erre is egy-két óra alatt rájöttünk.

Bár alapvetően C programozó vagyok (voltam), nem gondolom, hogy mindent C-ben kell megírni. A kezelendő adatmennyiség és a meglévő kódbázis miatt azonban én mindenképp ezt vittem volna tovább. Volt kommunikáció hardverrel bináris protokollon, és hasonló nyalánkságok. Ezeket a részeket úgyis le kellett kódolni kis pici C programokban, amiket aztán hívott a script. Illetve az inter-processz kommunikáció text fájlokon keresztül ment (sic!). Sokszor volt ott összeszorított farpofa, hogy ne fossa el magát az egész.

Ahogy korábban említettem, pályafutásom során találkoztam irgalmatlan zsenikkel (gyakran partnernél, ügyfélnél), de láttam olyanokat is eleget, akiknek nem lenne szabad C-ben vagy C++-ban programozni, mert a egyszerűen alkalmatlanok rá. A kanyarban nincsenek. Sokszor fel sem fogja, mit csinál egyáltalán a kód, amit ír.
Az ilyenek szoktak ott állni meztelen fasszal, amikor hibát kell keresni a trágyadombjukban és fogalmuk sincs, mi tévők legyenek.