Year 2000 and the Computer

	Sign In Sign-Up

Articles and Papers

Written About the Millennium

1000, 999, 998 and Counting

Steps in a Successful Year 2000 Project

by Gary Eubanks

2k-Times

April 6, 1997

By the Steps:

•List the Processes and Items Involving Electronics and Dates

•Identify Problems / Not Problems / Have No Idea

•Eliminate Items that are Irrelevent

•Prioritize the Business Impact by Process or Item

•Establish a Time Table, Muster your Resources

•Execute your Plan

•Test, Test, Test, and Test

Skip the history ... go to the Message to Management

Skip the history ... go straight to the text on the Steps

1000, 999, 998, and Counting

by Gary Eubanks

April 6, 1997

Sunday, March 6, 1997 was a bit of a special day in certain segments of the computer world. The relentless countdown slipped below 1,000 days until the date odometer rolls over to 01/01/00. No amount of procrastination, legislation or lack thereof will change anything. The event cannot be tabled, postponed, vetoed, or ignored.

You see, January 1, 2000 is not just any old New Year. It has serious implications in spite of its Roman numeral / Disney-like designation "MM". It is the day that the so-called "Millennium Virus" will simultaneously attack every un-inoculated computer, program, and any other device with a date-sensitive computer chip hidden inside. What may come as a tremendous surprise, this is a computer problem that is not the responsibility of us geeks in the Information Systems department ... whatever that is. This is a Management Problem!

The prestigious Gartner Group has estimated that the world-wide cost for fixing the programs running on mainframe and mid-range computers will be between $300 and $600 Billion. Our Federal government has budgeted $2.1 Billion, admits that this is about half of what is absolutely needed, and outside experts up that to about $30 Billion. The effects are not selective, spreading its problems to government, industry, education, business, banks, telecommunications, the military, and in our homes. Some of the big players have already tossed in the towel and admitted that they will only have the most critical applications ready. These include such stalwarts for timing and precision as the IRS. Just how irritating can this bug get? Now you tell me I can't even pay my 1999 taxes! (Don't bet on it, though.)

What exactly is happening? Actually, just like a good case of the flu, several things all at once ... and from both ends. The chips that so reliably add one second after another to keep the time are doing exactly that, and not missing a beat. As the most basic level of the problem is a failed algorithm, the instructions built into many of these chips which translate the 8 or 9 or 10 digit "count of seconds" into something that is understandable by us. This algorithm had no trouble displaying 02/29/96 or 12/31/99, but the huge preponderance of those chips in use in 1997 don't have a clue what to do one second after midnight on 1999-12-31. In PC's the ROM/BIOS interprets this as an error and displays 01/04/80 ... on Jan 1, Jan 31, Dec 31, etc.

The second problem is the almost universal use of a 2-digit year in virtually all of our mainframe and mid-range computer systems. The prediction of $300-600 Billion was to fix the programs in these "heavy iron" machines, also known as "legacy" systems. The Gartner Group didn't ignore desktop computers and imbedded chip sets in everything from watches to military aircraft and missiles; they simply left out an estimate in these areas because they had no way of even guessing at this number!

The use of "yymmdd" as a de facto standard began in the 1960's, and, much to the surprise of those of us who programmed then, many of these programs survive today virtually unchanged! They toil daily doing exactly what they have always done, and have a great deal of skill in dealing with date arithmetic using "yymmdd". There are less than 1,000 days to make sure that the next entry they see after 99-12-31 will not be 00-01-01, and that they will know what to do with 1999-12-31 and 2000-01-01. Literally Billions of lines of old legacy computer programs have to be looked at and, for the most part, manually changed so that the dates flow in the logical order as 1999- 12-31 followed by 2000-01-01.

A CALL TO MANAGEMENT

This is a MANAGEMENT problem! Why management? Among other reasons, it is not going to be the programmer's head that will roll if the ship sinks. The tremendous efforts and resources needed to solve this problem must be lead from the top. What computer programmer is so secure in his or her job that they are going to thump on the CEO's chest and insist on a special budget, off the corporate bottom line, ranging from an additional 50 to 200% of the normal information systems budget for the next three years? And to make matters worse, these expenses will not make anything run any better! With luck, you will succeed in making things run the same on 2000-01-01 as they did on 1999-12-31.

As an aside, January 1, 2000 is NOT the start of a new millennium. That won't happen for another 366 days and, yes, the year 2000 is a leap year.

There is no silver bullet, and there is a ZERO probability that one will be available in the next 1,000 days. Delaying the start of your Year-2000 project will NOT make it easier, and ignoring it will most certainly NOT make it go away!

Today is none too soon to get started in a Year 2000 project for your firm or organization. There are a number of groups and agencies ready and willing to help you get going, and I have witnessed an exceptional degree of experience-sharing among otherwise bitter competitors. There is also a growing list of consultants and service providers who have special expertise in Year 2000 projects, with emphasis on computers, imbedded-chip capital goods, and protection from legal liability.

So, where can I start? Like any big venture your Year 2000 project can be broken into a number of finite steps, and each step into a series of tasks. You are starting on one of the most important (and possibly expensive) electronic projects your company has ever undertaken, so a plan is imperative. Further advice - this is probably one of the most boring, unsexy, least productive and demoralizing assignments anyone could dream up for your staff. The payoff seems so minimal - to simply have everything electronic acting on Tuesday, January 4, 2000 exactly like it was on Friday, December 31, 1999 when you left for a long week-end.

STEP 1 - A List: As management, call on your computer people, those using electronic equipment from computers to fax machines, and those in charge of your physical facilities. Make a list of everything mentioned, with a special emphasis on any information which flows into or out of your offices by any means other than on paper. THIS IS CRITICAL! You have to know what your business partners (banks, suppliers, customers, the government) are doing and what they expect you to do! While you are talking with your people, try to begin a list of equipment by location, manufacturer, and model.

Don't put blind faith in your software provider! Both custom and shrink-wrap programs can be equally unprepared for Year 2000.

STEP 2 - Identify Problems: Armed with the information gleaned from the users and maintainers of your systems, try to make an estimate of how far each of the processes or pieces of equipment are from being ready for Year 2000. There will be a lot of "I don't know" responses here. Some of the processes and equipment will be easily resolved later in this process, others will yield this information only with great difficulty, and some will just have to be "wait-and-see".

STEP 3 - Downgrade Non-Issues: Think about a product's life cycle in this step. If your PC's generally are replaced every 4 years, the known non-compliant PC that was purchased in 1995 should be gone by 2000. Don't cross it off, because in 1999 someone might need to know it will be a problem before it resurfaces to help take a physical inventory or something. If it is easy at this point, make a note of what it would take to make these non-issue items compliant.

Also try to determine and note non-compliant equipment such as the new fax machine that will fax fine, but won't put the Year 2000 on the incoming or outgoing images. You certainly don't want it to be in the legal department 1,000 days from now, but it will work perfectly well for messages between the dispatcher and stock room.

STEP 4 - Prioritized: A huge amount of wheel-spinning can go into exhaustively identifying the Year 2000 readiness of every stick and stone in your business, and at this stage much of this work will become unnecessary in later steps. Assign a code, say zero for irrelevant to five for critical, to each function and, as possible, each process and piece of equipment on the list. Feel free to use zeroes and ones for items that will end their life cycle before they become a problem.

Be equally liberal in assigning fours and fives to anything that enters or leaves your organization using any media other than paper. Of particular importance here are electronic information transfers to or from customers, suppliers, shippers, banks, and the government. Some of these people will have very firm rules on how you will have to behave to continue to do business with them. Some will be helpful, some will be cantankerous and change their minds 3 times, and some won't have a clue of what you are talking about. If the clueless ones include critical-path suppliers this might be a good time to check your options for size A widgets ... you might have to change suppliers quickly.

STEP 5 - The Plan: You now have a neatly sorted list of priorities, and each has a solution path notation beside it ... even if this note says "unknown". By now you should also have a good idea whether your organization has the personnel resources to do the job or if it is time to get some help. Incorporate the outside professionals in your plan - for instance contact a top heating-ventilation-air conditioning professional to handle communications with the manufacturer of your furnace. They speak the language, and have more clout with the manufacturer ... and will probably be needed to make the fixes anyhow.

Go ahead and pencil in people to take responsibility for certain items, let them know where their piece fits into the total puzzle, and specifically who they need to talk with inside and outside your organization to accomplish their task. If it is an integrated item, such as data usage of a common data base, make sure that some timing parameters are included and that all parties know what everyone else's schedule is.

A critical item in your Plan must be a fall-back contingency. Ask someone to spend part of a day thinking through just how you will do payroll for Friday, January 7, 2000 if for some reason the computer system crashes just as the printer is ready to start.

STEP 6 - Execute: Pick your weapons carefully! There are a number of excellent resources and aids on the market which, for instance, assist in identifying date functions in COBOL computer programs and consultants specializing in building management systems.

As a manager in this stage you have two overwhelming mandates, and they are in direct opposition to each other. Timing is critical, and as the steps are often tightly integrated a slippage in one small item can cause the entire process to slip. In opposition to the pressure that needs to be exerted to meet deadlines is the fact that you must be very sensitive to the drudgery of the work involved. With one eye on the clock you need to be the cheerleader that keeps the moral going. You may be able to do some beating on outside consultants, but respect the dull repetitiveness facing your in-house people day after day.

STEP 7 - Test, Test, Test: Current experiences that are beginning to emerge are estimating this step as 40-60% of the total computer effort. We used to have a saying that there were only two kinds of programs ... those with bugs in them and those that are trivial. This is a non-trivial process, and there will be bugs. Your testing methodology needs to protect your current data and systems from contamination, yet look and feel as much like the real thing as possible. This is a tough combination. Finding computer bugs is hard work, and there is absolutely no way to predict the time and effort it will require to track down the problems.

Make sure your Plan left enough time for testing and bug fixes. A flawed system on Jan. 4, 2000 could contaminate data that might take weeks to decipher!

Just a word on budgeting and timing, then I will stop. Data processing projects are delivered late almost by tradition. From my perspective as a developer I would like to blame management for this, but at best I can only say that the budget - timing association is at fault.

Traditionally a new project begins with a budget ... how much will this thing cost and can this cost be reconciled with the benefits that will accrue over the life of the product. On settling on a monetary value, the project is shopped inside and outside the firm for a service provider that will fit the budget.

Management usually then suggests the timing, using a formula that is based on the money available. That is, the budget is "x", it costs "y" per week to employee the resources to do the project, therefore it should be done in "x / y" weeks. When half the money is spent the project is therefore declared to be 50% complete.

Your Year 2000 project probably won't work this way. First of all you have a finite deadline going in at less than 1,000 days. Because such a large chunk of the time (cost) must be allocated to testing (read that "debugging"), your programmers cannot possibly come up with a realistic estimate as to how long this step will take. The only operational guideline is to give the testing phase absolutely as much time and resources as possible, and hope this project breaks tradition by coming in just in time.

World Wide Web Resources:

Year 2000, Peter de Jager's home page.

http://www.year2000.com

U.S. General Services Administration

http://www.itpolicy.gsa.gov/mks/yr2000/y201toc1.htm

2k-Times (this writer's contribution to the confusion)

http://www.bluemarble.net/~storageu/y2k.htm