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?
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 24×80 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.