65 jaar oude code, dan heb je toch echt wel genoeg tijd gehad om een migratie te gaan doen.... Tja, migraties zijn duur, en leveren vaak in het begin niets op. Lees: ze kosten geld. En dan worden ze maar niet gedaan... Kortzichtigheid van managers.

Zie nu wat de echte kosten zijn van het niet doen...

TheYOSH

Beter lezen helpt echt wel. Cobol is 65 jaar oud, de code zal jonger zijn. Ik weet nog in de tijd van het Y2K probleem dat cobol krassers toen ook al schaars waren. Cobol staat als een huis (noem eens iets wat je in de afgelopen +20jaar voorbij hebt zien komen wat kwetsbaar was/is irt Cobol), dus niets mis mee om iets wat werkt te blijven gebruiken.

De eerste versie is 65 jaar geleden de laatste versie is COBOL-2023. COBOL word namelijk al 65 jaar gewoon door ontwikkeld.

Alhoewel Cobol programmeren bijna letterlijk dodelijk saai is, is een goed Cobol programma verschrikkelijk goed in data verwerking. Daar kan tot nu toe geen enkele andere programmeeraal/infrastructuur tegenop. Dit maakt migreren bijna onmogelijk.

Het probleem ligt anders.

Cobol staat als een huis net zoals VMS/OpenVMS iets waar al die nieuwe systemen niet aan voldoen.

VMS/OpenVMS is qua stabiliteit en veiligheid niet te evenaren en wordt bijv. o.a. nog steeds in kerncentrales gebruikt waar men heeft getracht het te vervangen voor nieuwere systemen.

Inderdaad.
De taal heeft veel faciliteiten die precies geschikt zijn voor het domein (financieel/administratief data verwerken) .
(volgens mij ook onder de motorkap, door getallen als fixed point te verwerken, en de financieel gewenste afrondingsregels gebruiken)


Verder - echt ervaren programmeurs weten dat 'wegmieteren en rewrite from scratch' lekker klinkt maar ECHT een recept voor een ramp is.
natuurlijk is het wel wat junioren roepen omdat ze hun net geleerde super veel betere taal willen inzetten.

https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

Er zal , vrees ik, onzettend veel ervaren uitzonderingen in de cobol code zitten die effectief de belastingregels definieren. (nog meer dan de wet).

Er zijn - zo google ik - programma's die cobol transformeren naar java. Geen idee hoe goed/leesbaar/onderhoudbaar het resultaat dan nog is.

Zie https://vulmon.com/searchpage?q=cobol

Wat ook wel wordt geopperd is overstappen van Cobol op Java. Dat is nu echt een totaal andere programmeertaal. Recipe for disaster lijkt me. En Java zelf is ook al weer 30 jaar oud, is er niets moderners?

[quote
De taal heeft veel faciliteiten die precies geschikt zijn voor het domein (financieel/administratief data verwerken) .
(volgens mij ook onder de motorkap, door getallen als fixed point te verwerken, en de financieel gewenste afrondingsregels gebruiken)
[/quote]
Dit is inderdaad super belangrijk. Java floating point is een ramp. In administratieve omgevingen wil je dit niet.

ja ik denk dat het toch makkelijker op word met .AI..??????

De wereld en github zit stampvol nieuwere talen .
Welke daarvan de komende twee,drie decennia 'relevant' blijven is een heel lastige gok.

Uiteindelijk wil je het probleem 'kleiner reservoir aan Cobol programmeurs' niet vervangen door , tegen de tijd dat de migratie klaar is, "erg klein reservoir aan Go programmeurs" . (ofzo).

Een taal met een 'stabiele' ontwikkeling - en echt long term support van oudere standaarden van de taal is voor dit soort software ook wel hard nodig.
Een taal community die elke twee jaar de vorige major release deprecate en de taal incompatibel wijzigt moet je mijden als de pest .

Het is niet echt mijn domein - maar mijn perceptie is dat praktisch alle 'moderne' talen zich richten op een ANDER programmeer veld dan het financieel/administratieve waar Cobol sterk in is.
Hoewel je over het algemeen in principe "alles" kunt schrijven in "iedere" taal is het wel erg prettig als de taal, tools en programmeurs-ervaring goed mappen op het probleem domein .
Uiteindelijk is het niet alleen de syntax van wat keywords, maar het hele probleem domein, en taal-idioom die je verwacht van een programmeur .

Het tekort was er dik 35 jaar geleden en zelfs op een opleiding gezeten voor Cobol maar zelf in die tijd was het een draak van taal. Niet mee door gegaan en een andere richting gekozen.

Wat is je punt?
Cobol Vulnerability, 3 in 2023, 6 in 2019 en 1 in 2012

Nu Java Vulnerability, op de eerste bladzijde al 9 meldingen voor het jaar 2024 terwijl het jaar net begonnen is.

Sons is OpenVMS op AXP vervangen door een OpenVMS op been AXP emulator op X86 on system kleiner te maken.
vliegtuigen kunnen soms niet groeien.

Daarnaast is OpenVMS inmiddels native op X86 beschikbaar V9.x
inmiddels ook met hobbyist licentie.
En een COBOL compiler...

Dit is inderdaad super belangrijk. Java floating point is een ramp. In administratieve omgevingen wil je dit niet.[/quote]Cobol is ook een taal waar met betrekking tot data WYSIWYG is

Zo zijn er nog wel meer talen waarvan ik vermoed dat er problemen gaan ontstaan. Op de opleiding werd Delphi/Pascal bijvoorbeeld afgedaan als "oude meuk" en werd verder totaal niet vertegenwoordigd. En dat terwijl het nog steeds wordt voorzien van moderne features, en in het bedrijfsleven veel voorkomt. Maarja, het is niet hip zoals Electron apps die 500MB aan RAM vreten terwijl er niks gebeurt. Ik ben pas "jong" met 31 jaar oud, maar ik heb toch behoorlijke weerstand tegen de "programmeertaal van de dag" die door opleidingen gepushed worden.

Hallo, ouwe Nixdorf. De principes blijven toch hetzelfde
en ook de machine taal.

AI gaat ons een algoritmetje helpen, toch?

Niet getreurd en de developer-broek hoog opgebeurd.

Nope code generatoren als schil om een taal leveren nog meer ellende en lockins op.

Met AI, misschien een ander voorstel. Zet het om naar C, dat is een taal die ook niemand echt goed begrijpt,
Wel heel hip te krijgen om te zeggen dat L.Torvald die taal kent.

Onbegrijpelijk dat deze organisaties dit niet aan hebben zien komen, er wordt zelfs nog geopperd dat het nog een goede toekomst heeft. Moderniseren van hun softwarestack is blijkbaar een utopie. In de jaren 90 werd COBOL al als oubollig en obsolete beschouwd.

Hoe zit het met de hardware waar het opdraait? al jaren end of life maar we blijven het gebruiken tot het stuk gaat?

Nee, het is helemaal niet zoals je het nu schetst.
Zowel Cobol als de onderliggende hardware is doorontwikkeld en nieuw, dus niet end-of-life door oude systemen.

In de jaren 90 werd Cobol al als oubollig en obsolute genoemd door degene die het niet begrepen, de zogenaamde snelle jongens.

Kijk alleen al eens hoe groot die moderne applicaties in omvang zijn qua disk opslag omdat ze niet goed ontwikkeld zijn en kijk eens hoeveel er gigantisch brak en lek zijn.

Een voorbeeld daarvan was Java, als je niet kon programmeren in Java dan deed je niet meer mee maar kijk eens wat een draak van een applicatie het is en zo zijn er nog wel een paar te noemen.

Cobol is niet slecht of oubollig (dat zit tussen de oren) en doet precies waar het voor bedoeld is en goed.

De taal wordt nog steeds actief ontwikkeld. En de hardware waar het typisch op draait (mainframes vaak) ook.

Jaren 90 -oh, toen Modula 2 en Turbo Pascal de standaard waren ? Allebei dood.
Ohja - toen Perl hot was . Ook in het sterfhuis .
Visual Basic - helaas niet helemaal dood.

Laten we even niet aan de hippe jongens van de jaren 90 vragen waar je naar toe moet porten .
Of roepen ze dat als gegarandeerde werkgelegenheid, elke tien jaar weer een rewrite naar de hippe taal van het jaar ?


Nee dus. Er is ook IBM COBOL voor Linux on x86.

Tja veel applicaties zijn ook nog geschreven in assembler daar zijn er nog minder van. Een applicatie herschrijven alleen omdat het geschreven is in Cobol PL1 of assembler is onzin. Buiten dat op zich is er niets mis met deze programmeer talen.

Haha, rond Y2K o.a. was er ook dikke schaarste onder Cobol programmeurs. Kan me nog herinneren dat gepensioneerde Cobollers werden opgeroepen aan weer aan de slag te gaan. En dát deden er een aantal, uiteraard tegen een 'marktconform overstijgend' zzp uurtarief ;-)

Tja, als COBOL ontwikkelaar zit ik hier tussen de 'oudere jongeren'.
Wat altijd wegvalt in de constatering dat COBOL een wat oudere (maar niet minder moderne) taal is, is dat het heel veel lol geeft om mooie dingen te maken of gewoon problemen op te lossen. De taal is daarbij veel ondergeschikter dan het werkterrein waarin het probleem dient te worden opgelost. Ben je in Duitsland dan spreek je Duits en ben je in Frankrijk dan spreek je Frans voor het beste resultaat, nietwaar?

Helaas is voor de opleiders COBOL altijd geschikt om als spaghettimonstervoorbeeld aan te halen terwijl in de praktijk schrikbarende programmatuur in alle programmeertalen voorkomt. Maar docenten willen de door henzelf bemachtigde en te onderrichten taal in een goed daglicht stellen en zetten zich daarbij graag af tegen die 'oude talen'. Althans zo denk ik dan. De modernere talen zijn ook veel visueler en "doen ook Apps" wat vanzelfsprekend de aandacht van jongeren trekt.

Automatisering is een werkterrein waar je je eigen "oplossend vermogen" mag inzetten, zeker met programmeren. Dat lijkt mij bij uitstek erg aantrekkelijk voor studenten. Het werkterrein voor COBOL is bovendien vaak maatschappelijk gericht. Belastingen of verzekeringen programmeren is wat anders dan een wasmaschineprogramma of robotarmpje programmeren. Helaas worden die "marktomstandigheden" mijns inziens wat weinig toegelicht op de scholen. De tekorten in COBOL programmeurs zullen dan ook blijven bestaan totdat de docenten de kracht van COBOL voor het voetlicht kunnen brengen.

Cobol is een van de modernste en stabiele talen op de markt. Programma's uit 2000 (en eerder)n werken nu nog steeds vlekkeloos correct. Welke andere taal kan dat van zich laten zeggen?

Het kern probleem is dat management de opbouw van hun eigen personeelspopulatie nooit heeft bekeken en daarop actie heeft uitgezet.

Met de nodige incentives (goed salaris, auto, deeltijd werken etc) zijn er voldoende werknemers te vinden om opgeleid te worden.

Kortom, het issue is niet de taal zelf.

46 jaar geleden begon ik als jongetje van 18 COBOL te programmeren. De grote jongens: banken, verzekeraars, overheid. Ik programmeer nog steeds, in vele talen. ik mag dus uit de nodige ervaring spreken.
Inderdaad, COBOL is een superdegelijke taal, robuust en betrouwbaar. Maar dat komt niet alleen door de taal. COBOL is een taal die nauw verweven is met de architectuur van de computers waar het ooit voor ontwikkeld is: IBM mainframes. Omdat ik ook in 370-Assembler heb geprogrammeerd weet ik hoe dicht COBOL is verweven met de toenmalige computers. Omdat we moesten leren hoe elk COBOL statement door de compiler werd vertaald in machine-code wisten we precies hoe het werkte.
Later draaide COBOL ook op andere platforms, maar de robuustheid van de systemen werd altijd mede bepaald door de vergaande kennis van de ontwikkelaars.
De enige taal die voor wat betreft betrouwbaarheid met COBOL kan meten is C++. Maar daar waar je in COBOL gedwongen wordt in een bepaalde structuur te werken, laat C++ je alle vrijheid om er een puinhoop van te maken. Even goed programmeren in C++ is moeilijker dan in COBOL. Maar de mogelijkheden zijn oneindig veel groter. Mijn advies is dus:
Laat ervaren deskundigen een zeer doordachte infrastructuur in C++ maken en ga voorzichtig migreren. Alleen dan ben je toekomstbestendig en blijft je software onderhoudbaar. A.S.