Earliest big tremors: question for Ed Yourdon

greenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread

In Gary North's April, 1997 edition, p. 4 of his newsletter Remnant Review, North said that his estimate for a pre-Y2K crash in the credit markets (in 1999) might be too optimistic, and could happen earlier. He thinks those markets will crash when the general public in any nation is persuaded the banking system is at risk. He said:

"There is a lurking problem, sometimes called the Year 99 problem. The 99 entry has been used for decades as a shorthand for certain computer commands, such as end of run. It can mean anything that the programmer wanted it to mean, and end of run is a common meaning. When the computer sees it, it shuts down, archives the data, and waits for further instructions that it recognizes. Unfortunately, it does not recognize 99, 00, 01, etc. New York State rolls over to fiscal 1999 on April 1, 1998. The other states roll over on July 1, 1998. The Pre-Millennium Bug problem could hit us then. It will take only one state government to experience a computer crash for word at last to get out to the public: the systems are going down."

My question for you, Ed, is: Is there ANY BASIS IN FACT, IN CODE YOU HAVE PERSONALLY EXAMINED OR ARE SUFFICIENTLY KNOWLEDGEABLE ABOUT WHICH OTHERS HAVE EXAMINED, of even ONE instance where end-of-run/archive data/delete record/stop program/etc. would be triggered by a rollover to a 1999 fiscal year such that a system would likely collapse? While it is not difficult to find programmers who are quite openly seriously concerned about collapses on 01/01/00, I cannot confirm that a single programmer anywhere is particularly concerned by the fiscal year, 1999 rollover taking place April 1st in New York, July 1st in most other states, and who knows when in corporations and governments all over the world. On the other hand, I find it strange that I am the only one persistantly and publically following up on whether this might be an early iceberg there is reason to believe we will crash into.

Your comments, please?


-- Jesse (Tooclassy@aol.com), February 17, 1998


This is sometime I have been wondering about also, and while I am not a programmer, I have attempted to read up on the issue. First, the question concerning the use of 99 for anything other then a reference to the year 1999 seems to be a software designer's choice. I would suppose that this use would apply especially to older, legacy type programming codes. Second, because it was a designer's choice, I tend to doubt it would be a embedded chip problem. As an aside, the bank that holds my aunt's IRA account had to take back their first attempt at projecting her required IRA distribution, account of "computer problems" and said they would issue the correct payout figure "before the end of this year". No mention of y2k, but I suspect that when they had to project past 2000, their program had difficulties. Gary North is 100% correct about the banking system: as long as people can get their own money out at will, they don't care about any y2k stuff. But when there starts to be problems, like my aunt's IRA payout, the public will get interested real fast. 1999 could will be the start.

-- Dennis Sherwood (emdesher@iconnect.net), February 17, 1998.

While I only program client-server on PC and UNIX, I have seen an AS400 system that stored dates as character, not date format and used the 9 fill for various reasons. (and that company hasn't started their Y2K work yet! !)

-- Rebecca Kutcher (kutcher@pionet.net), February 17, 1998.

I don't see this as terribly likely to be a problem, and I'll tell you why. (This is based on my experience of mainframe COBOL programming. Your results may vary.)

A date might be defined this way:

01 order-date. 03 order-month pic 99. 03 order-day pic 99. 03 order-year pic 99.

Now, what this means is that we've defined a six-character field called "order-date" which consists of three two-character fields. So, here's today's date's value in the case of each of the four variables:

order-date = 021798 order-month = 02 order-day = 17 order-year = 09

Now, I might well use high values -- in the case of numeric fields, that means nines -- to indicate the upper end of a range, termination, etc. However, it would go against my grain as a logical, not to say anal-retentive, computer programmer type to put zeros in the middle of my high value. In other words, I would not use

order-date = 090999 order-month = 09 order-day = 09 order-year = 99

Instead, I would use a truly impossible, truly at-the-high-end value:

order-date = 999999 order-month = 99 order-day = 99 order-year = 99

Another reason, besides my obsessiveness: The last thing I want is a user entering a value like that which I've reserved to have a special meaning. Month and day values of "09" are both within the normal parameters; values of "99" are not.

Having said all that, I'm sure that there is a system or two scattered about that will run into exactly the problem described, but my guess is that it won't be very widespread.

-- Greg Carter (gcarter@cartersystems.com), February 18, 1998.

Yowser! Sorry about that; the message board software didn't take my carriage returns seriously. Hope it's still reasonably legible; if not, email me directly and I'll email you back and, if we're lucky, the email software won't find a way to screw it up... ;)

-- Greg Carter (gcarter@cartersystems.com), February 18, 1998.

This is a test This is only a test of the test a test

-- Testing (Testing@test.com), June 29, 1999.

Moderation questions? read the FAQ