Met de kennis van vorige keer over BCD, wat we al een tijdje weten over hoe C met integers werkt, en met wat we weten over hoe een getal in een byte past, zou het oplettende lezers mogelijk zijn opgevallen dat er iets raars is met het Y2K-probleem. U weet het misschien nog wel, dat computerprobleem dat volgens sommigen ongeveer het einde der tijden zou betekenen, maar dat uiteindelijk nogal meeviel. Dankzij de miljarden die consultants over de hele wereld verdienden aan het oplossen van dit probleem natuurlijk. Indertijd werkte ik voor PwC en deed ook wat van dat consultancywerk. Was het paniekzaaien, was het een ramp die gelukkig net is afgewend, of was het dure bangmakerij? Ik heb daar geen oordeel over, maar recent begon ik me wel iets te realiseren.

De kern van het probleem was dat oude computers met krankzinnig weinig geheugen moesten werken. De IBM 1401, een van de eerste echt populaire mainframes, kwam al met een intern geheugen van 2K. En ponskaarten waren nu ook niet een medium waarop je makkelijk veel data kwijt kon. Dus om ruimte te besparen werden jaartallen met twee cijfers en niet met vier opgeslagen. Tot 1999 was dat geen probleem, maar als je zo telt komt na 1999 het jaar 1900. En dat zou voor allerlei problemen zorgen.

Maar klopt dat wel? Bij het naderen van het jaar 2000 domineerde C de markt en de eerstvolgende tien populaire talen waren grotendeels varianten van C. Al deze talen slaan integers op op een manier die geen gebruik maakt van BCD of een vergelijkbare codering, maar in bytes of words. Dat betekent dat een jaartal van twee cijfers makkelijk in zelfs het kleinste formaat gegevens, een byte, past. Na het jaar '99 volgt dan gewoon het jaar '100. Dat zou er misschien gek uitzien, als 19100 of als 1900, maar intern zou dat helemaal niet zo problematisch hoeven te zijn. Alleen als intern een mechanisme aanwezig is om van de 100 een 0 te maken, zou na het jaar 1999 het jaar 1900 moeten volgen. En dat is dan weer wat vreemd. Het zou immers betekenen dat je, om geheugen te besparen, geheugen zou verbruiken voor een dergelijk algoritme dat ook nog eens geen enkel positief doel zou dienen.
Hoe realistisch was dat hele Y2K-probleem dan echt?

Hier wordt het interessant om te bedenken hoe data in COBOL wordt vastgelegd. COBOL sluit niet, zoals C, aan bij de interne gegevens-representatie van de computer, maar bij de gegevens-representatie van mensen. Hier zou je een jaartal kunnen definiëren als

DATA DIVISION.
WORKING-STORAGE SECTION.
01  JAAR  PIC 99.

Omdat COBOL niet werkt met de gegevenstypes zoals de computer die gebruikt, krijg je het Y2K-probleem. Ter vergelijking, met minimaal geheugengebruik levert deze code in C het jaartal 100 op:

    int jaar = 99;
    jaar = jaar + 1;

Terwijl in COBOL de vrijwel identieke code een waarde 00 oplevert:

DATA DIVISION.
WORKING-STORAGE SECTION.
01  JAAR  PIC 99 VALUE 99.

PROCEDURE DIVISION.
    ADD 1 TO JAAR
   STOP RUN.

Wat betekent dat? Het Y2K-probleem was wel degelijk realistisch, maar het beperkte zich tot systemen geschreven in een taal die probeert aan te sluiten bij menselijk begrip. COBOL was in de jaren vanaf pakweg 1990 geen populaire taal meer, dus nieuwere systemen zullen er maar beperkt last van hebben gehad. Oudere mainframe applicaties, geschreven in COBOL, zullen wel degelijk met dit probleem hebben moeten omgaan.

Het levert nog een aardige consequentie op. Applicaties waar niets aan is gedaan en die het jaartal behandelen als een byte + 1900, hebben hetzelfde probleem; alleen 125 jaar later. U kunt dus aan uw kleinkinderen vertellen dat u het Y2K-probleem hebt overleefd, maar dat zij er alsnog last van kunnen krijgen!

Wie mee wil doen met #klooienmetcomputers kan dat doen via GitHub. Maak een account op github.com en zoek naar Abmvk/kmc. Het account Abmvk volgen kan ook. Lezers zijn vrij te gebruiken wat ze willen en om zelf zaken toe te voegen of aan te passen, vragen te stellen of commentaar te leveren.