New Jersey zoekt cobol-ontwikkelaars om mainframes draaiende te houden

De gouverneur van New Jersey vraagt vrijwilligers die in cobol kunnen programmeren, zich te melden om te helpen zijn mainframe draaiende te houden. De druk op de verouderde systemen van de staat is toegenomen vanwege de coronacrisis.

New Jersey-gouverneur Phil Murphy zei vorige week in zijn dagelijkse persmededeling dat zijn staat niet alleen vrijwilligers voor de gezondheidszorg zoekt, maar ook programmeurs. "Aangezien we verouderde systemen hebben, zouden we een pagina voor mensen met 'cobalt'-ervaring toevoegen, omdat we daarmee te maken hebben." Murphy doelt op cobol, wat staat voor common business-oriented language, een programmeertaal van begin jaren zestig van de vorige eeuw. Ondanks zijn imago van een verouderde programmeertaal, draaien sommige systemen in vooral grootzakelijke omgevingen nog steeds op cobol.

Volgens Murphy doen zijn medewerkers a heck of a job. "Maar we hebben letterlijk systemen van meer dan veertig jaar oud." Volgens hem zal een van de lessen na afloop van de crisis zijn hoe de staat op het punt is gekomen nu afhankelijk te zijn van cobolprogrammeurs. New Jersey is relatief zwaar getroffen door het coronavirus.

The Register verwijst naar eerdere uitlatingen van de gouverneur waaruit op te maken is dat de systemen van de staat onder toenemde druk staan door een enorme stijging in het aantal uitkeringsaanvragen. De helft van de zeshonderdduizend aanvragen van de afgelopen twee weken in de staat zou niet direct verwerkt zijn. De gourverneur legt de oorzaak bij de inflexibiliteit van de verouderde systemen.

Reacties (168)

[dehardstyler]

Vrijwilligers zelfs! Zelfs als je heel veel geld bied krijg je ze nog amper, laat staan vrijwillig.

[wouser]

Als niet werkend in de IT: Dit is toch een gat in de markt? Cursusje COBOL en je bent binnen dan toch?

Zal ongetwijfeld niet zo makkelijk zijn maar waarom is dit niet zo?

[sircampalot]

De programmeertaal is doorgaan niet het probleem, kennis van wat er draait, en waarom het zo gemaakt is, zijn de bottleneck.

[K-aroq]

Ik snap de vraag van Wouser wel. Kijk in vacatures en er wordt om ervaring met speficieke programmeertalen gevraagd. Terwijl dat eigenlijk helemaal niet belangrijk is. Als je kunt programmeren kan je dat in iedere taal. Je hebt alleen even een boek erbij nodig als je het in een andere taal gaat doen. Voor buitenstaanders kan dat verwarrend zijn.

[DjoeC]

Waarom geef je ons verdienmodel gratis weg?

Maar meer to the point: Cobol is voor veel toepassingen nog steeds de best beschikbare taal. M.u.v. een recente architectuur aanpassing die voor het soort "pijn" zorgde zoals je die ook bij Python 2 -> 3 ziet loopt het al jaren stabiel en vooral snel! Zelfs op een Raspi ;-) Het grootste probleem is dat - voor de buitenwereld - de taal niet voldoende sexy is en dat hij nauwelijks nog onderwezen wordt.

Ik zie liever een net Cobol programma dan de brij van Java, Python, C, dotNet, you name it die tegenwoordig "snel" geproduceerd wordt door vaak tijdelijk ingehuurde krachten die dit doen met een "na mij de zondvloed" gedachte. Wegwerp software. Kost klauwen met geld en levert nauwelijks nieuws op.

[Lifeform2]

`C` en `tegenwoordig` in een zin? Ik heb C sinds halverwege de jaren 80 veel gebruikt. Bijna 40 jaar geleden.

[DjoeC]

Het ging niet over de ouderdom van een taal maar over de brij die tegenwoordig geproduceerd wordt.... Technische kwaliteit is echt een ondergeschoven kindje geworden, snel produceren en "iets" zichtbaars aan het eind van een sprint produceren staat voorop. Kwaliteit doen we later wel, dat is het grote verschil met vroeger: Oude maar in oorsprong kwalitatief goede programmatuur die niet wordt onderhouden leidt later tot problemen. Nieuwe programmatuur die door een net afgestudeerde deskundige met wat klik-klak's in een GUI in elkaar wordt geflanst en als wegwerp wordt geproduceerd kent al meteen problemen....

Uitzonderingen daar gelaten heb ik weinig met de kennis en kunde van veel nieuwe instromers.

[Waterbeesje]

Wat ook nogal een puntje is, is dat je tegenwoordig bij processors met de gigahertzen om de oren wordt gegooid, waar je "vroeger" al blij mocht zijn met een 5 of 8 MHz processor. Die ouwe krengen deden het werk ook gewoon prima, maar konden flink hangen op een brei van onzin, waar een goed geoptimaliseerd programma wèl goed en snel aanvoelde.

Zie ik ook terug in de 'moderne' apps voor een telefoon. Een mail client van 250MB of groter? Op een 486 was dat nog de totaal beschikbare ruimte. En ook daarmee kon je mailtjes versturen... Oké, ik chargeer nu want de mogelijkheden zijn uitgebreider... maar met de tijd is er op hardware gebied zo veel verbeterd dat optimaliseren niet half zo belangrijk meer is, juist doordat de hardware het wel trekt.

Met deze vacature voor NJ is het dus wel degelijk van belang om hier goed geoptimaliseerd voor te kunnen programmeren: processoren zijn relatief traag en opslagruimte klein. Om dit te doorgronden moet je ook weten hoe deze antieke hardware zijn code het beste kan omzetten in de instructies om een resultaat te krijgen. En hoe je eventuele hardwarebugs tackelt vóór ze iets missen...

[cricque]

Correct, voor een beetje goede programmeur maakt het niet zoveel uit. Als het niet om een nieuw project gaat, moet je toch de gebruikte libraries, eigen framework leren en kennis van het product opdoen. Tegen die tijd ben je wel mee met de gebruikte programmeertaal. Uiteraard is het wat gemakkelijker dat je het meeste kent. Maar kennis van het product, libraries en meestal bij legacy, de eigen gemaakte frameworks leren kennen, is veel belangrijker.

En dan heb je dus HR en recruitment bureau's die bljiven vragen hoeveel maanden/jaren heb je ervaring in X ... Net of je alleen maar X doet op een dag. Op een gemiddelde maand vorig jaar deed ik C#, Delphi, Python, Golang, React, Angular, Node ... En door die recruitment bureau's (die de prijs flink opdrijven) is er een zogezegd "tekort". Onlangs nog zo eentje gehad, die ging mij een toptarief van 300 euro/dag bezorgen ... Ik zeg weet jij wat een goede electricien/loodgieter vraagt per uur ? 50 euro zei die man ... Ik zeg en hoeveel ga je mij geven ? Niet dat een electricien ondergeschikt is ofzo, verre van, moeten tegenwoordig ook van zeer veel kennis hebben. En dan komt altijd, ja maar dat is voor een lange periode etc. Uiteraard door die recruitment agencies die zelfs hun databankje raadplegen ga je ze niet echt vinden. Heb zo eens voor de grap "hobbies: java koffie drinken" toegevoegd op mijn cv (Note: java staat er niet op) en dit zo op monster/linkedin gezet. De dag nadien heb ik mijn gsm gewoon moeten afzetten. Kreeg ook constant email voor Java opportunities ...


Anyway good luck om vrijwilligers te vinden, en zeker al voor COBOL zou ik zo zeggen. Het probleem hierin is dikwijls dat je aan een zogezegd monoliet moet beginnen en als je pech hebt nog een paar kopietjes ook mag liggen aanpassen. Je kan er veel geld mee verdienen, maar geld maakt niet altijd gelukkig. Legacy code is er nu eemaal en als het een interessant sector is why not, maar meestal is dit de zoveelste saaie applicatie dat velen er niet willen aan beginnen.

[Floor]

In een monteur tarief zit ook de bus en gereedschap bij, daarbij is de ongevallen verzekering significant hoger. Kennis niveau van een goede monteur is ook hoog. Vooral wanneer er meet- en regeltechniek bij komt kijken. Nee, een goed opgeleide monteur moet met recht net zoveel betaald worden. Alleen dat goed opgeleide, daar ontbreekt het tevaak aan. Dat zie ik wanneer ik opleidingen bezoek.
Het terugbrengen van leerling/meester systeem van vroeger zou geen kwaad kunnen. In heel veel sectoren overigens.

[Pathogen]

Es-sen-tieel dit!

Dit zeg ik al zó lang tegen iedereen waar ik maar een beetje werktechnisch mee te maken heb maar het is de eerste keer dat ik die visie door iemand anders geüit zie worden. Dank!

[Katanatje]

Ik denk dat er over het algemeen toch meer en meer wordt beseft dat het niet enkel de taal is die er toe doet. Je bent alleszins zeker niet de enigste! 2 van de software mensen die bij ons aan de slag gingen hadden geen specifieke ervaring met Python ondanks dat dit voor ons de meest gebruikte taal is. Na enkele maanden zijn die productief omdat ze de juiste skills hebben. In onze hiring is het kennen van Python absoluut geen criterium om op te beslissen. We kijken naar het analytisch vermogen, ervaring met verschillende talen, vb'jes zelfgeschreven code waarop we verder redeneren tijdens een interview, ...

[Ayporos]

Tja (goed) programmeren is natuurlijk een skill, niet een stukje 'kennis'.

Daar moet ik natuurlijk wel de kanttekening bij zetten dat er wel degelijk een belangrijk verschil kan zijn tussen verschillende talen.
Ja, een Java programmeur zal zonder al te veel moeite zich thuis kunnen leren voelen in C# of andersom.. maar een Assembly 'guru' die ineens verwacht wordt in een high-level Object-Oriented taal code te gaan schrijven heeft wellicht een ietwat langere gewenningsperiode nodig.

En dan hebben we het nog niet eens gehad over het 'debat' FP vs OOP.
En als je nog nooit tegen een database aan geschreven hebt dan is dát wellicht ook nog even een nieuwe 'tak van sport' om zomaar even aan te leren als je dat nog nooit gedaan hebt..

Het voordeel van iemand zoeken/aannemen die al ervaring heeft met jou specifieke (soort van) taal/architectuur is dat je sneller ziet of iemand daadwerkelijk nuttig zal zijn of niet.
Je hebt sowieso al met elke nieuwe hire een 'integratie & evaluatie' periode.. maar met iemand die ook nog eens de talen/systemen zichzelf eigen moet maken komt hier éxtra tijd bovenop.
Stel dat dit 3 maanden extra tijd is.. in de situatie waar 50% van je nieuwe hires (10 man) het niet
'halen' betekent dat 15 maanden 'verspild' loon.

Markt dicteert natuurlijk, dus als je niks anders kan krijgen 'so be it' maar ik kan écht wel begrijpen waarom bedrijven liever iemand aan willen nemen die al wat ervaring heeft met betreffende taal/systemen.

[Reactie gewijzigd door Ayporos op 23 juli 2024 03:14]

[Immutable]

Ik zie een programmeertaal meer als een "gereedschap". En elke gereedschap heeft zijn eigen sterktes en zwaktes. Maar blijkbaar zijn er nog steeds veel programmeurs die denken dat je met een hamer prima een plank doormidden kunt zagen. Of heb je van die mensen die helemaal fanboy zijn van de schroevendraaier want hij ligt zo lekker in de hand, en denken dat de schroevendraaier het allerbeste gereedschap is.

Maar nooit hoor je iemand over hoe goed iemand is in het ontwerpen van het tuinhuisje. Uiteindelijk is de taal maar een gereedschap, en weten welk gereedschap het beste is voor de klus is best belangrijk maar uiteindelijk niet het belangrijkste. Hoe goed je ook het gereedschap kent, door en door. Je blijft dan een simpel monteurtje(programmeur). En je kan nog niet een complete tuinhuis "ontwerpen", en snappen dat bepaalde keuzes betreft het maken van een tuinhuis beter is als het andere.

Programmeren is maar gereedschap. Er wordt zoveel rotzooi ontworpen door de programmeer monteurs. Ik vraag me wel eens af waarom er niet meer gefocust wordt op het ontwerpen van "tuinhuisjes".

[Reactie gewijzigd door Immutable op 23 juli 2024 03:14]

[Ayporos]

Deze discussie had ik in een ander nieuws artikel met betrekking tot de term 'software-architect' welke 'officieel' niet bestaat en inbreuk maakt op de wet ter bescherming van de term 'architect' (welke alleen van toepassing is op bouwkundigen die een bepaald diploma hebben en contributie betalen aan het SBA)
Klinkt in mijn oren alsof jij het precies met mij eens bent en dat we meer architecten nodig hebben en minder code-kloppers.

[Reactie gewijzigd door Ayporos op 23 juli 2024 03:14]

[Immutable]

Helemaal mee eens. Ik vind het persoonlijk twee volledig verschillende banen. Je zou het idd goed kunnen scheiden door te zeggen:
- Software Programmeur.
- Software Architect.

[Vlad86]

Vind appart dat je gedownmodt bent. Iig, dit noem je codemonkeys, een teleurstellend fenomeem waar de business kant van een bedrijf ziet graag haar personeel als een schaalbaar unit en niet als een persoon met eigen ideeen en inbrengen. Dit soort tokos wil je zo veel mogelijk vermijden, omdat de ruimte tot ontwikkeling is zeer beperkt.

[Immutable]

Ik denk dat als je begint op de markt, het niet erg is om zaken te programmeren(als codemonkey) die hogerop "bedacht en ontworpen" zijn door anderen. Het ontwerpen vergt denk ik relatief veel ervaring + kennis van de state of art. Een combi die lastig is omdat ervaring ook zorgt voor een vaste groei in je bias. (Daarom is een mix van oudere en jongere mensen de beste combi die elkaar respecteren en beide open staat voor elkaars argumenten en goed kunnen relativeren.)

Er is alleen in de markt geen duidelijk verschil tussen de twee. In de USA volgens mij wel, dat heet tech lead. Hier in Nederland is het maar een cowboy wereld.

In de USA heb je ook 2 pilaren. Management / Engineering. Een Manager kan daar ook bijvoorbeeld een team aansturen van tech mensen die gewoon meer verdienen als hem vanwege die twee functie pilaren. In Nederland zie je vaak dat een manager boven engineering staat qua loonschaal. Heel raar.

[Taro]

Als je een cursus hebt gevolgd om te kunnen schilderen betekent dat nog niet dat je een goede schilder bent en mensen je dienst willen afnemen. Een programmeercursus volgen betekent niet dat je goed kunt programmeren.

Je moet er gevoel voor hebben en veel ervaring in hebben, dan kan je een andere programmeertaal vaak zo oppakken. Heb je er geen gevoel voor dan zal je er weinig meer van bakken dan stukken code bij elkaar zoeken en bij elkaar zetten, met als eindresultaat mogelijk een minder goed werkend geheel dan het startpunt.

Om goed te kunnen programmeren moet je op een bepaalde manier kunnen denken, redeneren en analyseren die niet voor iedereen is weggelegd.

[aequitas]

> Als je een cursus hebt gevolgd om te kunnen schilderen betekent dat nog niet dat je een goede schilder bent en mensen je dienst willen afnemen.

In het geval van dit soort COBOL systemen (een programma kan je het niet noemen) kan je in die analogie het beter vergelijken met het restaureren van een oud schilderij. Het is geen standaard werk, niemand weet er iets van en elke poging die je doet om iets te testen kan desastreuze gevolgen hebben. Succes met uitzoeken, en je weet het hé, het moet wel volgende week af zijn maar als je boel stuk maakt dan heb je een schadeclaim aan je broek.

[ceesiebo1]

Ik heb zelf jaren als Cobol programmeur gewerkt en het kan heel wisselend zijn. Als je pech hebt kom je in een grote monoliet terecht waar geen touw aan vast te knopen is. Vroeger was het ook gebruikelijk om programma's te kopiëren ipv modulair te werken. Dan kun je 300 programma's aanpassen met precies dezelfde wijziging. Erg slaapverwekkend en demotiverend.

[DjoeC]

Monolieten heb ik zelf (begonnen in de seventies) en de organisaties waar ik gewerkt heb nooit gemaakt. Wel gezien maar dan vooral van softwarehouses en pakkettenboeren waar onderhoud en upgrades onderdeel van het verdienmodel waren. Dan moet je er voor zorgen dat je klant vooral niet begrijpt hoe eenvoudig het kan zijn. Stiekum denk ik dat dat ook nu nog voorkomt.

[RBouman]

Ik heb het standaardwerk van Wim Ebbinkhuijsen hier nog in de kamer liggen als relikwie uit een lang vergeten "Goede tijd". Voor de niet-weters, dit boek is het standaardwerk voor COBOL ontwikkeling.
Eens samen met een collega een COBOL programma moeten converteren naar een andere taal, source
paste net op een blaadje a4, elke regel bevatte meerder commando's en eindigden allen op ee Go to.
Ook werd het "Alter" (= nachtmerrie voor elke programmeur) statement te pas en te onpas gebruikt.
Het kostte ons 2 dagen om de codebrij uit te werken naar een flowchart en om te zetten naar de nieuwe 4gl taal, Ik mis die tijd wel een beetje maar ik ga niet naar Amerika

Edit: tiepvauten verbetert

[Reactie gewijzigd door RBouman op 23 juli 2024 03:14]

[x280]

Succes, genoeg tutorials op internet. Blijkbaar werkt niemand graag voor een bank of verzekeraar. COBOL is oorspronkelijk gemaakt voor de financiele markten.

Doe mij maar gewoon C of C++. Betaald net iets minder waarschijnlijk maar er is genoeg werk als developer.

[BananaHeadz]

Developers verdienen meestal al genoeg, en dan is het werk leuk. Werken aan dit soort systemen vinden de meeste mensen niet leuk, dus dan kan je wel leuk 30 tot 50% meer verdienen, maar je hebt wel een kutbaan.

[SuperDre]

Nee, zo simpel is het niet. Omdat je de taal misschien kent wil nog niet zeggen dat je ook werkelijk fatsoenlijk dan de software kunt onderhouden.
Sowieso een misvatting dat als je een cursusje coderen doet dat je daarna ook werkelijk kunt coderen.

[Tommy_K]

Denk dat een goede analogie hier is dat je als je een taal kent dat niet betekend dat je er een fatsoenlijk boek in kan schrijven.

[ArawnofAnnwn]

Zo had er iemand de landstitel voor scrabble in Frankrijk gewonnen door het woordenboek uit zijn hoofd te leren. Hij kende elk woord, maar niet de betekenissen en was de taal niet machtig.

[init6]

Er is een bedrijf waar ik de oprichter van ken, hij zag dit probleem al 2 jaar geleden en is daarom nu mensen aan het omscholen naar Mainframe kennis. Vroeg of ik ook interesse had, heb hem success gewenst.

[Dafader]

cursus kost dan meer dan deze gig in New Jersey je op zal leveren.

[smitae]

Nee, meestal in combinatie met zOS ervaring. Toch een ander soort IT dan wat je tegenwoordig langs ziet komen.

Nadeel, het is niet “sexy”, geen Cloud, geen micro Apps, geen mobile dingen, dat soort dingen, etc, maar ja, zeker zOS ervaring en kennis is voor de komende jaren een goede investering. En dat soort mensen worden ook goed betaald.
Bv core payment systemen van de grotere banken zitten nog wel jaren op zOS, COBOL etc.

Je moet wel goed opletten dat je inzetbaar blijft in de IT, dus de rest wel een beetje bijhouden. De hele IT is altijd een mega cyclus, stil staan in je ontwikkeling is altijd heel slecht voor je inzetbaarheid.

[Eonfge]

In de VS kan een COBOL ontwikkelaar eenvoudig 100.000 USD verdienen. Dat New Jersey dus liever een vrijwilliger heeft is te zot voor worden.

https://www.payscale.com/...r_COBOL_Programmer/Salary

[The Underminer]

Hoezo? Iedereen kan zich toch geroepen voelen vrijwillig bij te dragen aan het managen van corona?
Dat iemand veel verdient betekent niet dat die persoon geen vrijwilligerswerk kan doen.

[Eonfge]

Je laat je wel makkelijk emotioneel chanteren. Vergeet je eigen huur, pensioen, gezondheidszorg en voedsel. Corona bevechten is zijn eigen beloning en dat jij daardoor niet kunt voorzien in je eigen levensbehoeften is niet belangrijk!

Dat jij een salaris wilt om jezelf te onderhouden is geen schande. Zolang jij geen misbruik maakt van de situatie, en een uitbundig salaris gaat opeisen, doe jij niets verkeerd. Punt is dat de meeste COBOL ontwikkelaars al lang goeie banen hebben, en een gezin om te onderhouden. Wil jij dat allemaal op het spel zetten om een lokaal ministerie uit de brand te helpen omdat ze jarenlang hebben bezuinigd op hun IT?

Je moet een gezonde balans vinden tussen de belangen van jezelf en die van de maatschappij, en als de maatschappij jou geen huur en eten gunt, dan ben jij die maatschappij ook geen gratis arbeid verschuldigd.

[Reactie gewijzigd door Eonfge op 23 juli 2024 03:14]

[StefanJanssen]

Wat @The Underminer zegt is dat dit naast je eigen baan is. In je avonduren bijvoorbeeld een bug oplossen. Je bent niets verschuldigd, maar ik zou als ik de kennis had dolgraag willen helpen.

[aequitas]

Mijn ervaring met legacy systemen is dat het soort problemen wat ze zullen hebben niet in een paar avondjes bugfixen op te lossen is. Waarschijnlijk zul je op grote schaal architectuur moeten herontwerpen. Wat betekend dat je mentaal best wat moet investeren. Ik kan je zeggen dat als je overdag een drukke baan hebt waarin je hetzelfde doet je daar in de avond ook niet zo op zit te wachten. En vergeet niet dat in Amerika de sociale voorzieningen heel anders zijn dan in Nederland. Kans is groot dat als je overspannen raakt door al dit extra werk en druk je straks op straat staat.

[mattie2013]

Wat je zegt. Dit is het probleem met +-30 jaar oude code: geoptimaliseerd voor miserabel weining geheugen en beperkte disk space. Meestal met one off oplossingen die op zijn minst originele manier erin gezet zijn. Hiernaast zijn er nog vele losse updates die door de spaghetti heen zitten om het nog minder overzichtelijk te maken. Hiernaast door de druk op het systeem beginnen deze problemen nog duidelijker aan het licht te komen en mogen vrijwilligers het oplossen. Die mogelijk ook nog een wurgcontract mogen tekenen als ze voor de overheid dure fouten maken.

Edit:lees onderstaand comment. Ik denk dat dit meer de mening van een expert is en hopelijk hebben ze het systeem wel zo gedocumenteerd.

[Reactie gewijzigd door mattie2013 op 23 juli 2024 03:14]

[andreas2005]

Ik vraag me wel af waarom iedereen denkt dat COBOL gelijk staat aan spaghetti? Ik heb lang aan zo'n Mainframe systeem gewerkt met COBOL programmatuur (onder andere als programmeur) en zoals met elk systeem wordt het alleen spaghetti als je daar zelf voor kiest.
Waar ik heb gewerkt werd alles eerst netjes uitgewerkt volgens de Volmac-methodiek, dus met documentatie. Pas als de documentatie klaar was van een technisch ontwerp en de bijbehorende programma's begon de programmeur. Die moest ook altijd met een vaste set standaards werken. Alle programma's werken dan op dezelfde wijze en met dezelfde modules. Dat maakt inwerken van nieuwe programmeurs veel eenvoudiger. Ook kunnen mensen elkaar dan overnemen.
En waar je nu moet vechten voordat iemand zich wenst te houden aan standaards, en de documentatie wordt vervangen door de opmerking "kijk maar in de code", was dat vroeger echt heel anders. Niet alles is beter geworden in de loop der jaren, en hier hebben we echt het kind met het badwater weggegooid.
Inmiddels zijn er weinig COBOL programmeurs meer, en deels is dat omdat 3GL-talen niet echt veel uitstraling hebben. Dat maakt de systemen kwetsbaar, het is niet zozeer de systemen zelf.

Waar New Yersey aangeeft dat het systeem het aantal nieuwe aanvragen niet aan kan ben ik best wel verbaasd en ook nieuwsgierig wat daar de oorzaak van is. Juist de snelheid was nooit een probleem met COBOL op een mainframe. Integendeel, dat is één van de sterkste punten.
Mogelijk is er toch ergens een database niet optimaal geconfigureerd, of een blocksize te klein bij de huidige aantallen. O, wat waren die hiërarchische databases toch fijn, nu ik er aan terugdenk. De mogelijkheden waren eindeloos!

[Verwijderd]

Wat grappig .. iemand die VSP (Volmac Structured Programming) nog kent. Maar .. ik ben NOG ouder .. ik ken ook de rampzalige voorloper daarvan, waarbij Volmac bedacht dat je de variabelen V0001, V0002 etc noemde, en een document erbij had waaruit bleek dat V0001 een bedrag was en V0002 een percentage, en in de coding stond dan Compute v0003 = v0001 * V0002 ... zonder eerst die labellijst te lezen: ga er maar aan staan.
VSP was overigens (net als de voorganger daarvan: JSP, prima leesbaar.

Het probleem met oude systemen is alleen, daar hebben veel mensen aan gewerkt. Ik heb ooit nog een programma in onderhoud gehad, iets van 30.000 regels coding dat EN de voorraad bijhield, EN orders verwerkte, EN de facturen printte, EN nog veel meer .. gelukkig verdrongen, met daarin perform section, perform label en go-to door elkaar. De kleinste wijziging daarin was een absoluut hoofdpijn dossier, temeer daar er en stuk of 4 kopieën van dit programma waren, uiteraard NET even anders.

[andreas2005]

Ik ben zó blij dat de variabelen gewoon namen hadden!
Overigens wordt die fout van betekenisloze namen nog steeds regelmatig gemaakt, dit staat helaas (!) los van COBOL.

De voorganger van VSP heb ik gelukkig nooit geleerd, met VSP kon ik prima uit de voeten. Maar het is niet alleen het programmeren, ook de hele werking van een ontwikkelstraat en hoe alle documentatie werd opgesteld hing fantastisch met elkaar samen. Elke fase had zijn eigen test-tegenhanger, en er werden echt zelden bugs in productie gevonden. Ook met de vele releases die we hadden (meestal 3 à 4 echt grote releases van ieder zo'n 20.000 ontwikkeluren (ontwerp-bouw-test). Dan vrijwel foutloos in productie gaan is wel echt een prestatie. En met een dergelijke regelmaat ontwikkelen houdt ook in dat documentatie cruciaal is.
Tsjemig, wat heb ik daar eigenlijk veel geleerd. Dan kijk ik naar huidige ontwikkelstraten en dan springen de tranen mij in de ogen. Alles wat toen normaal was kun je nu als wereldschokkende verbetering introduceren.

[RevellNL]

Ik denk niet dat die vlieger helemaal opgaat. Hoe gaat dit bijvoorbeeld werken als er door jouw toedoen een nieuwe bug in de programmatuur terechtkomt? En wie gaat er verantwoordelijk zijn voor downtime als jij er als vrijwilliger mee bezig bent?

[-PassY-]

Na een hele dag diensten verlenen aan/in de zorg zit ik 's avonds niet te wachten op bug fixen van een systeem wat ouder is als ik

ik ga dan liever demons in doom kapot knallen, of alles doormidden hakken in grim dawn. Hooguit bouw ik een extra ziekenhuis in city skylines

Na 18 jaar vrijwilligers werk zit ik er nu ook niet meer op te wachten, en zou ik gewoon betaald willen worden hiervoor

[theobril]

En terecht. Respect (dat woord gebruik ik niet veel vanwege de devaluatie ervan) dat je al 18 jaar vrijwilligerswerk gedaan hebt. Zelf doe ik het sinds kort, en het is wel heel erg leuk om te doen, mensen wiens scanner het niet meer doet na een windows-update helpen. Het is ook verhelderend om te zien wat er afgetobd wordt door niet-nerds, al mag ik mijzelf waarschijnlijk nauwelijks een nerd noemen.

[Noedell]

Dat is allemaal leuk en aardig, totdat men naar je toe komt met: "Sinds jij deze bug hebt 'opgelost' is er dit en dit aan de hand'. En dan is het leuke er gauw vanaf.

[dez11de]

Ik vermoed eigenlijk dat de meeste Cobol programmeurs al lang binnen en gepensioneerd zijn.

[x280]

Inderdaad, als ze al niet begraven zijn.

[Grzzl]

Nee hoor, die lezen nog mee op Tweakers

[RBouman]

Nee , ik moet nog een paar jaar voor mijn AOW ingaat en ik zit dagelijks hier op het forum.
Binnen ben ik wel, je weet wel Corona (Virus , niet het bier)

[machiel]

Eens. En de drempel is ook lager als het vrijwillig is.

[YopY]

Ja, maar tegelijkertijd, de VS is het rijkste land ter wereld en zou niet afhankelijk hoeven zijn van vrijwilligerswerk - ze pompen een biljoen (trillion) per dag in de aandelenmarkt, daarmee kunnen ze ook iedereen ruim betalen.

[Helixes]

Ik vermoed dat men hoopt op gepensioneerde COBOL-ontwikkelaars. De meeste (goede) COBOL ontwikkelaars die ik ken zijn in de afgelopen 5-10 jaar afgezwaaid.

En trouwens - nee heb je. Ja kun je krijgen. Je kunt natuurlijk altijd vragen naar gratis ontwikkelaars. Amerikanen zijn mondig genoeg zich bij het zelfde loket te melden en hun prijs te noemen. Voor hen geldt ook: nee heb je, ja kun je krijgen.

[TWyk]

Er zijn nog zat cobol programmeurs die nu een betere functie hebben.
Programmeur is een low level baan in grote bedrijven met IT afdelingen.
Lage salarisschalen.

[kidde]

Klopt als een bus.

Naar het gaat wel veranderen nu, degenen met bullshit-banen zitten al thuis of worden nog werkloos.

Een SEO-optimaliseerder, "UBER-klantervaring framework verbeteraar" of 'Facebook marketing campagne bedenker' verdient meer dan een verpleegkundige, boer , politie-agent, vuilophaler of fabrieksarbeider die beademingssystemen in elkaar zet voor Philips.

Net zoals een manager die vroeger COBOL programmeerde maar nu baas is van een leger Angular-programmeurs bij FB wel meer zal verdienen dan een COBOL programmeur.

Maar wie kan je missen, wie doet onzin werk waar de maatschappij eigenlijk niets aan heeft, en wie is er nodig om de crisis (ook in financieel opzicht) te overleven?

Op reclames wordt enorm bezuinigd; het is waarschijnlijk bij Google, Facebook en Twitter dat de JavaScript / Framework programmeurs bij bosjes op straat gaan belanden; inclusief hun managers.

[janbaarda]

De meeste ervaren COBOL programmeurs zijn met pensioen en in de voor COVID-19 dodelijke leeftijd. Blijf liever in huis. Daarbij komt dat in de VS, en dus ook in New Jersey, nagenoeg geen beschermingsmiddelen beschikbaar zijn.

[badflower]

Nu weet ik niet of dit voor Cobol geldt, maar de meeste developers kunnen prima vanuit huis werken.

[Koja78]

Waw.. Even mijn boeken terug opsnorren.. Ben vast een van de laatste lichtingen die dat nog op school kreeg.. (op as400)

[Dynacomp]

Begin 2000 op informatica nog wel wat code langs zien komen als onderdeel van BI. Maar geen concrete programmeeropleiding. Toen was java het helemaal...

[Koja78]

Ik ben afgestudeerd 2001 en wij hadden dus nog COBOL en RPG. De AS/400 van Howest was nog niet afbetaald

[Verwijderd]

Ja jij bent slim. Je neemt het salaris van een SENIOR programmeur.

Salaris Average COBOL Programmer Salary $74,500

Salaris Average Senior COBOL Programmer Salary $101,728

[BFmango]

100k usd per jaar is echt geen uitzondering. Mijn oom deed dat altijd en is nu met pensioen maar krijgt wel aanbiedingen die nog veel hoger liggen.

[DjoeC]

Omdat er nauwelijk nieuwe aanwas is buiten China, de Filipijnen of India - offshore, matige kwaliteit - zullen de meeste Cobolaars wel in de senior of zeer-senior klasse vallen. Een ton in $$'s is in de USA inderdaad niet ongebruikelijk, net als hoge contracting rates.

[Gerco]

$100,000 is veel voor Nederlandse begrippen, maar dat is voor een programmeur in de VS niet eens een geweldig salaris. Afhankelijk van waar je woont is dat maar net boven modaal. Er zijn staten waar dat 2x or 3x modaal (Iowa, Arkensas, etc) is en ook gebieden waar dat heel gemiddeld is (New York, Boston, New Jersey).

Het is zeker geen buitengewoon goed salaris.

[Flagg]

Ja in Silicon valley ws waar je 100.000usd ongeveer 35.000 waard is na aftrek woonlasten.

[MSalters]

Niet overdrijven, de woonlasten zijn ongeveer $5000 euro per maand. Dan hou je nog $40.000 over.

Maar inderdaad, havenarbeiders in San Fransisco verdienen ook al $100.000/jaar. Sommige IT'ers zitten daar op het dubbele.

[Flagg]

En dan heb je nog de hele zorg die je zelf mag betalen de opleidingen van je kinderen die je volledig zelf mag betalen etc etc.

100.000usd is nog amper modaal te noemen.

En dan moet je nog de schijn zien op te houden om mensen maar vooral te laten denken dat je de American dream aan het leven ben.

Terwijl het gewoon de Amerikaanse nachtmerrie is...

[naaitsab]

30 jaar werkervaring, gespecialiseerd in een zeer specifiek stukje van de IT en het salaris van een 18 jarige starter bieden. Moet altijd wel gniffelen als je weer zo'n vacature langs ziet komen. Toch bijzonder dat bedrijven IT nog vaak als kostenpost zien en niet een (cruciaal) stuk van de bedrijfsvoering.

Toch wel treurig dat een deel van de overheid kan/mag opereren op zo'n antiek systeem.

[FreezeXJ]

Tja, het kost ook geld, ongeacht of het werkt...Het probleem is dat het ook essentieel is, en dat bezuinigingen pas opvallen als het te ver omgevallen is (en daarmee bijna niet meer te redden). Tot die tijd worden er pleisters geplakt want da's veel goedkoper, en de manager ziet het verschil toch niet.

[naaitsab]

Dat zie ik op het werk ook wel langskomen, managers die alleen maar kijken naar €-tekens en niet naar de gevolgen als het klapt. Als de boel wel klapt staan dezelfde managers vaak het hardst te schreeuwen richting de IT. Altijd jammer dat soort gedachtegangen.

[FreezeXJ]

Ah maar ze pushen gewoon iemand om te zeggen dat het waarschijnlijk niet gaat omvallen (als ze dat al doen), en anders nemen ze het risico gewoon. Theoretisch kun je het namelijk best snel fiksen als er maar 1 dingetje misgaat, en anders hebben we toch hele PRINCE2-protocollen en verantwoordelijken die lekker met de zwarte piet mogen schuiven? Die zijn namelijk in 2004 wel gemaakt, en volgens mij moest Piet (die in 2009 wegging) dat up to date houden, en tja, dat is nooit elders belegd. Sorry, wij wisten van niks.

[Alfa1970]

Dat PRINCE2-protocollen gedoe en aanverwante artikelen, dat zouden bedrijven het eerst buiten de deur moeten zetten, gevolgd door 75% van alle managers en directeuren.
De overgebleven managers en directeuren zouden moeten leren luisteren naar diegenen die het daadwerkelijke werk doen. Dan worden bedrijven véél gezonder, véél flexibeler en heb je zulke ellende met 40 jaar outdated IT rommel niet. Uiteindelijk zal de winst ook nog stijgen omdat er veel mender opvreters in het bedrijf zitten, in plaats van 3 managers en 5 directeuren per werkende werknemer..

[JAVE]

Toch wel treurig dat een deel van de overheid kan/mag opereren op zo'n antiek systeem.

Zo'n systeem draait al jaaaaren. Daar zit enorm veel kennis/tijd in wat over de jaren heen is toegevoegd.
Nu ga je dit even omschrijven in een andere taal (maakt niet uit welke, hoewel ik voorstel om een taal te nemen die bewezen stabiel is, en waar veel serieuze literatuur over is geschreven).

Nu kost het een hoop geld, en (als het goed is) ziet niemand dat er wat veranderd is. Verkoop dat maar aan een pointy-haired boss...
(Bewijs nu eens dat jouw nieuwe code precies zo werkt als de oude code. (hint: Dat kan je niet))

Nu moet je daar nog even "Overheid en ICT projecten" bijdenken, en het wordt ineens goedkoper om een oud systeem draaiende te houden, dan alles herschrijven.

Oh, en zelfs dezelfde taal op een ander platform kan vreemde gevolgen hebben voor code die letterlijk al meer dan 20 jaar gewoon goed werkte:
Op het oude systeem was 99 + 1 = 00 voor een 9(2) veld (een numerieke variabele met 2 digits in COBOL)
En de vergelijking met 0 was dus waar. (Y2K gerelateerd, Na het jaar '99 kwam het jaar '00, helemaal goed)
Maar op het nieuwe platform (Unix in plaats van Bull Mainframe) was dit opeens niet meer gelijk. Daar bleek de compiler namelijk een overflow bit te zetten voor 99 +1, en "0 met overflow" is niet gelijk aan "0"

[naaitsab]

Dat is gelijk het grote probleem met het management, als het cruciale software/hardware betreft moet je bij de implementatie al bezig zijn met een continuïteitsplan voor meerdere jaren. Iets neerzetten en dan maar kijken hoe lang het blijft draaien is echt kortzichtigheid van de bovenste plank. Dat werkt wellicht wel voor een boormachine die je bij de leverancier zo kan aanschaffen en inzetten maar dat werkt bij IT natuurlijk niet zo. Dat weten de meeste gebruikers hier wel maar de meeste managers helaas niet.

Maatwerk is ook vaak killing voor de continuïteit van je software. Dan krijg je net als dit voorbeeld van die systemen die met 'touw en spuug' aan elkaar hangen en degene die er ooit aan gewerkt hebben zijn vertrokken. Bij maatwerk moet je helemaal scherp zijn op de continuïteit, dat maakt het nog een complexer geheel.

[OxWax]

"Nu kost het een hoop geld, en (als het goed is) ziet niemand dat er wat veranderd is. Verkoop dat maar aan een pointy-haired boss..."
Is dat een referentie naar ......
https://dilbert.com/

[mbovenka]

Natuurlijk. Ken uw klassiekers

[Bert Gent]

Wedden dat hij een hoop gepensioneerden krijgt die het vrijwillig doen? Zo zit een Amerikaan nu eenmaal in elkaar.

[RagingPenguin]

dit speelt natuurlijk gruwelijk op nationalisme en patriottisme what in de USA een hoop meer leeft dan hier in Nederland. Ik zie ook gerust een rij aan oudere developers staan die dit vooral vanuit een plichtsbesef doen en zich niet zo druk maken om de financiële vergoeding.

[wow7]

En dan niet te vergeten die gene die de verschillende dialecten en versies van cobol onder de knie hebben.
Versies
1959 COBOL
1960 COBOL 60
1961 COBOL 61
1962 COBOL 61 EXTENDED
1968 COBOL 68 ANS
1974 COBOL 74 ANSI
1985 COBOL 85 ANSI/ISO
1989 Uitbreiding van COBOL 85 met de intrinsieke functies ANSI/ISO
1997 OO COBOL bij veel compilerfabrikanten
2002 COBOL 2002 ANSI/ISO

Dialecten
IBM S/390 COBOL (VS COBOL II)
IBM ILE COBOL
IBM Visual Age COBOL
HP COBOL II
HP Micro Focus COBOL for HP UX
Micro Focus Net Express
MBP Visual COBOL
AcuCorp COBOL
CA Realia
Liant RM COBOL
Tandem SCOBOL (Screen COBOL)
Tandem Non-Stop COBOL
Fujitsu COBOL
Data General ICOBOL
Wang VS COBOL
UNISYS COBOL
Delta COBOL

[tweaknico]

En dan maar hopen dat het complete programma's zijn en geen COPY libraries hebben van diverse pluimage. Of binary linkage.

[Toff]

Dat is wel een heel goedkope copy / paste van Wikipedia ...

[Verwijderd]

De verschillende 'merken' Cobol: okay, maar de (IBM) versions zijn onwaarschijnlijk downwards compatibel. Ik heb zelf pas geleden Cobol 6 geïmplementeerd op een z/OS systeem. Er was letterlijk niet 1 programma, dat aangepast moest worden, terwijl veel Cobol uit de '80-er jaren was .. rond de 40 jaar oud dus. De versies bieden vaak alleen uitbreidingen, de dialecten speciale i/o statements (vaak .. niet altijd).

[HNO2]

Haha, ik heb 20j geleden als groentje nog bij een multinational gewerkt waar ook een COBOL programmeur zat.
Iedereen deed hier denigrerend tegen. Ik was getriggerd (why?). Na uitvraag wist deze dame mij te vertellen dat je zal zien dat dit nog wel heel wat jaartjes gaat blijven en dat als ze denken dat dit niet belangrijk is moeten ze de stroomkabel maar eruit trekken. 'we zullen dan eens zien..' zei ze.
Gelijk had ze blijkbaar. Ik moet hier toch effe stiekem om lachen. :-)

[KonradV]

Met ondertussen 35 jaar ervaring in COBOL programma's bouwen en onderhouden, mag ik wel zeggen, dat ik er "iets" van weet. Alles staat en valt met een logische opbouw van een programma, en de goede, bijbehorende documentatie. De eerste bedrijven waarin ik gewerkt heb, bouwden hun programma's volgens de JSP (Jackson Structured programming), en de Nederlandse variant VSP. Programma's volgens die opzet, zijn nu nog steeds goed leesbaar, en begrijpbaar, mits iedereen zich maar aan die standaard van programmeren hield, en men pas begon te programmeren, nadat er een gedegen Functioneel/Technisch ontwerp lag.
Veel van die basis-regels zijn in de loop van de jaren overboord gegooid. Er zijn tijdens de zogenaamde "Millennium Bug" crisis zogenaamde "automatiseerders" binnengekomen, die letterlijk in een autoshowroom van een softwarehuis de autosleutels van hun leaseauto kregen, tezamen met hun werkopdracht, omdat ze het woord "COBOL" correct konden spellen, om vervolgens bij bedrijven de programma's te gaan aanpassen. Om er vervolgens achter te koen, dat het iets ingewikkelder is, om een goed werkend programma " even snel" aan te passen met hun jaar theoretische Pascal/C++/Java kennis van de universiteit. Deze 'snelle jongens' hielden het dan ook al vrij snel voor gezien, ze verlieten de automatisering na enige tijd, of werden manager.
Wat ik wilde zeggen, is dat men zonder vakkennis de puinhopen alleen maar groter maakt, dan maakt de gebruikte programmeertaal niets uit, of het nou COBOL of Java is. Inderdaad kunnen COBOL programma's in de loop van de jaren uitgegroeid zijn tot enorme monolieten, en dan zal iedere poging om " even" de functionaliteit te gaan vervangen door een 'geweldig nieuw systeem' van een paar miljoen Euro, dat zo "flexibel" is, dat het alle 'oude meuk' wel even zal gaan vervangen. Na vele tientallen miljoenen Euro's aan specifieke aanpassingen voor de klant van dat "super" systeem, zijn verschillende keren uiteindelijk deze projecten gestrand in een duur fiasco, precies zoals bij bij verschillende overheidsinstanties de afgelopen tien jaar gebeurd is, met als gevolg dat de te vervangen COBOL systemen nog steeds draaien, en er nog minder programmeurs over zijn, om deze systemen te blijven onderhouden

[junkchaser]

Tja wat moet je daar nog op zeggen ... Cobol is zijn hype al lang voorbij? Ik weet nog 20 jaar geleden dat ik dat op school kreeg tijdens mijn hogere studies en toen was dat al met uitsterven bedreigd. Een verrassing dat ik dit zelf nog te lezen krijg op tweakers

[Dennis van der Stelt]

Is helemaal geen verassing.

Ik maak de opmerking wel vaker, dat het voor veel ontwikkelaars een keuze is; of met de laatste technieken werken (waar veel van hen van dromen, en de term 'fullstack-developer' vandaan komt), of gruwelijk veel geld verdienen als Cobol ontwikkelaar.

Dit zijn typisch monolithische systemen die omgebouwd zouden moeten worden. Niet zozeer omdat de technology niet meer mee kan, maar vanwege gebrek aan ontwikkelaars. Zo heb ik ook een bedrijf dat zeer succesvol was met ColdFusion, om zien schakelen naar .NET. Vanwege gebrek aan ontwikkelaars.

Dat is met heel veel Cobol systemen ook geprobeerd, maar hopeloos gefaald.

• Functionaliteit is niet 100% bekend en veel wordt bij omzetten vergeten
• Het systeem wordt 1 op 1 omgezet i.p.v. nieuwe user interface ontwerpen
• Als de user interface wél omgezet wordt, accepteren gebruikers de nieuwe interface niet.
• Het systeem wordt niet zo goed gebouwd als dat het vorige systeem draaide. Nieuwe technieken geven in veel gevallen geen garantie voor betere performance.
• Het oude systeem onderging 40 jaar lang bugfixes, het nieuwe systeem heeft weer allerlei bugs
• Lastig tot onmogelijk om systemen in parallel te laten draaien, maar moet omdat niet iedereen in een keer over kan naar nieuwe systeem. Ook omdat een big-bang upgrade niet mogelijk en zeer ongewenst is. Niemand kan beloven dat na 4 jaar programmeren het systeem wél goed is.

En ga zo maar door. Dat is de reden dat die systemen niet zomaar omgebouwd worden in een nieuwe technology. De technology heeft er niets mee te maken. Gaat om de mensen er omheen en de historie van het gehele systeem.

[Koja78]

Hoeveel mainframes zijn niet gewoon nagebouwd in sap :-)

[ceesiebo1]

Niet zo gek hè, SAP komt ook van het mainframe. Daarom zie je daar nog steeds van die ouderwetse attributen en transacties van 4 posities .

[Koja78]

I know.. mijn eerste aanraking was ook R/2 als studentje lijsten trekken.. maar ik bedoel functioneel..

[andreas2005]

Dat kan alleen in een heel specifieke omgeving, waarbij de organisatie zelf verandert om op de SAP-wijze te gaan werken.

COBOL is nog steeds de beste programmeertaal voor administratieve omgevingen als je maatwerk wilt hebben (dus de organisatie is leidend, niet je software). Dat het oud is doet er dan niet toe.
Maar dat gezegd hebbende, de interfacing is met COBOL wel een probleem; de taal is niet geschikt voor wat iedereen tegenwoordig ziet als een normaal invoerscherm. Daar kun je wel omheen door de de interface zelf te bouwen op een moderne wijze, en die tegen de achterkant te laten praten die nog COBOL is.

[Koja78]

Je eerste zinnetje.. change management... das is zowat overal de gap.

[sircampalot]

Vergeet daarbij de business case niet! Het kost enorm veel geld, en in het allerbeste geval heb je uiteindelijk een systeem dan precies hetzelfde doet.

[FreezeXJ]

En dat niet afhankelijk is van onvindbare mensen (die 200 per uur vragen als je ze vindt) en dat gewoon netjes gemonitored kan worden zonder de omliggende dinosaur pens.

[tweaknico]

Tegen de tijd dat je dat systeem foutvrij hebt is de wereld alweer naar het volgende platform...
En kan de hele migratie weer van voren af aan.

[TWyk]

Vaak minder doet.
Maar wel met een uitgebreidere interface.

[Zoop]

Ik vind mijn ervaring compleet terug in dit verhaal. Niet zo zeer cobol dan, maar een samenraapsel van aan elkaar gekoppelde systemen, iedere keer als er een nieuw systeem bij kwam, werd dat in een eigen platform, eigen taal iets nieuws voor geschreven, en aan het grote geheel geknoopt, na zo'n 30 jaar een gedrocht van een systeem. Waar 1 klein foutje voor een cascade van failures op de rest kon zorgen en bugfixes weken konden duren. Maar dat is wel allemaal gedaan, jaren lang finetunen en bugfixxen, dus hoe wankel het ook was, het werkte wel. Veel ervan afhankelijk van webinterfaces die alleen in IE6 functioneerde. Dat kon dus op een gegeven moment echt niet meer. Dat je VM's van oude windows systemen moest draaien om het in IE te kunnen openen was gewoon belachelijk.

Toen moest er 1 grote applicatie komen die het allemaal moest gaan vervangen, 1 platform, die het allemaal doet en draait op moderne OSen. Op papier een no-brainer dat het moest gebeuren. Zo'n 2 jaar geduurd om te ontwikkelen, ongeveer 10 jaar geduurd voordat ze eindelijk de stekker uit het oude systeem konden trekken (en dan nog features mistte dat het oude systeem wel had). Zoveel bugs, zoveel problemen, leek nog wel wankeler dan het systeem ervoor. Al die losse systemen waren los ontwikkelt en zo goed als niet gedocumenteerd. Hoeveel er wel niet boven water kwam NA de lancering van het nieuwe systeem, was om te janken. Maar ondertussen kan de bedrijfsvoering natuurlijk niet stil liggen. Heeft uiteindelijk makkelijk 10x meer gekost dan in eerste instantie gecalculeerd was.

Om nog maar te zwijgen hoeveel moeite het kostte om het personeel om te trainen het nieuwe spul te gebruiken. Zijn grotendeels geen IT-mensen, die vinden nieuwe zaken lang niet zo logisch, en hadden ook allemaal hun eigen eigenaardige werkwijze gevonden in het oude systeem. Dus dat werkzaamheden meer tijd en moeite kostten dan voorheen ("het zou toch sneller en efficiënter worden?").

Dusja, moest wel gebeuren, maar echt zo simpel niet. En zwaar onderschat wat een impact het had.

[Reactie gewijzigd door Zoop op 23 juli 2024 03:14]

[DSK]

Dat gruwelijk veel geld verdienen als Cobol ontwikkelaar kan tegenvallen vrees ik. Het eindigt ook op een bepaald moment en dat kan heel snel gaan.

Zelf heb ik een 7-tal jaar als mainframe-consultant (IBM z/OS en z/VM) gewerkt als "jongere". Hiermee ben ik van scratch begonnen. Vooral omdat ik de uitdaging wel leuk vond en het nu eenmaal iets anders is dan standaard Windows/Linux. Helaas is de markt in een heel snel tempo verdwenen. Eén partij begon de resterende mainframeklanten op te slokken (lees: shared hosten van hun workload voor een lagere prijs dan ze zelf hun machine up en running hadden) waarna IBM de rest van de machines dan maar bij hun nam om die partij niet al te krachtig te laten worden. Voor een partner/consultant schiet dan zo goed als niks meer over (behalve enkele vuile migratiewerkjes) en mag je plots wekelijks naar het buitenland...

[SuperDre]

En toch grappig om te zien dat die systemen nog draaien als een dijk waar een doorsnee nieuw systeem al omvalt als er iemand die kant op kijkt. Het verbaast me toch altijd weer hoe vaak doe oude systemen solider werken dan die nieuwste.. Maargoed, op den duur moet je wel vanwege gemis aan kennis. Maar nieuwe frameworks is mij wel gebleken uit ervaring dat dat vaak lang niet altijd beter is.

[SqyD]

Helemaal spot on. Ik heb begin deze eeuw gewerkt in de finance sector en die hangt voor een verontrustend deel aan elkaar van de legacy systemen, waaronder een schikbarend deel Cobol en andere mainframe technologie. Hoewel er in de loop der jaren koppelingen en schillen omheen gebouwd zijn zit een groot deel van de businesslogic vast in stokoude maar bijzonder stabiele code. Zo lopen er hele legertjes uitstekend betaalde specialisten rond die dankbaar gebruik maken van deze afhankelijkheid. Omdat herbouwen met moderne technologie behoorlijk duur en risicovol is, twee begrippen waar ze in de finance niet blij van worden, zal het nog wel een paar generaties duren voordat het eindelijke helemaal vervangen is.

[P_Tingen]

Ik heb mijn HEAO opleiding van 1989-1993 gevolgd en ook toen hoorde ik al dat Cobol een uitstervende soort zou zijn. Blijkt toch taaier dan gedacht...

[hatex]

Yep volgens mij lag het overgangsjaar bij ons op het HES bij BI op 94/95...

Toen zaten we nog op vax/vms te prutten met van die grote matrix regeldrukkers in t printhok..

Dat ging over naar windhoos met Delphi

In 2000 mochten de cobol oudjes weer van stal om de milennium bug te verhelpen.. meen te herinneren dat o.a. veel banken daar nog gebruik van maakten.

De schaarste destijds leverde een aantal flink centjes op

[Zoop]

Delphi ja ... goh.. leeft dat nog?

[hatex]

Geen idee eigenlijk... heette dat niet later ook nog visual pascal , of object pascsal of zoiets ?!

[RBouman]

Delphi is een Object Pascal, laatste versie heet Embarcadero Delphi 10.3 Rio
Embarcadero heeft CodeGear overgenomen omtrent 2008

[bbob]

Blijkt toch taaier dan gedacht...

Zo te horen is het zelf corona proof.

[sircampalot]

Een systeem invoeren is eenvoudig, een systeem uitvoeren onmogelijk.

[mkleinman]

Dan heb je nog Cobol gehad op school.

Ik heb Informatica gestudeerd tussen 1995 - 2000 en ik heb geen les meer gehad in Cobol of Fortran. Nog wel overigens in Assembler maar dat was meer bedoeld om te leren hoe op het laagste niveau de x86 architectuur werkte.

[dura]

Dat zou je zeggen ja, dat hoorde ik ook toen ik meer dan 30 geleden in de IT begon. Maar de realiteit is dat de kern van nagenoeg alle grote financiële systemen in ieder geval hier in Nederland nog steeds in Cobol zijn geprogrammeerd. Denk aan banken, grote pensioenfondsen, de uitkeringssystemen waarin tientallen miljarden omgaan etc.

[synoniem]

De oorzaak is waarschijnlijk niet de inflexibiliteit van de verouderde systemen maar gebrek aan capaciteit. Kan me niet voorstellen dat het aantal aanvragen flexibiliteit van de programmatuur vraagt. En ik maak me sterk dat een partij als IBM zo een blik mainframes kan opentrekken als dat gevraagd (en betaald) wordt.

[OCU-Macs]

En ik maak me sterk dat een partij als IBM zo een blik mainframes kan opentrekken als dat gevraagd (en betaald) wordt.

Sterker nog, IBM blijft het gewoon ondersteunen omdat het van ze geeist wordt. Nu nog steeds worden Z-series (voorheen de system 390 mainframe) en i-Series (AS/400) actief ondersteund, en ik kan je uit ervaring (ik werk als integratie consultant, dus ik knoop dergelijke systemen aan andere (eco)systemen) vertellen dat het aantal zelfs groeiende is!

Wel valt me op dat de mensen die dit alles ondersteunen steeds grijzer aan het worden is, hoewel ik de laatste jaren ook een aantal dertigers zie die er steeds meer in beginnen te doen.

Voor de hippe ICT'er van 'nu' die zich in de sferen van webapps begeeft wellicht een 'ver van zijn/haar bed show', maar waar het gaat om het draaien van corporate ERP systemen en -databases zijn dit soort systemen zowat het fundament van menig multinational.

20 jaar geleden dacht ik ook dat het weldra gedaan zou zijn met dergelijke systemen, maar ik heb mijn mening inmiddels herzien: Ik ga het in mijn loopbaan niet meer meemaken dat ze allemaal uitgefaseerd raken.

[ari3]

Voor de hippe ICT'er van 'nu' die zich in de sferen van webapps begeeft wellicht een 'ver van zijn/haar bed show', maar waar het gaat om het draaien van corporate ERP systemen en -databases zijn dit soort systemen zowat het fundament van menig multinational.

Uiteindelijk is een mainframe gewoon de hardware waar het op draait. Moderne mainframes zijn gewoon (grote) computers met virtualisatie ingebouwd. De Z-series draait verschillende besturingssystemen waaronder OS/390 (een UNIX-variant) en kan ook gewoon moderne Java-runtimes draaien. Hierdoor is het hele Java ecosysteem beschikbaar inclusief "hippe" talen als Scala, Clojure en Kotlin. De jong-geschoolde ICT'er zou prima zijn applicatie op een mainframe kunnen deployen.

[zenlord]

Het lijkt mij sterk dat de wetgeving gerelateerd aan deze aanvragen in al die decennia niet is gewijzigd. En als er een criterium voor een aanvraag wordt gewijzigd, moet je de software aanpassen (of moet je hopen dat de softare zelf flexibel is)?

[DSK]

Dat blik open trekken kan serieus tegen vallen, kan ik uit ervaring zeggen. Toch zeker in Europa rekent IBM vooral op hun partners hiervoor. Uiteraard houden die natuurlijk ook geen hopen mensen op de bank "voor het geval dat". Binnen IBM zelf is een heel groot deel wegbezuinigd, tot zelfs grote stukken expertise die niet meer in-house bestaan.

[TWyk]

Cobol vereist nauwelijks resources.
Meeste van die software is 20 of 30 jaar geleden ontwikkeld en draait supersnel op de modernere hardware waar het nu op staat. Want hardware update zijn er wel geweest voor die platforms.

[Janoz]

Ja, want met 9 vrouwen kun je een kind in 1 maand baren..

[Flagg]

Over langere periode en goed plannen kan je idd iedere maand een kind baren over een periode van 9 maanden.

Oftewel die uitgekauwde oneliner is just that... Een uitgekauwde oneliner.

[Janoz]

Mijn uitgekauwde oneliner is een reactie op de uitgekauwde non-oplossing 'dan trek je toch een extra blik hardware open'. Beiden zijn van exact hetzelfde kortzichtige kaliber.

[Flagg]

Ja klopt idd. Beide...

Heb ik er ook een domme oneliner om het af te maken

2 wrongs don't make a right.

[Reactie gewijzigd door Flagg op 23 juli 2024 03:14]

[connectcase]

Lullig voor ze.... Maar er zijn de afgelopen decennia vast en zeker meerdere techneuten geweest die hebben aangedrongen deze systemen en applicaties te vervangen. Waarschijnlijk zijn die genegeerd....

[Reactie gewijzigd door connectcase op 23 juli 2024 03:14]

[Luftbanana]

Heerlijk, die subtiliteit

Waarschijnlijk het zoveelste gevalletje "if it works, don't fix it", standgehouden door een manager die veel praat maar eigenlijk niets zegt.

Voor zover ik begrepen heb werkt het Nederlandse bankwezen ook nog veel met Cobol. Kan iemand uit die wereld een goede uitleg geven van waarom er nou écht geen Cobol uitfasering kan plaatsvinden? Downtime, check. Kost tijd en geld, check. Valt te overkomen met zorgvuldig ingerichte backup systemen met een acceptabele downtime die je als "storing" kunt aanmerken. Am I wrong?

[FreezeXJ]

Risico, nu hebben ze alle bugs er al uit, maar een testharnas is er niet, dus ze zullen alle acceptance tests van de grond af aan moeten uitzoeken en uitschrijven, en daarna... merk je dat er toch wat quirks in zitten. Mis er 1, en je systeem riskeert ongeplande downtime. De kosten daarvan zijn hoog, dus stellen ze de overgang maar uit.
Verder is het mankracht, er zijn nu al te weinig ITers (tegen minimumloon of daar in de buurt) dus 'even' een heel team aantrekken voor een jaar of wat om dit netjes op poten te zetten is onbetaalbaar. Duurder dan 'nog maar even doorhobbelen', zeker als er per kwartaal afgerekend wordt.

[sumac]

Mijn kennis is gedateerd en ook niet heel gedetailleerd, maar banken en verzekeraars werken nog altijd met oude applicaties op oude systemen die in virtual machines draaien, en zo eeuwig kunnen blijven voortbestaan. Als je niet afhankelijk bent van oude hardware die kapot gaat, kun je dit nog heel lang volhouden. Die systemen kun je goed afschermen voor de buitenwereld, en met de juiste interface sluit je het aan op een moderne front-end. Maar het blijft houtjes-touwtjes-IT.

Het probleem is geloof ik niet zozeer het schrijven van de nieuwe software, maar het uitpluizen van de oude, en dan vooral de vele uitzonderingen die erin zitten. En hebben ze nog wel de broncode? Want als die er niet is, dan wordt het nog vele malen lastiger. Ik heb geen idee in hoeverre dat het probleem is.

[Sjapmeister]

De meeste basale reden: kan men de gevolgen niet overzien. Veel mainframes van banken zijn inderdaad 40 jaar oud. Ik weet niks van programmeertalen maar doe de aanname dat dat dan in Cobol is geprogrammeerd ( het zijn van die systemen met zo’n groen / zwarte gui en zo’n knipperende groene cursor).

A) daar is in de loop van 40 jaar zoveel tegen aan gebouwd aan interfaces en veelal slecht of niet gedocumenteerd waardoor nu niet te overzien is hoe ver de tentakels van die data reiken in alle overige banksystemen.
Note: dus IT sector is dus zelf deels verantwoordelijk voor dit probleem, waar veel mensen in deze thread nu de business beschuldigen.

daar is in de loop van 40 jaar zoveel maatwerk ingebouwd (uitzondering op uitzondering op uitzondering) dat er nu geen enkel systeem dit kan vervangen tenzij men weer met maatwerk gaat werken en dan zit men over 20, 30, 40, jaar weer.

C) het draait over het algemeen heerlijk stabiel. Er zijn nagenoeg nooit verrassingen want die zijn er in 40 jaar wel uit.

Ik heb vaak geroepen dat ik denk dat de enige veilige oplossing is om vanaf punt x gewoon geen nieuwe data meer op te nemen en dat in een nieuw systeem te doen. Vervolgens het legacy systeem heel langzaam laten doodbloeden tot er bijna niets meer inzit en dit dan alsnog overzetten zonder het maatwerk en eventueel de business / relatie informeren dat het maatwerk deel verloren gaat. Maar ik hoor graag van de kenners hier of dat zou kunnen werken.

[Luftbanana]

Note: dus IT sector is dus zelf deels verantwoordelijk voor dit probleem, waar veel mensen in deze thread nu de business beschuldigen.

De IT sector omvat in dat geval ook de business, lees "opdrachtgever": je krijgt als programmeur uit te voeren opdrachten, maar jouw advies (zoals de behoefte van goede documentatie voor in de toekomst) wordt werd vrijwel altijd als onbelangrijk beschouwd. Opdrachtgevers vallen erg lastig over te halen wat dat betreft. Indien je een product als geheel verkoopt heb je er wél inspraak in, dan lever je het namelijk pas op wanneer de boel compleet is, incl. documentatie.

Zonder zeer uitgebreide documentatie kun je ook wel uit de voeten, maar dan moet je actief onderhoud uit blijven voeren op de gebruikte technologieën. Want betreft het standpunt "het is lekker stabiel": ja, klopt misschien wel, maar áls er stront aan de knikker is kun je er niets mee op korte termijn omdat de kunde ervan niet meer rondloopt. Uitstel van onderhoud is simpelweg vaak (veel) duurder dan periodiek onderhoud.

[SPee]

je krijgt als programmeur uit te voeren opdrachten, maar jouw advies (zoals de behoefte van goede documentatie voor in de toekomst) wordt werd vrijwel altijd als onbelangrijk beschouwd.

En nu gaan we allemaal naar scrum, met: "working software over documentation..."

[andreas2005]

1. COBOL is de best mogelijke programmeertaal voor administratieve omgevingen (ik ben zelf jarenlang COBOLprogrammeur geweest en heb in die omgeving ook heel lang de technische ontwerpen gedaan. Dit was voor een overheidsinstelling die uitkeringen verstrekt.). Ik heb zelfs nog een artikel geschreven voor de Computable in de jaren 90. Toen al waren er mensen die vonden dat wat oud is ook automatisch slecht is. Maar de onderhoudbaarheid van COBOL (mits goed opgezet en gedocumenteerd) is ongeevenaard, en daarbij is het voor een batchsysteem, zeker destijds op een mainframe, ook ongelooflijk goed te optimaliseren. Dit leverde een echt heel goede performance op, juist bij de batchgegevensaanleveringen die destijds de norm waren.
2. De kern van de systemen bij banken blijven hetzelfde doen, de wijzigingen zijn vooral toevoegingen. Zoals hierboven al gezegd, dit is in COBOL echt snel en goed te doen zonder dat het spaghetti wordt. Wederom, in de jaren 90 waren er 4GL talen die als de norm golden, maar waarbij alleen de initiële opzet sneller ging. Aanpassingen kostten een factor 3-4 meer tijd dan met een 3GL taal (cijfers gebaseerd op de ervaring van een bedrijf uit het zuiden des lands).
3. Qua businesscase: Je kunt wel zeggen "COBOL is oud en straks niet meer te onderhouden", maar waar ga je het mee vervangen, en welke taal ken jij die over 20 jaar nog steeds gebruikt wordt en waarmee je op die tijdsschaal ook de garantie durft te geven dat het systeem nog steeds onderhoudbaar is? Deze discussie speelt al heel lang, en wat 20 jaar geleden als opties werd voorgesteld, is nu echt niet meer aanwezig in de markt.
4. Maar misschien is nu wel hét moment in de tijd waarop wijzigingen moeten én kunnen. Welke toolkit stel je voor, en waarom is die toolkit geschikt om mee te werken? Bedenk wel dat je er eisen aan stelt die vergelijkbaar zijn met SCADA-systemen: altijd beschikbaar en zo foutvrij mogelijk als maar kan, en niet over een paar jaar ineens niet meer ondersteund. En de noodzakelijke functionaliteit van het systeem is groot: het moet als geheel echt heel veel kunnen. Dus een ontwikkelmethodiek à la Agile / Scrum kan wel, maar je kunt onvolledige functionaliteit niet in productie nemen: Alle functionaliteit is écht nodig. Uiteindelijk zit je toch op en big bang scenario qua implementatie.

[SuperDre]

Je kunt je ook afvragen waarom men nog die oude systemen gebruikt, en waarom het toch keer op keer als ze weer eens de boel proberen te moderniseren het compleet faalt. Je zou zeggen dat het toch niet zo moeilijk zou moeten zijn, want het is oude 'troep', alleen die oude 'troep' blijkt toch beter te werken dan die nieuwe zooi die het zou moeten vervangen. Vraag me dan toch altijd heel erg af waar dat door zou komen, en dat bedoel ik dus serieus.

[Crazy D]

Omdat niemand precies weet wat het allemaal kan, laat staan wat het zou moeten kunnen. En op een gegeven moment het de vraag is of het financieel niet rendabeler is om mensen om te scholen om de oude meuk te kunnen ondersteunen, dan nieuwbouw, jaren verder, met alle risico's van dien.

[tweaknico]

Of de zoveelste migratie poging is halverwege gestrand omdat het probleem te complex bleek voor het beschikbaar gestelde budget.

(Heb ook al meegemaakt dat een meet systeem uit 1996 pas na de derde poging vervangen kon worden).
ieder van de 3 pogingen heeft een veelvoud gekost van de originele bouw en onderhoud door de jaren heen.
En elke keer was het nieuwe systeem niet in staat om het oude (gebaseerd op 80486 industrial PC's) te vervangen kwa capaciteit... blijkbaar waren er 20 jaar hardware ontwikkeling nodig om een design uit 1997 te vervangen op een "moderne" manier.
Niet dat een van de originele ontwikkelaars ooit ge-interviewed is waar de kern van het oorspronkelijke uitdaging zat. (gewoon heel veel nummertjes uit een industrie lijn verzamelen en verwerken maar dan wel vrijwel realtime <1 minuut).

[cruysen]

Volgens Murphy doen zijn medewerkers a heck of a job. "Maar we hebben letterlijk systemen van meer dan veertig jaar oud." Volgens hem zal een van de lessen na afloop van de crisis zijn hoe de staat op het punt is gekomen nu afhankelijk te zijn van cobolprogrammeurs.

Ik denk dat de leer is dat ze jaren gelden al hadden moeten investeren in modernere systemen en niet pas als het systeem instort.

[Reactie gewijzigd door cruysen op 23 juli 2024 03:14]

[OxWax]

Politici en pro-activiteit gaan niet samen. If it works, don't fix it.

[hatex]

Tja daartegenover staat : fix it till it's broke..

Om if else while do te gebruiken :

Ik zou zeggen , IF it works THEN don't fix it and WHILE you have the time DO develop something new.....

Laat die ouwe werkende meuk zn werk doen totdat je iets compleet nieuws er naast hebt wat beter is en minstens net zo betrouwbaar ipv van blijven op te lappen en het ouwe gewoon uit kan... ik heb er van geleerd , scheelde mij een hoop downtime in ieder geval.

[OxWax]

Ik zou zeggen , IF it works THEN don't fix it and WHILE you have the time DO develop something new.....

Laat die ouwe werkende meuk zn werk doen totdat je iets compleet nieuws er naast hebt wat beter is en minstens net zo betrouwbaar ipv van blijven op te lappen en het ouwe gewoon uit kan... ik heb er van geleerd , scheelde mij een hoop downtime in ieder geval.

"Ik zou zeggen...." Inderdaad, u en ik zijn geen politici die altijd ergens terecht kunnen in het baantjes carrousel en niet afgerekend worden op prestaties.

Leuke long read (zelfs voor een Belg )
https://www.geenstijl.nl/...n-handdruk-van-capgemini/

[SuperDre]

En dat betrouwbaar en beter blijkt toch in heel veel situaties niet te lukken.. Misschien toch iets mis met al die nieuwe frameworks of developers.. Blijf het serieus afvragen waardoor het komt dat die oude systemen die goed draaien zo moeilijk om te zetten zijn naar een nieuw systeem dat ook zo robuust draait.

[Cavelion]

Managers letten altijd op de centen.
Dus is snel snel fixen van een bestaand iets goedkoper. Tijd voor documenteren kreeg je niet, want dat levert niets substantiëels op (volgens die managers).
Resultaat: een klein basisje, waartegen 1000 andere systemen zijn aangebouwd, jaar na jaar.
En niemand weet na al die jaren meer, wat en hoe het werkt. Het werkt perfect. Maar om dit uit te vissen, moet je nu 10 keer meer uitgeven, alvorens je zelfs maar kan herbeginnen aan het schrijven van een nieuw systeem.

En het leuke is dan vaak ook nog, dat ze dan beginnen van, zeg, nu we toch bezig zijn, kunnen we niet beter, dit en dat, zus en zo er bij doen. Dus maak het nog even moeilijker, kan je zelfs de systemen niet meer vergelijken één op één. En het liefst blijven ze specificaties en nieuwe dingen er bij eisen gedurende de loop van het initiële omzetsysteem.

Ondertussen zetten ze er 50 managers op, die natuurlijk ook allemaal hun stempeltje op het project willen drukken. En dan heb je 5 programmeurs die het echte werken mogen doen, aan een schijntje van wat al die managers verdienen. Maar oh oh, IT is toch zo duur.

En zie daar het traditionele recept, waarom steevast al die ICT projecten falen.

[Fluttershy]

Jeetje, wie had dat verwacht?

Een complex en gedateerd systeem dat tijdens een crisis meer resources nodig heeft. Resources met een complexe en gedateerde kennis ook nog1

Nee, dat had niemand aan kunnen zien komen...

[Verwijderd]

Als ze hiervoor een salaris zouden betalen dan zou ik daar echt op reageren. Maar vrijwillig...
De kennis van Cobol is zeldzaam dus daar moet wel wat tegenover staan.
Wij hebben daar ook jaren in geïnvesteerd met werken, cursussen en certificering.
Voor niets gaat de zon op gouverneur.

[SuperDre]

Men zal daar natuurlijk wel gewoon voor betaalt krijgen.

[Verwijderd]

Staat letterlijk in de eerste regel....

De gouverneur van New Jersey vraagt vrijwilligers die in Cobol kunnen programmeren

[SuperDre]

Omdat het vrijwillig is wil nog niet zeggen dat je er geen vergoeding voor krijgt. Ook hier krijgen vrijwillgers vaak genoeg een vergoeding of zelfs loon.

[MrMarcie]

Tegenover vrijwillig staat verplicht. Zo lees ik dat dan weer.

[HollowGamer]

Ik vind het altijd zo frustrerend dat ze echt tig jaren hebben gehad om eindelijk die bakken te vervangen door iets van deze tijd, maar dit vrijwel nooit doen of pas erachter komen als het echt te laat is/ze in de problemen zitten.

Het zou dan ook mooi zijn als politici of werkgevers het toegeven dat ze jarenlang gefaald hebben om het probleem te zien, maar dit vrijwel nooit gebeurd.

Cobol programmeurs verdienen bakken met geld, maar meer doordat deze groep vrijwel is uitgestorven. Leuk dat deze man dus zoekt naar vrijwilligers, maar misschien kan Amerika eens beter voor mensen zorgen en opleidingen bieden voor deze sector. Het stoort mij ontzettend om nu voor vrijwilligers te vragen, terwijl de mensen juist enorm hard worden getroffen en hun rekeningen niet meer kunnen betalen.

[SuperDre]

Vaak probeert men dit ook, maar de nieuwe systemen die dan bedacht zijn blijken gewoon niet goed te werken.

[jeroen3]

Nee, ik dank dat ze niet goed zijn bedacht.

[laserve]

Dit gaat ook nog eens gebeuren met C++ en die taal is niet zomaar met een boekje even aan te leren

[Immutable]

Dat gaat gebeuren met oude C++ denk ik. Moderne C++ ziet er tegenwoordig behoorlijk anders uit. Door alle zero cost abstracties zie je totaal geen C meer terug. Gewoon echt helemaal niks.
Terwijl in het oude C++ heel veel C onderdelen, en oude nu depricated C++ onderdelen gebruikt worden. Ja de moderne C++ compiler ondersteund het nog wel, als legacy. (En dat is ook de kracht van C++) Maar je zult het niet meer tegenkomen in moderne C++ projecten.

Echter is er gigantisch veel oude C++ code op de wereld. En juist die ervaring met oude C++ zal waarschijnlijk waardevol worden in de toekomst.