The bug didn’t get much post-millenial press so was it:
1: Intensive and excellent MIS manager preparations and database updates that prevented disaster
or
2: The true danger was massively overhyped.
or a combination of both.
As a side note for anyone who has the real scoop on this… except for providing retired COBOL programmers with some great post-retirement pocket change, were the (purportedly) hundreds of billions spent fixing the problem used on simple patches or were databases updated with real improvements, like being moved to more modern formats?
It was a mixed bag. (I will point out that COBOL is not incompatible with “modern formats.” There are a lot of DB2 applications, written in COBOL, that are quite capable of interacting with other relational systems. To a certain extent, SQL is SQL.)
There were many upgrades, there were lots of patches, and there was a fair amount of theft (particularly by the big accounting-firm-associated IT consulting groups). I know of several shops where Big 6 firms were thrown out the door as late as March, 1999 because their bold claims to recreate 30-year-old systems in Oracle or Sybase were running 15-20 months late, with expected implementations in March or June of this year. In each case that I saw, once the outside specialists had been sent packing, the in-house staff found ways to make the old system compatible with Y2K requirements.
Had there not been the hype (and, to a certain extent, the panic), we might have had a far worse time of it. (It takes a serious panic to get the attention of the CEOs of the world to get them to authorize funds to address a situation.) Once money was allocated and priorities were set, the coding necessary to handle Y2K was not that difficult. In many cases, a “patch” was all that was required, anyway, because once the data from 1998 and 1999 has flowed out of the system, the old 2-digit dates are quite adequate to handle day-to-day processing.
There were other situations that made it unlikely that 01/01/2000 would cause society to collapse: manufacturing and forecasting systems had to have their coding completed by 01/01/1999 to prevent errors throughout 1999. Large scale manufacturing systems needed an even larger window: a company building a ship or an airliner or a factory that needed to plan the assembly process two or more years in advance would obviously need to have their coding done before the first 2000 delivery date was entered into the system. This meant that some issues were addressed long before 1999. Similarly, insurance companies and financial institutions that had to prepare actuarial information or mortgage retirement programs should have been Y2K compliant back around 1970.
Most of the hype was needed to move some old-line corporate managers off their duffs to fund the changes and to get them to re-direct corporate priorities so that they were not constantly interrupting IT schedules with each needless change in corporate structure.
To a large extent the Y2K problem was overhyped. But it did give many companies an excuse to make changes that needed (or they would have liked)to be made. The problem was never that the electricity (or whatever) would go out, but that your bill that covered the end of one year to the beginning of the next would be messed up. If you ever catch the Robert X. Cringley show on PBS about Y2K, it does a good job of explaining the situation.
He brings up an interesting point in the story. Most of the solutions to Y2K were drastic overkill. WHo had the simplest? A branch of the Federal Goverment. They set the clocks back 28 years and fed the output so that it changed the date back to the proper date. They spent less than 1/1000 of some companies (and other Federal Agencies).
And if you thought Y2K was potentially bad, wait until 2038 or so, when 32-bit time rolls over. This may be somewhat more difficult to fix - I know the program I write will crash and burn then, and there’s nothing I can easily do about it. But then again, so will the current versions of Windows, IIRC.
In my first post, I forgot to tell you the federal agency that just set the clocks back 28 years and changed the printed output, it was the Department of the Treasury’s printing office–the people who print the money saved the most.
To Anthracite assuming that the people who make the operating systems don’t fix the problem by then, that may be your best bet too.
And while were on the subject, did you notice who else rolled their clocks back 28 years–Peanuts!! When Charles Shultz died, they started printing strips from 28 years previous so that the holidays would fall on the same date.
Well, I just want to know what all you IT people are doing about the Y10K bug. You know, when the year 9999 rolls over to 10,000. And DON’T try to tell me it’s way to soon to worry about it, they said the same thing about Y2K!
There was some excellent readiness for it. Except for a local shipping store whom I told that there computer was too old & is not Y2K ready & they said, yes it is. But it took them a month after jan 1st to get back to shipping again.
The most interesting thing we found in our shop related to VAX BASIC, which doesn’t allow unsigned integers. It wasn’t even a Y2K problem, but a Y2K + 3 problem.
One of the three apps I worked on was written in this language and had stored its dates in short integer (16-bit) format, with the counting starting in 1970, relative to 1970. For those who don’t know, this means the highest number you can store is 32767. (for those who do know, remember that one bit has to be the sign bit, which keeps you from going to 65535.) As 2002 is 32 years after 1970, and the dates were stored in Julian format (year and then number of days from Jan 1, with Jan 1 as day 1), this meant that when you got to 2003 and it tried to store 33001 (33 years from 1970, and day 1 in that year), it would crap out.
We changed the short integers to long integers (32-bit, which can store more years than there will probably ever be) and tested it, of course, but you gotta wonder how many other really old VAX BASIC apps are hidden in the bushes out there that do the same thing. Guess we’ll find out on Jan 1, 2003.
I just thought it was a cleverly leaked memo from Bill Gates’ “get rich quick idea’s” department. Another little thing to add a couple of $$ to the few dollar bills in his pocket!!
The only thing that happened in our city on NYE of Y2K was a bush fire, but that was started by an over-zealous NYE reveller with a flare!! A heap of firetrucks running thru the town at midnite caused a little consternation tho!!
No. It was genuine. I worked on a few systems that would have started spewing really bad info had they not been fixed. “Fixing,” however, did not always require major system re-writes. I don’t know that Bill Gates made more than a couple pf pennies, off it, but the Oracle and Sybase people made fortunes scaring CEO’s with mainframes into believing that their legacy systems were doomed.
(I also wrote some (mainframe) code to help bail out some Sybase systems that were slapped together to be Y2K compliant–but were destructive of the businesses they were supposed to support.)
Working in hotels I found we had a real early insight of the Y2K bug. We book 3 to 4 years out. So by 1996 we were already seeing programs NOT working. It gave us a lot of time to fix it.
We as of today just booked into 2008. If you had a problem with your program you would tell and of course have to fix it.
