- 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.
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Aki megtalálja a "miért"-re a választ a bejelentésben, jelezze! :D
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
L'art pour l'art!
Megyek, keresek is valami microservice framework-öt hozzá.
- A hozzászóláshoz be kell jelentkezni
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. :)
- A hozzászóláshoz be kell jelentkezni
"Szerencsére" itt keleten lassabban pörögtek a bitek akkoriban, így nálunk még akad néhány aktív programozó Cobol, Fortran, PL1 ismeretekkel...
- A hozzászóláshoz be kell jelentkezni
"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 :)
- A hozzászóláshoz be kell jelentkezni
Azt nem írtam, hogy hibátlan is volt, de a napi feladatát ellátta utána évtizedekig. Már csak az elhíresült y2k bug miatt is volt hiba a legtöbben.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Ez az a Hercules, amivel perben allt az IBM?
- A hozzászóláshoz be kell jelentkezni
A héten kezdtem el nézegetni a Hercules és az MVS használatát :)))
- A hozzászóláshoz be kell jelentkezni
Na ja, csak akkoriban ha elkezdtél írni egy programot, már az elején tudtad, hogy a végén mit kell neki majd csinálni.
- A hozzászóláshoz be kell jelentkezni
Ma meg elkezded írni, majd a végén kiderül hogy egészen mást csinál... ;-P
- A hozzászóláshoz be kell jelentkezni
Az már a másik gond, a kor elõrehaladtával azért ez már kevésbé jellemzõ - persze csak addig, amíg a kor addig nem halad elõre amikor már a végére már nem emlékszel hogy mit is kezdtél el fejleszteni. :-)
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
Egyszerű a válasz: mert piaci igény van rá.
(AZ IBM magától nem támogatna hobby projekteket.)
"Share what you know. Learn what you don't."
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
Rákérdezek, Lufthansa?
:D
- A hozzászóláshoz be kell jelentkezni
Nagybátyám a BKV-nál volt COBOL programozó amíg nyugdíjba nem ment. Lehet, még ma is futkározik 1-2 program, mert a hekker-gate alapján a modern alkalmazások fejlesztését kiszervezik....:D
- A hozzászóláshoz be kell jelentkezni
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Szerintem ilyesvalami lehet a válasz: https://xkcd.com/554/
:)
De mint tudjuk COBOL-t csak a hátulgombolósok használnak :D (aki nem ismerné: https://www.szabilinux.hu/orlando_unix/igazi.html)
- A hozzászóláshoz be kell jelentkezni
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."
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
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?" -=-
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
lol :)
De valoszinuleg ezert:2020’s COBOL Crisis is the Canary in the Coal Mine for Established Banks and Insurers
Support Slackware: https://paypal.me/volkerdi
- A hozzászóláshoz be kell jelentkezni
Manjaro - Android - Smalltalk - Flamenco - OSMC
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
A GNU COBOL nem megfelelő?
- A hozzászóláshoz be kell jelentkezni
Bárki supportálhatja, ha ért hozzá - ez a nyílt forrás egyik előnye, nem?
- A hozzászóláshoz be kell jelentkezni
bárki supportálhatja != supportálja valaki
- A hozzászóláshoz be kell jelentkezni
A bárki itt nem igazán megfelelő, mert az eredeti mainframe-ek is IBM termékek és azokkal kéne kompatibilisnek lennie.
- A hozzászóláshoz be kell jelentkezni
Az IBM Cobol for Linux x86-ra igaz, hogy kompatibilis az eredeti mainframe-kkel? Nem hiszem. Ez fals érvelés.
- A hozzászóláshoz be kell jelentkezni
Nem feltétlenül kell szvsz, hogy kompatibilis legyen, elég, ha a COBOL program érzékeli a környezetét úgy, mintha egy eredeti IBM mainframe-en futna.
"Share what you know. Learn what you don't."
- A hozzászóláshoz be kell jelentkezni
??? A compiler nyilván azért kell, hogy portolni lehessen a COBOL kódot Linuxra. Nyilván nem új projektet fognak COBOL-ban nyomni :)
- A hozzászóláshoz be kell jelentkezni
A valódi ok, hogy Linus utálja már a C -t. Mivel a Red Hat felvásárlás óta bejárása van az IBM belső köreibe kilobbizta ezt a Linuxos Cobol fordítót. Így most végre COBOL -ra áll át a Linux kernel fejlesztése. :D
- A hozzászóláshoz be kell jelentkezni
Jó poén :-) Persze ezzel az erővel Linus már rég assemblyben írhatná a kódot...
- A hozzászóláshoz be kell jelentkezni
Amire te gondolsz, az egy mainframe emulátor Linuxra :-)
- A hozzászóláshoz be kell jelentkezni
Van olyan céges policy, ami szerint nem. Régi sztori a syslog-ng története, gondolomm, vannak, akik hallottak már róla.
- A hozzászóláshoz be kell jelentkezni
Aki nem, annak elmeséled?
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
Lehet hogy már Rust-ban ;-P
- A hozzászóláshoz be kell jelentkezni
No-no fiam, Cobol talán nem lehet hidat építeni?
- A hozzászóláshoz be kell jelentkezni
úristen.... de péntek van :D
“Luck Is What Happens When Preparation Meets Opportunity" - Seneca
- A hozzászóláshoz be kell jelentkezni
Emésztőrendszert meg rust-ban gazdag étrenddel lehet támogatni.
Tudom... szar poén.
[elfut]
- A hozzászóláshoz be kell jelentkezni
"Ha IBM COBOL for AIX®-ra mar letezett ez a compiler, akkor nem gondolnam, hogy nagy effortot igenyelt linuxra is buildelni es kiadni."
Azért az nem ötperces meló, hogy egy RISC-re írt compiler jól működjön X86/64 architektúrán is.
- A hozzászóláshoz be kell jelentkezni
Majd ezt is asszimilálja a systemd és akkor ez lesz a COBOLd. (Én kívánok elnézést.)
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Látod ezért kellett volna inkább saját megoldást fejleszteni nulláról. :)
- A hozzászóláshoz be kell jelentkezni
Ezek általában nem technikai, hanem politikai kérdések/döntések.
- A hozzászóláshoz be kell jelentkezni
Ismerem ezt. Így történt, amikor message szervert írtam scriptnyelven. Épp a scriptnyelvekről volt előadássorozat abban a hónapban és valaki lázban égett.
(Úgy, hogy egyébként volt egy majdnem kész kódunk C-ben ami így ment a levesbe.)
- A hozzászóláshoz be kell jelentkezni
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. :)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni