Het heeft geen zin de programmeurs te verwijten dat ze jaren geleden in applicatie- en systeemsoftware data met twee cijfers zijn gaan gebruiken. Het jaar 2000 was immers nog ver weg -maar nu niet meer. De eeuwwisseling hangt als een zwaard van Damocles boven de IT-industrie.
Het is ook niet praktisch het probleem nog een paar jaar vooruit te schuiven. De meeste applicaties kijken immers verder dan vijf jaar vooruit. Nu al zijn er problemen. Het tankpasje van een leaseauto dat vijf jaar geldig is bijvoorbeeld, verloopt in 2000. De ene benzinemaatschappij accepteert zo’n pasje, terwijl een andere het weigert omdat het niet langer geldig zou zijn.
De problemen zijn rekenkundig: het verschil tussen de verval- en de huidige datum moet positief zijn, en 2000-1996 is positief, maar 00-96 niet. De diversiteit aan datum-formaten en rekenkundige algoritmen compliceren het probleem.
Data worden op diverse manieren weergegeven. De ‘westerse wereld’ gebruikt de Gregoriaanse kalender (naar paus Gregorius). Deze is gebaseerd op een cyclus van 365 dagen, met schrikkeljaren en als uitgangspunt het jaar 0. De Juliaanse kalender (naar Julius Caesar) telt simpelweg vanaf een standaard tijdstip. Helaas gebruiken verschillende subsystemen, zoals Cics, Cobol en besturingssystemen, alle diverse begindata. In alle gevallen zijn complexe berekeningen nodig om de verschillende datum-representaties te transformeren, inclusief conversies van en naar een voor mensen leesbaar formaat (mm/dd/jj of dd/mm/j?). Als onvermijdelijk gevolg hiervan zijn in de applicaties diverse rekenkundige modules ingebouwd, met alle consistentieproblemen van dien.
Het probleem is op te splitsen in twee deelproblemen. Deze hebben betrekking hebben op of berekeningen, of data. Als de datum-velden worden uitgebreid tot vier cijfers, moet men de hele database opnieuw bouwen. Het lijkt gemakkelijker om een nieuw tweecijferig formaat te introduceren, bijvoorbeeld: 75-99 betekent 1975-1999 en 00-74 betekent 2000-2074. Dit is echter niet aan te bevelen, want het vereist aanzienlijke aanpassingen en is een oplossing op de korte termijn. Bovendien hebben veel applicaties, zoals hypotheken, meer dan een eeuw nodig.
Applicatiecode aanpassen is nog problematischer. Sommige datum-routines gebruiken systeemfuncties, andere libraries, en sommige zelfs ingebedde code. Een datumconversie is dan ook een goede gelegenheid om deze problematiek aan te pakken.
Softwaretools zijn cruciaal bij het opsporen en isoleren van de specifieke code-secties. De betreffende secties moeten worden vervangen door standaardtechnieken en -formaten, in overeenstemming met de normen die de organisatie hanteert. Let op dat niet opnieuw een excessieve diversiteit ontstaat. Verder is dit het moment om te investeren in één compleet pakket voor datum-routines. Leveranciers van de genoemde analysetools leveren zulke pakketten vaak.
Routines in Cobol isoleren en aanpassen is zoals gebruikelijk het eenvoudigst. Gelukkig, want de meeste complexe gegevensverwerkende applicaties zijn nog altijd in Cobol geschreven. Voor andere gangbare talen bestaan eveneens tools. Andere subsystemen zijn echter moeilijker te corrigeren, vooral omdat sommige systeemprodukten nog gebruikt worden terwijl volledige ondersteuning niet meer bestaat. Problemen in oude sorteerroutines of batch-schedulers opsporen kan moeilijk zijn.
Een ander probleemgebied zijn de applicatiepakketten. Heeft u de broncode? Levert uw leverancier de upgrade? Zo ja, wie zorgt dan voor de implementatie en testen? Bent u overgeleverd aan uw leverancier? In dit opzicht zullen pakketten meer problemen opleveren dan zelfontwikkelde applicaties. Heeft u client/server-applicaties met datum-functies op zowel de host als de PC? Sommige relatief jonge PC Bios-routines lopen op 1 januari 2000 stuk.
Ook voor het beheren en invoeren van de upgrade van grootschalige systemen zijn softwaretools essentieel. Codering zal hoe dan ook een enorme klus zijn. Bij veel organisaties kunnen de kosten oplopen tot miljoenen guldens. Investeringen in softwaretools zullen lonend zijn. Onderschat de schaal en kosten van het detecteren en oplossen van het ‘Jaar 2000-probleem’ niet. U kunt er niet vroeg genoeg mee beginnen.
Een voorbeeld van de potentiële problemen is de berekening van schrikkeljaren. Zoals iedereen weet is elk door vier deelbaar jaartal een schrikkeljaar, behalve als het door honderd te delen valt. 1900 was dus geen schrikkeljaar. 2000 is ook geen schrikkeljaar – of wel? De ‘deelbaar door honderd’-regel geldt niet als het jaartal ook deelbaar is door vierhonderd. Weten uw datum-routines dat?
