My Assessment of the Y2K Issue
Adam Davis
A student in an English composition class I am taking wrote, as a class essay, about the Y2K issue. In critiquing her essay, I mentioned that I did not agree with her assessment. She asked me for my assessment, and I wrote this. I consider it in rough form, though if it is referenced very often I may tidy it up and provide links for more info. Your feedback is appreciated.
The main issue of Y2K is that when these programs were created (and I'm talking about large mainframe systems-not the word processors and other consumer programs) the programmers were concerned about two things, which dictated how they programmed. These two items are:
Let's look at an example of why these two were important. Take an average bank that has coverage in one state. This bank has to account for one million separate accounts. It may only have 300,000 customers, but each customer has a checking account, savings account, and then there are many who have other accounts for college or retirement, etc. Given that each account will have an average of 20 transactions every month, then the bank has to have, at its instant retrieval, twenty million transactions every month. Thus the bank has to be able to recall two hundred forty million chunks of data each year. Now, each transaction has a date code and a time code. If the programmer can use one byte to store the year information instead of two bytes, they have suddenly saved over 240 MB of data space. They have to be able to recall information as far back as ten years ago, so they now are responsible for over two billion records, and these have to be accessed in under 5 minutes. So, number one, the bank (a rather small bank), by leaving out one byte has saved over 2.4 billion bytes of information in storage space. Right now, one can get a hard drive that holds over 20 billion bytes for under $500. But in 1982 a hard rive that holds just over 20 million bytes cost well over five thousand dollars. Thus ten years worth of storage for that one extra byte would cost that bank over $600,000, not to mention backing that 'extra' data up. The next item is speed. First, by eliminating a few cycles of code by only processing one byte can save several seconds, if not minutes for each search. That time is very important to the person standing at an ATM or a cashier waiting for a transaction to complete.
This is one example of why we have a y2k problem. The reason I am not overly worried follows.
Fortunately we are a capitalist society. Businesses that do not address this issue will go out of business this next year. This is a great motivator, and not only are they addressing this issue now, but they will continue to monitor it as it happens. It will be a problem in the first quarter of 2000, as end of quarter reports are processed, possibly exposing code that hasn't been looked at. Many businesses are now dealing with y2k because their fiscal year may have just started, and includes dates that lie past December 31 1999. You probably have credit cards that have expirations of 12/02 or other months past December 31 1999.
So Y2K mainly affects systems of accounting. The power plants, natural gas suppliers, and other services may send you a bill for $2,000,000, for payment for the last 100 or 1000 years, but the gas pumps and electricity generators do not depend on a calendar to keep running. They may rely on a clock, but it doesn't matter to a pump whether its 1998 or 1999, and it won't matter when it turns to 2000. However, they expect glitches along the way, and any business that has any intelligence, especially critical ones, will have operators who can control these machines and systems manually should the need arise. Not only that, but businesses are holding other businesses accountable. As the network administrator for a small company in Ann Arbor, I receive many calls every month from businesses that depend on our systems. They ask whether we have 1. Checked our systems for y2k compliance, and 2. Checked all of our suppliers and businesses we rely on for y2k compliance.
Now, on a lower level, we need to look at personal computers and software. It is true that many of the everyday programs we use have y2k problems. Microsoft has admitted that even Windows has y2k issues. They are continuing to release patches and upgrades, but the reality is that the most that will happen is that a date shows up incorrectly on the little clock in the lower right hand corner of the screen. Perhaps when you insert a date into a document in Word, it'll come out January 1, 19100. These problems can be fixed, and are being fixed. The makers of major accounting programs (Quicken, MS Money, etc) are putting many of their other projects on hold to make absolutely certain that these program will not render irreparable harm to a user's accounting. This is because of the lawsuits that will fall on them if the software fails. Again, money talks. And it's getting louder and louder as the next millennium approaches.
As far as stockpiling food and supplies, I agree wholeheartedly. But not because I anticipate problems with Y2K. I can deal with those problems. It's the problems I can't anticipate that I want food storage for. The recent blizzard in January cut off some very important transit lines for some major stores in this area. This did not last long, but there are people who felt the problem as it shifted down to them. There is more chance of another huge blizzard on new years eve than there is of our critical systems failing.
I do not wish to downplay the enormity of work that is needed to bring y2k compliance to our nation, but, speaking as a computer hardware, software, and network consultant, I can safely say that we will not suffer the consequences that some people predict. Y2K will not bring us doom and gloom.