The Millennium Bug
Overleeft uw bedrijf de datumsprong?
Bent u een van de potentiële slachtoffers van de `Millennium Bug', een van de meest kostbare vergissingen aller tijden? Ook als u geen Cobol gebruikt bent u niet gevrijwaard. Lees verder en huiver, en maak u op voor een race tegen de klok.
Het magische jaar 2000 staat vlak voor de deur. Er wordt dan ook druk gespeculeerd over de goede zaken die ons in het volgende millennium te wachten staan. Voordat u echter van al dat goede kunt genieten zal er eerst nog een probleem uit de weg geruimd moeten worden. Bij de ontwikkeling van veel (de meeste?) applicaties is geen rekening gehouden met de mogelijkheid dat die software tot in de volgende eeuw gebruikt zou worden. Er zijn dan ook maar twee posities ingeruimd voor het bijhouden van het jaartal. Een computer die 311299 interpreteert als 31 december 1999 zal een dag later (010100) menen dat het 1 januari 1900 is. Dit is waarschijnlijk de meest kostbare ontwerpfout die ooit gemaakt is, de werkelijke omvang van het probleem zal misschien nooit duidelijk worden. Wel duidelijk is dat er n£ nog tijd is om er iets aan te doen, voordat het te laat is.
Algemeen wordt gedacht dat de Millennium Bug alleen optreedt bij mainframe-applicaties, dit is echter niet waar. Vrijwel alle Cobol-gebruikers zullen met het probleem te maken krijgen, hierbij maakt het niet uit op welk platform de code wordt uitgevoerd. Ook is het probleem niet beperkt tot Cobol alleen. Het PC-BIOS heeft er last van. Windows 3.x (mocht u dat gebruiken) weet niet beter dan dat de datum over drie jaar een eeuw teruggezet wordt. Alle applicaties die gebruik maken van een twee-cijferig veld voor het opslaan van een jaartal zullen door dit probleem geraakt worden. De kans dat u aan nieuwjaar 2000 meer dan alleen een kater van de champagne overhoudt is dus verre van ondenkbeeldig. De eerste problemen met de datumsprong hebben zich al aangediend bij reserveringssystemen die meer dan drie jaar vooruitkijken. Het oplossen van de problemen rond de datumsprong wordt door velen gezien als `het grootste project ooit ondernomen'. Het is dan ook hoog tijd om het probleem de aandacht te geven die het verdient.
Hoe groot is het probleem
Er zijn geen vaste richtlijnen die kunnen helpen bij het opsporen van probleemgevallen. Een applicatie die 10 jaar geleden is geschreven kan de datumsprong probleemloos verwerken, terwijl een pas opgeleverde toepassing in de problemen kan geraken. Alles is afhankelijk van de wijze waarop het jaartal geregistreerd wordt. Het zijn ook niet alleen uw toepassingprogramma's die geraakt worden door deze problematiek. Ook backup-programmatuur, tape-management software en opslagbeheer werken vaak met twee-cijferige jaartallen.
De Gartner-groep heeft een onderzoek gedaan naar de omvang van het probleem. Zij gingen hierbij uit van een `middelgroot bedrijf' dat gebruik maakt van 8000 Cobol-programma's met een totaal van 12 miljoen regels code. In die programma's staat gemiddeld iedere 50ste regel een datumreferentie, die gewijzigd zal moeten worden om het probleem te lijf te gaan. Dat betekent dat er binnen drie jaar 240.000 regels code moeten worden opgespoord en gewijzigd. Het kost volgens Gartner 30-40 dollarcent per regel code (we hebben het hier over alle codes, niet alleen de te veranderen regels!) om deze wijzigingen door te voeren. Ook de aard van de bedrijfsvoering heeft een grote invloed op de ernst van het probleem. Het zwaarst getroffen zijn financiële instellingen, verzekeraars en andere tijdgebonden bedrijfstakken. De bedrijfsvoering staat of valt bij een juiste registratie van de datum, en een dag uitval kost kapitalen. Seizoensgebonden bedrijfstakken zijn minder gevoelig, zij hebben meer tijd om het probleem te lijf te gaan. Er zijn geen instant-oplossingen aan te geven, aangezien de omvang en de aard van het probleem per bedrijf verschillend is.
Hoe lossen we dat op
De oplossing van de problemen rond de Millennium Bug kost veel geld, dat is duidelijk. Bovendien zullen deze investeringen niet direct leiden tot betere prestaties of een hoger rendement. Het zal dan ook niet altijd gemakkelijk zijn voor IT-managers om deze investeringen er door te krijgen. De grootste problemen worden niet verwacht bij het veranderen van de foutieve programmacode zelf. Het is met name het testen van de veranderde applicaties en het beheer van het veranderingsproces dat velen nu al de haren ten berge doet rijzen. Er zijn ook al diverse creatieve manieren bedacht om het probleem te lijf te gaan. Zo werd bij een grote luchtvaartmaatschappij vol lof gesproken over de pragmatische oplossing die zij verzonnen hadden voor het probleem. Ze hadden de programmacode gewoon zo veranderd, dat alle jaartallen onder de twintig naar de 21ste eeuw werden doorgeschoven. Dit werkte prachtig, totdat iemand erachter kwam dat deze oplossing roet in het eten gooide bij een van de meest voorkomende handelingen in Cobol-land: het sorteren van een dataset op jaartal. Het is nu weliswaar mogelijk om de sorteer-routine(s) zo aan te passen dat alles weer goed werkt, maar dat brengt weer andere problemen met zich mee. Als noodoplossing kan dit trucje goed werken, maar het blijft een lapmiddel. Een andere oplossing bestaat uit het uitbesteden van het werk in een van de bekende lage-lonen landen (India, het voormalig oostblok). Dit kan op zich goed werken, maar de problemen komen weer terug als de veranderde software hier getest moet worden. Een veelgehoorde oplossing is het meenemen van het millennium-probleem in het algemene onderhoud. Dit is echter alleen mogelijk als alle getroffen programma's in ‚‚n operatie worden veranderd, aangezien de nieuwe code over het algemeen niet compatible zal zijn met de oude code. Twee generaties programmatuur naast elkaar laten draaien op dezelfde data is vragen om problemen. Een goede gelegenheid om deze problemen aan te pakken is bijvoorbeeld bij de invoering van een (nieuwe versie van) nieuwe programmeertaal. Aangezien in dat geval toch alle codes opnieuw moet worden gecompileerd, is het meenemen van het datumprobleem in dit geval een logische keuze. In de praktijk zal dan vaak blijken dat er in het systeem diverse - wederzijds incompatible - manieren bestaan om de datum te registreren. In sommige gevallen zijn het niet de datum-routines die bepalen hoe de datum wordt opgeslagen, maar zit deze functie ergens diep begraven in de applicatieprogramma's. Voeg hier de diverse Cobol-varianten die in gebruik zijn aan toe en hou rekening met de mogelijkheid dat de broncode van sommige programma's onvindbaar zal blijken te zijn, en u krijgt een indruk van de omvang van het probleem. Als een dergelijke migratie toch al in gang gezet is, dan is dit waarschijnlijk een van de beste oplossingen. Het is onverstandig om aan de hand van de datumproblematiek nu te beslissen tot een migratie om aldus twee vliegen in een klap te slaan. Als u nog geen migratieplannen heeft, dan is het nu te laat om die alsnog in te passen bij het oplossen van de problemen.
Wanneer beginnen
Het probleem rond de jaarsprong is al langere tijd bekend, maar het begint eigenlijk nu pas echt onder de aandacht te komen. Op 29-30 januari 1996 wordt in New York in het Radison Empire Hotel een conferentie gehouden rond de problemen met het jaar 2000. In Chicago komt op 18-21 maart 1996 hetzelfde onderwerp ter sprake op de Year 2000 Solutions Conference. Op deze conferenties zal ingegaan worden op de mogelijke oplossingen voor getroffen bedrijven. Er zullen sprekers zijn van een aantal bedrijven die het probleem al eerder hebben opgepakt en nu midden in de conversieslag zitten. Het hele traject, van het bepalen van de grootte van het probleem via het uitbrengen van een projectaanvraag tot de feitelijke conversie zal aan de orde komen. Op het programma staan ook een aantal bekende profeten van `business process re-engineering' die de merites van hun nieuwe bedrijfsmodellen ten toon spreiden. Zoals we al eerder opmerkten vragen wij ons af of het wel verstandig is nu te besluiten tot een dergelijke radicale verandering zonder apart aandacht te besteden aan de oplossing van de problemen rond de datumsprong. Wij zullen u niets nieuws vertellen als we beweren dat dergelijke projecten over het algemeen (veel) langer duren en meer kosten met zich meebrengen dan was gepland. En als het project echt uit de hand loopt heeft u niets om op terug te vallen. We hebben nog geen informatie over een dergelijke conferentie dichter bij huis, maar wij kunnen ons niet anders voorstellen dan dat er hier ook behoefte is aan meer informatie rond dit thema.
Als er in uw bedrijf nog geen speciale projectgroep op dit probleem gezet is, dan is het zaak daar nu mee te beginnen. Ook als u denkt geen last te zullen hebben van het probleem (lees dan vooral het kader `Valkuilen') is het zaak om er aandacht aan te besteden. Het is beter om achteraf te kunnen constateren dat er geen reden tot ongerustheid was dan om op de valreep te ontdekken dat de zaak in het honderd loopt.
Het is niet te voorspellen wanneer u te maken krijgt met de eerste verschijnselen rond de eeuwsprong. Diverse bedrijven hebben er al last van bij budgettering en prognose. Het is ook niet zo dat een systeem dat de eeuwwisseling probleemloos doorstaat daarna geen problemen meer geeft. Die problemen kunnen namelijk ook optreden bij de overgang van 2000 naar 2001. Pessimisten zeggen dat de hele periode tussen 1997 en 2003 als verdacht moet worden beschouwd. Hun mening werd bevestigd door een experiment met een financieel systeem, dat al in 1997 in de fout ging.
Stemmingmakerij?
Sommigen zullen dit artikel en het hele thema rond de eeuwwisseling als stemmingmakerij af willen doen. Dit is het echter niet. Het is een werkelijk bestaand probleem, dat aandacht behoeft. Gelukkig zijn een aantal kwetsbare bedrijven al bezig met het zoeken naar een oplossing, zodat de kans dat uw bankrekening na 1 januari 2000 plotseling negatieve rente zal opleveren niet al te groot is. De omvang van het probleem wordt vooral veroorzaakt door de enorme omvang van de wijzigingen, en niet door de aard van die wijzigingen. Technisch gezien is het eenvoudig om alle twee-cijferige jaarvelden om te zetten naar vier cijfers (of een andere oplossing, er zijn er meerdere). Het daadwerkelijk uitzoeken van alle getroffen toepassingen (inclusief scripts, batch-files, job specifications, etc.) en databestanden en het plannen van de conversie (inclusief testruns) neemt de meeste tijd beslag. Al met al zal dit een grote investering in tijd en geld betekenen (Gartner gaat er vanuit dat grotere bedrijven tot 50% van hun jaarlijkse IT-budget zullen spenderen aan het oplossen van deze problemen). Het negeren van de problemen zal uiteindelijk echter nog veel meer kosten. Er zijn al gevallen bekend van bedrijfsonderdelen die in de verkoop zijn gedaan, omdat het oplossen van de problemen met de datumsprong meer zou kosten dan de verwachte winst van de betreffende bedrijfsonderdelen in de nog resterende tijd zouden tot 1 januari 2000.
Conclusie
Tussen het knallen van de champagnekurken en het vuurwerk zullen op 1 januari 2000 de nodige figuurlijke knallen gehoord worden van applicaties en hele computersystemen die plat gaan. Sommige systemen zullen niet direct crashen, maar eerst nog de hele database vernietigen voordat ze een halt toegeroepen kan worden. Er zullen bedrijven failliet gaan omdat hun factureringssysteem plotseling niet (goed) meer werkt. Wij zullen ervoor waken dat de eerste UNIX Info van het nieuwe millennium ook daadwerkelijk uitkomt in het jaar 2000. Wat heeft u voor maatregelen genomen?
Op dinsdag 28 februari 2006 13:50 schreef Avery het volgende:ik ben dan nieuw ik zie zo dat jij irritant ben jpg
PieAirIk denk altijd heel goed na voor ik iets stoms zeg...