Het probleem met de overgang naar het jaar 2000 zit hem niet slechts in aanpassing van applicatiecode, maar gaat veel verder. De praktijk is dat het ook bedrijven treft die nog werken met oudere, over het algemeen zeer stabiele systemen. De gevolgen voor vervanging van systeemsoftware en daarmee de hardware zijn niet te onderschatten.
De afgelopen maanden is veel geschreven over de problemen rond het jaar 2000. Aanpassing van applicatieprogrammatuur is het credo. Ontwerp een goed plan, analyseer alle aan te passen resources en ga aan de slag. Ook is al aan de orde geweest dat vooral machine-geschreven code een enorm probleem oplevert, omdat de tools voor scannen niet in staat zijn om deze code nauwkeurig te onderzoeken. Broncode is al verdwenen, en de bouwers ook.
Uit diverse brochures, ondermeer van IBM, valt op te maken dat het niet slechts een mainframe-probleem is. Het probleem komt voort uit de tijd dat geheugens peperduur en klein waren. Programmeren was vaak kunstwerk en alle ruimte (bytes) moest goed worden benut; efficiënt schrijven, afkorten waar nodig, nauwelijks teksten in de programmatuur en, natuurlijk, die datum! Geheugens van 64K waren geen uitzondering en daar werd heel wat in gedaan, meestal in assembler talen (machinecode) – overlay-structuren en wat niet al meer, om toch maar die overzichten te produceren die noodzakelijk waren. Uitbreiding naar 128K was al heel wat.
Het programmeren, met name in Cobol, ging al minder efficiënt; ‘geheugen zat’ was het idee. Functionaliteit werd toegevoegd, maar aan de datum werd niks gedaan; daarvoor bleven twee plaatsen beschikbaar. Verder zijn hele besturingssystemen geschreven in assemblercode.
Het probleem met de overgang naar het jaar 2000 zit hem niet slechts in aanpassing van applicatiecode, maar gaat veel verder. Vooral voor bedrijven met oudere systemen die zijn aangekocht en niet (meer) ondersteund worden, is dit een groot probleem. Een compliment voor de producenten en leveranciers is op zijn plaats, omdat dergelijke systemen nog werken. Ze zijn zo stabiel, dat bedrijven geen redenen zagen ze te vervangen. Die bedrijven hebben hun kosten al lang en breed terugverdiend, en in sommige gevallen zouden de systemen nog jaren mee kunnen, ware het niet dat het jaar 2000 nadert.
Onmacht leverancier
Voor dergelijke bedrijven betekent het jaar 2000 niet alleen aanpassing van de applicatiesoftware. Ze moeten ook de systeemsoftware aanpassen, en als gevolg daarvan de hardware vervangen, omdat met de invoering van nieuwe architecturen de systeemprogrammatuur niet meer op oude machines draait. In bepaalde gevallen betekent het ook vervanging van softwarepakketten of ontwikkelingen daarin; een compleet nieuwe aanpak.
In eerste instantie lijken leveranciers onwillig om oude systeemsoftware aan te passen, omdat ze nieuwe willen verkopen. Die gedachte is echter niet gegrond. In de jaren tachtig begon men te beseffen dat archiefmateriaal op bijvoorbeeld magneetband wel eens tot in het jaar 2000 bewaard zou moeten worden. Hiervoor moest dus systeemsoftware worden aangepast. Om niet het hele systeem overhoop te gooien, zijn allereerst die componenten aangepast die betrekking hebben op de eeuwwisseling. Andere systeemcomponenten bleven ongewijzigd. Vooral voor oudere systemen, waarvan het onduidelijk is of de broncode nog bestaat, kan en wil de leverancier geen enkele garantie geven dat deze nog goed blijven functioneren. Ze zijn veelal geschreven in assemblercode en zonder broncode is nauwelijks te traceren waar zich de datum-componenten bevinden, laat staan dat de relatie tussen de verschillende systeemcomponenten terug te vinden is. Ik ken geen enkele partij die daartoe met de bestaande ‘millenium-scanningtools’ in staat is. Het is dus niet zozeer onwil, dan wel onmacht van de leverancier. En niet onterecht; deze maakt ruim van te voren bekend wanneer de ondersteuning op software afloopt. Men kan niet verwachten dat deze eeuwig wordt bewaard.
Bij een bepaald systeem is geconstateerd dat met de overgang van 31 december 1999 naar 2000 het systeem op 2 januari begint. Een dag wordt overgeslagen; mogelijk een constructie waarbij het schrikkeljaar in het geding is.
Overigens moet vermeld worden dat het testen van de eeuwwisseling zonder een goede backup niet zonder risico is en zelfs funest kan zijn. Voor hetzelfde geld worden alle bestanden met een (2 cijfers) bewaarperiode na (19)99 plotseling uit catalogi verwijderd en is men na een normale start ineens alles kwijt. Wees op uw hoede!
Repository
Uit bedrijfsmatige overwegingen kan men niet het risico nemen om met een verouderd systeem door te gaan. De overgang naar een nieuw systeem is daarmee dan ook gerechtvaardigd. Dit kan ook grote voordelen hebben. De ontwikkeling is natuurlijk niet stil blijven staan; betere opslagmethoden, betere communicatiemiddelen met ‘de buitenwereld’, terwijl de kosten van hardware en onderhoud aanzienlijk zijn gedaald ten opzichte van het oude ‘ijzer’.
Tot zover de systeemsoftware; resteert nog het probleem met de applicatiesoftware. De voortgang in de nieuwe systeemsoftware kan ook voordelen bieden met betrekking tot de aanpassing van applicatieprogrammatuur en andere resources die te maken hebben met het millenium-probleem. Zo bestaat bij een mainframeleverancier een ‘language environment’; een verzameling routines in een run-time library die het mogelijk maakt bepaalde velden aan te duiden als ‘2-digit-century’. Ook het sorteerprodukt heeft die functionaliteit en zorgt voor de logisch juiste volgorde. Niet in alle gevallen is het dus nodig de datum uit te breiden tot 4 cijfers. De ‘language environment’ zorgt voor de juiste interpretatie. Hiermee kan heel veel werk worden bespaard, zij het dat wel activiteiten moeten worden ondernomen om aan te geven dat dergelijke rubrieken een 2-cijferig datumveld vertegenwoordigen. Al eerder is in artikelen over het millenium-probleem het belang van een repository aan de orde gekomen; een database waarin alle componenten die aan elkaar gerelateerd zijn voor wat betreft de wijzigingen voor het jaar 2000, zoals job-control, bestanden, programmatuur, worden vastgelegd. De vraag is echter hoe die wordt samengesteld. Het maken is één, het bijhouden is twee. Een repository die niet automatisch wordt bijgewerkt is niet volledig en zal na verloop van tijd niet meer actueel zijn zolang systeemontwikkeling op de diverse systemen gewoon doorgaat. Bij aanpassingen in de applicatiesoftware is het van het grootste belang de repository permanent bij te werken. Vooral in grote gedecentraliseerde omgevingen is dit geen senicure. Dergelijke systemen zijn overigens wel te koop, zij het dat de kwaliteit en functionaliteit nog al eens verschilt. Het systeem dat ik ken is zeer professioneel; via het netwerk brengt het grafisch alle gerelateerde componenten die in een gegevensmodel zijn gedefinieerd in kaart. Dit alles wordt om de zoveel tijd dynamisch bijgewerkt, zodat de informatie actueel blijft. Het systeem biedt mogelijkheden om aanpassingen op een of meer componenten online uit te voeren. Een impact-analysesysteem dat niet slechts gebouwd is voor het milleniumprobleem, maar door de grote functionaliteit een grote bijdrage kan leveren, zodat kan worden voorkomen dat een deel vergeten wordt. Het belang van een dergelijk systeem is niet te onderschatten, want juist bij gebreke daarvan kan nog een heleboel ellende achteraf ontstaan. Relatiebeheer voor het jaar 2000; als dat iets breder kan dan via de computer, kan het bedrijfsleven de ‘overgang’ wel aan.
Hans Bladergroen
