Dave Martin
Northern News Services

NNSL (May 18/98) - Most everyone has by now heard about the Year 2000 date code problem. Also known as Y2k threat or the Millennium Bug, the bug lies dormant in computer programs, waiting for the calendar to roll over to the new millennium.

What happens then is anyone's guess, but experts are predicting everything from a mild blip to utter chaos in information processing and sharing. One certainty that everyone agrees on is virtually every mainframe is at risk, and the more any individual, government or business relies on computers, the greater the risk.

Even systems that are already Y2k compliant are at risk from connected systems not yet fixed. Problems could range from systems just shutting down and refusing to run to expensive and even dangerous errors.

Even such everyday things as elevators, traffic lights and telephone systems may be affected.

For home computers and small business computers with recent (post 1995) software, there likely won't be a problem. It's older and larger systems that are most at risk. Common sense says that there are three approaches for the small- and medium-sized computer system user. Each has its pros and cons.

The first step is to inventory the system to assess what impact Y2k will have. Following that, the choices are to simply dispose of the systems or programs outright, renovate them or replace them.

Replacement is the costliest, but in some cases the most attractive as well. Some programs are simply too old to try and save by re-writing the code. New Y2k-compliant versions of most common programs already exist, and a business may even profit from the supercharged performance of more sophisticated software that is also Y2k-compliant.

For more heavily customized programs, renovation (re-writing code) is going to be the most cost-effective solution. That's not to say it's going to be cheap.

Computer and software programmers are already up to their ears in work, and companies are finding that if they haven't yet begun to fix their bugs, it's becoming more and more difficult to find someone nowadays.

It's safe to say that in Canada alone, billions of dollars will be spent to address the problem. Worldwide, the numbers being bandied about are staggering anywhere from $300 billion to $600 billion -- that's billion with a B -- being spent.

For the largest and oldest computer systems in use, however, it's safe to say that never before has there been a problem of this magnitude. So what's being done about it? Where can you go to get information on the fixes involved?

Fortunately, there are people working on the bug, and defining the scope of the problem.

In fact, a lot of work is already under way, and has been under way for years. Indeed, a whole new industry has sprung up in recent years to address the problem. De-bugging programs abound for the various programs that are most likely to be affected by the problem.

One place for a good, easy-to-read description of the overall problem and its solutions is The Canadian Information Processing Society (www.cips.ca). CIPS has developed position papers and definitions of Year 2000 compliance that companies and individuals can access to determine how to approach the problem.

The government of Canada has also recognized the need to address the problem, and Industry Canada (www.strategis.ic.ga.ca) has created the Task Force Year 2000. The task force is made up of 14 CEOs from some of Canada's largest corporations. Some of the companies involved include Placer Dome Inc., IBM Canada Ltd., Petro-Canada, Domtar Inc., Chrysler Canada and the Royal Bank of Canada. Other sites with related information include: www.mbs-program.com, which has a multitude of related Web sites and information on software fixes and workshops and conferences dedicated to the problem.

The government of Canada has published a list of parameters that a program must meet to be considered year 2000 compliant.

• From now until Jan. 1, 2000, each application must correctly process data contained dates before Jan. 1, 2000.

• From now until then, each application must correctly the process data containing dates after Dec. 31, 1999.

• From now until Jan. 1, 2004, each application must correctly process data contained dates before Jan. 1, 2000.

• From now until January 1, 2004, each application must correctly process data containing dates after Dec. 31, 1999.

• Each application must be able to handle the date 20010101 (Jan. 1, 2001) and all succeeding dates correctly.

• Display, print, input and store dates unambiguously in the context of the systems which use them; and,

• Each application must be capable of recognizing that 2000 is a leap here. The leap-year rule (from the IBM Year 2000 Planning Guide) says, if a date is evenly divisible by 4, but not divisible by 1,000 (unless divisible by 400), that it is a leap year.

Each application must also ensure:

• Feb. 29, 2000, is recognized as a valid date;

• Julian date 2000060 is recognized as Feb. 29;

• Julian date 2000366 is recognized as Dec. 31st, 2000;

• Arithmetic operations performed recognize that year 2000 has 366 days.