From about October last year

Y2K will not be a one-time event

) 1999 Michael S. Hyatt

Far too much emphasis has been placed on midnight, Dec. 31, 1999. It is as if the Year 2000 Computer Problem is an explosive device set to detonate at that very moment. The image in many people's minds -- straight out of an action movie thriller -- is that of a hidden time bomb, relentlessly counting down the seconds, and at the moment it clicks to "0," a cataclysmic explosion erupts with a deafening roar. It may come as a surprise for some people, but it is entirely likely that things will appear normal when we wake up on the morning of Jan. 1. This is because Y2K is an ongoing process much more than it is a single event.

Now, of course, if you live in an area which is hit by a Y2K-related power outage, water system failure, or chemical plant accident (just to name a few possibilities), New Year's Day very well may seem like a movie -- a disaster flick. But for most folks, at least in the United States, the initial days of the Year 2000 might be little different than the final days of 1999.

President Clinton's federal Y2K czar, John Koskinen, predicts a national "sigh of relief" in the early hours of Jan. 1, as the basic infrastructure of our society remains intact and operational. Koskinen's implication is that except for some scattered electronic failures during the first few weeks of 2000, the successful rollover to Jan. 1 will mean that the Y2K problem has been conquered.

I agree with Koskinen (one of the very few times!) that a national sigh of relief is possible on Jan. 1. But this will in no way indicate the Y2K problem has been "conquered" and that we are out of the woods.

Some commentators take delight in deriding those of us who have prepared for millennium bug disruptions, sarcastically asking what we are going to do with large stockpiles of food, water, and fuel on Jan. 2. "Boy, you're going to feel pretty foolish with your basement full of rice and beans when the power stays on in January," is the general sentiment.

If the basic utilities remain intact and operational in your area during the first week of January, I suggest you avoid the temptation to sell off your supplies or give them away.

Y2K is not a one-time event. It is not a yes-or-no situation, with Jan. 1 being either a disaster or a non-event. The Y2K problem is not like a car cruising down the highway and suddenly hitting a cement wall. It is more like a car cruising down the highway, and then the highway turns into 20 miles of dirt road. The car begins to shudder and must slow down. Although the car is still moving, it is not moving nearly as smoothly and efficiently as before.

The Institute of Electrical and Electronic Engineers (IEEE) sent an open letter to Congress earlier this year about the Y2K phenomenon, which said, in part, "Y2K is a long-term, not short-term, problem. ... Y2K is much more about the dates that can span the century boundary represented in data that must be processed by software, than it is about any calendar time or clock issues ... it will take years for the infrastructure to 'calm down' after Y2K impacts."

Bruce McConnell is the director of the International Y2K Cooperation Center, an information clearinghouse sponsored by the World Bank and the United Nations. In an October 1999 interview, McConnell said, "Y2K-caused effects on daily life will be complex and more chronic than acute." He explained that a picture is emerging of failures that may bounce slowly from one sector to another. When the Year 2000 arrives, according to McConnell, we are likely to see "a growing slowdown in commerce as capacity is reduced by a confluence of degraded infrastructure performance and shaky consumer confidence."

Mike Fletcher, a Y2K consultant, speaker and author, has spent the past few years traveling around the globe helping various corporations and government agencies deal with the Year 2000 problem. In a recent Internet column, Fletcher discussed a video conference in which he participated. During the conference, a representative of the U.S. Small Business Administration (SBA) said there are 24 million small businesses in this country, with "small business" being defined as any company with 500 employees or less. When we reach January 2000, according to the SBA, approximately 8 million of these small businesses will be fully ready for Y2K, 8 million will have done enough repair work to muddle through, and 8 million will have done nothing to address the problem and will be at risk of failure.

Even if you assume the at-risk companies are very small businesses, with only a few employees each, this still means there are tens-of-millions of U.S. jobs which are threatened by Y2K. So even if the basic utilities remain intact in early January -- power, phones, water and sewer, banks, etc. -- Y2K problems could slowly and steadily wreak havoc on the economy as we move through the Year 2000 and beyond. As Bruce McConnell explains, the fallout from Y2K glitches could eat away at economies for months.

This is why a stockpile of emergency supplies will still be valuable next year even if the worst-case scenarios do not come to pass. Despite the ribbing you may have to endure from neighbors and friends because you decided to store up supplies, your stash of goods will come in handy if:

Selected products become unavailable. Even the most optimistic forecasters admit global supply chains will be impacted by the Y2K problem. It may not be life-threatening, but a temporary shortage of, say, coffee or toilet paper will be a major inconvenience. The items you accumulate during 1999 surely will not go to waste next year.

Prices skyrocket. As we saw with the oil crisis in the early 1970s, a small reduction in supply can have a drastic effect on price. Every industry, not just the oil business, is threatened by Y2K disruptions. The prices for certain key products could double or triple, or worse, if the disruptions are significant. Anything you can acquire now, at 1999 prices, may turn out to be a tremendous bargain by next year.

You lose your job. Even without the looming Y2K problem, many experts say our economy is due to cool off. When Y2K is factored in, the current economic good times could suddenly become a distant memory. It's a fact: when the economy slows down, many people lose their jobs. Having a sizable stockpile of food, water, and fuel won't pay your mortgage or find you a new job, but it just may reduce some of the anxieties and solve some of the problems that often accompany unemployment.

It would be nice if we could know the full impact of Y2K by Jan. 2, 2000. Unfortunately, that is not the case. The full impact of this unprecedented situation will not be known for quite some time. Regardless of how it turns out -- and don't get me wrong, severe life-threatening breakdowns are still a distinct possibility -- it is wise to make preparations.

The supplies you accumulate now may be needed to protect the health and safety of your loved ones. Or they may be used simply to make your life a bit more comfortable next year. Either way, the only foolish Y2K preparation you can make is the decision to do nothing.

-- (.@...), January 05, 2000

Answers

Well said.

I have always been concerned about economic problems, and having been (suddenly) unemployed before with no idea how I was going to pay for my next meal, prompted me to make some preparations. Living without a job for five months, even with unemployment insurance, is no picnic.

Storing some food and necessities are just basic common sense and people should not be reviled for doing what they thought was best for themselves and their family. We should keep the following quote in mind: "The dirty little secret about freedom means 'you're on your own'" --Supreme Court Justice Clarence Thomas

-- Marie (pray4peace@compuserve.com), January 05, 2000.

"The image in many people's minds -- straight out of an action movie thriller -- is that of a hidden time bomb...,"

Man, oh man... anybody out there know who could have helped propagate that "Time Bomb" (2000) nonsense.

Let's out him!!

-- Jim Thompson (jimthompsonmd@attglobal.net), January 05, 2000.

Y2K bug prophet warns next few weeks crucial

-- It ain't over (till@its.over), January 05, 2000.

Do you know what the problem here is? Most of us doomers are a bunch of amateurs when it comes to using scientific methods to arrive at conclusions. Look guys, we used the "belive the experts blindly" approach and we bombed out, royally. So lets stop re-hashing the same old tired arguments without subjecting them to some scrutiny.

I'm a doomer and sliently hoped the world would be shaken at its foundations for a few weeks because of the "Different stmuli, Different response" theory. Best that could have happened was that the wester world would have been shaken out of its lust for more and more - a, la David Suzuki. Well it aint gonna happen. Ok, I can live with that and I've got enough variatey in my stockpile to keep me eating the way I used to for 6 months or so.

But now we are into figuring out where this beast called y2k went and hid and lets not predict this using the same flawed approach we used pre y2k. Lets remember those who don't study history are doomed to repeat it.

So from the post at the top, for example we have the following said:

During the conference, a representative of the U.S. Small Business Administration (SBA) said there are 24 million small businesses in this country, with "small business" being defined as any company with 500 employees or less. When we reach January 2000, according to the SBA, approximately 8 million of these small businesses will be fully ready for Y2K, 8 million will have done enough repair work to muddle through, and 8 million will have done nothing to address the problem and will be at risk of failure.

Ok lets pick this appart rather than swallow it whole blindly and choke on it again later. I submit the following:

The 8m that will be ready probably have between 20-500 employees and therefore use a serious number of IT systems such that failure would cause a sever problem which is why they have prepared.

The 8m that will muddle through probably have between 3-20 employees and again will be ok since they probably can resort to manual payrolls etc. and "muddle through" as was suggested.

The 8m that did nothing probably have between 1-2 employees and are home based businesses (they are included in these stats) that basically have a PC with the usual suite of e-mail etc. and can fix all that quickly if it fails, i.e. they will obviously be in FOF mode (easily running on manual mode until failuers are fixed), but I am willing to bet that not one of those "businesses" will go bankrupt because of y2k because the just don't have "mission critical" applications that affect hundreads or thousands of customers. Those that do have failuers (because not all 8m will) will just have a bit of trouble putting out reports, letters and the like for a few days till they fix the PC, software etc. or just buy another one and get on with life.

So lets not get all fired up about these "small businesses" causing massive unemployement etc.

Time for the doomers to wake up a bit and realize, it will not be death by a thousand knives, but sort of like being eaten alive by a thousand ducks. It sure going to feel bad while they try, but it just aint going to happen in the end.

-- Interested Spectators (is@the_ring.side), January 05, 2000.

Oh no! You mean I have to keep paying attention to what's going on around me? I thought it would all be over in about 2 hours, with frequent 3 minute breaks to allow me to view exciting consumer opportunities! ;)

Thanks for the post, it's a timely reminder.

-- Servant (public_service@yahoo.com), January 06, 2000.

Interested Spectator, your point is well taken. Still, question for you though: How come Brazil and India and Italy did very little and STILL they absolutely NO y2k problems?

I know Argentina pretty darn well Y2K-wise, and the above cited SMB split goes approximately like this: One third did 'something' (not full remediation and testing by any means) and two-thirds of SMB's did ABSOLUTELY nothing ! Please don't tell me these SMB are not IT-rich because it's simply not true.

-- George (jvilches@sminter.com.ar), January 06, 2000.

PCs and the like are not going to be reported and that technology is current with the first world and is largly ok (if you look at microsoft, you'll a lot of stuff is compliant as long as you don't do a few things -- even Windows 3.11 is ok as is unless you try and change the date/time on Feb 29 itself or as long as you don't care about the format of the date when doing a directory listing (its incorrect)).

Only the largest companies in the third world uses technology sufficiently that problems would show up on the y2k watchdog radar screens. And even then the errors will show up in the business systems (I deal with embeds below) at the same time as over here probably on the 31 of Jan if they do. Here's why from my post on 1.1.2000Yes embeds are "non-issue" BUT IT will have its real rollover test TONIGHT here's why

In a nutshell:

You see if you done any programming you know that must of the bugs occur at what are known as boundaries. Now 1/1/2000 is a boundary. It is a boundary when you rollover and it remains a boundary until you use it.

Boundaries cause errors just prior to the boundary, at the boundary and just after the boundary. That is the rule of programming.

So you can expect the potential for the most errors at the following times (amongst other times) for IT systems:

Begining of first month before boundary. Begining of first payroll (etc.) before boundary. Begining of first week before boundary. Beginign of first day before boundary. After boundary has crossed. Begining of first day,month,week,payroll etc. after boundary. End of First day after boundary. End of First week after boundary. End of First payroll after boundary. End of First month after boundary. End of First quarter after boundary. End of First year after boundary.

The vast majority of potential errors come where the vast majority of the date calculations can occur. These occur in the After periods when we reach the End of xxx time.

The other issue is the embeds.

I think what I posted in the following thread is why nothing happend during rollover and nothing will with respect to the embeds (though I didn't figure this out till afterwards!). Exerpts follow.

Serious Question on Embeddeds

----- EXERPTS -----

After the rollover I put my brain in gear, rather than relying on the "experts" as I have done to now about what goes in the embeds. I'm not a hardware guy, but I went back and thought about my only hardware project from 20 years ago in university (back when memory was expensive).

Any thing that is in hardware that deals in time is going to use counters to determine when time has elapsed. They are not going to use dates because you have to use more memory to store it and then convert it to a number to do the calculations and then more memory to convert the number back to a date. So they'll count seconds or days. The point of storing a date calculation is know when a certain amount of time has passed. If you use counters (even thousands of seconds for many days) it is the simplest, cheapest, and bug free way to do that - regardless of date. Now some of the more fancy hardware that is newer may have some date functions for things like maintenance (since memory is not a problem now) that has been arbitrarily decided to be done at month ends rather than on a fixed interval, but my guess are those are very few and between.

Yourdon, I'm surprised you fell for this in such a grand way, you're supposed to be one the "experts" who investigated all this. Why Mr. CEO said all his teams were being sent home was because his clients along with all the other companies with embeds found out the above and realized that the "consultants" were swindling them by just investigating and investigating and investigating but actually doing very little else. I'm willing to bet that 99.999% of all embeds are like what I describe above. That's why the world could tollerate a 0.001% hiccup in the number of embeds out there and not blink at all.

I'm willing to bet if you turn on 99.999% of the systems with embeds there is no place to enter a date or even set one - after all I don't see every one of these systems with a keypad or keyboard to enter a date if the current date is incorrect. These systems are black boxes like your modem. Yes they track time (with a counter) not by knowing what day of the year it is. They don't care about dates they care about durations of time and days passing.

(snip)

I read the report (Embedded Systems and the Year 2000 Problem like you suggested, and here are my comments.

1) They suggest that there are 50b chips with 25m with potential y2k problems in critical systems that need fixing. This means that if they are coorect .05% of all chips is sufficient to cause some serious chaos. Well now that we have 20/20 hindsight we can assume that far less than .05% of the chips failed. So my .001% figure actually seems quite interesting although I was just guessing. (My guess is based on the fact there can't have been too many failing since we are still here with out any major hicup (even is a lot of stuff in the grid is running on manual).

2) The paras talking about using absolute time for relative time keeping and about its correlcation to y2k is in my opinion fundementally *wrong* for a number of reasons:

Yes, chips keeping absolute time can be used for relative time keeping events. But the key question is how is absolute time recorded in the chip. I am again willing to guess it is using counters in 99.999% of the chips for the reasons I gave above - its the cheapest and least bug free way to do so. Then those systems that need to have the counters convert to a real date, the counter is just interpreted as an offset of seconds, days, weeks (or what ever increment is being counted) from a known date to get a current date that will be used on a display (not in the calculations) for us humans. The GPS rollover problem was exactly this problem. They were counting weeks and the counter ran out at 1024 weeks (notice a number that is a power of 2 - for all non-computing types out there, any number that is a power of 2 always has special signficance in computing since they are binary coutning machines) and rolled over. The GPS week counter is just added to Jan 6.1980 (week 0000).

Similary the other embedded chips using absolute time will be doing the same thing. Those that are used for applications that need to present real date and time to us humans will add the counter to a known date. This could be set at manufacturing time, or more likely the known date is set with a keyboard/keypad or some interface at which time the counter is also set to 0. This is because unless you can guarnatee the chip has power since it was manufactured, the counter will have stopped and therefore the chip can not give accurate time.

For those applications that are using absolute time counters for relative, time, then the issue becomes a) when was the chip fired up with power so the counter starts off, b) what does the counter count (millisecs, seconds, hours etc.) and how big is the counter before it rolls over.

As can be obviously seen every absolute time based chip (weather being used for relative time keeping or real absolute time) will rollover at a different time (not necessarily in 2000 but depending on what is being counted, when the counter started and how big is the counter -- they could rollover tommorrow, 2 years ago, or 4 years hence. This has nothing to do with y2k and the rollover date has no correlation to y2k. Again just consider the GPS counter rollover as an *EXACT* example of this issue). The issue is that when they rollover (as GPS did in August 99) has the rollover been accounted for in the design so the application the chip is in can continue to work?

So as you can see, regardless of what is going on - relative time counters set back to 0 after a period of time has elapsed (as I suggested) or absolute time counters used for relative time keeping (as the article suggests) or even absolute coutners used for real date and time, Y2K is not an issue for these chips. They will only be using dates for output functions for humans. Their interal "date" calcuations are really just adding and subtracting the counters as like I said that is the most fool proof way of doing date and time calculations. To store date and time in the chip in human readable form is a headache as the chip then needs to convert the human readable date and time representation to numeric form for calcuation and back to human readable form to store in the chip.

Any chips that need to check if a certain date has occured, will not translate the counter to human readable form (as again that is a complex process), but rather when the date to be checked is first entered into the system it will be converted into the correct counter value for that date and stored as a number. The chip then just has a simple job of comparing its counter to that number to know if the date has been reached.

Therefore, the only chips that will have a y2k issue are those that actually store dates in human readable form right in the chip. I think there will be very few of those.

I'm not a hardware guy, I'm an experienced software person. But all the techniques that are used in hardware are programmed in software, and so although none of my software has been put into chips, everything that the hardware people do, we software people have done in our own programs when we needed to track time. So there is nothing special they do that we have not already done. I just didn't put this through my head until after rollover when I realized the whole embedded chip y2k issue was 99.999% nonsense. The bug never really existed there.

----- SOME RESPONSES RECIEVED -----

Interested Spectator, regarding the last thing you wrote, about the systems that track time, but could care less about the date, well my husband had said the SAME thing to me no more than a couple of weeks ago. And He was working on hardware years before getting into software. And I figured he was right, but I Still worried about those nuclear embeddeds. Because the stakes Were so high. And that was my main concern. That and the electricity going out. So right now I feel pretty good, but won't use all the preps just yet. I've learned a lesson that Boyscouts follow as a matter of rule. Preparedness is a good lesson, pure and simple. What I Really wish is that solar power would become economically feasible. That's where we need to be going anyway.

-- DB (tomG@h.com), January 01, 2000.

IS,

I happen to be one of those utility company Y2K project team members. We examined and tested over 6500 systems with embedded chips. About 95% of those turned out to be exactly as you have speculated - no date/time function or only elapsed time or day counting. However, until we did the testing, we had no way to know this. Most systems were put into service years ago with no documentation about how dates were caculated. We spent 80% of our money testing and documenting systems and only about 10% on remediation. As it turned out, there was only one critical system that would have failed and that would have knocked 15 megawatts off-line. Since we produce about 3000 megawatts on average, we barely would have noticed it. If we would have known this two years ago, we could have saved a lot of time and money but we didn't, and there was no way anyone could have known.

We told everyone we could find that there would be no problems with power on Jan 1. We told everyone we were Y2K ready. We set up a monitoring center because, although the probablityo f problems was very low, it was not zero. As it turned out, we were right and I'm happy. What disturbs me is that some people either never listened to us or assumed we were lying. We worked hard and that's one of the reasons we're all able to get on the net tonight and post messages.

Happy New Year to All.

-- (Someone@somewhere.com), January 03, 2000.

-- Interested Spectator (is@the_ring.side), January 06, 2000.