Neem het 2000-probleem serieus

Onder degenen die rechtstreeks betrokken zijn bij het onderhoud van bedrijfskritische gegevensverwerkende applicaties leeft het '2000-probleem'; slechts weinig anderen lijken de ernst ervan te beseffen.

Het is vooral verontrustend dat veel topmanagers zich nog niet van de potentiële catastrofe bewust schijnen te zijn. 'Catastrofe' is niet te sterk uitgedrukt: het gaat om bedrijfskritische systemen, en niet om gewone kantoorapplicaties. Vandaag de dag is modieus om te spreken over het upgraden van PC's naar een 32-bit besturingssysteem en hiermee het probleem van de onbetrouwbaarheid van Windows 3.1 op te lossen. Dit kan veel tijd en geld kosten, terwijl de impact op de bedrijfsvoering gering zal zijn, al zullen nieuwe client/server-systemen ervan profiteren. Men stort zich op een bijzaak in plaats op van de naderende ramp.
Om het 2000-probleem te kunnen oplossen, moet het eerst in kaart gebracht worden. De problemen zijn technisch en betreffen zowel de programmacode als de gegevens in bestanden en databases. Daardoor is het moeilijk om de boodschap over te brengen aan het management: dit kan zich de schaal van het probleem gewoonweg niet voorstellen. Probeer bijvoorbeeld het belang van testen maar eens uit te leggen en waarom applicaties die nu goed draaien óók getest moeten worden.
De oorzaak van het 2000-probleem ligt in het weergeven van jaartallen door de laatste twee cijfers. Hierdoor valt 2000 'eerder' dan 1999, wat fouten veroorzaakt in tijdsafhankelijke berekeningen. Verder heeft gebrek aan aandacht voor details geleid tot zorgeloos gedrag en slechte gewoontes, iets dat het probleem nog vergroot. Een voorbeeld hiervan is dat veel applicaties het datumveld gebruiken als speciale marker: 99 staat voor het eind van het bestand, 98 voor speciale korting enzovoort. Dit betekent dat de problemen vóór 2000 zullen optreden, wat inhoudt dat er nog minder tijd is om te herschrijven.
Een ander eenvoudig probleem dat illustreert hoe makkelijk fouten kunnen optreden, is de berekening van schrikkeljaren. Een schrikkeljaar is een veelvoud van 4, met uitzondering van de honderdtallen, tenzij het jaartal deelbaar is door 400. In sommige schrikkelsoftware ontbreekt de 400-regel, zodat 29 februari 2000 wordt overgeslagen.
De omvang van het probleem komt duidelijk naar voren uit het grote aantal 'standaarden' voor het weergeven van data. De - gangbare - Gregoriaanse datum is jjmmdd. De Juliaanse kalender gebruikt de lopende dag in het jaar, weergegeven als jjddd. Er zijn tal van geformatteerde vormen: d/m/j, m/d/j, 25 juni 1996 etcetera. Seriële of integere data, waarbij het aantal verstreken dagen sinds een referentiepunt wordt geteld, lijken bruikbaar - maar software-pakketten gebruiken allemaal verschillende referentiedata. Zelfs binnen één systeem bestaan variaties: op een IBM-mainframe gebruikt DB/2 Jan 1, 0001, terwijl Cobol 370 Jan 1 1601 noteert en Cics Jan 1, 1900.
Door het gebrek aan discipline is er een veelheid aan manieren waarop in programma's met data wordt omgegaan. De hoofdberekeningen, zoals 'hoeveel dagen zitten er tussen de eind- en de startdatum', zijn �f externe subroutine-aanroepen die vanuit copybooks worden ingevoegd, �f, erger nog, inline-code. Daarnaast bestaan er gespecialiseerde technieken en moet je rekening houden met quick-and-dirty ad-hoc trucjes.
Een programma haalt tijdens executie gegevens uit een scala aan bronnen, zoals bestanden, tabellen, databases, parameters en systeemfuncties. Dit is een bron van inconsistentie. Cobol 370 bijvoorbeeld ondersteunt formeel viercijferige jaaraanduidingen; dit is echter een uitbreiding van Cobol II, dat formeel gebruik maakte van tweecijferige codes.
Het probleem blijft dus niet beperkt tot de hoofdprogramma's. Ook JCL, sorteerroutines, macro's, dataset-namen, test-scripts en databases moeten gecontroleerd, aangepast en getest worden. Gezien de spreiding van het probleem over de systemen en applicaties zal de planning van het implementeren en het testen van de veranderingen zeer ingewikkeld zijn.
Het is de moeite waard eens te kijken naar praktijkervaringen op een kleinere schaal; daaruit blijkt het serieuze karakter van het probleem. De meeste organisaties hebben recentelijk een nieuwe versie van een belangrijke applicatie ingevoerd. Bij een upgrading van de code zonder dat de database verandert, vormt het implementeren van de wijziging al een aanzienlijk probleem. Als de database ook verandert, wordt het probleem nog groter: men moet zowel de nieuwe code installeren als de database opnieuw bouwen. Voor veel moderne systemen komt daar het probleem van gespreide verwerking bij. Vaak moeten meerdere sites gewijzigd worden, die zich bovendien in verschillende tijdzones kunnen bevinden. Iedereen die wel eens een verandering in één programma heeft aangebracht, zal zich door die ervaring realiseren dat uitbreiding naar alle programma's geen triviale kwestie is.