Het jaar 2000 en Acorn computers
door Bob Brand met medewerking van Maarten J. Seinen

In Asterisk nummer 16.1 (januari 1998) stond op pagina 16 een artikeltje met als titel ,Acorn gezekerd tegen afstorten'. Daarin werd gemeld dat RISC OS bestand is tegen de jaar-2000 overgang.

Inderdaad, RISC OS op zich is goed tot 3 juni 2248, 6:57:57 en 75 honderdste seconde UTC (zie kader aan het einde). Maar het besturingssysteem (operating system of OS) is niet het grootste probleem met de overgang naar het jaar 2000.
Er zullen weliswaar heel wat machines en OSsen problemen krijgen op 1 januari 2000, maar het echt grote probleem wordt gevormd door de applicaties die met data (het meervoud van datum, niet gegevens in het algemeen) omgaan. Databases, spreadsheets, administratieprogramma's, wat dan ook.

Alle programma's die slechts twee cijfers opslaan voor een jaar gaan in 2000 fout of ze nu op een Acorn draaien of niet. Maar ook allerlei netwerk protocollen bijvoorbeeld gaan uit van slechts van 2 cijfers voor het jaartal.

De oorzaak.

In de beginjaren van de computerindustrie was geheugen kostbaar, heel kostbaar. We hebben het dan over meerdere dollars per byte voor het werkgeheugen of core-memory (toen nog echte ,core'-, magneetkern geheugens, ferrietringetjes met draden erdoor, een grote computer had wel een hele kilobyte aan geheu-gen!) en rond een dollar per byte voor opslag op harde schijf. Daarnaast in- en uitvoermechanismen die van een vast aantal karakters uitgingen.

Bijvoorbeeld 80 karakters op een ponskaart. Mensen met een lange achternaam of een lange straatnaam zullen daar ook nu nog wel eens tegenaan gelopen zijn. (,,Het past niet in de computer.'')

En opmerkingen van mensen die met de huidige generatie computers zijn opgegroeid als ,,in een byte kun je toch tot 255 tellen, dus twee bytes gaan tot 65535'' kloppen wel, maar als je maar een beperkte hoeveelheid geheugen hebt wil je die niet gebruiken voor onnodige conversies. Als de hardware zoiets trouwens al toeliet. Bovendien is een getal in leesbare vorm opgeslagen eenvoudig terug te vinden in een dump van het geheugen (als er bijvoorbeeld problemen zijn) en ook direct zonder geheugenvretende extra omvormingen uit te printen.

Een beetje bedrijf kon dus enorme bedragen besparen door alle overbodige zaken weg te laten. Bovendien scheelt dat werk en daarmee kans op fouten bij het invoeren van gegevens. Zeker de ,19' voor een jaartal was nergens voor nodig. Alleen bij geboortedata (in de jaren '50 waren er aanmerkelijk meer mensen in leven met een geboortedatum in de 19e eeuw) en erg langlopende zaken was dat wel nodig. Maar zelfs bij geboortedata werd de 19 weggelaten als de doelgroep toch geheel in deze eeuw zou vallen. Ik noem maar iets als een schooladministratie.

Daarnaast gingen (en gaan) de ontwikkelingen op computergebied zo snel dat men dacht dat computerprogramma's nooit langer dan een jaar of vijf mee zouden hoeven gaan voordat ze vervangen zouden worden door nieuwere en betere. Een twee-cijferig jaar hoeft verder geen probleem te zijn. Zolang je maar binnen een eeuw blijft kun je zonder meer data met elkaar vergelijken en verstreken tijd bepalen. Het jaar 89 is later dan het jaar 62 en er zitten 27 jaar tussen.

En alles werkte tot (bijna) volle tevredenheid. Er zijn bijvoorbeeld ook al decennium crises geweest omdat als je in bijvoorbeeld 1960 bent en er van uitgaat dat je programma 1970 niet eens zal halen rustig de hele 196 weg kunt laten en een 1-cijferig jaar kunt gebruiken.

Het millennium probleem.

Maar goed... Ondertussen komt het jaar 2000 met rasse schreden dichterbij. En veel programma's uit het verleden draaien nog altijd! Opgelapt, aangepast, maar in principe nog altijd het oude programma uit de jaren '50, '60, etc. Alleen al omdat de hoeveelheid oude data (nu wel in de zin van gegevens) in het oude, oorspronkelijke formaat staat en conversie mag niet om bijvoorbeeld juridische redenen (archieven moeten de originelen bevatten) of het zou gewoon veel te duur worden in zowel opslagmedium als computertijd.

Maar ook omdat het programma gewoon deed wat het moest doen en een nieuwe versie altijd tijd en geld kost. Dus werd en wordt er verder gewerkt met de oude formaten. En daar komt het probleem uit voort!

Want op 1 januari 2000... verandert het twee-cijferige jaar ineens in 00!
En dan? 00 is minder dan 99, zowel numeriek als ,alfabetisch' als string. Dus bij sorteren op datum gaat het fout. En ook bij het bepalen van het verschil tussen twee data heb je een probleem. Wat zal 00 - 99 opleveren? Als het programma met integers met teken werkt -99. Maar ook + 99, + 1 of -1 is mogelijk.

Of er komt een 3-cijferig antwoord uit terwijl er maar voor twee cijfers geheugen gereserveerd is zodat het antwoord ,overloopt' en er in het geheugen iets wordt overschreven dat voor iets anders gebruikt wordt.

Het hangt er helemaal af van hoeveel rekening een programma houdt met deze ,onmogelijke' waarden wat er zal gebeuren. Een crash of ,gewoon' doorgaan met een raar getal en ineens 99 jaar achterstallige rekeningen hebben of... 99 jaar achterstallige rente tegoed hebben is allemaal mogelijk.

Ook computers die via netwerken aan elkaar gekoppeld zijn krijgen een probleem. Zijn berichten (van welke aard dan ook) van 01-01-00 nu 100 jaar oud en kunnen dus gelijk verwijderd worden op het moment van ontvangst of wat? En niet alleen de software, ook de hardware zelf is niet noodzakelijk veilig. Oudere computers, en niet alleen PC's, hebben vaak geen mogelijkheid om de hardware klok op een datum in 2000 (of verder) te zetten. En als dat wel kan dan is het nog niet zeker dat het ook goed gaat.

Testen met vooral oudere PC's hebben aangetoond dat door een foutje bij het uitlezen van de real-time klok deze machines harder gaan lopen als ze uitstaan en de datum na 2000 is. (Zie website aan het einde van dit artikel.) En vergeet niet dat er computers zitten in heel veel verschillende apparaten. Degenen die een videorecorder hebben zouden bijvoorbeeld eens moeten proberen om de klok daarvan op een datum in 2000 te zetten. En als dat al lukt, welke dag van de week geeft de recorder dan aan?

Oplossingen?

De keuzes uit het verleden zijn dus nog altijd onder ons. En daar moeten we mee verder werken. Er is geen eenvoudig antwoord te geven op wat er zal gebeuren. Elk programma en elke applicatie gebouwd op een programma zal moeten worden nagekeken. En dat is heel veel werk.

Als de sources van het betreffende programma beschikbaar zijn (wat voor oudere pro-gramma's en/of gekochte programma's lang niet altijd het geval is) dan kan het programma ,gerepareerd' worden om met 4-cijferige data om te gaan. Maar dan moeten ook de bestaande gegevens geconverteerd worden.

Een andere mogelijkheid is om een ,window' te gebruiken rond een vaste datum (bijvoorbeeld alles onder de 80 is in de 21e eeuw en alles boven de 80 in de 20e eeuw) of schuivend rond de huidige datum. Als de sources niet meer bestaan kan er een conversie-laag tussen de oude data en het eigenlijke programma geplaatst worden. Of in het uiterste geval kan zelfs een heel nieuw programma geschreven worden met de oude functionaliteit.

Kortom: in principe een oplosbaar probleem, maar als je even nadenkt over de enorme aantallen computers op de wereld en de hoeveelheid gegevens die er zijn die allemaal gecontroleerd moeten worden, nou dan wordt het nog een hele klus om dat in de circa 640 dagen die er nog resten tegen dat deze Asterisk in de bus valt te klaren. Zoals al opgemerkt: het is heel veel werk.

Maar ik heb toch een Acorn...

Aan het begin van het artikel werd al gemeld dat een Acorn computer onder RISC OS gewoon door zal lopen in het jaar 2000 en lang daarna. Maar dat betekent nog niet dat Acorn gebruikers geen problemen zullen hebben. Want hoe zit het met de applicaties?

Om heel kort enkele Acorn programma's te noemen die ik heb kunnen bekijken:
Squirrel, een database, gebruikt 4 cijfers voor z'n jaar in datum velden. Ingave van het jaar 91 AD staat zelfs expliciet in de handleiding als voorbeeld. Ingave van een twee-cijferig jaar wordt automatisch aangevuld met de eeuw die de systeemklok aangeeft. (Een voorbeeld van windowing dus.)

Maar: de ontwerper van een database opgezet in Squirrel hoeft voor zijn data niet gebruik te maken van het datum type. Als hij/zij gekozen heeft om een jaar als 2-cijferige integer vast te leggen dan kan het programma zelf nog wel 2000-compliant zijn, de betreffende database is het niet.

De Minerva databases DeltaPlus en afgeleiden (tot aan MultiStore 2.00, nieuwere weet ik niet) hebben daarentegen geen apart datum type. Hier hangt het dus geheel af van de ontwerper van de database. Als die 4 cijfers gebruikt heeft voor de jaartallen dan zou er geen probleem hoeven te zijn. Maar met 2 cijfers kunnen de gebruikers nog raar staan kijken in 2000.

Andere applicaties.

Het lijkt me geen gek idee dat gebruikers van andere databases en spreadsheets ook eens te kijken wat de (on-) mogelijkheden zijn wat data betreft. Resultaten van zulke testjes kunnen naar de Asterisk redactie of (via AcoNet) direct naar mij gestuurd worden zodat er in een volgende Asterisk gemeld kan worden wat de stand van zaken is met betrekking tot andere applicaties.

Enkele data om op te letten zijn: 1 jan 2000, welke dag van de week geeft het programma aan? (Het moet een zaterdag zijn, ja de overgang naar 2000 is een lang weekend, pas op maandag 3 januari 2000 zullen veel bedrijven merken welke programma's wel en niet goed werken.)

Verder 28 feb 2000, 29 feb 2000 en... 30 feb 2000! Dit is strikt genomen niet het millennium probleem, maar de regels voor schrikkeljaren zijn vaak maar gedeeltelijk of zelfs verkeerd geïmplementeerd. In de tijd dat geheugen schaars en duur was was het voldoende om alleen de 4-jaar regel te implementeren. Dit blijkt nu een idee te zijn waarmee het programma tot 2099 voort kan. Maar er zijn mensen die de schrikkeljaarregel niet goed begrijpen en denken dat 2000 een superschrikkeljaar is met 2 schrikkeldagen. Een Amerikaans quizprogramma heeft dat ooit nog eens extra benadrukt.

(Voor de duidelijkheid: 2000 is een gewoon schrikkeljaar.) Uiteraard dan ook 1 maart 2000. Maar ook de overgang naar 2001 moet bekeken worden.

En ook als de data intern in de spreadsheet of database als 4-cijferig getal worden opgeslagen is het nog niet gezegd dat alle interne functies die die data gebruiken ook goed werken. Maarten J. Seinen gaf het Microsoft spreadsheet programma Excel als voorbeeld hiervan op AcoNet. Je kunt zonder problemen 4-cijferige jaartallen invoeren en weer weergeven, maar diverse (statistische) functies ,zien' toch alleen maar een twee-cijferig jaartal! En als er mensen zijn die een RISC OS machine al langere tijd op een datum na 2000 hebben getest, zowel wekenlang aan als regelmatig aan- en uitgezet dan zijn die testresultaten ook welkom.

Tenslotte.

Wat er werkelijk zal gebeuren op 1 januari 2000 is onmogelijk te voorspellen. Dat iedereen er iets van zal merken is zeer waarschijnlijk. Maar het einde van de beschaving zoals we die kennen wat sommige pessimisten voorspellen lijkt mij zeer onwaarschijnlijk.

Meer informatie.

Op het Internet is veel informatie te vinden over het jaar 2000. De meeste computer- en software bedrijven hebben op hun website informatie over hun produkten.

Natuurlijk ook Acorn: http://www.acorn.com/acorn/news/year2000/. Een meer algemene ingang is de website van Peter de Jager, een Canadees jaar-2000 expert: http://www.year2000.com/. Maar een kleine zoektocht met een willekeurige search-engine levert je al gauw enkele duizenden andere treffers op.

Het specifieke probleem dat PC's voor gaan lopen na 2000, in de hierna volgende nieuwsgroep het ,time dilation' probleem genoemd is gedocumenteerd op: http://www.elmbronze.demon.co.uk/year2000/dilation/. En veel informatie van mensen ,in het veld' is te vinden in de nieuwsgroep news:comp.software.year-2000.

Houdt verder kranten en tijdschriften in de gaten. Langzaamaan begint het ook daar door te dringen dat er een probleem is. Denk aan de aankondiging in de week van 2 maart 1998 dat er in het volgende kabinet eigenlijk een minister voor millennium problemen moet komen. Ook verschijnen er langzamerhand boeken over het millennium probleem, maar ik kan (nog) geen boek aanraden.

De RISC OS systeemtijd.

De systeemtijd en ook de tijd die gebruikt wordt om datum en tijd van files vast te leggen onder RISC OS is een 5-byte unsigned integer waarin het aantal centiseconden geteld wordt sinds 1 jan 1900, 0:0:0 UTC. Dit formaat werd al op de BBC micro gebruikt, om de simpele reden dat een 4-byte teller ,slechts' een kleine anderhalf jaar kan omvatten. En omdat je met 1/100ste seconden voor de meeste praktische doeleinden voldoende mogelijkheid hebt. (Voor echt nauwkeurige tijdmetingen moet je toch een externe klok gebruiken.)

Deze 5-byte tijd kun je converteren naar een leesbare string met de SWI's

Territory_ConvertDateAndTime en Territory_ConvertStandardDate

AndTime (voor RISC OS 3.1 en hoger) of OS_ConvertDateAndTime en OS_ConvertStandardDateAndTime voor alle versies van RISC OS en zelfs Arthur.

De versies met ,Standard' leveren het formaat dat het commando *time of BASIC's PRINT TIME$ geeft.

Het laatste moment waarop RISC OS nog goed is, is op de

te bepalen: