Rev the Y2K fears were stupid because they assumed that people COULDN’T fix the problem. Plus I personally saw Y2K taken to extremes. I saw doctors sending electric fucking typewriters and scales to our I.S. department to be sure they were Y2K compliant. I saw a clinic in a fairly large town, (for central Minnesota) order six months wort of supplies for fear that the Y2K bug would render them incapable of ordering. (Didn’t happen.)
You gotta admit, there was much Y2K sillyness. Much indeed.
Ogre: My semi-WAG: Not every computer in the world needed to be made Y2K compliant, only those that weren’t designed that way. Any home computer or consumer electronic made after, say, 1980 or so was probably Y2K compliant out of the box, even if “Y2K” wasn’t a media buzzword at the time.
Miller is right; the bulk of Y2K fixes were to software packages written in COBOL. Very few PC applications used COBOL - the vast bulk of Y2K fixes were to mainframes and minicomputers. Your personal PC would probably work fine if there were no Y2K fixes; your bank’s computer, on the other hand, wouldn’t.
For what it’s worth, the radio station I was working at on 31 Dec. 1999 was one of the few places that actually experienced a Y2K related computer crash. A patch that was supposed to be installed wasn’t, and at 6:00 pm when the computer tried to update for the next day’s stuff, ker-flooey.
They had it fixed up by the time my shift started at 7:00. But still. The OP is totally correct here.
I hadn’t heard those stories, nor anybody claiming the real problems couldn’t be fixed. I believe you that they happened though.
But there were real issues that could have caused massive problems. But there was a lot of effort made to fix them. I’m a software engineer, and for years I specialized in bug finding and fixing. I know that it takes very little for a system to go tits-up.
In The Man Who’s example, they were able to get the system up quickly because someone had previously taken the time the identify the problem, and write a patch. If that effort hadn’t previously been made, I can almost guarantee the place would have been down for at least a day.
Just a followup from another IS/IT guy. Y2K issues were in 4 key areas:
Hardware - Easy to check, easy to fix (replace it). This accounted for a large part of the hardware side of the tech bubble as everyone updated systems for Y2K.
Operating Systems - Easy to check, easy to fix (patch every install… mostly mainframe and Unix issues). Again, this wouldn’t have affected most people on Windows or Mac OS.
Software - Hard to check, hard to fix. Fortunately, critical programs were checked first and most Y2K bugs were “little stuff” that didn’t make the schedule. Lots of time and money were spent here, ensuring that banks, billing and other critical systems worked. As mentioned by Athena, we’re talking mostly COBOL.
Embedded systems - Easy to check (do the chips work?), often hard to find because inventory records weren’t kept. A lot of effort went into this too. Embedded systems refers to computer chips embedded inside cars, traffic switching systems, pipeline control rooms, etc. This issue led to most of the disaster stories about refineries, airplanes and other “not obviously computer” systems crashing.
Another interesting Y2K side effect was that a tremendous amount of thought and effort went into disaster planning. In the places I worked in New York, Y2K plans were continuously updated and proved very useful after 9/11. Without having worked through the issues for Y2K, I doubt any of the banks or financial institutions affected by 9/11 would have recovered as fast.
On another note, the C4I-PRO (Information Warfare specialist) newsgroup was, at the time, filled with conversation about how Y2K was the best dress rehersal for information warfare that could be devised. C4I-Pro seems to be offline now, but this page has a bunch of related links.
So Y2K was a bust because nothing critically bad happened. But that’s because many hours and dollars were spent making sure nothing bad happened. The investment in the Y2K issue has been, and will continue to be, very useful as we become further and further dependent on the internet and computer systems.
The problem was that the threat was over-blown in the media. I saw an ABC special where a woman was stock-piling bikes to use as barter when the world-as-we-know it stopped working. Gas pumps would stop working, electricity would be out, banks would no longer give us our money. We would revert to the pre-industrial age.
I personally attended a Y2K convention in which the key-note speaker told the tale of how a power company in north-eastern US did some Y2K testing and shut down power in several cities and towns. This seemed ludicrous to me, as I had not seen it reported by any news agency. Something that big would have had to have made big news. During the Q&A period I asked the speaker if he could tell me exactly which power company had had this problem. He was not at liberty to divulge this information.
As a man who makes systems that control HVAC I can tell you that none of our systems were ever in any danger of shutting down due to the Y2K problem. In our critical equipment there is always a fail-safe. Our controls systems can be manually over-ridden for safety reasons at any time. I suspect that this is true in the energy systems and in the gas pumps.
Y2K was a very real problem for our industry and a lot of time and effort went into fixing it. But it was blown out of proportion in the media to the point where many people were stock-piling food and water for no reason. This is why it now garners scorn amoungst the masses. They don’t understand what went on behind the scenes. All they know is they were told that the sky was going to fall - and it never did.
I was also working as a Y2K expert in 1999, responsible for checking and rechecking systems at a manufacturing plant. In other words, I was one of the people e-mailing HVAC manufacturers because my client needed confirmation that things were or were not Y2K compliant.
The fuss and concern were real. I remember having to another round of checks because a senior manager set his two digital watches to 11:59 pm 12/31/99 and one of them failed. I was also asked by someone if their car would continue to run on January 1st. I even had to officially include partially dismantled x-ray equipment on the Y2K compliance list.
In addition to COBOL, some dBase based software had problems, and there was one piece of software which I wasn’t able to check because we didn’t have the source code. Sure enough, that piece failed, so I wound up writing a patch for it in early January while suffering from a raging case of the flu which should have had me home sick in bed. To me, that was the real Y2K bug! dBase, by the way also uses only 2 digits to store dates, but, on the other hand, when I first started working with it back in 1990 or so, I simply told it if the year is greater than 50 or so, it starts with 19, otherwise, it starts with 20. I wasn’t thinking of Y2K compliance back then, just of doing my job right. You can imagine how staggered I was to read years later that some fellow patented that technique in 1999 and the patent was granted! :rolleyes:
The problem was blown out of proportion at the time – I kept pointing out that banks routinely make 30 year mortgages, so they were dealing with the Y2K issue well before 1999 and I’m quite sure they’re going to find ways to get their money – but some things did need to be done. I was rather amused by what I consider the ultimate short-lived job title, but I was doing a lot of other things for the client. Besides, giving the job to me meant the IT department people I worked for and with spent less time dealing with their bureaucracy, which made them happy. Since they were happy, I was happy, and my employer got paid which made my employer happy. Who says computers can’t bring joy?
Yeah, I worked at a mainframe shop at the time. We were rather frantically preparing for the collapse of our mainframes. While the primary OS’s had been updated with Y2K compliant stuff, there was a huge library of sub-routines and custom built JCL libraries that weren’t even looked at.
2 stories of note:
on 12/31/99, we were waiting at my friends house (he was a co-worker) for the calls to come in. We watched the ball drop, and right at midnite, he hit the breakers to the house. Dead silence for a moment, then another one of our co-workers says quite calmly… “shit. Now we gotta go to work.”
In all seriousness, nothing major happened. One of our products (Qucktape, if you know of it) turned out to not be compliant, oddly enough. It pretty much quit working for a day or two while we tracked down a patch.
People did do a lot of work to bring stuff up to code, but even if people did nothing it wouldn’t have been the apocalypse that some people were preparing for. You know, the ones that bought generators and batteries and bottled water and MREs, and took all their money out of the bank. That was just stupid and likely was fueled by the media.
Just as an example of something that was Y2K compliant before Y2K was coined, *nixes didn’t need to suffer from Y2K related issues at all. They count time as seconds since the epoch (canonically, 1 January 1970, 00:00:00 GMT). 1 January 2000, 00:00:00 GMT is just another 32-bit signed integer to the OS.
As 32 bits is a finite quantity, we will `run out of time.’ In 2038 (19 January 2038, 03:14:08 GMT), the capacity of 32 bits will be exceeded and, for the remaining 32-bit *nix systems, time will wrap around to some time in the early 1900s. (13 December 1901, 20:45:52 GMT, which is the datetime keyed to the lowest possible value 32 bits can represent.) This will be correctable but supremely annoying, kind of like Y2K.
The Year 2038 Problem – Will it be a big thing, or will 64-bit machines have Won The War by then? (64 bits effectively negates the problem by pushing back the horizon to a point beyond the expected lifespan of the Universe.)
Actually, if you used a short int and a YYDDD format for the date, with Jan 1, 1970 as the base year, you had a year 2002 problem. I fixed a VAX system with this exact problem. It could theoretically have affected both VAX and UNIX, as UNIX’s base is also Jan 1, 1970.