I spent many years as a federal programmer and admit that I am personally responsible for some of the systems that will undoubtedly fail at years end. Unless of course, they have been retrofitted to accommodate a 8 digit or larger date field. I have never believed that September 9, 1999 would make a whit of difference due to something that I have never seen in print.

I'll try to keep this simple and short. Generally, date values in COBOL or Fortran programs such as I was familiar with, were read into date variables. A date variable is a programming construct that contains nothing but a date value. Date variables cannot be confused by the computer system with a call to the system for a system shutdown.

The value of the variable can be tested, such as the question, "is this date value greater then X?". Such a test does not mean anything in relation to a system shutdown, unless the test question, written in a coded algorithm essentially said, "If this value is met or exceeded, then perform a system shutdown". A programmer could perform this test if they wanted to in a number of ways.

If such a test was conducted, the variable would sometimes have to be read into a string variable in many cases (not always) and the logical comparism would then be made. Still, string variables don't equate to a system shutdown either - unless a specific test is made in the code testing for a condition that must be met, as in the example above.

The fact that a date variable or string variable could contain a 9999 or 90999 or any combination of these doesn't really mean anything. What Y2K programmers have had to do is to examine the algorithms that test these values. This can be a tricky repair as nested algorithms on COBOL and Fortran code can exceed several hundred lines for a single test condition and it can be easy to make a mistake in the attempted repair of the code.

This may all be rather boring - but the point is, it's not the 9/09/99 that was at fault - it was the test of the values that is subject to failure. If a value being tested does not fall within a certain criteria, it is very possible that the test condition would fail, something unforseen by the programmer and the program would stop running. Nested IF THEN ELSE statements required ALL conditions to be contained or encoded. I have made this mistake myself many times in crafting code by failing to test for all possible conditions or values that may be found in a variable, not just date variables.

So what does this mean? Well, it's not 9/9/99 folks and never was. It's the test conditions that matter and who knows what kind of erroneous code were accidently left in the original programs?

Lastly, the Y2K problems are different. The algorithms are subject to flaws like I previously mentioned, but we have the additional problem of mathematical computations being included. Simply said, you cannot divide by zero - if you do, the program will crash. Enough programs crash and the system itself will shut down.

Thus, a 00 date divided by anything will fail, unless the programmer first tested the condition to find out if a valid number of 01 - 99 existed in the variable in the first place. Few programmers performed these test back then, unless we had a data set that we knew could not be trusted. Inversely, the opposite is true. By assuming we had a data set that could be trusted, we didn't bother to code in the precondition tests. Now that we have interconnected computers, this once held belief of ours may prove to be fatal.

By the way, there lies the real problem. We've got untold amounts of legacy data all written with little bity date fields (too few digits to reflect the actual date or Julian date). Current and future programs running in the year 2000 reading this data are apt to get confused, burp and even stop running due to the mathamatical computation problems.

I don't know if this helps, but nobody ever pointed this out in anything that I've seen. The problems are far more complexed and intertwined then this and I've only covered a tiny bit of it.

The only other thing I'd like to mention is this - it wasn't all the programmers fault that we have bad code in our systems today. It was the bean counters who refused to upgrade the disk drives and memory in those days (this stuff used to cost tens of thousands of dollars). We were forced under budget constraints to write compact code, indeed thousands of hours were spent slimming code down to run efficiently on systems that had little memory and disk space. Thus 1999 turned into just 99 and 2000 turned into 00.

-- Ray Shuster (shusters@montanasky.net), September 09, 1999

Answers

See Those Dratted Nines.

-- Lane Core Jr. (elcore@sgi.net), September 10, 1999.

What sort of algorithm requires division in which the divisor is the year?

-- Lane Core Jr. (elcore@sgi.net), September 10, 1999.

In certain maintenance programs that I had written, I can easily imagine the need to divide the year. Computations of date values and converting them to Julian dates (years back we had to do this manually) is one possibility. This code could easily still be out there. There are undoubtedly many other possibilities, but it's early yet and I've not had my coffee. Ray

-- Ray Shuster (shusters@montanasky.net), September 10, 1999.