What is Y2K and What Effect Did It Present On Modern Culture? Two seemingly small digits may turn January 1, 2000 from a worldwide celebration into a universal nightmare. Affecting companies worldwide, many pay millions upon millions of dollars in order for computers to recognize the difference between the years 2000 and 1900. One of the world’s most detrimental dilemmas, the year 2000 computer bug is an extensive and interesting problem that everyone must face. The definition and implications of the Year 2000 crisis are as unique as the steps taken by modern human culture to prevent them. Like all other tasks, computers process dates as numbers.
To the outside world, date values can have numerous formats and meanings but to the internal workings of a computer, a date is just another set of numbers (Kendall 63). When expressing the year part of a date, using two digits such as "4/5/96", the possible values for this year part range between 00 and 99. Obviously, if the year part were expressed using four digits, the values could range between 0000 and 9999 (“The History and the Hype”). In real life, if one adds 1 to 99, the answer is 100. However, if one tells a computer to add 1 to 99 and also specifies that the result must be no more than two digits, the answer is 0 or 00.
Now consider the effect of this numeric example on a date which expresses year values with two digits. If one takes the date "4/5/99" and tells the computer to add 1 to the year part, the result would look like "4/5/00" (Kendall 68). To most humans, this date will suggest that the year part represents the year 2000. But, to a computer (and this is basically the problem), because the numeric representation of the year is effectively zero, the year is interpreted as 1900. According to the logical thinking of a computer, adding 1 year to 1999 results in the year 1900 (Johnson Interview).
The whole question is one of interpretation. Humans can usually distinguish the intended value of a two digit year because of the context of a date within its subject matter. For instance, if one writes "I will graduate 6/1/01", most people will automatically assume that the year they hope to graduate in is 2001. If the person said the same thing to a computer, the chances are that the computer would interpret the same year as 1901 (Marcus 34). Basically, the definition of the Year 2000 problem is the “inability of computer programs to correctly interpret the century” from a date which only has two year digits (Johnson Interview).
On the face of it, the specification of the problem appears to be fairly simple, and so many may think so is the solution. After all, how much of a problem can two digits cause? As the reader will discover, those two digits will be the reason for the largest and most costly task ever undertaken by any industry, world wide. Almost all the time, the first question asked when somebody learns about the Year 2000 problem is, "How was this allowed to happen?" (Johnson Interview). To most people, the thought that so much damage could be done; by so many people over such a long period of time and completely undetected; is absolutely beyond belief (“Y2K: So Many Bugs...
So Little Time”). The fact of the matter is that the Year 2000 issue is there. Programmers are aware of this problem for years. Unfortunately for us, because of the "I won't be around in 15 years, so it doesn't concern me" attitude the programmers display, the problem goes unchecked (Johnson Interview).
It's only because the likely implications of the Y2K crisis being almost on top of us and because companies now stand to lose large amounts of money that the issue is now finally receiving the attention it deserves (“Y2K: So Many Bugs... So Little Time”). When examining the underlying reason for the cause of the problem, two culprits arise. The first, and certainly the most instrumental reason, is the issue of storage space in the 1960's & 70's (Blair Interview).
During this era, the cost of storing data was far from insignificant. In an effort to minimize storage costs, most projects will make a drive to cut down the amount of stored data required by an application (Johnson Interview). In this conservation, there is no stone left unturned. Draining numeric storage space to the smallest possible data type often occurs. Programmers cut character storage space, and before long, dates begin to feel the cut too (“Y2K: So Many Bugs..
. So Little Time”). At the time when only needing the two-digit year part, it is uneconomical to store the full four digits of a year, including the century (“Y2K: So Many Bugs...
So Little Time”). Programs are able to continue processing dates as normal without ever understanding the concept of a century, so why not take out the century part altogether and save all that storage space (Marcus 35)? So, instead of storing a date as "4/5/1968," programmers begin to store dates as "4/5/68" (“The History and the Hype”). Before long, the industry adopts storing dates with only two digits for the year, because of saving space (Kendall 89). No doubt, at the time, some people will raise doubts about the long-term effect of this solution, but they are probably told that their systems will not be in place for more than a few years (Blair Interview). In fact, it's not uncommon for corporate companies to have 20-year old applications in place now, which are core components of their major systems (“Y2K: So Many Bugs..
. So Little Time”). Apart from the obvious problems with systems which are still around today, by adopting the two-digit year as an industry standard, the industry is laying the foundations for a future problem. Even as the cost of storage space became less of an overhead and there is no longer any need to store dates with two digit years, programmers continued to write applications which did so, partly out of habit and partly because of the need for new applications to share data in a common format with existing systems (“Y2K: So Many Bugs.
.. So Little Time”). In addition to the cost of storage, the second probable reason for using dates formatted with two digit years is the question of user acceptance (Kendall 92). In every day life, it's usually quite rare to complete any kind of date using four digits for the year. Consider things like checks, application forms, passports etc.
None of these require that the date contain a four-digit year (Blair Interview). So it's only natural for users to expect the same level of freedom from computer software. In fact, in many departments it has become common place for new application designs to be rejected by users on the grounds that it is unreasonable to expect a user to enter dates with four digit years (“Y2K: So Many Bugs... So Little Time”).
From the users’ point of view, why should they be forced into entering a full four digit year when the software is perfectly capable of accepting and processing a short two digit year (Blair Interview)? It's only now that the consequences of processing two-digit years are really being thought through that the flaws in this argument are beginning to show (“The History and the Hype”). From the technical perspective, there are two effects that could happen to a rogue application in the Year 2000. The first sign that something may be wrong would be when the whole system crashes! In some cases, a computer program will simply not be able handle calculations using the number zero. Without going into too much technical jargon, from a programming point of view, this would be the equivalent of putting square pegs into round holes (Johnson Interview). In many ways, a complete melt down would probably be the better of the two Year 2000 consequences. This is because a system crash is possible.
It is something that can be seen and hopefully corrected. Given a system failure, a maintenance programmer should be able to identify the problem and go about fixing it (Johnson Interview). The second possible consequence of the Year 2000 problem is far more difficult to locate. In this situation, the system will continue to work without falling over, this will give the impression that nothing is wrong.
However, while the program is running, errors will fill the results of date calculations (Johnson Interview). This second scenario is far more dangerous than the first because errors will creep into the data long before anybody notices that something is wrong. If the system provides data to other systems or the data calculated by the system is used over and over again, the effects of miscalculated dates could be far reaching. Because there is no possible crash or system failure, it could be weeks before the errors are picked up, corrupting systems, sub-systems and all kinds of external data by that time (Johnson Interview).
Let's look at few examples of how incorrectly calculated dates affect ordinary business systems: Suppose one function of an accounting system is to provide a list of all invoices which have been outstanding longer than a month for the purposes of the debt collection office. Brand new orders may be given an invoice date of 2/2/00. In this case, the accounting system would flag up these brand new invoices because they have been outstanding for over 100 years (Blair Interview)! This scenario is mild compared to some possibilities. Suppose a finance company lends money to Mrs.
Jones. The loan was created on February 2, 1996 and is set to run for a period of 5 years. The finance company's system, therefore, calculates that the expiration date is February 2, 2001 and sets a flag to stop taking payments from her account after that date. The following day, the system calculates that the expiration date of 02/02/01 has passed and therefore decides not to take any money from Mrs.
Jones' account (Kendall, 67). There are countless possible disaster scenarios just waiting to happen to systems when the century changes, and in some cases, these problems will start to happen before the change of the century. The bottom line is, if your system calculates, processes or stores any type of date related data, it is definitely at risk from the Year 2000 issue (Blair Interview). Everything in our world, from phone companies to the grocery store, is computerized (“The History and the Hype”).
If Y2K takes effect, problems accessing food, money, and getting in touch with family and friends will occur. Fixing the worldwide problem requires an estimated $600 Billion (US) and analyzing millions of code (“Y2K: So Many Bugs...
So Little Time”). This spares only a few systems from Y2K. Estimation suggests that there are 500 billion lines of application code worldwide, of which some 85 percent needing corrected (“The Millennium 2000 Bug Total Y2K Repair Kit”). Various reports stated that by the turn of the millennium, as much as 50 percent of all businesses which failed to address the Year 2000 challenge will break down (“Y2K: So Many Bugs...
So Little Time”). Managers become heavy-hearted thinking about their future as December 31, 1999 rolls in (Kendall 67). Knowing that there is going to be a disaster does not help much especially when there are few resources to handle the problem. Fearing the effects of the crisis, companies worldwide need an additional 200,000 COBOL programmers (“The History and the Hype”). Because the cause of the problem stems back some twenty or thirty years, the programming languages most affected by the Year 2000 problem are older languages such as COBOL.
In fact, it's probably fair to say that COBOL accounts for most of the world’s business applications (Blair Interview). Because the Year 2000 problem is so easily identifiable with COBOL and because there are new languages, many people are under the impression that any system written using the new programming languages is completely Year 2000 ready (Gates 72). In reality, nothing could be further from the truth (“The History and the Hype”). Visual Basic includes various date handling functions and procedures which are totally unaware of the Year 2000. In fact, because of the implication that these functions will work into the Year 2000, and because of over confidence in the language, applications built using Visual Basic are probably more likely to cause problems than many other languages (Gates 72). Microsoft has taken steps to correct these problems by introducing fixes to these date functions in each of the major new releases.
Visual Basic 5.0 introduces an industry accepted technique known as windowing. This technique makes assumptions about the intended century of a two-digit year. However, the window is a fixed window that only interprets dates up until 2030, which flaws the solution. For instance, given the date "01/01/32", Visual Basic will assume that the intended year is 1932 (Gates 72-73). The role that dates play in a business is critical to whether or not the problem will exist.
Going to the problem of electrical companies, date-coding plays only a minor part in the production of electricity, but it plays a major part in the metering of electricity usage (“Y2K: So Many Bugs... So Little Time”). The Senate concluded that local power blackouts will be likely, but national power breakdown is not.
If they do happen it will only be for about a week, but in major metropolitan areas they shouldn’t be more than 48 hours. (“The Millennium 2000 Bug Total Y2K Repair Kit”). The government is working laboriously to get prepared for the new millennium, but are they ready? One of the lagging branches is Social Security which keeps track of everyone in the country (“Y2K: So Many Bugs... So Little Time”).
Next is the military, nuclear reactors, and air transport systems. The Department of Defense reported that only 72 percent of its “mission-critical systems” are ready (“The Millennium 2000 Bug Total Y2K Repair Kit”). Also, what about the nations linked up to us? Being so far behind, they jeopardize the rest of us. Another lagging industry is hospitals and health care. Health care is one of the worst-prepared for Y2K and carries a significant potential for harm. For patient treatment, insurance claims, and pharmaceutical manufacturing and distribution, the industry relies on computers (“The History and the Hype”).
Fearful organizations are not the only ones suffering the millennium bug. Anyone, even a personal computer user, can be. Surfing the net would prove that the Y2K's awareness level is growing with more sites dedicated to this problem (Blair Interview). “Pessimists” say that we will fall into global recession and have another “depression” as in the 30’s era. Stock markets might fall because of companies that are not exactly ready for Y2K. ATMs and banks may not be able to transact money because of this.
Grocery stores relying on computers to deliver goods, take inventory, and even scan pricing will go down. There will be riots, looting, and world wide power outages. Home appliances will go crazy and telephones will be unusable. Planes and trains will collide into each other, gas pumps won’t work, or the cars computer will malfunction so we can’t go anywhere. They think that it is the end for civilization as we know it.
Could they be right? Could we be going back to the Stone Age (“The Millennium 2000 Bug Total Y2K Repair Kit”)? There is no magic solution, silver bullet or quick fix to the Year 2000 problem (Johnson Interview). “Yes, it's true that we can put a man on the moon, or speak to people on the other side of the planet. If we want, we can even blow the world up a thousand times over. However, we can't fix the Year 2000 problem with one swoop of a magic wand (Blair Interview).
” Because of the complexity and number of different business applications, platforms, languages, technologies, programming styles and business scenarios, it is impossible to come up with a one-time, fix all solution. Instead, the problem needs to be addressed by each company individually (“The History and the Hype”). Unfortunately, the only way of being 100% certain that a given application will function as expected into and beyond the next century is to physically address every single line of code and thoroughly test each function in the given application. Regardless of the size and complexity of an application, it only takes one single line of programming code to bring a system to its knees (“The History and the Hype”)! Ignoring the Year 2000 computer crisis—one of the most serious and potentially devastating events this world has ever encountered— was of no use.
Postponing it was out of the question. It set a date for us. A considerable number of people believed the end of the world was near, implicating that we would be back to stones and sticks. Be prepared for the worst and hope for the best is one way to describe the Year 2000 crisis. Even though we didn’t know what exactly would happen when the double zeros struck, Y2K will definitely be a milestone in history. Works Cited Blair, Gary.
Interview. 16 Mar. 2000. Gates, William H. Business @ The Speed of Thought: Using a Digital Nervous System.
New York, NY: Time Warner, 1999. ‘The History and the Hype.” 5 Oct. 1996: n.pag.
On-line. Internet. 10 March 2000. Available WWW: http://www.time.
com/ Johnson, Warren. Phone interview. 14 Feb. 2000.
Kendall, Julie E., and Kenneth E. Kendall. Systems Analysis and Design. Upper Saddle River, NJ: Prentice Hall, 1999. Marcus, David L.
“E-Mail Nation.” U. S. News & World Report 22 Mar.
1999: 54-62. ‘The Millennium 2000 Bug Total Y2K Repair Kit.” 12 Sept. 1996: n.pag. On-line.
Internet. 8 February 2000. Available WWW: http://www.firstgalexy.
com/2000cure/fix.htm “Y2K: So Many Bugs… So Little Time” 14 Dec. 1998: n.pag. On-line.
Internet. 10 February 2000. Available WWW: http://www.scientificamerican.com/ Word Count: 3001
