I recently found a graphic presentation by Gartner Group, but have lost the link. One graph shown at a Senate hearing was called "How Many Failures and When?" It indicated that so far in 1999, we should have experienced about 5% of all the "failures" that will occur from Y2K (5% occurred prior to 1999). The graph showed that the number of failures per day in Jan.,2000 would be far greater than they are now, but not astronomically greater- maybe 8 or 10 times greater. Since I have heard of no serious disruptions from failures in even the most unprepared parts of the world, I would expect next year's failures to be less than catastrophic, except for one thing. If there is an easily definable qualitative difference between failures now vs. next year, all comparisons are meaningless. So here's the question, and I'm hoping for IT people to respond, not just idle speculators like me. Will the same types of quick fixes/workarounds that are being used this year be available in January and beyond? Example: one that I don't think will be usable is the quick fix by some of the state unemployment commissions, who are entering 12-31-99 as the expiration-of-benefits date. Of the fixes or bandaids being used now, is that the rule or the exception?

-- Bill Byars (billbyars@softwaresmith.com), May 10, 1999

Answers

I think you're right. If there is a lot of dirt being swept under the carpet right now, 1/1/2000 is when the carpet disappears.

However, I don't think that pre-2000 appearances of Y2K bugs can all be the sort that can be got around just by entering fake dates. And although I'm still cautious, I'm beginning to think that there is some cause for optimism to be gained from the fact that things are no more noticeably screwed up than they were six months ago.

-- Nigel Arnot (nra@maxwell.ph.kcl.ac.uk), May 10, 1999.

It really depends on the type of system. For instance, if you don't care about the date in a system but time inherently includes year as yy, you can select a quick fix like setting year to some other year, on the other hand if you have a complex IT system that makes decisions on date you've got a problem.

In general with IT systems, early problems have been spacing themselves out, allowing bandaids and a "fix on failure" methodology. This won't be the situation very soon. Solar Max starts in december, and it will disrupt communications, all of the realtime system, hardware and COTS software issues hit on rollover, the file maintenance and archiving failures start at 00. Many logic faults start as soon as 00 hits. There are going to be some VERY messed up systems. I think many won't be fixable. The question to me is how early we start to reach the situation where things aren't fixable. Mid December?

-- noel (ngoyette@csc.com), May 10, 1999.

Bill,

One aid in analyzing Y2K factors is to consciously distinguish between the present and the future in terms of dates referenced by software.

>Qualitative difference between 1999 failures and 2000 failures?

In 1999 a year number of "00" is of a future date (assuming that the "00" is supposed to represent year 2000 rather than 1900), and the current year is represented by "99". So failures to properly handle year "00" will be limited to processing of future dates.

(When I write "in 1999", I'm speaking here of systems that do not have their clocks set forward to 2000 already, such as some test systems do.)

But in 2000, "00" will be the current year number, so mistakes in handling the zero year number can occur in processing of current dates, which did not happen in 1999 (in systems whose clocks were set to current real time).

>Will the same types of quick fixes/workarounds that are being used this year be available in January and beyond? Example: one that I don't think will be usable is the quick fix by some of the state unemployment commissions, who are entering 12-31-99 as the expiration-of-benefits date. Of the fixes or bandaids being used now, is that the rule or the exception?

Note that the essence of the quick fix in the state unemployment example is to substitute a pre-2000 date for the proper post-2000 date for a *future* (expiration of benefits currently authorized) date. This avoids triggering erroneous handling of post-2000 dates ... for a while.

But every day now the number of future days that are pre-2000 and thus can be plugged in to this type of fix decreases by one. After December 31, 1999, the supply of pre-2000 future dates drops to zero, and _that quick fix method is no longer available_.

Many other fixes or bandaids can be categorized like this one -- use (improperly, as a temporary measure) of a pre-2000 date instead of the proper post-2000 date. All of them have the same defect -- their lifetime is running out at the rate of one day per day.

-- No Spam Please (No_Spam_Please@anon_ymous.com), May 10, 1999.

Do you honestly think that we are going to be TOLD about these problems? What about all those food vouchers that got handed out accidently earlier in the year to a whole bunch of people in the states? What about the AOL (?) crash?

Keep looking guys, the info you seek is out there...waiting to be found..

-- Laura (someone@home.com), May 10, 1999.

In order to get a true picture of the qualitative difference, you need to take a look at the scenarios one at a time.

1st - if power is down then we won't even know about other problems until after the power is restored (ie. replacing imbedded chips, fixing system bugs, etc.)

2nd - if the computer operating system has trouble with the year 2000, then it may be necessary to wait for an operating system fix before you can determine if the application software has problems.

3rd - Once processing begins on the application system, then we will know how the current dates (y2000) are being handled, as 2000 or 1900. It should be noted that since different programmers work on any one system, different parts of the system may recognize 2000 and others will see 1900.

At this point, everyone should pretty much know the scope of changes needed to fix the problem. Of course, all this will occur after 1/1/2000, since there is no way to find all the problems by the end of the year.

Finally - if the effort required to fix the problem is greater than the number of programmers available to work on it...then it probably won't get fixed and the company may go out of business.

Qualitative vs. quantitative ... the problems that are fixed this year have the luxury of being completely tested before going into a production environment. Next year that won't be the case, and chances are more problems will be created than fixed.

If any 1 of the scenarios occur, it may only be 2 days to 2 weeks, until the problems are resolved. However, for each additional scenario you can add on another 2 to 4 weeks. Also, tack on an additional 2 weeks if your application software has been purchased from a vendor (ie. Microsoft), since they will have to ship the fixes to you. And be aware that scenario 3 can exist multiple times on one computer, since most companies have more that one application system installed.

-- DJ (reality@check.com), May 10, 1999.

Bill,

The qualitative difference would be that failures now would be mostly in accounting software. January 2000 failures will also affect systems that deal with manufacturing and distribution, which will be much more noticeable.

-- Kevin (mixesmusic@worldnet.att.net), May 10, 1999.

Or as PNG put it...

http://www2.gol.com/users/png/fy_rollover.html

Fiscal years have little to do with company or country operations. Producing products, providing services and distributing them are the elements that create commerce. Looking ahead in projections and deciding where and when you are going to post the results is keeping score...not producing, providing or distributing.

-- Kevin (mixesmusic@worldnet.att.net), May 10, 1999.

1999 is in the same run of numbers (sometimes called "epoch") as 1998, 1997, etc. 2000 is different. This we all know.

In 1999, most programs will still work, probably as far as the public is concerned (aware of). Any problems in 1999 with lookahead probably won't affect the public too much (with the exception of stuff like the credit cards expy dates we've heard about). Problems in 1999 with lookahead to 2000+ will very much impact stuff internal to the company, though.

Now, come 2000+, the public will see a lot more of the screwups; they won't be just/mainly internal to the company any more.

-- vbProg (vbProg@MicrosoftAndIntelSuck.com), May 10, 1999.