"The Survival Guide for the Year 2000 (The Y2K Computer Virus)"

	Sign In Sign-Up

by Patrick Janidlo (janidlo@logical.net)

This article is not directed at the computer "geeks," who are well aware of the problem. It's not intended for the managers who have been told disaster looms. This article is for the common stiffs who work hard, pay taxes, and hope to see a social security check when it's time to retire. To you, the masses, I speak; we are in trouble.

A type of virus is embedded in most software application code and data files. This virus (which is referred to as Y2K) will be dormant until 12:01 am, January 1, 2000 and then computers will begin to crash. Well, not exactly crash, but the virus is going to corrupt the data it produces. And, no one will know which data is correct and which data is bogus.

A touch of reality is that the year 2000 will be upon us in just less than 3 years. If firms dropped all current software modification/development projects, in order to direct efforts at disinfecting the current applications from this virus, there would not be enough worker years (or resources) to fix every application. All companies can only do is fix their "mission critical" software -- and pray. To put it in a dollar amount, the estimated cost (by the Gartner group) of fixing all the infected applications world-wide is between 300 and 600 billion dollars! (Folks, expect the consumer goods prices to rise as we approach 2000.)

That's not including all the revenue that will be lost after the year 2000 hits and these applications fail. Also, one must factor in the human cost when businesses, from their inability to function, go out of business. The Office of Management and Budget (OMB) has put a $2.3 billion price tag on fixing this problem with all United States government's computer systems, as stated in the Associated Press.

Which companies are at risk of having this virus? Any that use software, mainly mainframe shops, and those companies that retrieve data from the mainframe. But don't assume that PC applications are virus free. That's the problem; the virus is incorporated into an application's code. And no one knows which applications (or data) will be corrupt unless a company or a government agency sifts through every line of code for the virus, and every piece of data the application produces and retrieves. This is the first step, as time consuming as it is, in becoming "Y2K virus free." Then this organization must correct all the applications and data files. And there is no assurance that all the dates are corrected. An anonymous quote about Y2K is, "it's not like finding a needle in a haystack, but finding all the needles in the haystack." And the needles that you miss have the potential of corrupting the data.

What is this virus, you must be asking by now. Be prepared to laugh. All it has to deal with is the way legacy (and some modern) applications store a date. That's it! (A better analogy than a virus is a cancerous tumor.) Back in the 1960s, our last generation of programmers decided to store the year of dates as two digits instead of four, e.g. 1996 is stored as 96. The applications that retrieved the data made the assumption that the millennium/century (in any given year) was 19 and that creates the problem. I'll explain in a bit why this is such a problem. But first a little history as to how this problem arose:

This problem has been around for 30+ years, ever since the first computer applications. The 1960s/1970s programmer was faced with many technological limitations. They stemmed from mainframe memory capacities in the 250 kilobytes range (a byte is 8 bits long, a kilobyte is a 1000 bytes, a megabyte is a 1000 kilobytes, and a gigabyte is a 1000 megabytes), and limitations with data storage on magnetic tapes and direct access storage devices (DASD). The magnetic tapes had a capacity of a 1600 bits per record and each tape held up to 144,000 records. A million records would require 7 tapes. Compared to a PC today, which has a 2 gigabyte drive with an average seek time between 8 and 11 milliseconds, the DASD had a maximum storage of 7.25 megabytes with an average seek time of 75 milliseconds. Thus, the addition of just one byte to a million records meant an increase of a million bytes in storage. Therefore, these limitations forced an accepted standard to drop the two digits every time a date was referenced or kept in data files (it also saves a couple of key stokes every time a user types in a date.)

The problem with a 2-digit date is it will cause problems in arithmetic operations, comparisons, and sorting data by date. To elaborate, my birth year is 1968, which is represented by an infected application as 68. When I receive my car insurance bill in the year 2000, I should continue to have a reduced rate since I'm over 25. The computer takes my birth year and subtracts it from the current year, 2000 which is represented as 00, to attain my current age. If 00 minus 68 equals negative 68, how will the computer interpret my age? Well, I'm not 25+ years old anymore, therefore, I would not get the discount. Then again, a -68 might create an unstable environment in the computer, and possibly crash the application (which is O.K., if I never receive the bill, but troublesome if I own or operate the insurance company). Or, another scenario is that the application might drop the minus sign, putting me in another rate class, which could be higher than the rate I deserve.

So, why can't you just add an extra 2 digits to the year and get on with it? Well it's not that simple. First, you have to locate all the date references within the code and in the data. I read that one agency, while sifting through their code, found 23 different name references, for the date, within the code (e.g. DATE, DTE, YEAR, YR, MMDDYY, DDMMYY, YYMMDD, DOB,...). Then you have to modify the code and test it. And with testing, it's hard to determine if these apps will work beyond the year 2000, due to the inability to change a system date on a mainframe, especially when the mainframe is being used 24 hours-7 days a week for current "daily" operations. Another factor is that it is difficult to recreate all variants of a transaction that could occur within a system. Thus, any modifications to applications are left to a wait-and-see outlook.

With data files, it's even harder to "just" modify. You can not change the date in a data file's record and expect the applications to read it correctly. There has to be some intervention to assure that the applications that write the data file records create the correct date. Also, the applications that read the data file records expect a certain date format (either a 2-digit or a 4-digit year).

To put it in perspective, the government agency that I work for has several hundred in-house applications, with several million lines of code. That's not including the hundred or so data files, plus all the data we retrieve from outside sources, and the hundred or so canned software applications we run that can not be relied on being Y2K-free. Plus, we send data to other agencies and companies, putting them in a squeeze to update their applications to read our modified data. Most agencies and companies are in a dilemma as to how to clean the applications from this virus, with limited time left. But we have to start fixing this problem today because the production date can not be missed. There are no extensions allowed, sorry. Deal with it.

Are you wondering if your community has the virus? A check to verify if local businesses are plagued by these legacy applications is to open your local paper's Sunday classifieds and look for job offerings for COBOL/CICS/VSAM/IDMS programmers. These are usually for jobs that maintain these legacy apps. This is a good indication (but not an absolute) that this virus lurks in your community's organizations.

Possible Year 2000 Scenario:

Let's put the overall Y2K virus problem into perspective with a little role playing. You head to your nearest ATM on January 3, 2000 (the< first work day of the year) to remove some of your hard-earned money, except your bank account is showing no funds. "Must be a bank error, I will call," you think to yourself.

At home, you notice your electric, gas, and telephone service have all been turned off, due to some glitch in their electronic billing systems< that shows you as delinquent in payment for the longest time. So, all the utilities "automated disconnection report" applications ran, and now you're in the dark. Angered, you decide to drive to the nearest utility to speak to a rep (a supervisor, the director!) when you are pulled over on a speeding violation. Your driver's license record shows your license is revoked--due to a DWI violation that you got 20 years ago, and was resolved 15 years ago. But not to worry, the jails are empty because, for some reason, every inmate was eligible for parole. This might seem extreme, but it is plausible.

Think about it, utilities shutting off service, not being able to get money, incorrect data about you being displayed to people in power, stores failing to operate, hospitals unable to find your medical records; anything that has to do with electronic data could fail. Society would fail to function, ineptly relying on the damaged information it receives, and damaging people in the process. Riots could break out.

So, finally, here is...

The survival guide:

•If you have any money in an institution (banks, retirement funds, stocks, bonds, CD's, investments, etc.) either a) withdraw it (sell it) before Dec 31, 1999

b) have the institution assure you (in writing) that their firm's

applications are Y2K virus-free, for legal recourse.

•Rent a generator for the weekend. You never know.

•Get a battery-powered HAM/CB radio (and a manual) to communicate long distance, if the telephone companies cease to operate.

•Get a battery-powered AM/FM radio to retrieve news reports.

•Stock up on dry and canned food, bottled water, batteries, candles, gas (even propane for the gas grill), medication, first aid supplies, etc. (keep in mind that store's computers might be down and purification plants could accidentally release the wrong batch into the water supply.) Have a "manual" can opener available.

•Don't fly on Dec 31, 1999 (who knows if the air traffic control will be up and running, let alone whether the airplanes online computer will continue to work.)

•Move upwind, and away from military strategic sites and cities. Who knows if the Department of Defense systems will be working correctly. Some third world country might take advantage of this vulnerability. Consider the fact that military personnel will be partying on New Year's Eve, too. And that New Years Day 2000 falls on a Saturday.

•The government seems to be behind corporations in resolving this problem. You must not rely on the government agencies to be able to assist you, whether in welfare, unemployment, etc. in the year 2000.

•The IRS is expecting a major failure of their systems in the year 2000, so don't expect a tax refund check.

•Stay out of the hospital. Your medical record might show the wrong data. Mammograms, CAT scans, chemotherapy, etc. should be avoided. For those of us that have a medical problem, a precaution could be to request a paper copy of all your medical records.

•Be aware of you current employer's computer vulnerabilities and what effects will occur after 2000, especially whether the company will be able to operate.

•Be aware of all computers, big and small (digital watch, microwave, television, car, etc.).

Things to expect:

It's not the end of the world (as grim as I make it out to be). As the year 2000 approaches, consumer prices will begin to rise as corporate< America starts implementing year-2000 "solution" projects. These are "zero-"revenue-generating projects, therefore, the 300-600 billion dollars to fix this bug is going to be obtained through raising consumer goods and services prices, and possibly cutting staff in all departments except, of course, data processing.

It is expected that only 50 percent of corporations and government agencies will be year 2000-compliant by 1999. The rule of thumb, because no one knows which 'mission critical' applications will fail, is you must expect them ALL to fail. In so doing, you will minimize your risk of being dependent on anyone's computer data.

Another potential problem:

The year 2000 is a leapyear. So why is this a problem, you ask? Because of the 4/100/400 year leap-year rule. To better understand the problem, read: "You're working on Feb. 29; are your systems?" by Michael D. Lips, ComputerWorld, February 26, 1996.