I still remember the day, a week before Christmas, when one of my bosses decided it might be a good idea for me to cancel my holiday in the Virgin Islands in order to monitor the Windows 98 peer-to-peer network at the law office on New Years Eve.
That’s when I knew the madness was getting out of hand. The next day I quietly changed the dates on all the computers to December, 2000. Once everyone was in the office I sent out an e-mail saying, “congratulations, we’ve successfully passed the Y2K test; please change the date back on your computer.”
That, I think, saved my vacation, but here’s the funny part: nobody in my office actually knew how to change the date back to 1999 on their systems. That is why Y2K was such a damned problem–it was the fucking idiots in authority who didn’t understand shit about the tools they depended on to do their jobs.
You’re right, when I started studying Computer Science in 1985 they had just taken punch cards out of the curriculum. I did hear the horror stories of older students, though.
Still, my point was that even after storage was not a real issue anymore (I’m guessing since the 1980’s, except if you were working with dedicated devices) there were other restrictions that forced you to use only 2 characters for the year. For legacy applications your point is well taken.
At one point I started collecting Y2K horror predictions, and they were everywhere. It was funny how certain aspects of the scare would emerge in just about every story. Does anyone remember the elevator warnings? Almost all stories which gave an overview of the Y2K problem mentioned elevators as one of the potential problems, even though all of the major elevator manufacturers had web sites devoted to dispelling the concern.
is that there had to be bunches of systems, from the property tax records in West Bumfuck, SD, to the power company in Lower Slobbovia, that weren’t fixed before 12/31/99 rolled over to 1/1/00.
I remember scanning the news for reports of actual Y2K problems, in the days after 1/1/00. There was hardly anything. Instead of thousands of minor but newsworthy-in-an-amusing-sort-of-way Y2K glitches fighting for space, there seemed to be just a few. I’m having a hard time believing the world was that thorough in checking and (if necessary) fixing everything. I’ve got to believe that the problem, pre-fix, was just not particularly pervasive.
FWIW, it wasn’t just the media raising expectations of the problem. I was job-hunting in mid-1998, and I talked with outfits at job fairs that were fixing the Y2K bugs, among other things. I asked them what would happen to their new hires after 1/1/00. They said they expected the Y2K cleanup to last for a couple years after.
Maybe they were BSing me, or themselves, but the point is they weren’t the media; they were in the business.
Some of the other Y2K related “bugs” where incredibly overblown. One that comes to mind was the September 1999 “end of file” bug. Basically, the theory went that programmers used 999 to indicate the end of a text file and that a date of september 1999 (0999) could be interperted as an early end of file.
From my experience with financial institutions, most flat files that use this sort of system break ALL THE TIME for everything from missplaced commas to extra padding spaces. Human intervention is required on an almost daily basis. The company I was working with had an entire middle office team dedicated to “file cracking” to figure out what was wrong with the various formats and how to convert them into something more usable.
So a bunch of failed files on a particular date is nothing new and not really a problem.
Also, with respect to RTFirefly’s comments, the vast majority of date bugs where never really bugs at all, or were fixed by fixing the operating system or the core libraries. So assuming that the original programmers followed some sort of reusable coding structure (sometimes a stretch, but that’s another rant), date functions are contained in one place and accessed from all sorts of other code. If you fix that one place, the problem goes away.
The media, and many managers, refused to believe that you could solve the problem by fixing one piece of code (date functions) rather than looking for the hundreds of thousands of places that used the date functions.
An an analogy, assume that SDMB decides that the [ b ] tag is no longer for bold. They change one routine that translates [ b ] to bold, and it’s done. No one has to go through every post that uses [ b ] and fix each one. To a large degree, the same thing happened with Y2K date issues. At first glance, the problem looks huge (Oh my god, there are 1.21 gajillion places [ b ] is used, we have to fix each!), but in reality it’s not so bad.
On the one hand, you’re right: it is difficult to believe that IS departments were so thorough that no bugs escaped. (And it is also true that the media hype got ahead of the reality in some instances, of course.)
On the other hand, it could very well have been as serious as some predictions had worried about, but two things minimized the January 1, 2000 effect:
the use and need for dates do not bunch up on the current date;
companies that discovered Y2K bugs were really careful to report them as hardware malfunctions. (Who wanted to be known as the “one” group that didn’t fix their bugs?)
The stories about power failures and machinery failing were, indeed, overblown. Few of those devices really care about what the actual date is.
The stories about financial systems failing were far more real, but they failed over the course of several years, not at the stroke of midnight on the faux millennium.
For example, financial and manufacturing systems that need to perform forecasting began failing on January 2, 1999 (or 1998 or 1997, depending on how far out the system needed to project its predictions). (January 2, because nobody comes to work on 1/1 to see where their production schedule will be in two years.)
As noted above, mortgage and similar systems were corrected around 1970. In the Cleveland area, there was a humorous (to those who didn’t bank there) error when, in '96 or '97, one of the ATMs in town began failing to recognize newly issued cards with an expiration date of 01/00 or later. That was pretty swiftly corrected.
Similarly, back-looking systems don’t fail until the end of the month when, for example, an Accounts Receivables system needs to correctly age the outstanding balances. An A/R system running at the beginning of January, 2000, was processing data for December, 1999 and would not have had a problem to report on January 1 (when they were running no jobs) or January 2–February 1 might have been a different story. In addition, a huge number of companies buy packages to handle their financials, so once McCormack & Dodge/D & B Millennium/G.E.A.C. Millennium or MSA/D & B Enterprise/G.E.A.C. Enterprise have each plugged in their patches and the patches installed, that huge section of the industry that bought their software is covered for their applications. The same was true in manufacturing for the people who bought IBM’s COPICS or MAPICS or the competing products.
However, without some hype, we’d have been hurt a lot worse. The shop where I worked declared in 1988 that all new applications would have a four-digit year and all system enhancements would include provisions to update those fields. We just did the work and included the costs in the upgrades. However, when we went to management to get money to upgrade the systems that were not being changed, we were told to go away. They had no intention of “wasting” money on “IT problems.” It was not until they began to get pressure from outside sources (ISO-9001, Federal requirements when the Feds were a customer, banks that would not loan money if the systems were not demonstrably Y2K compliant) that management actually opened the purses and agreed to fund the necessary changes.
The September 9 bug (I don’t recall an “end of September” bug) was always one that I figured was invented by a reporter with one semester of “Introduction to Computers” in their college curriculum 20 years (or more) earlier. I never met a programmer who believed it for a moment. While there were a very few systems that actually used 9s for their end-of-file marker, they tended to load their entire record with 9s, not just their date field. However, the glaring error in the story was that September 9 would never have been carried as “9999.” It’s a date folks! The storage value would have been either “090999” or “990909” (depending on whether the format was mmddyy or yymmdd). You don’t eliminate the leading zeroes on the month and day.
Oh, and in one regard, Y2K really was a disaster. There was a lot of money thrown at it, that did not need to be wasted in the way it was, just to make ignorant managers feel good.
Tons of money was thrown away on immature client-server products to fix problems that were more economically handled by rather simple upgrades to mainframe applications. (This is not a slap at client-server products, in general, but many of them are not nearly powerful enough or robust enough to support very large applications, a point that was more true in 1999 and even more true in 1996-1998 when the decisions to replace the mainframe applications were made.) I know of three major corporations in Cleveland that, as late as June and August 1999, threw out the client-server vendors and the Big Six accounting firms that had “sold” them and used brute force to make their functioning mainframe applications contiune on through Y2K because after several years of development, the replacement software could not be made to handle the business.
The money spent on badly conceived projects had a direct bearing on the bottom lines of many companies that contributed to the “softened” economy of 2001.
I did hear the horror stories of older students, though.