Has anyone doing remediation found any real 9/9/99 problems? What sort of program was it and how bad would the failure have been if you hadn't fixed it?

-- biker (y2kbiker@worldnet.att.net), August 30, 1999

Answers

I got almost 20 years in IT, I don't have any code that uses 090999 or 990909 (yymmdd) formats. I use all 9's to indicate a special EOF condition. This has nothing to do with 9/9/99. I can't speak for everybody else out there. 9/9/99 would only come into play if you program forced you to enter a valid date. In which case, the code would have to be modified to allow you to enter a fake 99/99/99 date.

All of my fixes involved year 2000 fixes. This is the real problem and outweighs anything else. There's just no comparison between this and all the other dates we've been hearing about. We just have a few ignorant ones on this forum that insist they are valid comparisions. Whatever anybody tells you, they aren't. Plain and simple. It's a year 2000 problem.

-- Larry (cobol.programmer@usa.net), August 30, 1999.

I've remediated quite a few programs for Y2k, and have written hundreds or thousands in 25+ years. Never saw a 9/9/99 date sensitivity. Never heard of it. Can't imagine even an idiot writing a program that way.

But 12/31/99 is used for EXACTLY the kind of function people are ascribing to 9/9/99. That is, it's used for an EOF marker, it's used to mean "date that never arrives", etc. It WILL cause the same kind of problem people think 9/9/99 will cause.

This is NOT a 00-year problem, like the "y2k" problem, but it will show up the day before 1/1/2000, and no one will distinguish which problem occurred, when TSHTF. So we ARE going to see 12/31/99 problems, but no one will care. We are NOT going to see 9/9/99 problems, but unfortunately people are still yammering about it, and pollies will use the non-event as "proof" that Y2k is no problem.

So the real problem for 9/9/99, given the false expectations that have been raised for it, is that nothing will happen, and DGIs and DWGIs will feel validated in their non-preps. It would almost be better if something happened, because the cause->effect of non-event->non-prepping is going to hurt us in the long run.

-- bw (home@puget.sound), August 30, 1999.

Doesn't look like it; see thread "List of Dates," above.

-- A (A@AisA.com), August 30, 1999.

In a word -- no.

I've been a big iron programmer on very large mission critical business systems for over ten years. There are only two ways I can think of the 9/9/99 date causing problems.

The first is the expiration dates for some computer tapes. Tape labels can and often do have an expiration date coded. A common one is 99365 which is the Julian date for 12/31/1999. Some tape systems might use 9/9/99 encoded as a date on the tape label to mean the tape is expired and can be scratched. Other systems might take 9/9/99 or 99365 to mean keep the tape forever. If a tape gets scratched, that means the tape can be reused -- and the old data written over. This means that stuff stored is likely to be lost. I think this is possible but unlikely in any company having done remediation. If it does happen, then the question is how important is the data lost? In most companies, lost data causes embarrasment and headaches, but life does go on!

Secondly, if either program logic or input data values of all nines mean something to a computer program that's running that causes an abend or data that doesn't balance, the problem is likely to be fixed quickly. In an abend, the programmer will delete or change the all nines data or record and restart the computer job. Bad report data will probably be adjusted or manually overridden or just corrected and rerun.

In short, 9/9/99 might bring some bugs to the surface, but is no more likely to cause TSTHTF than the Earth is likely to get hit by an asteroid the size of the moon. It MIGHT happen, but I don't expect it to. Hope this helps.

-- Anon (Anon@work.now), August 30, 1999.

You can add me to the list. 31 years of working and playing with computers, and I've never seen it.

Ed Yourdon made some recent comments on 9/9 here:

Another Y2K Problem

Tick... Tock... <:00=

-- Sysman (y2kboard@yahoo.com), August 30, 1999.