IBM kondigt Cobol-compiler voor Linux x86 aan

IBM heeft Cobol for Linux on x86 1.1 aangekondigd, een compiler die IBM's bestaande Cobol-compilerfamilie moet aanvullen. Het bedrijf hoopt dat klanten hiermee bedrijfsapplicaties geschreven in Cobol naar hybride cloudomgevingen brengen.

IBM meldt bij de aankondiging dat Cobol for Linux on x86 1.1 uit een compiler en runtime library bestaat en gebaseerd is op Enterprise Cobol for z/OS. IBM biedt daarnaast ook Cobol for AIX aan. Het bedrijf geeft enterpriseklanten met de aanvulling de mogelijkheid hun zakelijke Cobol-applicaties in te zetten voor hybride cloudomgevingen, of deze nu uit IBM Z-, Power- of Linux x86-systemen bestaan.

Cobol staat voor Common Business Oriented Language en deze programmeertaal voor zakelijke toepassingen stamt uit 1959, waarbij onder andere Grace Hopper een grote rol bij de ontwikkeling speelde. Met name op IBM-systemen zijn er nog altijd bedrijfskritische applicaties in gebruik die geschreven zijn in Cobol. Een tekort aan ontwikkelaars die de taal beheersen dreigt echter een probleem te worden. Programmeurs die er mee overweg kunnen, gaan met pensioen en bij jongere generaties is de taal niet populair, mede vanwege de wens Cobol uit te faseren.

IBM zet nog wel in op Cobol. Zo kondigde het bedrijf begin maart ook al Cobol Check aan voor het testen van Cobol-applicaties op IBM Z-systemen, Volgens IBM zijn er naar schatting nog 200 miljard regels in Cobol geschreven code in gebruik en gaat het om 'up-to-date-technologie'.

Reacties (124)

[dashorst248]

NB: ik heb geen ervaring met COBOL, en niet noodzakelijkerwijs een fan van die programmeertaal, maar heb wel een soft-spot voor (computer)geschiedenis, en COBOL is natuurlijk wel een belangrijk onderdeel ervan. En Grace Hopper is de bom.

Wat iedereen hier natuurlijk als eerste reactie roept is "COBOL MOT DAUD!" Waarom COBOL? Ik had dat allang herschreven in <insert favoriete hipstertaal>. Er heeft iemand een aantal jaren geleden een artikel geschreven waarom je niet zo makkelijk van COBOL afkomt.

The traditional answer is deeply cynical. Organizations are lazy, incompetent, stupid. They are cheap: unwilling to invest the money needed upfront to rewrite the whole system in something modern. Overall we assume that the reason so much of civil society runs on COBOL is a combination of inertia and shortsightedness. And certainly there is a little truth there. Rewriting a mass of spaghetti code is no small task. It is expensive. It is difficult. And if the existing software seems to be working fine there might be little incentive to invest in the project.

Echter blijkt de echte reden waarom die systemen niet omgeschreven worden blijven het feit dat COBOL anders rekent dan moderne programmeertalen.

One of the fun side effects of my summer learning COBOL is that I’m beginning to understand that it’s not that Java can’t do math correctly, it’s how Java does math correctly. And when you understand how Java does math and how COBOL does the same math, you begin to understand why it’s so difficult for many industries to move away from their legacy.

Voor je eerste COBOL programma is deze stackoverflow.com blog post een mooie met ook links naar verdere introducties.

IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO.
PROCEDURE DIVISION.
DISPLAY "Hello, world".
END PROGRAM HELLO.

Maar ik kan zeker het eerste gelinkte artikel aanbevelen aangezien dat veel dieper in gaat op decimaal berekeningen en tweakers waardig.

[Hoopje]

Inderdaad een erg leuk artikel om te lezen. Ik geloof er alleen geen snars van :-)

In dat artikel wordt heel erg de nadruk gelegd op fixed vs. floating point. Maar binnen het bereik 4 (inclusief) tot 8 (exclusief) -- dus voordat de afrondfouten in het voorbeeld de spuigaten uit gaan lopen -- gedragen ook de normale floating point types in moderne programmeertalen zich fixed point, en hebben alle getallen hetzelfde aantal (binaire) cijfers achter de komma. Dat Python-programma dat gebruikt wordt vergelijkt ook niet floating point met fixed point, maar binaire floating point met decimale floating point met een hogere precisie.

De auteur heeft het een keer over "decimal precision" (whatever that may be), dus misschien beweert ze dat het grondtal van de getallen een rol speelt. Maar ook dat lijkt me ver gezocht: die decimale getallen maken op een gegeven moment dezelfde rare sprong naar 100 als de binaire getallen.

Wat wel een rol lijkt te spelen is de precisie. Een normale 64-bit floating point (double), die tegenwoordig door bijna alle programmeertalen aangeboden wordt, heeft een precisie van ongeveer 17 decimale cijfers. In dat Python-programma vergelijkt ze dat met een decimaal floating point type met een precisie van 28 decimale cijfers. Maar als je de precisie wat naar beneden bijstelt, naar 17 bijvoorbeeld, dan treedt die fout ongeveer net zo snel op als bij binaire floating point.

Natuurlijk is het verschil tussen binaire en decimale floating point wel heel relevant, maar vooral vanwege het feit dat sommige getallen die er voor mensen heel eenvoudig uitzien geen exacte binaire representatie hebben. Berucht is het feit dat 0.1 + 0.2 niet gelijk is aan 0.3 (in binaire floating point). Decimale floating point is in COBOL blijkbaar ingebouwd, terwijl je er in Python en Java een bibliotheek voor nodig hebt. Dat kan inderdaad zijn, maar het gaat in beide gevallen wel over de *standaard*bibliotheek. En het gebruik van een bibliotheek heeft niet perse een impact op de performance. Wat wel een impact op de performance heeft is dat de meeste moderne CPUs alleen hardwaresupport hebben voor binaire floating point, niet voor decimale. Ik zie trouwens dat sommige IBM serverprocessors dat wel hebben, en ik kan me heel goed voorstellen dat IBM's COBOL-compiler daar, in tegenstelling tot Python en Java, gebruik van maakt.

[Reactie gewijzigd door Hoopje op 23 juli 2024 06:19]

[RonaldHeirbaut]

Een van de mooiste dingen in COBOL is de REDEFINE.

[BugBoy]

In een tijd dat geheugen schaars was en automatische optimalisatie tijdens het compileren vrijwel non-existent was het best begrijpelijk.

[Willem_54]

Daar ben ik het mee eens, dat maakt een programma heel efficient.

[dasiro]

heerlijke herinneringen aan m'n cobol-opleiding in 2002.
Lector die tijdens het examen langskomt om de vraag "wat doet deze code?" te verbeteren, want hij was de laatste punt vergeten te zetten

[unconnected]

Maar ik kan zeker het eerste gelinkte artikel aanbevelen aangezien dat veel dieper in gaat op decimaal berekeningen en tweakers waardig.

Dit was zo heerlijk om te lezen Thanks!

[beerse]

Hier durf ik alleen maar aan toe te voegen dat zo rond 1990 al werd verteld dat Cobol programmeurs schaars zijn omdat ze praktisch allemaal zo met pensioen gaan. Als techneut heb ik toen een heel andere keuze gemaakt.

Terug kijkend denk ik dat veel techneuten kiezen voor andere talen dan Cobol. Misschien is Cobol meer voor bedrijfskundigen en dergelijke. En bedrijfskundigen kiezen vaker niet voor een opleiding/training in computers en/of programmeren.

[R3M1]

COBOL ... Née, doe maar PL/1 ... voor echte mannen

[Faeron]

COBOL is oude meuk. Dat COBOL bestaat is het gevolg van het vaak ontbreken van iets belangrijks: een exit-strategie. Lekker een cloud-service in gebruiken nemen, een applicatie installeren, een dienst afnemen, een leverancier kiezen. En dat allemaal zonder jezelf af te vragen: wat als we er weer vanaf willen. Als je zoiets probeert te regelen tijdens een traject, dan ben je vaak de azijn-pisser. Van iets af kunnen terwijl je juist bezig bent om het in gebruik te nemen is dan 'een negatieve gedachte'. Echter, het is oh zo belangrijk, want wat als er iets misgaat met die dienst, leverancier, of dat product. Een leverancier of een dienst wijzigt de voorwaarden naar iets onacceptabels of een product bevat een kwetsbaarheid en een patch blijft uit. Dan ben je de sjaak! Het feit dat COBOL, ADA, Fortran en dat soort antieke meuk nog bestaat laat zien dat we dat nog steeds niet goed doen.

[Reactie gewijzigd door Faeron op 23 juli 2024 06:19]

[lenwar]

Ik snap je sentiment. Maar jij (en vele mede-tweakers met je) denken te vaak vanuit de techniek, waar een bedrijf vanuit bedrijfsvoering denkt. Techniek is voor bedrijven niet een doel, maar een middel. Het is uiteraard een middel dat veel geld kan kosten als je het verkeerd gebruikt, maar ook besparen als je het goed gebruikt.

Stel dat ik als bank een applicatie heb die in COBOL is geschreven in de jaren 80, waar ik bepaalde financiële producten in heb zitten. Die producten worden nu bijvoorbeeld niet meer verkocht. (denk aan kredietopslag voor een periode van 200 jaar (ja het bestaat/bestond ))

Het enige dat die applicatie nog hoeft te doen, is de producten bijhouden door een applicatie (die door internationale wetgevers (en dat zijn er nogal wat) en nationale banken (dat zijn er ook nogal wat) ). Effectief doet de applicatie weinig meer dan een paar keer per week een rapportje draaien.

Nou mag jij een business case bedenken voor die bank:
- De applicatie, die minimale patches nodig heeft, die prima draait op bestaande en toekomstige hardware/VMs.

- Een compleet nieuwe applicatie (laten) schrijven die alleen die oude producten opslaat en verwerkt en die vervolgens door allerlei internationale overheden en banken goedgekeurd moet worden, en als je die eenmaal hebt, dan ook moet onderhouden.

Bovenstaande is natuurlijk een geval dat niet vaak voorkomt, maar het zijn wel juist de soort omgevingen waar COBOL applicaties nog steeds veel gebruikt worden. Het is domweg een kostenbaten-analyse. Pas als het onderhoud van de COBOL applicatie aanzienlijk meer geld gaat kosten (hosting, onderhoud, personaal, enz.) dan een vervangende applicatie (die ook gehost, onderhouden en personeel nodig heeft), zal men het actief gaan vervangen. Wat je meestal ziet is dat als de betreffende organisatie ergens anders een nieuwe applicatie introduceert, die ook per ongeluk de functionaliteit van zo'n 'legacy-programma' ondersteund, of zou kunnen ondersteunen, dat je er dan pas van af komt.


Verder ben ik het helemaal met je eens hoor. Bedrijven moeten, nu meer dan ooit, bij het aangaan van een nieuwe dienst, eerst is goed kijken hoe ze er vanaf kunnen komen, maar dit is domweg een stukje historische techniek, toen dit nog niet van toepassing was.

[Faeron]

Ik snap je sentiment. Maar jij (en vele bedrijven met je) denken te vaak puur vanuit kosten-baten. Wat je daarbij mist is de risicogedachte. Je beschrijft een ideale situatie, maar die zijn zeldzaam. Dat zo'n antiek stuk software nu nog ondersteund wordt met een recent uitgebrachte compiler is mooi, maar wat als die er niet was? Je beschrijft een situatie dat een oud stuk software tot 'einde der dagen' niet aangepast hoeft te worden, maar wat als dat niet het geval is? Wat als de omgeving verandert? Organisaties hebben een bepaalde afhankelijkheid van processen en software is daarvaak een onmisbaar onderdeel van. Software die geschreven is in een verouderde taal vormt simpelweg een risico. Kan in die oude taal de nieuwe gewenste functionaliteit geschreven worden? Is de benodige kennis beschikbaar? Is voor die oude omgeving een OTAP-straat beschikbaar? En ja, op dit risico kan je weer je kosten-baten verhaal los laten, maar ik heb vanuit mijn werk te vaak, echt veel te vaak, de niet-ideale situatie gezien. Dus, nee, vandaag de dag nog COBOL software hebben draaien is in de meeste gevallen geen goed idee.

[Reactie gewijzigd door Faeron op 23 juli 2024 06:19]

[Blokker_1999]

Ik denk dat velen die vandaag nog COBOL gebruiken die risico inschatting ook wel gemaakt hebben. Jij gaat uit van "wat als" situaties die uiteindelijk niet het geval zijn. COBOL wordt nog altijd ondersteund en er zijn geen plannen om de komende jaren te stoppen met die ondersteuning.

En als er aanpassingen nodig zijn, dan is het vaak nog altijd veiliger van een kleine aanpassing te maken aan bewezen code dan die bewezen code volledig overboord te gooien voor een totaal nieuw, maar volledig onbewezen product.

Vergeet niet dat afstappen van COBOL en naar een moderne applicatie overstappen ook niet goedkoop is en al helemaal niet zonder risico. Want die nieuwe software zal weer vol met bugs zitten, bugs die je opnieuw veel geld kunnen gaan kosten en opnieuw vele jaren nodig zult hebben om die eruit te patchen. Ook dat moet je in je risico overweging meenemen.

[Faeron]

De risico's van overstappen naar een moderne applicatie zijn prima beheersbaar, als je er van te voren over nagedacht hebt: de exit-strategie!

En de bugs in nieuwe software zijn prima beheersbaar met een goede ontwikkel-aanpak. OTAP, testen, duidelijke specificaties en documentatie. Wat mij betreft geen argument om oude software niet te vervangen.

[lasharor]

Dan is het weer een kosten baten plaatje. Het is niet zo dat die stappen in die exit-strategie geen geld kosten.

[TheMak]

Bij Cobol applicaties is er natuurlijk niet echt sprake van een definieerde exit strategie. Deze zou qua fysieke computer zijn:
-Overstappen naar een andere mainframe
-Overstapppen naar stevige unix-omgeving
-Overstappen naar een linux machine
-Overstappen naar virtual machine
-Overstappen naar de cloud
-Overstappen naar cloud binnen de EU

Voor programmeer omgevingen zou je hetzelfde rijtje kunnen hanteren.

Door te blijven bij een IBM mainframe heb dus heel wat migraties kunnen besparen.

[lenwar]

Maar jij (en vele bedrijven met je) denken te vaak puur vanuit kosten-baten.

Dat klopt. Het zijn tenslotte commerciële bedrijven. Hun doel is geld verdienen.

Als we puur bij mijn voorbeeld blijven. Geloof maar dat de betreffende bank ook rekening houdt met de beveiliging, ondersteuning, enz. enz. enz. Dit valt allemaal onder het kopje kostenbaten. Hoeveel geld kost het om een stuk archaïsche software te ondersteunen, veilig te houden, enz. enz., en hoeveel kost het om heel de bups om te zetten.

Met al je andere aangehaalde zaken (kennis, otap beschikbaarheid, enz. enz.) heb je allemaal goede punten, maar ook dat wordt echt wel meegenomen.

Er is wereldwijd nog prima COBOL-expertise te vinden. Ja, die consultants vragen exorbitante bedragen, maar als je applicatie minimaal onderhoud nodig heeft, dan maakt dat op zich niet zo veel uit. Ook dat is weer een kostenbatenverhaal.

Mijn concrete voorbeeld kan je inderdaad bestempelen als 'de ideale situatie', maar het kan prima zo functioneren. Als bedrijven er echter voor kiezen om risico's te aanvaarden door het niet goed onder controle te houden, is dat natuurlijk ook een keuze. (onderhouden of schade repareren is een keuze)

[Proliges]

Dat klopt niet. een kosten-baten analyse bevat eigenlijk ook altijd wel een risicoanalyse.
Jij begint hier al over een OTAP straat en risico's maar je moet beseffen dat dat voor veel bedrijven helemaal niet relevant is.

Daarbij betekend verouderde software niet perse een verhoogd risico enkel en alleen omdat het oud is.

[webkiller71]

Als je uitgaat van risico: hoe groot is het risico dat de nieuwe applicatie bugs of subtiele verschillen introduceert? Vaak is dat heel groot. Des te ouder, des te groter de kans want dan zitten er heel veel randgevallen ingebouwd die je misschien niet meer herinnert.

[hellum]

In de tijd dat COBOL nog veel gebruikt werd bestonden al die dingen nog niet en documentatie was nog op papier.

[Proliges]

De realiteit is vaak anders. Ik heb al bij verschillende bedrijven oude software (en dan heb ik het over software van 20-30 jaar oud niet eens over cobol programmas van 40-50 jaar oud) omgebouwd naar nieuwe software en steevast zijn er nieuwe bugs en valt er andere programmatuur om.

Als je denkt dat het bij elke toko helemaal in orde is qua documentatie, unittesten en ontwikkelstraten dan heb je het echt bij het verkeerde eind. Ik durf te zeggen dat het bij 98% van de bedrijven niet in orde is, of in het verleden niet in orde is geweest waardoor er gaten zijn ontstaan.

[hiostu]

Besef je wel dat deze Cobol systemen al lang geleden ontwikkeld zijn. Door mensen die nu al met pensioen zijn of tenminste al naar andere werkgever. Bij veel bedrijven waar ik kom weet ik dat ze Cobol systemen hebben, waarvan ze niet eens meer de rekenregels of modellen weten. Financiele instellingen met bv levensverzekeringen waarvan ze niet meer dezelfde waardebepalingen kunnen doen in nieuwe systemen. Ze hebben dan een 3-tal opties:
1. Heel veel geld uitgeven aan zeer dure expertise om te reverse engineeren van de rekenregels.
2. Economisch converteren, dus klanten een nieuwe polis aanbieden in een nieuw systeem met nieuwe rekenregels, hierbij moeten ze dus extra geld geven om de klanten over te halen. Met het risico dat wanneer er 1 klant nee zegt, ze nog steeds met een probleem zitten.
3. Het huidige systeem in bedrijf houden en wachten totdat alle levensverzekeringen van een specifieke polis in het Cobol systeem aan het einde van de looptijd zijn.

De keuze kan afhankelijk zijn van de kosten voor het behouden van het systeem, complexiteit, aantal klanten nog in het systeem, etc.

Het is niet altijd zo zwart/wit.

[hiostu]

Allemaal waar, maar dat verandert op dit moment de feiten niet.

[dmantione]

Wat in bedrijven ook vaak gebeurt is dat de eigen bedrijfsautomatisering over een hele lange periode groeit naar de behoeften van het bedrijfs, het is de geldmachine waar het bedrijf op functioneert. Heel vaak is het intern ontwikkeld en hoewel bedrijven echt wel geïnteresseerd zijn in documentatie zit veel van de kennis in de hoofden van de eigen programmeurs. Als je een blik nieuwerwetse programmeurs opentrekt kunnen die niet zomaar een nieuw systeem op specificatie gaan bouwen, want die specificaties zijn er niet. Het is dan letterlijk het wiel opnieuw gaan uitvinden, dat is een enorme investering en de tijd dat het nieuwe systeem ontwikkeld wordt moet het bedrijf gewoon doordraaien. Een investering om naar een modernere taal over te stappen was dan ook vaak simpelweg niet economisch te verantwoorden.

Zeker de Cobol-systemen die vandaag nog draaien zijn vaan robuuste goedwerkende systemen. We weten dat er in de automatisering heel vaak dingen mislukken, dus even een project starten om de boel te moderniseren betekent ook nog heel grote kans op mislukking als het niet goed aangepakt wordt. Gecombineerd dat ook moderne systemen vroeg of laat verouderd zijn is er soms best wel een goed argument te maken om ouderwets te zijn.

[Anoniem: 435630]

Ja, leuk antwoord. Het antwoord dat je geeft is precies wat Faeron bedoeld. Het is voor sommige zaken gewoon heel belangrijk om het component 'techniek' mee te nemen in aanbestedingen. Het zou niet de eerste keer zijn dat er naar een paar jaar van platform A naar platform B wordt gemigreerd en dat er niet aan een open database format (of ander voorbeeld) gedacht is waardoor er heel erg veel geld gestoken moeten worden in het migreren naar een ander pakket.

[i-chat]

En cobol stamt uit een tijd dat we termen als 'exit-strategie' 'open document format' 'portabillity design' etc al hadden uitgevonden?

Het is makkelijk om te roepen ... maar als we dan toch bezig zijn, waarom genezen we dan niet gewoon alle lepra patiëntjes uit de tijd van jezus, de builenpest ergens in de middeleeuwen? terugkijkend was dat allemaal toch niet zo moeilijk?

[Reactie gewijzigd door i-chat op 23 juli 2024 06:19]

[aswelter]

COBOL is oude meuk.Het feit dat COBOL, ADA, Fortran en dat soort antieke meuk nog bestaat laat zien dat we dat nog steeds niet goed doen.

Het feit dat je een programmeertaal op zijn leeftijd beoordeeld laat inderdaad zien dat "we" inderdaad iets niet goed doen. En dat niet goed doen is onderwijzen.

Een taal beoordeel je niet op zijn leeftijd maar op zijn structuur en de manier waarop de taal aansluit op de problemen die opgelost moeten worden en hoe hij aansluit op de manier van denken die noodzakelijk is om die problemen te vangen in een taal.

Als "we" dat nu eens zouden onderwijzen dan zouden een behoorlijk aantal nieuwe en oude hype talen eindelijk eens in de prullenbak verdwijnen.

[Johandmc]

Ook al gaat dit over de COBOL-programmeertaal, ik las vandaag in de automatiseringsgids dat Fortran (dus die andere oude programmeertaal) zelf opeens in de top 20 van de meest gebruikte programmeertalen terecht is gekomen, wel op plek 20 van de Tiobe-Index.

[Azbest]

Het verbaasd me dat niemand hier Dijkstra aanhaalt:

The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense.

Amen. En stel dat we straks een boel programmeurs hebben die COBOL kunnen herschrijven naar andere talen, dat betekent nog niet dat we dan klaar zijn. Het probleem van COBOL is eigenlijk meer hoe we met legacy omgaan. Windows XP is net zoiets, veel software upgrades werden genegeerd omwille van comptabiliteit van oude hardware.
Ik voorzie dat later een boel Java code omgezet moet worden, object oriented programming was ook zo´n hype.

[KonradV]

Er is weinig mis met COBOL, je kunt hert tegenwoordig prima onder Eclipse of in Visual Studio Code ontwikkelen, met alle faciliteiten van het mainframe. De performance van de systemen is nog steeds ongeëvenaard, zeker als die voor 50.000+ gebruikers in het land moeten moeten werken. Er is vaak naar alternatieven gezocht, geen enkel ander platform, ook niet in de veel geprezen "cloud" blijkt qua performance een alternatief te kunnen bieden, met de benodigde duizenden servers is al snel een heel datacenter nodig, daar zijn er lang niet genoeg van. Zeker niet wanneer die vanwege de AVG niet buiten Europa mogen staan.
Het wordt hoog tijd, dat er weer COBOL mensen opgeleid worden, om de applicaties in de toekomst te kunnen blijven onderhouden, en nieuwe te bouwen

[bzzzt]

Volgens mij is de performance van Cobol niet per se orde groottes beter op dezelfde hardware als andere efficiënte talen. Het verschil wordt eerder gemaakt door een andere cultuur rond het ontwikkelen (beter weten wat je doet, minder copy+paste van Stack overflow). Dat je voor functionaliteit van 1 mainframe duizenden servers in een datacenter zou moeten hebben gaat er bij mij niet in.

[coolkil]

Gedeeltelijk wel. Duizenden is misschien wat overdreven maar ik ken toch een case waarbij we terug gingen van 140 CPU cores naar 10.

Dit was dan wel geen z/OS mainframe maar een LinuxOne mainframe. We migreerden van Linux naar Linux maar wel met een 130 cores minder. Dit zal misschien niet gelden voor alle usecases maar is toch een aanzienlijk verschil. Uiteindelijk draaien er meer dan 150 Linux servers op.

[Reactie gewijzigd door coolkil op 23 juli 2024 06:19]

[bzzzt]

Tsja, als je honderden cloud instances laat draaien voor een handjevol gebruikers valt er inderdaad een hoop te winnen. Ooit bij een datacenter geweest waar naast een paar servers waar we duizenden gebruikers mee bedienden een rack vol hardware stond voor 12 gebruikers "omdat de klant dat wilde". Als je servers als statussymbool gaat inkopen krijg je dat soort wanstaltige situaties.

[coolkil]

Dit zijn actief gebruikte systemen. ze komen van onpremise x86 en ze gingen naar mainframe(s390x). draait productie en staat als een huis wat betreft stabiliteit. zeker weten geen status symbool alhoewel het zeker een zeer cool apparaat is om te zien.

[Tintel]

Als dit waar zou zijn waarom worden dan nog steeds nieuwe talen ontwikkeld? Dat Cobol niet dood is, wil toch niet zeggen dat het de enige taal is die dergelijke zaken kan regelen. Het is andersom - omdat ze niet willen veranderen, is Cobol nog in leven. Al kun je argumenteren dat de nieuwe varianten van Cobol niet dezelfde taal zijn.

En al die randvoorwaarden als waar de servers moeten staan hebben toch niets met de taal te maken? Dat zijn technische problemen die een andere afdeling moet oplossen.

De performance van de systemen is nog steeds ongeëvenaard

Ten opzichte van wat dan? Het is toch niet herschreven in een andere taal? Stellen dat iets snel is, is niet hetzelfde als elk ander - nog niet bestaand - systeem is minder snel...

Beetje wankel voorbeeld:
Houten stoelen zijn ook best mooi en je kan er prima op zitten. Moeten we dus houtbewerking als hoofdvak (her)introduceren of accepteren we dat we ook op metalen/kunstof stoelen kunnen zitten?

[Irsu85]

Als er 200 miljard lijnen cobol nog zijn moeten die gecompileerd worden. Als ik java schrijf kunnen die .java bestanden toch niet zomaar gerunt worden? (o ja, omzetten naar python of zo is ook geen optie, dat zou te duur zijn )

Edit: typo

[Reactie gewijzigd door Irsu85 op 23 juli 2024 06:19]

[shenrbe]

Het gaat hier over 200 miljard lijnen.en legacy systemen die heel veel data beheren.
1 van de grote struikelpunten bij het converteren van deze legacy systemen is de performantie van de io. Cobol converteren kan voor 95% automatisch gebeuren. Maar dan heb je de functionele logica nog niet aangepast aan systemen waarbij je de data op een andere manier moet benaderen om de performantie van mainframe enigzins te kunnen benaderen.
De meeste bedrijven met legacy systemen hebben de front office reeds geconverteerd naar moderne systemen. Maar voor de offline verwerking is het andere koek.

[Reactie gewijzigd door shenrbe op 23 juli 2024 06:19]

[gimbal]

Mja. Ik huiver zelf meer voor het gebrek aan automatische testen met dichtbij 100% dekking. Veel geluk met bewijzen dat je vervanging exact doet wat de oorspronkelijke applicatie deed in alle permutaties. Performance? Daar ben ik een stuk minder bang voor eigenlijk.

[shenrbe]

Uit mijn ervaring en ik heb nu toch al 3 conversiepogingen meegemaakt, is de performantie altijd al het struikelblok geweest. Heel veel offline verwerking (zeker bij banken en verzekeringsinstellingen) draait nu al op de limieten van de mainframes. Je hebt maar 24 uur op een dag.
Theoretisch kan je de performantie van de server systemen opschalen, maar dan moet je de oorspronkelijke coding gaan herschrijven en ervoor zorgen dat je in blokken parallel kan verwerken. Maar dat is een investering waarvoor de business dan niet wil investeren omdat het hen niets opbrengt.
Ik ben het met je eens dat je 100% automatisch moet kunnen testen. Vanaf het moment dat je manuele testen moet invoeren ben je nooit zeker.
Voor online testing bestaan er tools waarbij je een capture doet van alle screen input en output en dat opnieuw kan afspelen op het geconverteerde systeem. Als je dat een hele tijd laat draaien op je oorspronkelijk systeem en het daarna afspeelt op je nieuwe systeem, kan je redelijk zeker van zijn dat je dezelfde functionaliteit hebt.
Voor batch systemen moet je eigenlijk de situatie voor en na de batch vastleggen in een snapshot en dan de 2 resultaten gaan vergelijken.
Dit is wel te automatiseren, maar is duur en dus ook weeral een struikelblok in het conversieproces

[Kliko]

Laten we het nog groter maken. Het artikel zegt namelijk: 200 Miljard!

[tomskio]

Zie regel 2 van het artikel

[coolkil]

Waarom niet? Genoeg organisaties die nog ladingen hebben draaien. Als je kritische bedrijfsvoering er van af hangt ga je niet lichtzinnig 'even' wat nieuws bouwen en implementeren. Maar nu heb je wel de kans om het eventueel op andere locaties te draaien. Eventueel in AWS, Azure of GCP en nog support van IBM ook.

Wat betreft oude meuk. Er zijn nog wel meer 'oude' talen die nog veel gebruikt worden. denk aan SQL en C. Een exit strategie is altijd iets om in je achterhoofd te houden bij IT projecten. maar vergis je niet dat veel van de software geschreven is in een tijd dat er ook nog geen degelijk alternatief was. Dus er was geen exit strategie of de exit strategie moet zijn geweest te stoppen met automatisering.

[curkey]

Ik denk dat je een overdreven negatieve kijk hebt op oude talen. Over zoveel jaar roep je wellicht hetzelfde over Java of Rust.
Er zijn legacy applicaties die simpelweg gewoon goed draaien en aan alle business requirements voldoen en die een shitload aan werk zouden kosten om in een andere taal te herschrijven, met alle bugs en andere kinderziektes van dien.

Je zegt het zelf eigenlijk al in je laatste zin: het feit dat er nog zoveel ouwe meuk bestaat is ook omdat er geen goede moderne vervanger voor is die je kosteneffectief kunt inzetten. En het feit dat je geen goede vervanger hebt, maakt het oude dus per definitie geen 'meuk'.

[gimbal]

Het is al enkele jaren zover als het om Java gaat, gelukkig hebben ze daarom een breed Scala (pun intended) aan andere talen uitgevonden die binnen dezelfde runtime kunnen draaien. Je bent tegenwoordig niet meer hip als je niet Kotlin programmeert in plaats van Java.

[Martijn033]

Ik zou Cobol niet willen betitelen als "oude meuk". Dat het bestaat sinds 1959 wil niet zeggen dat het niet van deze tijd is. Cobol blijft aangepast worden aan de huidige tijd.

[anandus]

COBOL is oude meuk. Dat COBOL bestaat is het gevolg van het vaak ontbreken van iets belangrijks: een exit-strategie. Lekker een cloud-service in gebruiken nemen, een applicatie installeren, een dienst afnemen, een leverancier kiezen.

Maar waarom? Als het z'n werk doet, zeker als het bedrijfskritisch werk is, dan lijkt me het adagium "if it ain't broke, don't try to fix it" helemaal prima.
Daarnaast is het vaak een stuk duurder om oude programmatuur te vervangen door iets moderns, dan het in stand te houden.

[hackerhater]

Tjah steeds meer problemen om er programmeurs voor te vinden?
Dat lijkt me een goede reden om er vanaf te willen.

[hackerhater]

Dat is inderdaad een mogelijke oplossing voor die bedrijven.
Vereist wel een lange termijn inzicht

[ajolla]

Het zijn allemaal bedrijven met een lange COBOL traditie. Die hebben dit toch wel zien aankomen.
Toch?

[hackerhater]

Ga er maar niet van uit

[ignitem]

Onder aan de streep levert iedere programmeertaal machinecode op. Cobol is een redelijk low-level taal dus zal redelijk efficiente machinecode produceren. Het is ook een redelijk compacte taal die niet van honderden libraries afhankelijk is om zijn werk te doen.

Herschrijven van je COBOL programma in een andere programmeertaal levert toch weer dezelfde machinecode op. En afhankelijk van de taal nog redelijk BLOAT ook. Hetgeen enkel fouten in de hand werkt.

Nieuwe projecten zou ik niet meer een COBOL ontwikkelen, maar bestaande programma's hier en daar aanpassen hoeft geen probleem te zijn.

[JAVE]

Ik denk dat het nog steeds goedkoper is om iemand COBOL te leren dan je systemen te migreren.
Verkoop maar 'Het kost x manjaar om te migreren, en uiteindelijk merk je geen verschil' aan de cententellers.

Daarbij is 'andermans computer' misschien niet zo slim voor banken en verzekeraars, dus cloud solutions zijn niet echt een prio voor systemen waar COBOL op draait.

En of iets dezelfde machine code oplevert hangt helemaal af van de compiler en wat voor optimalisaties die gebruikt, en welke aannames er gemaakt worden.

Ik heb een migratie tussen twee systemen (Bull mainframe -> HP-UX) mis zien gaan omdat de COBOL compiler op het mainframe '99 + 01 = 00' (In geval van een veld met 2 posities) vond, maar de compiler op HP-UX dat zag als '99 + 01 = 00 + overflow bit'

Als je dan het resultaat vergelijkt met '00', dan is het in het laatste geval false, terwijl dat gewoon true had moeten zijn volgens alle bestaande logic in de code.

(Dit kostte een paar dagen debuggen, met uiteindelijk meters kettingformulier met gegenereerde assembly)

[gepebril]

Als eenieder efficient en logisch zou nadenken was er denk ik amper droog brood te verdienen in ICT. Lang leven de prutsers!!!

[mae-t.net]

Je zou ook kunnen stellen dat het kennelijk een stuk duurzamer is dan de meeste opvolgers. Daarbij komt dat een cloud-service (die COBOL draait ), een dienst of een leverancier alleen maar middelen zijn, geen doelen. Jouw exit-strategie zou dus ook niet werken. En ja, het zal soms wel verstandig zijn om je software opnieuw te ontwerpen,maar dat is ook niet echt heel triviaal. Als je om je heen kijkt naar gefaalde automatiseringsprojecten dan ben je gewaarschuwd.

[Reactie gewijzigd door mae-t.net op 23 juli 2024 06:19]

[beerse]

Als je Cobol, Ada en Fortran oude meuk vind, dan moet je C en Basic ook oude meuk vinden, die zijn niet heel veel jonger.

En als je het over cloud services hebt: Als het even kan draait daar de zelfde cobol. Moet er toch het nodige mee gebeuren.

[SuperDre]

[qoute]Het feit dat COBOL, ADA, Fortran en dat soort antieke meuk nog bestaat laat zien dat we dat nog steeds niet goed doen.[/quote]
If it ain't broken, don't fix it.... Als COBOL nog doet wat die moet doen, waarom afstappen? ik zie juist vaak dat men te graag over wil stappen op de nieuwste hipste frameworks die vaak eigenlijk exact hetzelfde doen als oude frameworks, maar hier en daar dan net even iets op een andere manier.
Oude meuk heeft zich blijkbaar wel bewezen want anders was het echt wel al langer vervangen. Omdat iets nieuw is, wil nog niet zeggen dat het beter is.

Maar je hebt wel gelijk, je moet altijd goed rekeninghouden met de situatie dat een service/leverancier ineens wegvalt, wat dan? Maar je kunt daar ook niet alleen maar mee bezig zijn, want je weet toch niet wat de toekomst brengt. Daarom zeg ik vaak ook, beter maar het meest gebruikte framework gebruiken dan een nieuw mooi framework waarvan je nog niet weet hoe die zal gaan lopen.

[PjgV]

Deze discussies worden al vele jaren gevoerd. Ik begreep ooit (al 10-tl jaren geleden) van de IBM-mannen bij een grooote verzekeringsmaatschappij en bij een coöperatieve bank dat Cobol juist in de fin. wereld wordt gebruikt vanwege de transactionele opzet. Vroeger werden transacties nl. 1x per dag gerund in gigantische batches en dat deed Cobol dan het beste en het snelste.
Verder moesten ze Cobol handhaven omdat er (levens)verzekeringen waren die draaiden in op Cobol gebaseerde speciaal geschreven software en die dus nog een heel mensenleven mee moest.
Of hypotheekberekeningen die essentieel waren voor de te leveren producten.
Dus waren er veel gepensioneerde freelancers bezig met onderhoud (hoewel dat ook wel meeviel).
Daarnaast heb ik toen ook verscheidene projecten voorbij zien komen waarbij de Cobol-progs moesten worden omgebouwd in een op dat moment in de mode zijnde (natuurlijk 'betere') taal. Vaak ook in India uitgevoerd.
Het eindresultaat was altijd dat er juist geen eindresultaat werd opgeleverd, maar er wel heul veul geld was uitgegeven....:-)
Dus was daarna het beleid: als het werkt niet aankomen en laten draaien.

[bazzi]

Gewoon levensverzekeringen afkopen. Dat kan goedkoper zijn dan oude systemen in de lucht houden. Laatst meegeholpen aan oude verzekeringen die nog op de hand werden geadministreerd, toch maar digitaal te gaan doen voor een grote verzekeraar. Maar daar lag ook de optie: opzeggen en afkopen, of investeren en laten lopen.

[UTMachine]

Klopt, ik heb ook projecten voorbij zien komen om Cobol dingen te vervangen. Alleen maakte ze dan weer de "fout" om het dan ook direct te willen outsourcen naar India. Zolang je niet weet wat je precies outsourced en de 3de partij (hard) kan afrekenen op geleverd resultaat ... Dan is het gedoemd om te mislukken.
Indiaanse developers zijn niet dom, maar ze lezen soms geen specificaties (die zijn van levensbelang in de financiele wereld) of zijn weer te creatief (en denken het beter te kunnen).

[jimshatt]

Voor welk type applicatie wordt COBOL ingezet? Ik vermoed applicaties waarbij er grote hoeveelheden data/records verwerkt moeten worden, financiële transacties e.d. maar ik vraag me af of er tegenwoordig geen talen zijn die dat net zo goed of beter kunnen en makkelijker te ontwikkelen zijn. In dat geval gaat het dus voornamelijk om legacy applicaties?

[MneoreJ]

Tegewoordig vrijwel puur legacy idd (en systemen bovenop die legacy) maar Cobol als taal heeft wel degelijk wat goede dingen die andere talen niet (of veel minder) hebben. Gestructureerde records lezen en schrijven bijvoorbeeld is iets waar Cobol ingebouwde functionaliteit voor heeft (PICTURE) en wat andere talen meestal met libraries en custom taaltjes moeten doen. Toen Cobol op het toneel verscheen was het alternatief eigenlijk alleen Fortran en diverse vendor-specifieke assemblies en jobtaaltjes, die geen van allen bijzonder praktisch waren voor dataverwerking in plaats van pure number crunching.

Programmeurs zijn nooit echt warmgelopen voor Cobol door de "clunky" syntax die nog meer op Engels lijkt dan Basic (zeker van de eerste versies) en het feit dat het alleen gebruikt wordt om hele onsexy toepassingen te bouwen a la salarisadministratie en bevolkingsregisters, maar er was zeker een markt voor (en die is er dus nog steeds).

[MSalters]

"Ingebouwde functionaliteit" versus "libraries"? Dat klinkt alsof ingebouwde functionaliteit beter is. In verreweg de meeste moderne talen zijn libraries populair omdat het inzicht breed is doorgebroken dat libraries effectiever zijn.

[Martijn033]

Bij libraries weet je als programmeur (vaak) niet precies wat er binnenin gebeurt. En updates kunnen dan een probleem vormen. Sowieso is de voortdurende behoefte om updates te doen in moderne talen een probleem voor dit soort applicaties: elke minuut downtime kost serieus geld. Applicaties in Cobol draaiten probleemloos door, dat is inmiddels wel bewezen.

[SadisticPanda]

Banken. Overheden.

Waarom zou je overschakelen naar iets anders als de taal nog steeds voldoet en er speciaal voor geschreven is? Let er op dat cobol oud is, en stamt uit tijden waar elke bit telt qua geheugen. Meeste code is heel performant. Heb nog tijdje al COBOL ontwikkelaar gewerkt. Meeste projecten opzetten van cobol naar andere taal is gewoon onbetaalbaar en is lang niet zo performant. Tegenwoordig wordt er gewoon een frontend gemaakt voor bv webinterface maar de achtergrond blijft gewoon cobol.

Heb de omschakeling meegemaakt van rechtstreeks op het mainframe werken met paar duizend gebruikers tegelijk. Alles teringsnel en mainframe zit gewoon met vingers in de neus. Hadden ze frontend gemaakt voor een webinterface voor van dat terminal venster te geraken. Lag alle 5 minuten op zijn achterste.

Het is niet omdat het oud is, dat het moet veranderd worden....

[Carbon]

Banken. Overheden.

De Belastingdienst en SVB maken nog steeds gebruik van Cobol.

[KonradV]

Er was ook nog zo iets bij een bepaalde overheidsinstantie, waar de systemen na 1 maart opeens behoorlijk 'traag' werden en nauwelijks te gebruiken waren. Volgens insiders lag dat aan de Java front-end, die de massale bulk aan gegevens niet aankon, die uit het Mainframe opgehaald moest worden.

[Trashed]

De huidige ontwikkelomgevingen zijn gericht op snel bouwen en veel minder op efficiënt computergebruik. Dat kan, want rekenkracht en opslag kosten bijna niets meer dus dat een berekening honderd of duizend maal zoveel cpu-cycles kost voor hetzelfde resultaat is geen probleem meer. Als de applicatie maar snel af is nietwaar?

Sommige zaken wil je echter wél efficiënt kunnen uitvoeren en dan is een taal die minder instructies genereert niet te versmaden.

Maar ongetwijfeld is er ook een hoop dat prima opnieuw zou kunnen worden gebouwd in een up-to-date omgeving.. alleen.. nu nog zien dat we die clouddiensten AVG-proof krijgen nietwaar? (nieuws: 'Meeste Europese bedrijven overtreden AVG door Amerikaanse clouddiens...)

[Reactie gewijzigd door Trashed op 23 juli 2024 06:19]

[wica]

Het grote voordeel van COBOL, is dat er bijna geen bugs meer inzitten. Juist omdat het zo lang gebruikt wordt. Wat bij nieuwere talen nog wel eens een issue kan zijn.

[ToolkiT]

Ik weet dat PeopleSoft in de batch processen veel cobol gebruikte. Waarschijnlijk nog steeds omdat het een enorme klus is om dat te porten en je dan waarschijnlijk ook nog eens op performance achteruit gaat en kans op nieuwe bugs omhoog gaat..
Ik compileerde weekelijks Cobols..

[servies]

@dashorst248 Als je het artikel goed had gelezen dan had je gelezen dat Cobol niet anders rekent dan moderne programmeertalen...
Ze hebben alleen een extra type dat de meeste andere talen niet standaard kennen (fixed point) Daarnaast zie ik een vergelijking tussen een JIT (java) en precompiled (Cobol).
Ik heb in 1995/1996 op de HIO voor het laatst iets met Cobol gedaan op de en dat hoop ik graag zo te houden. Het was toen al hopeloos verouderd...

[DjoeC]

Verouderd? Een taal waar je alles mee kunt, die - mits goed geschreven - prima onderhoudbaar is en ook nog eens snel resultaten levert. Simpel te integreren met databases en ook als gewenst geschikt voor browserbased. Technieken als XML en JSON zijn standaard.

Wat wil je eigenlijk in een taal? Mijn beeld is dat "men" vooral point-solution talen ontwikkelt. Het grappige is dat er maar een paar talen op deze lijst staan die algemeen gebruikt worden en die meer dan 5 jaar draaien zonder grote aanpassingen. Java? Nieuwe versie = conversie. PHP? Tja. Ik herinner me Pascal, Kylix, Ada (voorgeschreven door DoD), C, C++, etc. Allemaal talen die ofwel qua specificaties vaak wijzigen of in de nacht zijn verdwenen. Python is de nieuwe ster aan het firmament (naast Java waar bedrijven nogal op kicken), ik ben benieuwd hoelang dat blijft. Upgrade Python 2 naar Python 3 heeft al flink voeten in de aarde gehad...

Inderdaad, Cobol is niet sexy maar doet wat het doen moet. Als je een grote organisatie bent met een levensverwachting die jaren vooruit kijkt is het een prima platform. Ben je een high-tech of een fly-by organisatie dan heeft het alleen zin bij hoge volume verwerking iets dat de meeste Nederlandse organisaties niet kennen. Laten we zeggen dat er minder dan 100 bedrijven en organisaties in Nederland zijn die geschikt zijn om iets met Cobol te doen en ja, vaak is dat historisch gegroeid. Maar dat maakt de taal niet slecht of de toepassingen minder geschikt.

Platform keuze is geen schoonheidswedstrijd maar een betrouwbaarheidsafweging gezien tegen de verwachte levensduur van een applicatie waarbij vooral TCO een rol hoort te spelen (doen we dat nog - TCO voorspellingen maken?).

[MSalters]

C en C++ wijzigen bepaald niet vaak qua specificatie. Sterker nog, zelfs met de nieuwste C++20 is volgens mij het originele K&R C boek nog te compileren. Uitbreidingen, ja, maar vooral C++ is gebouwd om met libraries te kunnen werken, en de meeste uitbreidingen zijn dan ook in de Standard Library.

[Carbon]

Als je het artikel goed had gelezen dan had je gelezen dat Cobol niet anders rekent dan moderne programmeertalen...

Er is wel degelijk een verschil!
Cobol maakt gebruik van BCD ipv floatingpoint
CPU's als de x86, 68K, en zelfs de 6502 hebben aparte instructies voor het rekenen met BCD getallen

[servies]

@Carbon

Cobol maakt gebruik van BCD ipv floatingpoint

Dat is het verschil niet: het verschil is de standaard fixed point, terwijl bij andere talen standaard floating point wordt gebruikt.
Hang een library voor fixed point aan je C(++)/Java/... software en dat specifieke voordeel voor Cobol is foetsie.
@DjoeC

Java? Nieuwe versie = conversie. PHP? Tja. Ik herinner me Pascal, Kylix, Ada (voorgeschreven door DoD), C, C++, etc. Allemaal talen die ofwel qua specificaties vaak wijzigen of in de nacht zijn verdwenen.

Que???? C is nog exact hetzelfde als 30/40/50 jaar geleden. Ja, er zijn bibliotheken bijgekomen, maar de syntax van C is niet veranderd in die tijd... En is zeker nog niet verdwenen
C++ is veel uitgebreider geworden qua syntax in de afgelopen jaren, maar de meeste programmas die geen gebruik maken van externe bibliotheken zul je nog zo kunnen compileren zonder veel aanpassingen te moeten maken... Ook deze nog zeker niet verdwenen...
Ook in Java zie ik weinig syntax wijzigingen naast de nieuwe uitbreidingen, dat bibliotheken veranderen, tja, dat is niet de taal... en ook hier: verdwenen????
Pascal heb ik al 30 jaar niets meer mee gedaan, kan ik niets over zeggen.
Als je het hebt over talen als Python en PHP, dan moet ik je gelijk geven, die zijn nog regelmatig onderhavig aan wijzigingen die van invloed zijn op de syntax, dat zijn dan ook relatief jonge talen...

[DjoeC]

@servies Misschien moet ik dat voor Java nuanceren. Het hangt steeds meer aan elkaar van frameworks, libraries en snippets waarbij de bouwers amper een idee hebben hoe die feitelijk inhoudelijk werken, die soms ook gewoon niet verder ontwikkeld worden met alele bijbehorende security issues etc. Waarbij een versie update vaak echte consequenties heeft maar uitstel van gebruik leidt tot slechtere oplossingen.

Misschien wat kort door de bocht maar ik denk dat het de kern wel weergeeft.

[servies]

Tja, daar ben ik het wel een beetje mee eens. Maar het gebruik van frameworks snap ik ook wel weer: waarom iedere keer het wiel opnieuw uitvinden... Alhoewel dat met die verschillende frameworks ook iedere keer weer opnieuw gebeurd...

[curkey]

SAP ABAP is het broertje ervan, die rekent ook zo als je wilt.

[com2,1ghz]

Lekker Kubernetes met COBOL

[MneoreJ]

Goede zaak, komt de schaalbaarheid van Cobol on Cogs diensten alleen maar ten goede.

[Brent]

Of Cobol on Wheelchair: https://github.com/azac/cobol-on-wheelchair

[armageddon_2k1]

COBOL microservice gaan maken.

[latka]

Als je een cluster aan mainframes kan betalen dan kun je die paar K8s experts ook nog wel betalen

[SPARCie64]

OpenShift is beschikbaar voor IBM Z (zowel Bare-metal als de z/VM hypervisor)

Eigenlijk best grappig dat OpenShift/Kubernetes op de afstammeling van de allereerste echte hypervisor (VM/370) kan draaien, maakt de cirkel weer rond (in ieder geval op dit moment)

[Reactie gewijzigd door SPARCie64 op 23 juli 2024 06:19]

[RonaldHeirbaut]

Beetje laat. Tien jaar geleden heb ik al migraties gedaan naar Linux met OpenCobol. Nu GnuCobol. https://sourceforge.net/projects/gnucobol/
Werkt fantastisch en is bloedsnel.

[synoniem]

Ik vermoed dat IBM daar geen support op geeft en op de eigen compiler wel.

[farlane]

GnuCOBOL translates COBOL into C and compiles the translated code using a native C compiler

Is COBOL bloedjesnel of is C bloedjesnel?

[RonaldHeirbaut]

Uiteraard is C bloedjesnel. Maar wat GNU-Cobol erg goed doet is dat ze de Cobol-source omzetten in C. Doorgaans gaat dat weinig succesvol, de ene taal in een andere omzetten, maar deze ontwikkelaars zijn er goed in geslaagd.

[DjoeC]

Mainframe Cobol maakt tegenwoordig gebruik van wat de Language Environment heet. Diezelfde LE wordt gebruikt om andere mainframe talen op te draaien (Fortran, PL/1 en ja, zelfs C/C++). M.a.w.: De taal maakt niet zoveel meer uit, uiteindelijk gebruiken ze via intermediate code allemaal dezelfde machinecode routines.

Voor de liefhebbers: Language Environment for Dummies: What is LE and How Do I Get There?

Hoe dat in deze X86 versie gaat werken heb ik zo snel nog niet gevonden.

[Reactie gewijzigd door DjoeC op 23 juli 2024 06:19]

[wildpicture]

Uit de tijd dat programmeren nog een echt vak was. Er werd van tevoren nagedacht over de optimale structuur van een programma. Niet zoals tegenwoordig vaak gebeurt, maar wat klikken en slepen met objecten en libraries zonder enig benul te hebben van structuur en optimalisatie.

Ik weet het, ik wordt oud. Het enige COBOL dat ik zelf ooit geschreven heb, was op het AMBI T1 examen. Toen waren al die jochies die het hardst roepen dat een bedrijf geen "oude technologie" mag gebruiken, nog niet geboren.

[MneoreJ]

Tja, maar vergeet niet dat dat merendeel ook gewoon pure noodzaak was, als in, het kon moeilijk anders. Eer je de ponskaarten gereed hebt, die naar de mainframe mag brengen, en vervolgens weer een kaart terug krijgt van de compiler met je fout... dan kun je maar beter eerst tijd steken in zorgen dat het al zo goed mogelijk is. Tegenwoordig draait de compiler na elke druk op de Enter knop (en met wat meer moeite kun je de profiler daar ook nog achter hangen), dus een groot gedeelte van dat "denkwerk" kun je naar de computer verschuiven...

Ik heb ook nog "goede" herinneringen aan een C programma uitschrijven op papier en dan ook echt voor iedere ontbrekende puntkomma punten afgetrokken krijgen. Makkelijk onderwijzen wel, maar ik zou het geen betere vorm van ontwikkelen willen noemen.

Je hebt het ene uiterste en het andere uiterste, de waarheid ligt zoals gebruikelijk ergens in het midden.

[RBouman]

ja het oude werk, eerst JSP datamodel maken, dan een JSP programma-diagram maken en dat omzetten naar een programma. (JSP = Jackson Structured Programming)
Dan bij het intypen van de programmacode een punt vergeten of een type fout maken in de eerste regel
IDENTIFICATION DIVISION.
En je kreeg daarna een halve boom aan papieruitvoer omdat de compiler er niets meer van snapte.

[Craftynl]

Ons ERP draait er nog op

[liefre]

Ik ben een gepensioneerde ontwikkelaar met een heus T2 praktijk diploma cobol. Examen duurde een dag.
Vroeger werd het geschreven met potlood. Er is trouwens cobol74 en cobol85 en hierin is wel een verschil.
Tja vele puinhopen gezien en mensen die methodes bedachten waardoor er een soort van foutloze en onderhoudbare code werd geschreven. Cobol is simpel, echter de interfases / io beeldschermen, cics, utm, etc. en kennis van het operating systeem maken het moeilijker. Ik heb tevens een certificaat Java programmeren en meerdere van de soort certificaten. Ik heb bewondering voor de echte java programmeurs of moet ik zeggen architecten. Wil een systeem vernieuwen, dan kan het beste alles weggooien en opnieuw ontwerpen en bouwen. Maar wel door de juiste mensen. Die bepalen het resultaat. Tevens is zoiets een enorme belasting voor de organisatie en zijn daar de juiste mensen nog of wel aanwezig. Ik ben ook nog rpg/rgle en cool2e "expert" Cool2e genereerd cobol of rpgle. Tja was indertijd een manager die cool2e uitlegde als een 4e generatie taal en je dan aangaf waar je heen wilde i.p.v. programmeren. Ook veel van dit soort idioten meegemaakt. documentatie moet alleen beschrijven wat het zou moeten doen zonder in details te treden, anders is het heel snel veroudert.

[mvrhrln]

pff Cobol, jaren 90 voor mij, examens op ruitjes papier, zonder computer, waren nog eens tijden.
Ooit heel muis en menu systeem voor gemaakt (muis/menu ala turbo pascal 6.0 look and feel)

[janbaarda]

Cobol, is dat niet die computer taal waarbij je "1+2" programmeert als " 1 plus 2 "? Een programmeertaal die bedoeld was om spreektaal te imiteren ...

Cobol wordt voor zover ik weet alleen nog gebruikt omdat veel oude software (voornamelijk voor financiële systemen) daar mee gemaakt is. De documentatie van veel wijzigingen is in de loop der tijden verloren gegaan (zo ook de programmeurs): ergo niet veranderen, alleen tegenaan bouwen.

[RBouman]

je mag ook gewoon zoiets schrijven hoor in COBOL
COMPUTE xx = (a + e(1)) / c * 2;

[janbaarda]

Dank, dat is nieuw voor mij. Ben dan ook geen ervaren COBOL programmeur.

[RBouman]

20 jaar gedaan
Daarna overgestapt naar oa pl/sql en Oracle

[mvrhrln]

ja idd hele zinnen tikken, voorbeeld (van wikipedia):

[code]
MULTIPLY 12
BY getal GIVING uitkomst uikomstafge ROUNDED
ON OVERFLOW DISPLAY "Getal is te groot"
NOT ON OVERFLOW DISPLAY "Getal past"
END-MULTIPLY
[/code]

Had je nog sections etc etc, dingen moesten in de goede kolom staan etc.


ze kunnen nog altijd mailen (wel opfris cursus nodig )

[Reactie gewijzigd door mvrhrln op 23 juli 2024 06:19]

[cricque]

Nog gehad op school toen ze in transitie zaten naar java. Een jaartje cobol/pascal/assembler, volgend jaar was het Java. Ja ik moest mijn jaar opnieuw doen omdat ik gezakt was voor boekhouden & economie wat toen verplichte vakken waren ... Maar nooit gebruikt nadien. Meteen beginnen programmeren in VB en C++ en nadien Delphi en C++. Als goeie Cobol programmeur kan je gerust zeer goed geld verdienen, maar je moet het ook willen doen uiteraard. Er zijn leukere dingen, en daar wringt het schoentje. DIkwijls zijn oudere applicatie gigantische blokken code en moet je op meerdere plaatsen dezelfde wijziging doorvoeren. En er zijn weinig garanties dat iets gaat werken. Tegenwoordig is dit allemaal een pak beter.

Maar het probleem is dikwijls lange termijnvisie en de kost. Vele bedrijven zeggen, het werkt nu, dus we kunnen het blijven gebruiken, de kost voor iets nieuws is te hoog. En dan is de vraag, gaat dat nieuwe systeem beter zijn (dat is ook niet altijd het geval). Zo blijf je uiteraard in een eindeloze cirkel draaien. Moest IBM er niet iets in zien dan zouden ze dit echt wel niet doen