Michael JohnsonDet går att flytta ett COBOL-program till ett modernt språk och bevara syntaxen, men samtidigt ändra reglerna för hur belopp beräknas. OpenAI ägnade ett inlägg den 19 oktober åt just detta problem: företaget redovisade resultat för sina modeller på programmeringstester i COBOL, Fortran och andra språk med mindre mängder träningsmaterial och öppnade testuppsättningen MultiLangBench.
För team som underhåller äldre affärssystem ligger nyhetsvärdet inte bara i de redovisade procentsiffrorna, utan också i två olika typer av tester. Det ena bedömer hur program skapas från grunden i olika språk; det andra kontrollerar om en COBOL-migrering bevarar det observerbara beteendet. Uppgifterna kräver olika tester och har olika koppling till risken vid driftsättning.
Två tester – två tekniska uppgifter
I MultiLangBench ska modellen skapa en SQLite-kompatibel motor som tar emot frågor och ändrar en databasfil. OpenAI redovisar den genomsnittliga andelen godkända tester för 20 språk: GPT‑6 Astra fick 87,4 procent med den högsta nivån av resonemang, medan GPT‑5.6 Sol fick 26,8 procent. Varje implementation kontrolleras mot det förväntade databasresultatet; även körtid och API-kostnad utvärderas.
Företaget har publicerat MultiLangBench på GitHub, inklusive testinfrastrukturen. Det publicerade arkivet beskriver tester som skapats utifrån SQLite TCL Tests och reglerna för att kontrollera resultaten. Det gör det möjligt för utvecklare att granska vilka operationer som ingår i bedömningen och sedan upprepa den med sin egen modellkonfiguration.
COBOL-migreringen prövar en annan förmåga: att skriva om ett befintligt program i C++, Java, Kotlin, Python eller Rust och bevara dess beteende i dolda tester. OpenAI redovisar 86,6 procents träffsäkerhet för GPT‑6.1 Sol med låg resonemangsnivå, jämfört med 5,4 procent för GPT‑5.6 Sol i samma läge. Med en högre resonemangsnivå når GPT‑6.1 Sol 97,9 procent i den här utvärderingen.
Varför migrering kräver kontroll av affärsregler
OpenAI framhåller i sin beskrivning att kompatibilitet beror på källspråkets semantik. COBOL:s fasta aritmetik kastar till exempel bort överflödiga decimaler om avrundning inte har angetts uttryckligen. Om den nya implementationen avrundar annorlunda kan programmet köras utan problem men ändå ge andra finansiella resultat.
Kriteriet i migreringstestet är därför att utdata ska stämma överens för de testade fallen, medan teamets praktiska kriterier också bör omfatta de egna beräkningsreglerna, dataformatet och systemets beroenden. Ett bra första steg är att välja en modul med tydliga in- och utdata, fastställa referensresultat för verkliga gränsfall och köra originalversionen och den omskrivna versionen parallellt.
Vad resultaten innebär för teamen
OpenAI:s siffror gäller de publicerade testuppsättningarna och inställningarna för resonemang. MultiLangBench utvärderar skapandet av en SQLite-kompatibel implementation, medan COBOL-testuppsättningen mäter om beteendet bevaras vid migrering; resultaten beskriver dessa specifika tester. För team ger de en riktlinje när modeller ska väljas och en grund för egna reproducerbara jämförelser, men inte en färdig bedömning av kompatibiliteten med vilket produktionssystem som helst.
Den praktiska slutsatsen är enkel: testa modeller på den egna koden och med egna kontrollfall, och väg in kostnaden tillsammans med hur ofta uppgifterna lyckas. Vid modernisering av COBOL är det särskilt viktigt att kontrollera avrundning, saknade poster och andra regler som är inbyggda i det gamla programmets beteende. De nya resultaten gör sådana tester mer tillgängliga, men ansvaret för att bekräfta likvärdighet är fortfarande en del av utvecklingsarbetet.