For all the non-geeks out there, a short description on why the typical application doesn't automatically suffer from 9999 bugs is provided herein.

The primary reason is you need to be using a rather bizzare packed data format. It is not enough to merely be using 9999 as an End Of File marker. The manner of generating the EOF marker is also important.

9999 without bugs:

The typical 6 byte format of yy/mm/dd would code the given date as:

[9][9] / [0][9] / [0][9] *** date of 1999 Sept. 9

assuming each byte is stored as either ascii characters or more likely, as binary integers. Thus the string of nines like 999999 would look like

[9][9] / [9][9] / [9][9] *** end of file marker

which is TOTALLY DIFFERENT from the date above, and no computer will mistake the two.

Of course if you are smart and have the right tools, you can express the same thing in a three byte format using four bits per digit and using BCD (binary coded decimal.) instead of wasting 8 bits per digit. In that case the patterns above still apply (each [n] above represents four bits instead of eight) and your application will have no problems (until y2k of course)

9999 with bugs.

There is another way to express the same data but it is messier and it results in the dreaded 9999 bug:

In this case you are using four bytes formats. The year still consists of two fields using a whole byte for each decimal digit. The month and day each use one byte expressed as a whole 8 bit integer number from 0 to 255.

[y] [y] / [m] / [d] **** the 9999 bug. [0000,1001] [0000,1001]/ [0000,1001] / [0000,1001] **** in binary.

now in THIS case the two data formats are the same and can cause problems.

Additional bug scenarios.

It also depends on how the End Of File marker is inserted into the file. If the software actually packs the EOF marker "manually" by putting in the proper bit pattern then you might get off scott free as I've indicated. However the BIG problem is it is more likely the programmers used the built in DATE functions to "automatically " insert the EOF as follows:

*** append EOF marker;

write BUFFER(i) = Date (99/9/9) close BUFFER(i)

*** file is closed.

In this case the function "Date ()" is used to generate the data and it goes without saying that whether you write

Date (99/9/9) or Date (99/09/09)

the date function will generate THE SAME bit patterns in both cases REGARDLESS of what the actual format is or how many bytes bits it takes or whether it uses julian dating or whatever.

I imagine this is the more common bug.

In fact, your application could be Y2K COMPLIANT and it could still use this stupid EOF scheme. This is a case where using structured programming functions makes things worse because you started using functions in "creative" ways.

-- Hunchback (Quasimodo@belltower.com), September 12, 1999

Answers

and isn't that just like life?!

[y] [y] / [m] / [d] ** the 9999 bug.

[0000,1001] [0000,1001]/ [0000,1001] / [0000,1001] ** in binary.

-- hunchback (quasimodo@belltower.com), September 12, 1999.

I never thought 09/09/99 was a big deal. I work mostly with minis, severs and Pee Cees. It is just not an issue on the little machines. The way the big-iron folks were talking, though, maybe there is something in old ISAM/VSAM and COBOL systems that the above explaination is missing?

There does seem to be a few mainframes that went belly-up either due to 09/09/99 testing, or the lack thereof.

-- Anonymous99 (Anonymous99@Anonymous99.xxx), September 12, 1999.