Det var nog ett äkta problem som hade att göra med det sättet som man skrev datumsrelaterad kod under 70- och 80-talet.
Eftersom det i dåtidens datorer var ont om framför allt minnesresurser gällde det att spara på "överflödig" information som tex siffrorna på århundradet i en datumsuppgift. Dessa tolkades som "19" precis som vi numera tolkar in siffrorna 20 som föregår ett datum i tex format "ååmmdd".
År 2000 då låg väldigt långt bort och dåtidens programmerare (som jag tex) hade svårt att tänka sig att koden skulle överleva fram tills dess utan att den reviderades eller skrevs om med kraftfullare datorer som skulle kunna eliminera behovet av sådana "genvägar".
Visserligen kom det fram bättre och snabbare datorer i rasande fart och minnesproblematiken blev snabbt överspelat. Men det blev också mycket dyrare att konvertera gammal kod genom (manuell) omprogrammering. Det blev enklare och betydligt billigare att "frysa ned" gammal kod som pga sina resursbegränsningar också var mycket effektiv. De nya modernare system kommunicerade med den således infrusna kärnan genom dess gränssnitt som ofta blev betydligt bättre dokumenterat än dess innehåll. Detta gällde i synnerhet mjukvarurutiner som var neutrala i förhållandet till specifika applikationer, kunde användas av flera applikationer samtidigt och kallades mycket frekvent av dessa. De skrevs företrädesvis i form av "bibliotek" som många program kunde använda sig av samtidigt. Ett typisk exempel är hantering av datum och annan funktionalitet som idag tillhandahålls genom operativsystemet.
På detta sättet byggdes lager på lager av kod och efter en tid blev denna massa av gammal kod fullständigt osynlig tom för experter på området. År 2000 närmade sig och fler och fler av de äldre programmerare som kände till utvecklingen uppmärksammade på kommande problem som med säkerhet skulle uppstå runt millenieskiftet när tex ett datum med utseende "010203" skulle tolkas som 1901-02-03 i applikationer som i sin (oftast osynliga) strukturs inre värld byggde på dessa infrusna moduler av gammal kod. Men problemen viftades lättfärdigt undan av dåtidens yngre nomenklatur som med sin bristfälliga utbildning och erfarenhet ofta tolkade detta som skrämselpropaganda av en bunt COBOL-stofiler som genom de turbulenta förändringar i programmeringstekniken hade hamnat offside.
Det dröjde ändå fram tills IBM, den enda kvarvarande gigant på stordatorsidan, på allvar och med kraft påpekade för problematiken. Oron var också mest berättigad på de större datorerna som bankväsendet, försäkringar, trafiksystem och många tynga produktionsbolag baserade sin verksamhet på. Paniken blev inte mindre genom att det inte fanns mycket tid kvar att åtgärda problemen. Och i den mån det fanns kvar gammal källkod fanns det inte tillräckligt mycket med utbildat personal som kunde både gammal COBOL och modernare programmeringstekniker för att hantera problemen.
1999 blev därför rent ekonomiskt en jättesucce för mig med mängder av uppdrag som rörde "gamla försyndelser" från 70- och 80-talet. Jag blev jätteförvånad hur mycket av min gamla produktion bara knallade vidare på många datorer t.o.m. i flera länder och hade klarat av mängder med maskin- och operativsystemsbyten under många år. Det flesta av mina datumrutiner hade dock varit förutseende och innehöll kod som klarade ett milleniumskifte. Bl.a. använde jag i min kod s.k. "juliansk kalender" för att jämföra datum och utföra datumsaritmetik. Det visste jag naturligvis då men det kan ju vara lönsamt att "utreda" den detajlen igen efter ca. 25-år. I de fall som behövde åtgärdas var lösningen oftast inte precis trivialt och oftas fanns de bara en "quick and dirty" fix för att flytta på problemet ytterligare 100 år, hehe.
Ja, nu blev det en sån lång text igen av bara farten. Men jag hoppas att den kan bidra att bringa lite ljus i mysteriet "milleniesyndromet".
//Singha711
Finns det någon som inte tjänar till detta dokument? eller som är icke glad plzzzzzzzzzzzzzzzzzzzz stå upp
