De oplossing van het ‘2000-probleem’ in bestaande applicaties bestaat uit twee delen: gegevens opschonen en code opschonen. Gezien de schaal van het probleem en de beperkte tijd die er is om oplossingen te implementeren, zijn planning en projectmanagement cruciaal.
Om de gegevens op te schonen, moeten alle datum-velden in elke database worden aangepast. De nieuwe database zal alleen met nieuwe programma’s werken. Omdat het lang zal duren voordat de ‘schone’ systemen geïntroduceerd kunnen worden, moeten de bestaande en de nieuwe systemen enige tijd naast elkaar draaien. Alle bestanden en databases moeten op een ordelijke manier gelezen, gewijzigd en herschreven worden. Het is waarschijnlijk niet mogelijk om de benodigde wijzigingen op bestaande gegevens uit te voeren. Soms moet het datum-veld immers van twee naar vier posities worden uitgebreid. Bovendien zullen oude en nieuwe programma’s enige tijd naast elkaar bestaan.
Hoewel ook de timing van database-conversies cruciaal is, zal het grootste probleem een tekort aan middelen zijn. Parallelle verwerking eist twee keer zoveel opslag- en verwerkingscapaciteit. De benodigde middelen zijn meestal wel te huur, maar omdat iedereen tegelijkertijd extra capaciteit nodig heeft, is er een probleem. Schaarse middelen zijn duur. Ook ontstaat een archiveringsprobleem: archieven en online-databases moeten gecoördineerd worden, wat de druk op systeemmiddelen extra verhoogt.
Database-conversie is een bekend probleem (zij het niet op deze schaal); het opschonen van de programmatuur niet. Dat zal dan ook meer inspanning kosten. Bovendien zijn nieuwe technieken en investeringen in specialistische software-tools nodig.
De eerste en moeilijkste opgave is het evalueren van de huidige systemen en het ordenen van de hoeveelheid werk. Het is niet praktisch om eerst programma één te doen, dan twee en zo alles af te lopen. Sommige programma’s zijn belangrijker dan andere. Een aantal programma’s is het wijzigen niet eens waard. Idealiter resulteert de evaluatie van bestaande programma’s in drie categorieën: ‘goed’, ‘slecht’ en ‘matig’. Goede programma’s hoeven niet aangepast te worden, matige wel, en slechte moeten vervangen worden. In die fase zullen veel organisaties kiezen voor het vervangen van bestaande systemen door pakket-oplossingen. In de praktijk kost het implementeren van een pakket drie jaar. Het is dus misschien wat laat om daar nu nog mee te beginnen.
De industrie is al een tijdje bezig met het ontwikkelen van algemeen toepasbare software-tools voor code-analyse. Het 2000-probleem is slechts één van de toepassingsgebieden voor dergelijke tools. Het punt is dat alle organisaties nu tools nodig hebben, en vrijwel niemand er praktijkervaring mee heeft. Ze moeten nu boeten voor het voortdurend te weinig investeren in software-onderhoudstools.
De evaluatie van programma’s moet in feite een inventaris opleveren die orde in de chaos brengt. De onderlinge referenties en afhankelijkheden tussen programma’s, gegevens en JCL zijn inzichtelijk te maken door een bill-of-materials op te stellen. Als ook een gedetailleerd gegevensmodel kan worden opgesteld, is dat van blijvende waarde. Door dat vastleggen van details over de systemen, kan het werken aan het 2000-probleem nog wat lange-termijn voordelen met zich meebrengen.
Omdat al dat werk onvermijdelijk is, zou het verder moeten gaan dan code-wijzigingen; de code moet waar mogelijk geconsolideerd worden. Te denken valt aan code herstructureren (als dat nog niet gedaan is), overtollige code verwijderen, en consistente subroutines introduceren. Het opbreken van grote modules in kleine, eenvoudiger te onderhouden modules is wenselijk, maar kost meer. Nu 2000 nadert, moet een eventuele code-consolidatie beperkt blijven.
De gegevens zijn op te schonen door het datum-veld uit te breiden van twee naar vier posities. Dit vergt extra opslagruimte en kan ertoe leiden dat databases opnieuw ‘getuned’ moeten worden. Zo luidt de aanbeveling van Ansi, die voor Gregoriaanse data jjjjmmdd aanraadt, voor Juliaanse jjjjddd en voor integere (de Cobol 97-standaarden) ‘Jan 1, 1601’. Deze regels moeten strikt nageleefd worden. Een alternatief is het coderen van de eeuw-waarde in de hoogste vier bits van het byte dat voor het huidige decade wordt gebruikt (bijvoorbeeld 0 = 17-de eeuw, 3 = 20-ste eeuw, 15 = 32-ste eeuw). Dat moet voldoende zijn, en zo kan het aantal posities voor de datum in de database hetzelfde blijven. Standaard-trucjes (bijvoorbeeld: jaren boven de 75 vallen in de twintigste eeuw, jaren onder de 76 in de eenentwintigste) zijn niet aan te bevelen, om problemen in de toekomst te vermijden. Mijn advies luidt: volg de Ansi-aanbevelingen!
