Revival van de Cobol-krasser, maar is het nodig?

Cobol

Vermoedelijk moest menig (bijna) gepensioneerd ict’er even in de ogen wrijven, maar het stond er echt: ‘De Amerikaanse staat New Jersey is op zoek naar mensen die de stokoude programmeertaal Cobol nog in de vingers hebben.’ Ict’ers die niet zo lang werkzaam zijn in het vakgebied moeten gedacht hebben: Cobol?

Cobol is een programmeertaal die vooral in de jaren zestig opgang maakte en die gebruikt werd in zakelijke omgevingen. Het is de afkorting van Common Business Oriented Language (algemene zakelijk georiënteerde taal). In New Jersey is er nood aan de man en wordt er met spoed naar Cobol-programmeurs gezocht, omdat de mainframe-computers van de overheid de toestroom van werkloosheidsaanvragen naar aanleiding van het coronavirus niet meer aan kunnen.

De ‘Cobol-krassers’ moeten met antieke computers kunnen omgaan; mainframes van meer dan veertig jaar oud. De programmeurs moeten vooral helpen om de toevloed aan werkloosheidsaanvragen in goede banen te leiden. Die zijn sinds de coronacrisis met 1600 procent gestegen.

Het UWV in Nederland heeft (nog) niet te maken met zulke werkloosheidspercentages, maar ook deze overheidsorganisatie werkt met oude systemen. Sterker, zij blijft er langer mee werken, omdat het in 2020 aan ruimte ontbreekt voor innovatie. Als de coronacrisis nog even in Nederland aanhoudt, dan loopt bij ons vermoedelijk de werkloosheid ook wel op. Dat rechtvaardigt de vraag: moeten wij ook de Cobol-krassers uit de mottenballen gaan halen?

x

Om te kunnen beoordelen moet u ingelogd zijn:

Dit artikel delen:

Reacties

De mainframes zelf zijn zeker geen 40 jaar oud. Ze draaien met recente hardware en recente operating systems. Maar de programmatuur die erop draait zal vast wel wat ouder zijn. Immers, voor nieuwe hardware hoef je in een mainframe in het algemeen geen nieuwe software te bouwen. We draaien nog steeds zonder problemen software van meer dan 20 jaar geleden, ondanks dat zijn we in die tijd al verschillende keren gemigreerd naar nieuwere versies van het OS en hardware.

Het overgrote deel van de Fortune 500 bedrijven draaien met mainframes en grote cobol applicaties. De reden is simpel, mainframes kunnen data in grote bulk verwerken. Het is dan vreemd dat juist deze omgeving problemen heeft met de grote hoeveelheid aanvragen.

Ik denk zo dat het probleem van de software meer in de design zit. Als je 1.000 mutaties per dag verwacht en er nu 100.000 per dag krijgt dan zal een tabelletje iets sneller vol lopen. Daarnaast zitten er tegenwoordig veel interfaces naar andere omgevingen, die het dan nu ook flink voor de kiezen krijgen. En dat is wat bijvoorbeeld het unemployment office dan ook nu ziet, ze krijgen meer aanvragen dan ze ooit hebben gezien. Nou, nooit, het is vergelijkbaar met de jaren 30. maar ja, toen bestonden computers nog niet. Dat dan de opzet van applicaties niet goed is heeft dan niks met de taal te maken, of met de leeftijd.

Voor een werkloosheids uitkering hoeft het ook niet zo moeilijk te zijn. Het proces daarvan is in 100 jaar niet echt veranderd. Dus is het vrij logisch dat ook de software daarvoor niet zo vaak aangepast hoeft te worden. (totdat er allemaal uitzonderingen en speciale regelingen moeten worden opgezet.)

Nu ben ik nog niet in de mottenballen beland, maar er lijken twee dingen door elkaar te lopen.

Cobol kunnen programmeren en om kunnen gaan met 40 jaar oude mainframes.

Dat zijn nog wel wat verschillende expertises.

Ik ben mijn IT loopbaan wel begonnen in het mainframe tijdperk, maar heb het vak geleerd op de IBM S36/S38 en de AS/400 als opvolger.

Cobol was één deel van de benodigde vakkennis, maar kennis van OCL, JCL of CL was eveneens onontbeerlijk, die laatste drie zijn echt machine specifiek, evenals de machine specifieke uitbreidingen / implementatie van Cobol-74 zelf.


Op de vraag of we in NL voor het UWV de kennis uit de mottenballen moeten halen, is mijn antwoord: "Dat weet ik niet, en ach, ik ben nog niet te oud om een nieuw kunstje te leren...".


Mainframe is "slechts" een hardware omgeving; Z/OS "slechts" een OS en Cobol "slechts" een taal...allemaal dingen die te leren zijn.

Ik vermoed dat het imago van deze omgevingen eerder een belemmering vormt voor velen. Immers het is "oud", en zeker niet sexy. (terminal sessies, max. 80 karakters op een regel als je met JCL bezig bent (is dat trouwens nog steeds zo?), minder CI/CD of DevOps mogelijkheden).





Nog eentje toe aan alle reacties de kracht van Cobol is dat het uitermate geschikt (leesbaar) is om (financiele) regelgeving in vast te leggen. Doe dat maar eens in andere talen. Al zeg je Cobol dan heb je het al gauw over legacy. Legacy in zin van achterhaald, oud, krakkemikkig en sloom. Niet als bewezen en betrouwbaar. Legacy, het argument om alles weg te mikken en het eens even helemaal anders te doen. Of het 40 jaar oud is dat zegt helemaal niets, ook Cobol gaat met zijn tijd mee. Kijk naar C, nog zo een oude knar, en dat is nog steeds een van de programmeertalen.

Hoorde onlangs het verhaal van een organisatie die weer investeerde in het opleiden van Cobol programmeurs.

@PaVaKe, Ja, JCL is nog steeds 80 karakters.

Minder DevOps ben ik niet per definitie met je eens. Al kun je niet zomaar een willekeurig tooltje uit de kast trekken, maar dat geldt ook niet voor andere platformen.

Al voor 2000 werden onze Cobol programma's op de PC onderhouden. Gewoon in een reguliere PC omgeving (IIRC met microfocus Cobol). Daarvan werd dan een JCL gegenereerd die dan via filetransfer naar het mainframe ging. De output kwam vervolgens weer bij de ontwikkelaar terecht.

Ook in ontwikkeling heeft de tijd niet stil gestaan. Ja, je kunt nog steeds op een terminal sessie in 24x80 je Cobol schrijven maar er zijn vele andere mogelijkheden. Daarbij zie je ook steeds meer initiatieven om de ontwikkel omgevingen te integreren. Wat te denken van een Eclipse omgeving waar naast je PC en mobile ook de mainframe software (al dan niet Cobol) wordt onderhouden. En los van Cobol, ook het mainframe kent Java(script), C en diverse scripting talen.

mooi, ik heb de advertenties alvast bijgewerkt:

Ben jij een ambitieuze full stack cobol developer met passie voor Z/OS en wil je in een ervaren team van toffe collega’s werken aan innovatieve projecten voor verschillende nationale en internationale opdrachtgevers? Dan hebben wij een top baan voor je!
PL1/DL1, mainframe, JCL, IBM S36/S38 zijn voor jou geen onbekende termen.
Samen met je SCRUM team ben je volledig eigenaar van producten en projecten. Jullie zijn gedurende het hele proces betrokken, van product visioning en scoping tot het gezamenlijk verzorgen van demosessies en natuurlijk de feestjes bij oplevering.

@Berry : dank voor de toelichting. Ik ben al weer een tijdje uit de mainframewereld, maar goed te lezen dat de ontwikkeling daar waar mogelijk met de tijd mee is gegaan

De term 'uit mottenballen halen' betekent vooral het mobiliseren van een oproepbare flexibele arbeidsschil en ik ben bang dat daarvan geen sprake is omdat er geen gebrek aan innovatie is maar een tekort aan strategische visie aangaande het onderhoud. Oud-leden lezen lachend 's ochtends de Computable omdat ze 10 jaar geleden te oud voor het 'SCRUM team' waren en daarom wegbezuinigd werden als antwoord op een toen toenemende werkloosheid als gevolg van de 'bedot.com' crisis. De 'Benidorm-brigade' zit niet te wachten op een oproep om opnieuw Cobol te gaan krassen omdat ze niet werkeloos zijn maar gepensioneerd.

Dorus had ooit een liedje over twee motten in zijn oude jas, veel organisaties kunnen hetzelfde zingen met alle bugs in hun platform omdat ze een strategische visie aangaande het onderhoud missen. En het uitbesteden hiervan zorgt voor een contractuele inertie omdat de rode innovatie van de kostenverlaging geen verandering is maar een verschuiving.

Lekker weer COBOL programmeren of krassen zoals we dat vroeger zelf al noemden. Dat had te maken met het feit dat je eerst je programma's moest uitschrijven en dan liet inkloppen door een ponsdame.
IBM Mainframe, S36/38, AS/400, goeie tijden.

Laat ze maar bellen, ik zit klaar (niet tussen de mottenballen!)

@Een oudlid | 8 april 2020 10:44
Iets dat toe is aan onderhoud, heet "legacy" en moet vervangen worden door iets moderns, is de huidige gedachte.

Gert-Jan,
De ponsdame kan ik me niet herinneren, wel het reserveren van tijd voor het compileren van code of testdraaien hiervan. Ook kan ik me de uitbranders nog herinneren naar aanleiding van 'constructiefouten' in de code zoals de tussentijdse I/O instructies wat toen dure operaties waren. Batchverwerkingen zijn nu als vloeken in de SOA kerk maar ze waren efficiënter dan voor elk ingrediënt naar de supermarkt gaan.

Wij hadden een zaal voor ponsdames (oneerbiedig ponspoesen en soms erger genoemd). was maar gedurende een maand of drie daarna konden we zelf de sources inkloppen.
De JCL ging zelfs nog via ponskaarten.
(ben ik oud?)

De ponskaart, papieren telextape enzovoort stamt uit de jaren 70 en was in de jaren 80 zo'n beetje overal door de terminal vervangen. Als je in de jaren 70 al Cobol aan het krassen was dan ben je inderdaad oud want dat is 50 jaar geleden, die generatie ging grotendeels na de mileniumbug met vervroegd pensioen.

Zo oud nou ook weer niet, begonnen in 1980 ;-)

Sinds wanneer zijn S36, S38 en AS400 mainframes?
Toentertijd werden die "mini"-computers genoemd.

Het waren echter fijne machines, stabiel als een huis.

Jan,
IBM poetst met regelmaat oude spulletjes op door ze een nieuwe naam te geven, de AS/400 heet nu iSeries en er zijn nog zo'n 100.000 organisaties wereldwijd die hiervan gebruik maken. Veelal voor hun core processen zoals erp en de financiën want het zijn onveranderlijk stabiele machines. Probleem is dat kennis van het platform zeldzaam wordt omdat de veteranen uit de jaren 80 al met pensioen zijn of op korte termijn met pensioen gaan.

Overdacht van kennis staat niet op de agenda omdat veel managers denken dat ze erp- of financieel systeem wel even naar de cloud kunnen migreren. BV Kansloos is eerder failliet dan succesvol want er zijn vandaag nog altijd meer dan 220 miljard regels aan Cobol code actief omdat de helft van financiële systemen hierop draait. Naast een gebrek aan kennis is de omvang van de 'tech debt' een probleem waar al 5 jaar aandacht voor wordt gevraagd.

Jan, het waren in onze tijd inderdaad mini's of midframes, tegenwoordige soms uitgescholden voor mainframes. Waarschijnlijk een gebrek aan kennis en omdat veel applicaties nu draaien op telefoongrote hardware. ;-)
Het blijven (zeker de iSeries) super stabiele apparaten die foutloos blijven draaien tot je letterlijk de stekker eruit trekt.

Uw reactie

LET OP: U bent niet ingelogd. U kunt als gast reageren maar dan wordt uw reactie pas zichtbaar na goedkeuring door de redactie. Om uw reactie direct geplaatst te krijgen moet u eerst rechtsboven inloggen of u registreren

Vul uw naam in
Vult u een geldig e-mailadres in
Vult u een reactie in
Jaarbeurs b.v. gaat zorgvuldig en veilig om met uw persoonsgegevens. Meer informatie over hoe we omgaan met je data lees je in het privacybeleid
Als u een reactie wilt plaatsen moet u akkoord gaan met de voorwaarden

Stuur dit artikel door

Uw naam ontbreekt
Uw e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
article 2020-04-07T11:09:00.000Z Sander Hulsman
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.