Jag tror inte det är där problemen ligger.
Dels är det så att man inte vill väcka en sovande björn. Systemen fungerar ju, då flyttar man gärna problemet på framtiden. Men med lite eftertanke borde man ju inse att lösningen blir dyrare och dyrare ju längre man väntar. Vid millenniumskiftet har problematiken kommit till medvetande för en del företag och jag har själv varit inblandat med att säkerställa att den gamla koden inte ställde till med otrevligheter. Härvid har det framkommit ett antal problem som ganska snabbt avförde alla tankar om (halv-)automatisk portning till modernare språk etc.
Det första problemet bestod i att i hitta och säkerställa källkoden. Man får komma ihåg att källkoden inte underhölls i en utvecklingsmiljö som idag utan som separata filer med temporärt innehåll och som man snabbt slängde på tape för att spara plats. I en del fall har faktiskt källkoden gått förlorad, antingen genom slarv eller okontrollerade konverteringar av medieformat genom tiderna. Den snabba utveckling på mediaområdet med ideliga byten av medium, standard och format nödvändiggjorde många konverteringar vars resultat inte alltid kontrollerades. Det var inte den gamla källkodsmassan som hade första prioritet då när databaser och annan vital företagsinformation skulle flyttas till nya maskiner, media och format. Detta i synnerhet när man så småningom kunde flytta program i objektform (ej maskinkod) mellan maskiner av samma märke (IBM) för att garantera driftskontinuitet vid övergången. Det blev faktiskt en chock för många datachefer som naturligtvis genast tystade ner denna obehagliga upptäckt.
I de fall det fanns gamla media att tillgå (tape) fanns ofta inte den gamla utrustningen att uppbringa som kunde montera de ålderdomliga tapen och läsa dess innehåll. Man får komma ihåg att det fanns mängder med specialformat då och standardisering inte var så långt framskriden som idag.
En ytterligare orsak för källkodens bortfall var att efterföljande driftsansvariga och systemförvaltare (ja, det var dåtidens dödgrävarjobb) mer och mer ansåg att denna funktionalitet ingick som en del i operativsystemet, i synnerhet när det gällde funktionsbibliotek (med t.ex. hantering av datum etc.).
Det var många lik som kom till ytan och om jag är ärlig tror jag att upp till 20 % av källkoden är borta eller kan inte återställas utan vidare.
Det andra stora problemet utgörs av det faktum att den gamla koden ofta är inbunden i ett transaktionskontext. Dåtidens transaktionshanterarna var i början handskrivna och blev sedan mer och mer del av stordatorns operativsystem. De är som tunga kvarnar som betjänar funktioner med ett väldigt specifikt interface. De skiljer sig väldigt mycket ifrån traditionell procedurell logik och är raka motsatsen till interaktiva program. Det är bl.a. bristen på CPU-kraft som nödvändiggjorde en hel annan programmeringsteknik och unga programmerare idag har svårt att första hur man kan föra en komplex dialog med användare och databaser med hjälp av en kommunikationsyta på t.ex. 120 tecken. Och då inte med kontinuerlig kontakt med CPU utan bara ett litet tidsfragment eftersom datorn var upptagen med att serva även 1000-tals andra funktioner som alla ombesörjde sin egen återställning av minnesareor och transaktionsstatus. En hel del kod gick åt at hantera undantagssituationer som idag är automatiserade som ”Rollback” och ”Recovery” av transaktioner och databas. Allt denna funktionalitet finns kvar även idag, men djupt inne i operativsystemet resp. databassystemet.
Det tredje problemet är att många funktioner har med tiden blivit inkapslade med nytt interface utåt i många lager. Det är som en arkeologisk utgrävning med många skikt som representerar tidsålder och tillhörande teknik. Det känns meningslöst att enbart konvertera den innersta kärnan och har kvar alla lager av osynligt manipulerande och implicit logik. Inkapslingen och det logiska sambandet sker också gruppvis vilket gör det svårt att bryta ut enskilda element.
Det fjärde problemet är enklast att beskriva med italienarnas välkända nationalrätt: spaghetti. Allt hänger ihop i en salig röra. Kom ihåg att alla koncept till strukturering inte var utvecklade än och i den mån de fanns var de på sin höjd eftersträvade men aldrig tekniskt bindande. Första prioritet var alltid prestanda pga. bristen på CPU och minne. Rör man på ett ställe kan det få oöverskådliga konsekvenser. Så de är nog bättre att inte röra i det då.
Just nu har ingen aning hur man kommer att lösa problemet COBOL på längre sikt. Jag tror dock att man får invänta en ny generation av intelligenta maskiner som automatiskt designar, utvecklar och kodar sina egna program och som kan lära sig (artificiell intelligens). Om något årtionde är vi där och COBOL och andra kvarlevor från en svunnen tid som tex alla programmerare kan få en värdig begravning.
Tills dess gäller: Döda språk lever längre…
Mvh
//Singha711
Bra inlägg och du har naturligtvis rätt i din beskrivning av de problem som förekommer vid
överföring av äldre system till modernare miljöer.
Jag var lite väl simplifierande i mitt inlägg om att porta system.
Jag avsåg de fall man hade access till källkod och dokumenterade systembeskrivningar.
Eller i de fall man kan dekompilera kod med godtagbart resultat.
Men det finns naturligtvis massor av lägen där detta inte tillåter sig göras med tillräcklig
precision/säkerhet rätt av. Precis som du skriver.
