15 år efter Y2K: Omfattende jagt på datofejl gav smertefrit nytår

Ingen atomkraftværker nedsmeltede, flyene faldt ikke ned fra himlen, og pengene forsvandt ikke fra vores bankkonti, da årstallet skiftede fra 1999 til 2000. Men kapløbet mod Y2K var ikke en fuser.

I dag er det kun Twitter-brugere eller dem, der sendte tonsvis af sms-beskeder fra deres Nokia 3310'er i deres teenageår, som på egen krop har oplevet behovet for at spare to tegn, når man skal skrive en dato.

Men alle borgere i Danmark med et cpr-nummer kan ved selvsyn se, at det i computerens barndom var almindeligt at nøjes med to cifre til at repræsentere årstallet.

I 1999 skulle prisen for den besparelse betales for al software udviklet i 60'erne, 70'erne og 80'erne, og fantasien fik lige pludselig frit løb, da nedtællingen til årtusindskiftet nærmede sig nul. Der var frygt for, at flytrafikken ville gå i stå, at bankernes systemer ville holde op med at fungere, eller det helt store skrækscenarie at russiske eller amerikanske atommissiler ville affyre sig selv.

Med blot to cifre i årstallet var essensen af problemet, at visse programmer ville skifte korrekt til 2000, andre til 1900 og atter andre til 19100. To cifre var rigeligt i 1960'erne, hvor data blev indlæst fra hulkort med et begrænset antal kolonner til rådighed, og det havde formet dataformaterne og praksis for datoer i softwareudviklingen. Først i midten af 1980'erne begyndte dataloger at tale om, at det ville give problemer, når årstallet skulle passere 99.

Det var dog først i 1990'erne at det begyndte at stå klart, at software, der brugte disse datoformater, sandsynligvis stadig ville være i brug, når vi nåede år 2000, og i slutningen af 1990'erne kom it-branchen for alvor i omdrejninger for at løse problemerne. Mange frygtede dog, at det ville være umuligt at nå at rette alle fejlene.

Der blev oprettet kriseberedskaber, og over hele verden tilbragte mange mennesker nytårsaften parat til at skride ind, hvis noget skulle gå galt. Men i takt med, at nytåret blev skudt ind i den ene tidszone efter den anden, fortsatte alt med at fungere. Nytårsmorgen var konklusionen, at der stort set ikke havde været flere it-problemer end på en vilkårlig anden dato.

Hele År 2000 Problemet, eller Y2K, blev flere steder kritiseret for at være hysteri, hvor en grisk it-branche havde udnyttet frygten til at få kunderne til at betale i dyre domme for at få rettet problemer, der ikke fandtes.

Men var År 2000 Problemet den fuser, det blev udråbt til i januar 2000?

»Så vidt jeg husker, så kom vi igennem uden problemer. Jeg mener, der blev lavet nogle rettelser, men det var ikke så voldsomt, som vi havde troet,« fortæller driftschef Jørgen Bo Madsen fra Ipvision til Version2. I 1999 var han netværkssikkerhedschef hos TeleDanmark og sad dermed med en del af ansvaret for at få telegiganten helskindet ind i 2000.

Hos det, der i dag er TDC, lå opgaven med at opdatere softwaren dels hos de eksterne leverandører af software, men i høj grad også hos TeleDanmark selv, som havde mange egenudviklede systemer.

»Det var primært vores egne systemer, hvor vi skulle gå softwaren igennem. Jeg var lidt overrasket over, at det ikke var et større problem. Vi havde rigtigt mange it-systemer, og de fleste var i stand til at klare år 2000,« fortæller Jørgen Bo Madsen.

Det var dog ikke ensbetydende med, at der ikke var problemer, der skulle rettes i koden, og det var stadig et stort arbejde.

»Vi gik grundigt til værks, men vi kom ikke gennem alt. Vi lavede en risikoanalyse og tog så de vigtigste systemer først,« siger Jørgen Bo Madsen.

En af de ukendte faktorer ved År 2000 Problemet var netop, hvad der ville ske, hvis man ikke nåede at gennemgå og som minimum teste alle systemer. Da mange it-systemer skal tale sammen eller på anden vis er afhængige af hinanden, så kunne et relativt lille problem ét sted brede sig som ringe i vandet og give problemer for mere kritiske systemer.

»Jeg synes ikke, det var hysteri. Det var vigtigt at få fokus på det. I automatiserede systemer skriver du jo mikrokode, hvor det er vigtigt at spare på pladsen, og så er det svært at gennemskue afhængighederne,« forklarer Jørgen Bo Madsen.

Behovet for at rette i programkode, hvoraf meget af den var programmer, der havde rødder tilbage til 1970'erne og var skrevet i Cobol, skabte en akut efterspørgsel på de særlige kompetencer, der skulle til for at kunne finde fejlene i et næsten glemt programmeringssprog og rette dem uden at ødelægge programmet.

»Der var jo en kæmpestor bekymring for, hvordan det ville gå. På DIKU var vi en gruppe, der lavede vores eget firma og udviklede et værktøj, hvor vi brugte typeteori og ML til at opdage problemer i Cobol-programmer,« fortæller Mads Tofte til Version2. Han er i dag rektor for It-Universitetet, men var dengang lektor på DIKU.

Firmaet blev aldrig en forretningsmæssig succes, fordi mange havde fået lagt en strategi for deres år 2000-skifte, inden DIKU-folkene langt om længe fik forretningsmodellen på plads. Men gennem dialog med IBM og en enkelt dansk kunde blev værktøjet til Cobol-analyse afprøvet på en række Cobol-programmer.

»Der var masser af år 2000-problemer i koden. Ofte var de forholdsvis nemme at rette, men de var ret almindelige, og der var meget kode at gå igennem,« fortæller Mads Tofte.

Efter årtusindskiftet var det vanskeligt at sige, hvor meget arbejde der blev lagt i at løse problemerne, og om det var indsatsen værd, når nu nytåret passerede uden problemer.

»Da det blev år 2000, var der ingen af os, der anede, hvordan det ville gå. Det var en kæmpe positiv overraskelse, at det forløb med så lidt smerte. Bagefter har jeg spurgt mig selv, hvordan det kan være, at det gik så godt, i betragtning af hvor meget kode der skulle gennemgås,« siger Mads Tofte.

Hans bedste bud på en forklaring er, at den store indsats, som blev leveret af mange tusinde it-folk over hele verden, kan sammenlignes med et distribueret system. Så mange mennesker, der arbejdede på forskellig vis frem mod et fælles mål, gav måske en utrolig robusthed og tolerance i forhold til at håndtere fejlene.

»Når rigtigt mange it-folk ser et problem, og hver især sætter fornuftige ting i gang, så lykkes det dem at gøre rigtig meget. Frygten for, hvad der kunne ske, var motiverende. Hvis der ikke havde været den frygt, så var det nok ikke lykkedes,« siger Mads Tofte.

It-branchen oplevede et boom i slutningen af 1990'erne, drevet frem af blandt andet År 2000 Problemet, og de kræfter, der efterfølgende blev frigivet, og den modernisering, der fulgte med fejlrettelserne, var med til at sætte gang i først dotcom-bølgen og siden den enorme it-vækst, der har præget begyndelsen af det 21. århundrede.

»Jeg tænker tilbage på den tid med stolthed og varme følelser. Det var spændende at være med til at løse en samfundsmæssig udfordring og kunne bruge forskning til det. Også selvom vi ikke blev millionærer,« siger Mads Tofte.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (26)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Erik Jensen

Der var sælgere der fik solgt en del udstyr på frygten og der var nyheds medier der fortalte at ens brødrister ville holde op med at virke.
De fleste i min familie er enige om at det var ren hysteri og der ikke var nogle problemer. Så jeg må stadig bruge tid på at forklare igen og igen, at der var faktisk systemer der ville få problemer og at de fleste blev rettet.
Det eneste jeg oplevede af fejl fordi vi havde forberedt os, var en backup der mente der var 100 år minus en dag til den skulle tage næste backup. Kunden valgte ikke at udskifte backup serveren men at tage chancen. Måske lidt optimistisk fordi den kørte OS/2. :)

  • 4
  • 0
Ditlev Petersen

Der var virkelig mange steder, hvor årstal var tocifrede og de fleste af dem ville have givet spektakulære problemer. En del sygehuse ville ikke have kunnet finde deres patienter, hvis ikke det var blevet rettet. Men det blev rettet og der viste sig kun et par oversete fejl efter nytår, ingen alvorlige. En enkelt maskine blev ikke rettet, i stedet var der et lille program, der stillede datoen tilbage hver aften. Den skulle kun bruges til opslag i historiske data (til gengæld må loggen have set spøjs ud). Det er utroligt, så meget kode man i løbet af en dag kan lade løbe over skærmen og analysere.

  • 5
  • 0
Torben Mogensen Blogger

Der blevet lavet masser af software i 1990'erne, der kun brugte to cifre til årstallet. Man skulle tro, at folk kunne forudsige problemet, når det lå mindre end 10 år ude i fremtiden, men vanens magt er stor, og nogle havde måske også den holdning, at det var nogen andres problem at rette op på det senere. Det fungerede jo fint på den nuværende kundedatabase.

  • 1
  • 0
Gustav Brock

De optrådte skam også i radioen.

Daværende (chef)redaktør for Computerworld(!), Finn Morsing, udslyngede om skiftet til år 2000 en dommedagsprofeti i et interview nytårsdag 1999 i DR Radioavisen kl. 18.30. Nogle af os har ikke glemt dette.

Adspurgt af journalisten bekræftede Finn Morsing uden den mindste ironi, at han vurderede, at Radioavisen samme dato og tidspunkt år 2000 ikke ville blive udsendt. Det blev den som bekendt. Han var også en af dem, der direkte rådede folk til at indkøbe forråd til 14 dage!

Så omkring alle de saglige opgaver, der stille og roligt blev løst, florerede hysteriet skam lystigt. Heldigvis efterlod det ikke meget andet end morskaben.

  • 2
  • 0
Ditlev Petersen

over forudsigelser om År 2000. Desværre blev den slettet. Men der var også en svensk forsvarschef, der frygtede, at kampvognene ville køre rundt i cirkler og flyene falde ned. Det med flyene ved man jo aldrig - der var noget med en F16, der vendte sig om på ryggen, da den passerede datolinjen. Men det var lang tid før år 2000.

Eller som et blad (kan det være Dr.Dobb's) skrev bagefter: Ed, Your'don!

  • 0
  • 0
Ditlev Petersen

Der var en amerikansk stat, hvor man ville prøve ad, om der skete noget, og stillede datoen frem. Der skete én ting: Et rensningsanlæg udtømte sit indhold over en nærliggende park. Men de var ikke helt sikre på, om det nu også var et Y2K-problem.

Og en amerikansk by, der købte flere tusinde gammeldaws skrivemaskiner.

  • 1
  • 0
Christian Nobel

Der blevet lavet masser af software i 1990'erne, der kun brugte to cifre til årstallet. Man skulle tro, at folk kunne forudsige problemet, når det lå mindre end 10 år ude i fremtiden, men vanens magt er stor, og nogle havde måske også den holdning, at det var nogen andres problem at rette op på det senere. Det fungerede jo fint på den nuværende kundedatabase.

Der er vel ikke det store problem i at software kun bruger to cifre til årstallet, hvis det f.eks ikke skal bruges til at stadfæste folks fødselsdato.

Sliding windows (som der guddødemig var nogen der prøvede at patentere) kan jo udmærket tage hånd om de antagelser der skal gøres i langt de fleste tilfælde.

  • 0
  • 0
Thomas Vedel

Jeg var dengang ansat i udviklingsafdelingen på "Landbrugets Rådgivningscenter" (nu SEGES). Vi havde langt over 100 applikationer kørende som vi var nødt til at foholde os til, heraf mange helt eller delvist egenudviklede, og af dem en del som vi udsendte til kunder på CD.

Som jeg husker det havde vi ingen fejl ved overgangen til år 2000, men vi havde det sidste halvandet år op til årsskiftet brugt rigtig mange timer på at sikre (og rette) rigtig mange programmer, og jeg kan huske at det irriterede os grusomt at Y2K problematikken i medierne efterfølgende blev slået op som "hysteri".

At der ikke i praksis var problemer ved årsskiftet, skyldtes alene at opgaven med at sikre og tilrette it-systemerne var blevet taget alvorligt i it-afdelingerne rundt omkring, og at problemerne blev håndteret i tide.

  • 7
  • 1
Erik Jensen

Det var heller ikke sikkert det var OS/2 der var fejlen, det kan være det var backupsystems kalender beregning. Skal ikke kunne sige det, de var ikke interesseret i at jeg skulle kigge dybere på det. Jeg løste det hurtigt ved at rette datoen for hvornår næste backup skulle foretages.

  • 0
  • 0
Torben Mogensen Blogger

Og ikke først i år 10000, som en spøgefugl nævnte.

En del rettelser af Y2K problemet skete ikke ved at udvide til fire cifre, da det ville kræve omskrivning af omfattende databaser, der brugte to cifre til årstal. I stedet ændrede man i programmerne, så tocifrede tal under f.eks. 60 blev betragtet som 20XX og tocifrede tal fra 60 og op blev betragtet som 19XX. Dermed blev tidsrum o.lign. korrekt udregnet, såfremt ingen af tallene under 60 rent faktisk skulle være 19XX og ingen tal over 60 skulle være 20XX. I mange tilfælde er det uproblematisk, for eksempel hvis datoerne er datoer for posteringer: Så kan man bruge datoen for den første postering som skilletal. Dermed vil det virke indtil datoer 100 år efter den første postering, hvisket nok er efter 2060 for de fleste databaser. :-)

Hvis en sådan database stadig eksisterer om 45 år, vil vi få problemet igen. Det er dog ikke specielt sandsynligt. Værre er det, hvis året ikke er dags dato, men f.eks. fødeår for personer. Så kan man ikke bare sætte grænsen til f.eks. 60, da man dermed udelukker folk født før 1960. Man kan dog sætte grænsen til fødeåret for den ældste person, men da det nemt kan have været før 1920, er løsningen ikke langtidsholdbar. Det er blandt andet derfor, at man ser historier om 106-årige, der bliver indkaldt til folkeskolen.

Jeg ved ikke, hvor stort dette problem er, men med mindre der er nogen, der har styr på skilletallene (og evt. justerer dem, når man nærmer sig grænsen), kan der komme Y2K-relaterede fejl langt før udgangen af dette århundrede.

  • 4
  • 0
Daniel Gertsen

Dermed vil det virke indtil datoer 100 år efter den første postering, hvisket nok er efter 2060 for de fleste databaser. :-)

Det er allerede i 2038 :-)

http://en.wikipedia.org/wiki/Year_2038_problem

Der begynder tidsstempler der tæller sekunder, at overskride 32-bit integer grænsen på 2.147.483.647

Og det har som sådan intet med diverse databasers alder at gøre.
Og problemet kan i princippet opstå allerede i dag, hvis du eksempelvis har mulighed for at vælge en fremtidig leveringsdato i en webshop, og vælger en dato i år 2039.

  • 5
  • 0
Henrik Madsen

For en del år siden arbejdede jeg et sted hvor man havde en Windows NT maskine med et program som var lavet af en leverandør til at starte og stoppe nogle maskiner.

Pludseligt en dag den 1 april stod alle maskinerne som "no connection" selvom en lysdiode på selve maskinen indikerede at der rent faktisk VAR forbindelse.

Det undrede vi os meget over for i al fortid fulgtes lysdioden og "no connection" altid af og maskinerne var delt op i nogle klynger af 2 så det typiske var at 2 maskiner stod med "no connection" og computeren som styrede havde så ikke lys i lysdioden.

Det viste sig efter meget kløen i nakken at satte vi uret tilbage på maskinen og genstartede programmet så virkede det hele igen og konklusionen blev at producenten af softwaren havde en bagvedliggende database hvor måneden blev angivet som et tal mellem 1 og 100.

8 år og 4 måneder efter programmet blev skrevet nåede vi så til uge 100 og da der kun var 2 felter til angivelse af måned så blev programmet forvirret.

Om det var en regulær bommert fra producentens side eller det var bevidst for at sørge for at vi købte opdateringer skal jeg ikke kunne sige, men da datoen ikke reelt havde nogen betydning på maskinen besluttede vi blot at sætte årstallet 5 år tilbage.

Fejlen nåede aldrig at gentage sig for inden de 5 år var gået blev maskinen nu alligevel skiftet ud med en nyere, men vi kørte da med det med en forkert dato i en 2-3 år efter.

10-11 år's levetid for en PC'er der kørte i døgndrift syntes vi nu heller ikke var helt ringe.

  • 2
  • 0
Normann Aa. Nielsen

Jeg vil gerne fremhæve dette svar. Fejlen kommer igen, men denne gang ikke på en bestemt dato - nærmere drysset ud over en årrække.

Da vi i mit daværende firma "rettede" Y2K, gjorde vi det ved at anvende et offset på året på 50 år. Hvis vores software derfor stadig kører i år 2050, vil der komme et problem. Men andre satte offset til andre værdier, så der vil være Y2K-relaterede problemer "dryssende" ud over en periode, som jeg tror starter allerede i 2020 - og fremefter.

  • 2
  • 0
M.F. Rasmussen

Som andre skriver var det ikke kun 99 til 00 der gav problemet, om end vores PDP-11 maskiner rent faktisk gik i HALT inden vi fik lavet en Y2K patch, men vores VAX/VMS havde et Y2K offset problem, hvor tælleren løb fuld - så vidt jeg husker skete det i sidste halvdel af 1999. Det blev dog opdaget af Digital nogle uger før, og patch blev sendt ud til dem som havde licens til operativsystemet.

  • 0
  • 0
Per Møller Olsen

Der er i mine øjne ingen tvivl om, at der var useriøse konsulenter, der tjente på usikkerheden omkring Y2K. Men jeg er også helt sikker på, at vi havde set mange flere problemer, hvis der ikke havde været fokus på det.

For der VAR problemer ved skiftet. Og de VAR også indenfor de fokusområder, som man havde frygtet, at der kunne opstå problemer.

Jeg fandt denne liste over problemer (primært i USA):
http://www.cs.swarthmore.edu/~eroberts/cs91/projects/y2k/Y2K_Errors.html

I Japan var der fejl på atomkraftværker. Det medførte sikkerhednedlukninger:
http://money.cnn.com/1999/12/31/worldbiz/y2k/

Nogle havde også problemer i årene rundt om Y2K. Min bror var nyuddannet politibetjent og der havde de problemer med PolSAS, der gik ned ved årsskiftet 1998-99 - det morede vi os meget over.

I norge stod togene stille ved årsskiftet 2000-2001 ... en forsinket Y2K-fejl åbenbart:
http://www.computerworld.dk/art/69158/y2k-fejl-stoppede-norske-tog

Spørgsmålet vil jo altid være, hvor slemt det havde været, hvis man ikke havde haft et "Y2K-hysteri".

  • 2
  • 0
Michael Hartvig

Unix Epoch har også nogle grænse datoer... Gælder i øvrigt også negative værdier, hvis man regner på historiske dateringer.

"At 06:28:16 UTC on 7 Feb 2036, Network Time Protocol will loop over to the next epoch, as the 32-bit time stamp value used in NTP will overflow.

At 03:14:08 UTC on 19 January 2038, 32-bit versions of the Unix time stamp will cease to work, as it will overflow the largest value that can be held in a signed 32-bit number (7FFFFFFF16 or 2,147,483,647). Before this moment, software using 32-bit time stamps will need to adopt a new convention for time stamps, and file formats using 32-bit time stamps will need to be changed to support larger time stamps or a different epoch.

At 06:28:15 UTC on Sun, 7 February 2106, the Unix time will reach FFFFFFFF16 or 4,294,967,295 seconds which, for systems that hold the time on 32 bit unsigned numbers, is the maximum attainable. For these systems, the next second will be incorrectly interpreted as 00:00:00 1 January 1970 UTC.

At 15:30:08 UTC on Sun, 4 December 292,277,026,596 64-bit versions of the Unix time stamp will cease to work, as it will overflow the largest value that can be held in a signed 64-bit number. This is not anticipated to pose a problem, as this is considerably longer than the time it would take the Sun to theoretically expand to a red giant and swallow the Earth."

  • 2
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize