Y2K: Hoax, Or Averted Disaster? 625
Allnighterking writes "Y2K -- remember the fear it generated? Cartoons were written about it. The dried food industry saw a boom. Doomsayers abounded. But in the end, no planes fell, no one died and the electric grid stayed up for three more years. Was it all a hoax? Or was it the result of careful and complete planning and upgrading. American RadioWorks has a series of articles talking about the disaster that never happened called Y2K You can either Listen in or read the Transcripts of each of the 3 broadcasts and decide for yourself. The over 100 Billion pumped into the US economy alone may well have fueled the boom and predicated the bust. Could the success at Y2K prevention have made the coming problem in 2038 something people will ignore?"
It happened (Score:2, Interesting)
not a hoax (Score:5, Interesting)
A compiler?? (Score:1, Interesting)
(I already knew that cross compilers for embedded systems were generally crap but I really hadn't expected that particular problem.)
Y2k Over Rated (Score:3, Interesting)
Anecdotal ... (Score:5, Interesting)
Replaced computer, had no problems.
Moral of the story: this was a lighting system. Big deal. The client invested several tens of thousands in the project to check three large office buildings in my location, and avoided a minor pain in return. However: everything was checked, and it might have been anything. If it had been the UPS's or the fire alarms for instance, the result of not doing anything could have been a major pain. Point is - we found something, so it wasn't just a waste of time.
(
For small businesses, it was no hoax (Score:5, Interesting)
These would all, everyone of them, puked big time without serious remediation. In many cases it was line-by-line code work, or the building of elaborate insulating layers between modules. In many cases, the cleanest and most rational fix really was a system upgrade. But I can tell you (from having simulated calendar rollovers on such systems), that on 1/1/2000, a lot of my customers (minus the serious work), would have been unable to buy, sell, pay their people, etc., for weeks into 2000 - at which point many would have been mortally wounded. This was no hoax, and the most important work I did at that time was educating the business owners who kept hearing the words "hoax" or "exagerated" on the news.
I wasn't worrying myself about planes falling out of the sky, but I was worried about calamitous damage to a huge chunk of the economy: the $2-15M/year business. Of course, I like to hunt, so no harm buying a little extra freeze-dried food anyway, right?
Re:The current disaster shows the possible scale (Score:3, Interesting)
If it cares about the day of the week, (and it's working this out from the date, rather than using a 0-6 counter and a clock) it's going to need to know the correct year to work that out correctly. I agree that a lot of this was hype - even if the traffic light *did* think it was Sunday when it was Monday, nothing terrible's going to happen.
Similarly, elevators don't give a hoot what year it is.
I'm no elevator engineer, but as far as I recall, more complex elevators do know (for example) "It's 9am - when I'm doing nothing I'd be best served by going to the bottom of the building, since people are going to be arriving." This would presumably be achieved by a simple RTC, with (quite possibly) the full date*. If the RTC suddenly wraps over into an invalid state, that'd probably be a problem for the elevator. Again, we have stairs, the world will not end - but lots and lots of these kinds of problems *could* have caused a good degree of inconvience.
* A reply to this might be "Stupid elevator engineers! The elevator just needed a 24-hour clock!". A possible counter-point would be that the elevator engineer was forseeing an elevator that responded to different day-of-week usage patterns ("It's Friday, everybody goes home early, I'll go to the top floors earlier than I would otherwise do", "It's Sunday, I'll optimise for trips between street level and the tourist observation balcony", etc.).
Re:Mirror? (Score:2, Interesting)
Re:Perl Script (Score:3, Interesting)
Re:Perl Script (Score:3, Interesting)
I guess Gentoo isn't 2038 ready. Must be time to panic.
Re:The current disaster shows the possible scale (Score:3, Interesting)
Well, if the clock fails, then all will happen is that people have to wait an extra minute or two for an elevator. As long as the elevator doesn't fall down the shaft, everything will be okay.
Re:The current disaster shows the possible scale (Score:5, Interesting)
Twice in my life I've seen traffic lights stuck on green in both directions. I don't know how it can happen, because I don't know how traffic lights are switched. Nevertheless.
I remember. . . (Score:3, Interesting)
"So what's it been like for you this evening?"
One of them turned to observe me. She glared with that particular flavor of ultra-tough female no-monkey-business copitude we have all seen.
"It's going fine, sir. The Y2K Bug is just a myth."
Okidoke, ma'am. Have a happy.
-FL
Re:Collective fear (Score:3, Interesting)
I think one example of systems that could have had problems and could have caused serious trouble were the avionics and other systems in airplanes (and air traffic control). I recall reading articles about the hard work the Y2K teams did, digging into these systems looking for any component that might have a 2-digit year or other similar problem.
I also recall reading that the Chinese government found a very good way of making sure Chinese airlines would be safe: Chinese airline officials (executives?) were required to be in passenger planes in the air as 1999 ended and 2000 began.
Re:Collective fear (Score:5, Interesting)
Good God! Are you still with that vendor? We chose to stay open on 12/31 (it was a FRB business day) because we are an ag bank and usually do a tremendous amount of business on 12/31.
I think that at one point I figured that the amount of paperwork I had to do to "prove" that we were in good shape doubled the amount of work involved in preparations.
I ran our core system's "test bank" in updates past 1/1/2001. For each "critical date" I calculated interest accruals and compared them to what the system calculated. I ran transactions and made sure that they posted properly.
The people I really felt sorry for during the process was our Board of DIrectors. They had to listen to me for 1 or 2 hours at each meeting talk about Y2K preparedness.
As a side note, I was home before midnight that night - and I was the last one out of the bank.
It wasn't like NOTHING happened (Score:5, Interesting)
Re:Collective fear (Score:3, Interesting)
Agreed that it was overhyped, but there were desktop level systems that would have died without work. I saw a number of them during testing and prep during '98/'99
The classic was all those xBase systems that used Substr(Dtos([datevale]),3), effectively stripping off the "useless" first 2 digits (apologies if my syntax is incorrect - it's been a while
Of the work I did on Y2K (including a large Telco, small organisations, a couple of software houses and a public transport service), I'd say about 70% of it was valid. The rest was all being done to dot the i's, cross the t's and keep the lawyers at bay if anything went wrong (eg: "Yes your honour, we did do all that we could to check. It's strange that this one got through but it's not for want of trying, so tell those bastards to naff off and take someone else to court"
Dit-toe (Score:5, Interesting)
However, if we had not done any of that, critical systems would have gone down and we would have lost serious money (millions) on bad trades, fines for failure to settle properly, loss of business from negative publicity, etc.
Re:Don't be silly (Score:2, Interesting)
Re:The current disaster shows the possible scale (Score:3, Interesting)
Re:Not a hoax (Score:2, Interesting)
But they were! Especially in the context of my original remarks (smaller businesses running desktop accounting systems, etc), the stuff running on their machines would absolutely have tanked (or worse - seemed to be working, while corrupting data). Most end users (not slash-dotters!) have a very blurry distinction between their hardware, the operating system, the network, the application, and the data. The accounts payable supervisor for a small business will tell you that she "goes to her computer" to pay an invoice, or the shipping clerk will tell you that he "uses his computer" to make UPS shipments.
It was up to us systems people to know how compartmentalized (or not) the problem was in 1999. It was up to good business managers to not engage IT contractors that would defraud them or sell them something they didn't need. Many people hired consultants to police the consultants.
On the home front, there absolutely were people with this problem built-in. Folks using older BIOS versions, two-versions-ago copies of home bean counting software from Intuit, non-patched copies of MS Access, and so on. Would a mis-dated home computer or confused home-consumer desktop app have caused serious financial problems or risk? Probably not as much. Were the problems real? Sure they were, but not for everybody in the same way.
I loathe the scare-tactic opportunists in IT as much as the next guy, but what's even worse are psuedo-pundits that falsely soothe nerves and talk people out of being personally thoughtful about something like Y2K and its direct impact on their situation. For what it's worth, by the way, out of a constellation of about a dozen friends-and-family PCs that I had adopted as tech support charity cases in 1999, probably five or six were spared some inconvenience by things I did for them pre-2000, and two of them were spared major screw-ups in their personal financial records (stock software, etc.). If those people's time is worth anything (I say, it is), then dealing with the problem up front avoided stress, potential fiscal ugliness, and the loss of the value of that time.
I assure you that not one person I interacted with during that period, business or personal, considered the fixes to be hype. Of course, I LONG for those days, when it was something easy to deal with: now those same end users are getting killed with malware that's much more productivity-killing and likely to cause an ill-defined sense of general computing dread. Sigh.
Re:damn right! was: [Re:Collective fear] (Score:2, Interesting)
John
Re:Not a hoax (Score:3, Interesting)
This might not be relevant to you, but then, you worked for a company that made a scam as their business principle. Not someone I would buy anything from.
Bean Counter Stampede (Score:3, Interesting)
Well, it was all a "hoax" or "overblown" according to the beancounters until around early 1999, when the press picked up the story for real. Then there was a realization, a sudden panic, and by March of '99 there was a Y2K coordinator in place. The rest of the year was spent in a mad panic to fix/certify the systems. You can imagine how much real work got done during that time.
I imagine this wasn't an isolated incident. Anybody else?
Latent bugs after 2001-01-01 (Score:3, Interesting)
Where I work (air traffic control) we did extensive testing for two or three years prior to the big event. Most of our major systems were unaffected or easily corrected, although about 20% of the corporate desktops were red-flagged.
We did have one legacy system that we couldn't replace that was known to be a problem. The short-term solution was to roll back the clock to 1972 (the last leap year that started on a Saturday). Everything was fine for about 4 months. Then one day all the flight plans were wrong.
After some investigation it was determined that the shift to daylight savings time in 1972 was on a different weekend than the one in 2000. Normally that wouldnt't be a problem as all aviation-related time and date fields are stored in UTC form. This particular computer, however, was responsible for automatically injecting the scheduled carrier flights into the flight-data system on a daily basis so the airlines wouldn't have to send new flight plans all the time. When the clocks change in the spring and fall, the airlines shift their schedule by one hour UTC so that the 7:00 AM (local) flight still takes off at 7:00 AM. Since this computer thought it was daylight savings time a week or two early, it added one hour to all of the proposed departure times just like it was supposed to do.
We don't normally send flight plans to the computer more than an hour before departure, so the airlines were loading the passengers, closing the doors, and then finding out there was no record of the flight with ATC. The controllers would hand-write the flight data strip and send the aircraft on its way, only to have the computer-generated flight data strip pop out shortly thereafter.
This bug was very easy to fix, but obviously very difficult to predict.