Færøsk migrering med kultursammenstød og timestamp-problemer

Pointen er at en kodebase hvor der er spredt GOTO statements ud over det hele, hvor der er globale variable i stor stil, etc. ikke er en moderne kodebase.

Der er trods alt begræsningener på hvordan GOTO kan bruges i C#, og tilgang til globale variable kan krydsrefereres – så du har muligheder for at ræssonere om kodebasen.

Jeg ville have skrevet en PL/1 fortolker til .Net. Dygtige/middelgode softwareudviklere kan nemt lære et nyt sprog og gamle sprog/udviklingsmiljøer har typisk et relativt lille medfølgende library. Dette kunne nemt implementeres i C# og de har alligevel lavet det for at få koden til at køre. Det er typisk ikke sproget der er det svære at lære - det er hele det "standard library" der kommer med der tager tiden.

Men du skal også tænke på muligheden for at få ny arbejdskraft. "Lær et uddødt sprog, og bliv ved med at videreudvikle i det" tiltrækker nok udelukkende folk der tænker i job security. "Vær med til at bringe en legacy kodebase ind i det nye årtusind, og du kan trods alt bruge de sprogfeatures du er vandt til" sælger nok, trods alt, en del bedre :-)

Der er nu en kodebase i et moderne, statisk og typestærkt sprog, hvor der (med mindre de har lavet noget virkeligt dirty magi i konverteringen) nemt kan trackes referencer, laves refactoring og så videre.

Pointen er at en kodebase hvor der er spredt GOTO statements ud over det hele, hvor der er globale variable i stor stil, etc. ikke er en moderne kodebase. Uanset sprog. Det ligner det bare på overfladen.

Forhåbentligt er der også blevet oprettet et stærkt korpus af automatiske test.

Det ville være interessant at høre hvad de har gjort, men det er altid meget svært at putte automatisk test på gammel kode som ikke er designet til samme. Jeg har gennem årene set rigtigt mange ressourcer blive brugt på at forsøge at hælde magisk test-sovs ud over gammel kode uden at det gav det helt store.

Selv hvis man ikke beslutter sig for at / har held med at omskrive til grundlæggende mere moderne kodebase, er forudsætningerne da klart bedre end at snuble videre med mainframe og PL/1 :)

Jeg ville have skrevet en PL/1 fortolker til .Net. Dygtige/middelgode softwareudviklere kan nemt lære et nyt sprog og gamle sprog/udviklingsmiljøer har typisk et relativt lille medfølgende library. Dette kunne nemt implementeres i C# og de har alligevel lavet det for at få koden til at køre. Det er typisk ikke sproget der er det svære at lære - det er hele det "standard library" der kommer med der tager tiden.

Jeg er mere skeptisk over hvor brugbar og "videreudviklingsvenlig" den konverterede kode er. Dette ville være fantastisk at se nogle større kode-snippets. Men diskussionen om GOTO (i faktaboksen) viser klart problemerne ved at konvertere fra PL/1 til mederne sprog.

Der er nu en kodebase i et moderne, statisk og typestærkt sprog, hvor der (med mindre de har lavet noget virkeligt dirty magi i konverteringen) nemt kan trackes referencer, laves refactoring og så videre. Forhåbentligt er der også blevet oprettet et stærkt korpus af automatiske test.

Selv hvis man ikke beslutter sig for at / har held med at omskrive til grundlæggende mere moderne kodebase, er forudsætningerne da klart bedre end at snuble videre med mainframe og PL/1 :)

C#/.NET har en fantastisk generics feature (som er uendeligt meget bedre end den i Java) ...

Hvad gør I på det nye systemet? Bruger I VMWare, HyperV eller lignende til fejlover for at håndtere hardware fejl og opdateringer?

Det nye miljø køre i wm ware, Elektron har eget hosting center og hoster servere for andre virksomheder og institutioner. Dette miljø er spejlet.

Med .net 5 vil vores "windows main frame" miljø sikkert kunne flyttes til docker og kubernetes så det er inde i overvejelserne.

Interessant at man i den grad kan omprioriterer sin tekniske gæld, og samtidigt belåne lidt af friværdien :)

Jeg er udvikler på Elektron og er kommet til sidst i forløbet og har gjort mig de samme overvejeler som der skrives om her i kommentarerne. Jeg er dog nået frem til at migreringen var den rigtige løsning.

Den første udfordring vi har stået over for har været det med at vedligeholde kode i PL/1, der kommer ikke lige folk ind fra gaden i dag og har disse kompetencer. Men det er ikke kun programmering, det er også drift af Main frame, der har været en udfordring. Ved at skifte over til c# + windows miljø er vi inhouse gået fra ca 10 ansatte (alle 55+) til ca 30 ansatte, der kan programmere og drive løsningerne. Selv om koden ser lidt mærkelig ud, er den ikke umulig at forstå og den virker!!!.

Selv om Main framen var fra 2008, så var den ikke hurtig. Svartiderne på kald til Main frame backend lå før migrering på gennemsnitligt på 4-6 sekunder, efter migrering gennemføres 75% af alle kald på under 700 millisekunder. Skulle de svartider forbedres på main framen ville det kræve dyre opgraderinger. Prisen for migrering er tilbagebetalt inden for ganske få år i forhold til omkostninger til evt. main frame opgradering og licensbesparelser.

Der er ingen tvivl om, at det rigtige er at kode systemerne om, men det vil tage mange år, hvor der skulle køres parallelt på Main frame og ny platform, hvis der ikke var migreret. Vi er nu i gang med at forberede en ny platform til nyudvikling, der kan sameksistere med den migrerede platform og det er betragteligt nemmere at få til at lykkes i forhold til at skulle lave en ny platform, der skulle sameksistere med en main frame platform.

Man må håbe at de får adskildt database, API og bruger applikationer fornuftigt.

PL1 programmering på mainframe er meget anderledes end moderne systemer i cloud, microservices mm, så den nye platform vil blive helt anderledes, end det vi kommer fra. Jeg er så heldig at være med til at forberede den arkitektur, hvilket er en spændende udfordring :-)

Opdagede lige at denne artikel åbenbart er en af de nye vi-skal-profilere-dig-endnu-mere artikler.

Jeg har ikke set det før, da jeg har været logget ind på min arbejdspc, men da jeg lige skulle checke på en tablet, fandt jeg ud af det.

Jeg ved ikke hvad man havde forestillet sig, men jeg gider altså ikke logge ind på V2 via en telefon eller en tablet, så hvis man tror at man får mere loyale brugere på den måde, så er der vist noget man har fået helt galt fat i.

Suk!

Det er helt ufatteligt hvad man kunne finde på af håbløse ting i det sidste årtusinde

Efter at have udført en række code reviews, kan jeg roligt sige det samme om indeværende årtusinde :)

Jeg tror, der snarere skal en while-løkke til i den inderste for at bevare goto-logikken.

Eftersom vi kun skal ud af den inderste for-løkke, er der ingen grund til at bruge goto eller omskrive noget her. Den idiomatiske måde at stoppe løkken i C# er blot en break.

de to for-løkker kan omskrives til

for(int j = 1; j <= 10; j++)  
{  
   int i = 30;
   while (i >= 1 && (/* betingelsen */) )
   {  
       // resten som i eksemplet.  
       i--;
   }  
}

Eksempelvis vil jeg tro de to for-løkker kan omskrives til:

Jo ... men skal det overhovedet være for-løkker? C# har iterators. Eller skal data overhovedet ligge i arrays (jeg går ud fra at det er arrays)? Det ligner noget som kunne ligge fint i et HashMap/Dictionary. Og det der mystiske med BuiltIn.Substr ... burde det hele ikke være et metode på LYKYL-klassen? Ovenstående er småting. Baseret på hvad vi kan se ud af 5 linjer kode.

I lidt større perspektiv: nu kører koden i et objekt-orienteret miljø. Hvordan udnytter koden samme? C#/.NET har en fantastisk generics feature (som er uendeligt meget bedre end den i Java) ... hvordan er det brugt til at sikre kodegenbrug?

Og hvis vi zoomer endnu mere ud: Hvad med Microservices, SOA og alle de andre buzzwords der basalt dækker over at lave distribuerede systemer? Vi kunne fortsætte ...

... som viser at den konverterede kode bibeholder det abstraktionsniveau man havde med PL/1 (men på en markant grimmere måde). Der er så mange ting man ville skrive anderledes og mere læseligt hvis koden var native C# kode.

Jeg er helt enig i at koden kunne godt bruge en omskrivning til ren C#, men jeg tror desværre at dette projekt er mindst lige så omfattende, som konverteringen fra PL/1 til C#.

Der er dog nogle dele der er lettere at oversætte end andre dele.

Eksempelvis vil jeg tro de to for-løkker kan omskrives til:

for(int j = 1; j <= 10; j++)
{
   for(int i=30; i >= 1; i--)
   {
       // resten som i eksemplet.
   }
}

... men hjælper dette på læsbarheden på koden? Ville det ikke være bedre at loope imellem veldefinerede konstanter?

Og så er der navnene på variablerne: LYK, TAINCLYK, LYKIL.

Her gætter jeg på at man skal være færing, før de giver mening. :-)

Tak for en spændende serie, hvor der også bliver fortalt om problemer, og konkrete løsninger. Absolut et projekt for de modige :)

Hvordan ser løsning ud fysisk? Jeg forstod at hele løsningen kørte på én mainframe, som er købt i 2008. Og at resultatet kører på 45 Windows maskiner, som er købt løbende de 6 år hvor systemet er udviklet. Umiddelbart lyder det som om systemet fysisk fylder ca. det samme.

Hvordan ser det ud med oppe tid? En mainframe er kendt for at have god tollerance for hardware fejl, sådan at softwaren ikke bliver berørt af det. Og derfor tager mainframe udviklerne heller ikke højde for hardware fejl. Hvad gør I på det nye systemet? Bruger I VMWare, HyperV eller lignende til fejlover for at håndtere hardware fejl og opdateringer? Fordi softwaren tager vil stadig ikke højde for at en maskine kan være nede?

Det store spørgsmål er hvad målet med projektet var:</p>
<p>Var det at reducere licensomkostningerne?
Var det at få et mere moderne udviklingsmiljø og afviklingsplatform, hvor man så kan arbejde videre på koden?

Jeg håber næste skridt er at omskrive de enkelte applikationer til rigtig C#. Ikke fil for fil, men applikation for applikation.

Åh nej. Det er grunden til at man skal holde sig langt væk fra at konvertere gamle systemer med mindre kunden i praksis giver en blankocheck på opgaven: Det er helt ufatteligt hvad man kunne finde på af håbløse ting i det sidste årtusinde</p>
<blockquote>
<p>Løsningen bliver at lægge kunstige forsinkelser ind i systemerne</p>
</blockquote>
<p>Hahahaa. Jeg gætter på, at vi om ca. 30 år læser stort set den samme historie igen

Det store spørgsmål er hvad målet med projektet var:

• Var det at reducere licensomkostningerne?
• Var det at få et mere moderne udviklingsmiljø og afviklingsplatform, hvor man så kan arbejde videre på koden?

Der er ingen tvivl om at dette reducerer licensomkostningerne. Jeg er mere skeptisk over hvor brugbar og "videreudviklingsvenlig" den konverterede kode er. Dette ville være fantastisk at se nogle større kode-snippets. Men diskussionen om GOTO (i faktaboksen) viser klart problemerne ved at konvertere fra PL/1 til mederne sprog. Ingen skriver i dag kode med GOTO statements.

Der er også denne snippet fra artiklen ...s3_do_leave.png

... som viser at den konverterede kode bibeholder det abstraktionsniveau man havde med PL/1 (men på en markant grimmere måde). Der er så mange ting man ville skrive anderledes og mere læseligt hvis koden var native C# kode.

På sigt vil det gøre koden svær at videreudvikle. Vi kommer sikkert til at høre historier om få år om at der nu skal bruges 4 gange så mange udviklere for at vedligeholde systemerne. Jeg håber næste skridt er at omskrive de enkelte applikationer til rigtig C#. Ikke fil for fil, men applikation for applikation. Med fornuftige opdelinger mellem applikationer. Med veldefinerede interfaces. Etc. etc. Men jeg gætter på at alle nu sætter sig ned og vedligeholder C# koden i dens nuværende form de næste 30 år.

Måske er det også det rette forventningsniveau. Færøerne har deres egne love og regler hvilket medfører at meget/alt skal laves specielt til Færørerne. Og givet at der kun bor 50.000 borgere på færøerne med tilhørende begrænsede skattegrundlag, så bør forventningerne også være derefter.

Interessant at man i den grad kan omprioriterer sin tekniske gæld, og samtidigt belåne lidt af friværdien :)</p>
<p>Det er nok billigere at finde en bunke C# programmørere, frisk fra fad, til at rette i kodebase. Så kan den måske nå at blive pæn og fejlfri, til næste gang, deres vendor-lock-in, bliver et problem.

For når nu man har så komplekst et skattesystem, ville det så ikke være en overvejelse værd at lave en radikal skattereform - altså træde et skridt tilbage og se på hvordan man drastisk simplificerer systemet, i stedet for at fortsætte med at tro at jo mere magisk IT sovs man hælder ud af flasken des bedre.

New Zealand lavede manøvren i 80'erne, hvor man var sovset ind i et bureaukratisk, men så lagde om til et meget simplere (og effektivere) skattesystem.

Interessant at man i den grad kan omprioriterer sin tekniske gæld, og samtidigt belåne lidt af friværdien :)

Det er nok billigere at finde en bunke C# programmørere, frisk fra fad, til at rette i kodebase, end erfarne og måske pensionsmodne PL/1 folk. Så kan den måske nå at blive pæn og fejlfri, til næste gang, deres vendor-lock-in, bliver et problem. (Der går nok lidt tid, inden de kan få nye funktioern, uden alt for mange katastrofale fejl i )

Man må håbe at de får adskildt database, API og bruger applikationer fornuftigt.

Tak for en spændende serie, hvor der også bliver fortalt om problemer, og konkrete løsninger. Absolut et projekt for de modige :)

Løsningen bliver at lægge kunstige forsinkelser ind i systemerne

Åh nej. Det er grunden til at man skal holde sig langt væk fra at konvertere gamle systemer med mindre kunden i praksis giver en blankocheck på opgaven: Det er helt ufatteligt hvad man kunne finde på af håbløse ting i det sidste årtusinde

Løsningen bliver at lægge kunstige forsinkelser ind i systemerne

Hahahaa. Jeg gætter på, at vi om ca. 30 år læser stort set den samme historie igen