IBM introduceert AI-model watsonx voor vertalen oude Cobol-code op Z-mainframes

IBM introduceert zijn AI-codeassistent watsonx Code Assistant for Z. Dit AI-model moet gebruikers helpen bij het omzetten van Cobol-code naar Java op hun IBM Z-mainframes. Het model komt in het laatste kwartaal van 2023 beschikbaar.

Watsonx Code Assistant for Z is een nieuwe toevoeging aan het watsonx-AI-platform, dat IBM in mei al introduceerde, schrijft het bedrijf in een persbericht. Met de nieuwe versie komt de codeassistent ook beschikbaar voor IBM's Z-mainframes. Dit moet het volgens IBM makkelijker maken voor ontwikkelaars om de applicaties op basis van ouderwetse Cobol-code op hun mainframes 'selectief en stapsgewijs' te moderniseren naar Java.

Cobol staat voor Common Business Oriented Language en deze programmeertaal voor zakelijke toepassingen stamt uit 1959. Met name op IBM-systemen zijn nog altijd bedrijfskritische applicaties in gebruik die geschreven zijn in die taal. IBM zegt tegen onder meer VentureBeat dat ongeveer 84 procent van zijn mainframeklanten Cobol-applicaties draait. Er zijn echter steeds minder ontwikkelaars die bekend zijn met Cobol en daarom kan het lastig zijn om die code te onderhouden. Met het watsonx-model kunnen bedrijven gaandeweg overstappen op modernere en makkelijker leesbare Java-code.

Het model werkt niet door Cobol-syntax regel voor regel om te zetten naar Java, vertelt IBM-cto Kyle Chartet aan media, waaronder VentureBeat. Dat zou de code volgens IBM nagenoeg onleesbaar en lastig te onderhouden maken. In plaats daarvan zoekt het model de intentie van de Cobol-code uit en wordt die omgezet naar reguliere Java-code met dezelfde functionaliteit. De inputs en outputs van de code worden na het genereren gevalideerd; eventuele 'hallucinaties' van het model moeten daarbij gemakkelijk worden opgemerkt, aangezien de code dan niet naar behoren werkt.

De watsonx Code Assistant for Z komt later dit jaar beschikbaar voor IBM's Z-mainframes. Dat moet gebeuren in het laatste kwartaal. Een concrete releasedatum is er nog niet. Gaandeweg wordt de assistent uitgebreid met extra functionaliteit, zegt het bedrijf.

Een videodemonstratie van IBM's watsonx Code Assistant for Z

Reacties (42)

[thomas_n]

De inputs en outputs van de code worden na het genereren gevalideerd; eventuele 'hallucinaties' van het model moeten daarbij gemakkelijk worden opgemerkt, aangezien de code dan niet naar behoren werkt.

Dit lijkt me in de praktijk complexer liggen. Wat als de code naar behoren werkt, behalve in onvoorziene omstandigheden? Voor "bedrijfskritische applicaties" vraag ik me af of dit betrouwbaar genoeg is. Zeker als men gewend is te werken met cobol-applicaties die al decennia betrouwbaar hun werk doen.

[latka]

In theorie als je alle input/outputs valideert is er geen onvoorzien gedrag over. In de praktijk is het probleem dat honderden inputs betekenen dat er meer toestanden van de software zijn dan atomen in het heelal.
Dus ik denk dat er nog handmatig testen bijkomt. Dat er noodzaak is voor een oplossing als deze is wel duidelijk: cobol word op geen enkele school aangeleerd zover ik weet.

[this]

Ik weet alleszins een hogeschool in België waar dit nog aangeleerd wordt.

[dasiro]

ik heb in m'n eerste jaar in 2002 in elk geval Cobol gekregen (toen Hogeschool Antwerpen, een paar keer gefuseerd/hernoemd tot tegenwoordig AP). Niet dat ik er nog iets mee heb gedaan of onthouden, buiten het feit dat een simpele ontbrekende punt aan het einde van je code ervoor kan zorgen dat ze helemaal niets doet

[kristofv]

Op KdG krijg je inderdaad nog een , beperkte, inleiding omtrent mainframes en programmeren ervoor.

Aangeleerd worden is wel een groot woord als je die school bedoelt, het is bijlange niet zo dat je met die kennis opeens een mainframe kan gaan supporteren/ productie code schrijven voor.

[this]

Uiteindelijk is dat ook maar wat je nodig hebt, het meeste leer je on the job.
En ik had het op HoGent. Mainframes was een keuzerichting in het 3e, maar COBOL kreeg je wel al eerder.

[Vaevictis_]

Dat klopt natuurlijk niet dat je 10x met de input de juiste output krijgt is geen garantie dat het de 11e keer ook hetzelfde resultaat eruit komt. Op unit niveau is dit anders dan op bedrijfsproces niveau, daar zit meer afhankelijkheid en complexiteit is. Er kan juist wel onvoorzien gedrag optreden. Ik denk dat je het meer moet zien als hulpmiddel voor een ervaren Java coder die weet hoe de applicatie zich hoort te gedragen.

[latka]

Lees even na over model checking. bedrijfsproces/state is een onderdeel van de test. Het werkt zeker wel en gebeurt al op grote schaal voor verificatie doeleinden.

[Prince]

Ik denk niet dat je deze evolutie moet bekijken als een "shoot and forget" soort van ding.
Net als bij de meeste zaken is dit een super volledig startpunt om code te migreren; 99% van het initiële codeer-werk is gedaan.
Natuurlijk moeten er nadien nog tests gebeuren, net als bij elke code-aanpassing.

[2green]

Inderdaad. Wat je in de praktijk ziet is dat ze het model herhaaldelijk aanpassen om inderdaad bij die 99% in de buurt te komen. En ergens rond dat punt neemt de hoeveelheid werk aan de conversie-tool toe in relatie tot de overige bugs in de opgeleverde code (java) te verhelpen.

[scholtnp]

Inderdaad, dit lijkt me vragen om problemen: out of index arrays, double free of pointers en ga zo naar door. Zet AI dan echt aan het werk en schrijf het gelijk in Rust. En maak een oneindige berg testcases die je eerst op de Cobol code afvuurt en daarna op je nieuwe programma. Zolang er verschillen zijn ga je dat niet in productie draaien.

[aikebah]

double free of pointers

Knappe AI die dat in java code voor elkaar weet te krijgen.

[Verwijderd]

Rust zit nog niet op het niveau van Java

[thabasement]

Ja dat is precies wat ik ook dacht. Je kan wellicht met een groot statistisch model (a.k.a. AI) wel een inschatting maken van de intentie van de code, maar meer ook niet. Dit zal naar mijn mening nooit zonder controle van mensen achteraf kunnen, tenzij de code vanaf de grond af aan volledig gegenereerd is door een soortgelijk model.

[ceesiebo1]

30 jaar geleden begonnen als Cobol programmeur, maar dat was ik na 12 jaar wel zat. Mijn Java leraar zei vroeger: Java is het nieuwe Cobol. Komt nu wel heel dichtbij met dit tool :-). Gaat wel ten koste van mijn pensioenvoorziening. Ik zou de laatste paar jaar best nog wel flink wat geld willen ophalen om door wat Cobol programmatuur te gaan.

[pauldaytona]

Nou voorlopig is het nog niet klaar, dus tot je pensioen kan je best nog aan de slag. Ben ik blij dat ik al met pensieon ben.

[CrazyBernie]

Las laatst dat uitfasering cobol nog wel zo’n 30 jaar gaat duren. Dus denk dat je pensioen voorziening wel goed zit hoor.

Achteraf gezien was cobol gewoon een heel goede taal in combinatie met de ibm mainframes om stabiel transactie en data processing applicaties mee te ontwikkelen.

[david-v]

Hoezo achteraf? Cobol is een taal van 1960 die als doel had makkelijk te leren en zeer snel met (enorme) gegevensbestanden en batchverwerking en dan vooral in de context van een zaak/business. Daarom zie je die taal bij veel banken bijvoorbeeld. Fortran had je toen ook, maar minder geschikt voor dergelijke verwerkingen. Dat het nu nog steeds gebruikt wordt is dan het bewijs dat de taal al vanaf het begin goed was in waar het voor bedoeld was. Maar...ik denk wel dat dit success niet zo zeer te maken had met de taal zelf maar met IBM die werkelijk overal die mainframes binnen kreeg, er was ook niet veel anders...

[CrazyBernie]

Je hebt gelijk achteraf is de verkeerde term.

Ik bedoelde het vanuit de context dat er nu al decennia gesproken wordt over het uitfaseren van cobol(heb zelf ook in het verleden met die projecten te maken gehad) omdat er betere alternatieven zouden zijn.

[ArcticWolf]

Doet mij denken aan een verhaaltje op FB van een Cobol programmeur een paar jaar geleden, een bedrijf zocht Cobol programmeurs en die HR medewerker had er totaal geen benul van en snapte er niks van toen er allemaal 60 jarige op gesprek kwamen

[k995]

Hey als 44 jarige ken ik ook nog Cobol, we zijn niet allemaal 60 .

[-Vasa-]

De horror van op het BME Gent een doosje met diskettes te krijgen van de docent dat we dan moesten kopiëren met compiler...
En de examens op codeer-bladen waar maar 5 regels werden voorbehouden voor correcties en we achteraf dan de regelnummers moesten bijschrijven ...

[k995]

Kdg antwerpen hier , en ja de code uitschrijven op papier was een horror.

[ikwilwp8]

Dat moesten wij een jaar of 8 geleden ook nog in Amsterdam, althans, kleine stukken code. Dwingt je wel tot nadenken

[StGermain]

57 hier, wat had ik er een hekel aan…

[Atlantis1995]

Hier een 51-jarige. Ik heb het ook nog geleerd. Cobol 85 voor een Tandem Non-stop systeem.

[merethan]

Shite! Ik had Cobol als backup plan: Mocht ik snel geld nodig hebben dan duik ik een paar weken in de Cobol boeken die ik van mijn Opa heb gehad, daarna baangarantie met goed salaris.

Helaas/gelukkig is dat plan nu wat meer op losse schroeven gekomen

[CPV]

Cobol is geen BASIC, dat leer je niet in een paar weekjes.

[DjoeC]

De taal is het vehikel, het gaat erom of je het probleem in logische stukjes kunt opknippen (denk Volmac VSP). Als je dat kunt is het uitschrijven in een taal, zij het Cobol of bijvoorbeeld Python, zo gepiept.

Houdt er wel rekening mee dat als je met Cobol aan de slag gaat die taal maar een deel van de oplossing biedt. Er komt vaak ook nog CICS, DB2, JCL en allerlei andere kennis bij kijken. Een goeie Cobolaar is een all-rounder, niet zoals een Javvan die tegen frameworkjes aanpraat en daarmee wel werkende maar zelden efficiente oplossingen aflevert.

Wil je ook "leuke" constructies gebruiken dan is grondige kennis van de taal - welke dan ook - wel wenselijk.

[pepijntb]

Waarom niet direct naar Kotlin? Mooie moderne taal en waardige Java opvolger mijns inziens.

[david-v]

Tja, IBM en een moderne programmeertaal zoals kotlin (is dat niet vooral voor apps?).

Ik denk dat het hier door komt

[Cafe Del Mar]

Het is maar de vraag of het kopen van deze tool en nadien het testen, corrigeren en herschrijven van de "vertaalde Cobol" een betere investering is dan een migratietraject op te zetten richting "native" Java, met alle gewijzigde infra die erbij hoort.
Ben je zo zeker dat alle logica die er als koterij bijgebouwd is de laatste 30 jaar ook echt relevant is om te laten "vertalen" met deze AI-tool? Kan je niet beter uw business teams bevragen wat ze vandaag nodig hebben en dat bouwen in Java?

[overhyped]

Veel oude mainframe applicaties draaien al decennia, en moeten nog decennnia door. Oude pensioen polissen, of levensverzekeringen bijvoorbeeld. 1 keer peer maand komt er batch uit die wat journaalposten in de boekhouding aanpast en wat bank opdrachten verstuurt.

Die staan nu in de ‘uitsterf’ modus, zo goedkoop mogelijk in leven houden tot de laatste polis afgelopen is, er zijn dus waarschijnlijk geen business teams die hier een mening over hebben, die zijn bezig met hun nieuwe producten. Als een bedrijf als IBM dan een garantie kan geven, mischien zelfs in een BPO model, dat de kosten per polis voor de komende 20 jaar met centen omlaag kunnen is dat een mooie business case.

[CPV]

Nou, ik denk dat het businessmodel ergens anders ligt.

Als deze applicaties al decennia draaien en niet meer gemodificeerd hoeven te worden, is er geen reden om er iets aan te doen.

Het wordt anders als het draaien van de applicaties een probleem wordt, omdat de Z-systemen uitgefaseerd gaan/moeten worden.
In het filmpje is te zien dat de voorbeeld-CICSapplicatie niet alleen COBOL draait, maar ook DB2 als database heeft. Hiermee zit je aan je Z-mainframe vast, wat duur is om dit aan te houden als dit door steeds minder applicaties gebruikt wordt.
Dan zou overzetten naar een ander platform, dus met een andere programmeertaal en een ander databasesysteem waardevol zijn.

[overhyped]

Zeker ook een valide case! Al gaat Z de k ik langer leven als iemand hier op tweakers

[CPV]

Ja, Z-systemen zullen blijven, maar het aantal wordt kleiner, maar meer in gebruik bij organisaties die de kracht en efficiency van deze systemen kunnen gebruiken.

Ik herinner me nog een Gartner rapport van 5 - 10 jaar geleden, dat meldde dat 90% van de TOP500 bedrijven op Z-systemen draait en dat 98% van de TOP500 transacties op Z-systemen uitgevoerd worden.

Ik weet nog dat het kleinste z-mainframe voor ons al te groot was. Via MLC, CMP en SCRT waren de kosten nog in de hand te houden, maar het tij was niet meer te keren. Via het IBM-MAIN forum kregen we regelmatig weer de melding: another one kicked the dust.

Toch een droevig gevoel na een systeemprogrammeurs-carrière van SVS via MVS naar z/OS.

[Kalief]

Mag de Belastingdienst oren naar hebben.

https://werken.belastingd...back-to-basic-met-cobol-6

[DropjesLover]

Hoe of op wiens data is deze AI gebaseerd? Want je moet hem voorbeelden geven van Cobol applicaties en hun correcte Java tegenhanger.

[SillieWous]

Gokje: op data van IBM.
Neem aan dat ze als een pionier in de computer wereld genoeg legacy/oude applicaties hebben. Die hebben ze dan omgezet in Java en voila.

[david-v]

Aangezien cobol en IBM mainframe redelijk 1 op 1 relatie hebben vermoed ik dat het vooral code is van IBM zelf waar de AI op getraind is

[wimdebok]

Er zijn twee dingen waar ik benieuwd naar ben, performance and leesbaarheid. Cobol staat bekend om zijn leesbaarheid en om zijn performance. Wat moet ik me daarbij voorstellen bij het vertalen naar Java? Herschreven code, dan lijkt het me niet om leesbaarheid te gaan. Hoe zit het dan met de performance?

Herinner me Java programma's die ik heb moeten beheren, dat viel niet mee kwa performance en gebruik van resources. Aan de andere kant gewerkt met elastic en ik was verbaasd over performance.

Zou het dan niet verstandiger zijn om te investeren in Cobol programmeurs. En mensen de tijd geven om zich de code eigen te maken Een LOI cursus?

Is het niet altijd zo: vandaag werken aan de legacy van morgen? Continuiteit helpt.

[Reactie gewijzigd door wimdebok op 22 juli 2024 19:38]

[SuperDre]

Ugh, naar Java.. niet heel veel beter dan Cobol