The idea is to make the Y2K bug a non-event
TWO years ago, I was asked if companies would face a massive headache on December 31 1999, because of "the Year 2000 problem".
This problem, often abbreviated to "Y2K" in an industry that loves acronyms, could cause computers to generate incorrect results in pension and social security plans or in mortgage rates. It could shut down automated air conditioning systems or keep gas from pumping properly. It could interfere with anything based on date calculations.
The Year 2000 problem is caused by the use in software of two-digit dates, such as "01", to stand for years. When we go from 1999 to 2000, two-digit dates become ambiguous.
If you retire in 2001 and the computer interprets "01" as 1901, it could decide that you retired before you were hired and so your pension is zero.
"There will be a headache, but how much pain it will cause remains to be seen," I said about the problem.
Assisted by computer vendors and consultants, companies are trying to minimize the two-digit problem before 2000 arrives. Mainframes are the most severely affected, in part because two-digit usage was common in older systems where memory was limited.
Because the problem could lurk anywhere in very complex code, the hardest part about a solution is finding all the places where it occurs.
The two-digit date is a convenience that consumers like. When you go to the doctor's office and fill in your birth date on a form, you instinctively write a two-digit date.
It's not surprising that programmers write applications that work the same way we think. This is why even some software written in the late 1990s has the problem, although few mainstream PC products do.
Of Microsoft's 60 core products, for instance, only three do not meet our definition of compliance. All three were released prior to 1995, and only Word 5 for DOS requires an upgrade. Most Microsoft products function well into the 22nd century, and Windows NT handles dates more than 10 000 years ahead.
But much PC software is customised in some way, and two-digit dates could have been used in these customisations.
Businesses should recheck their existing custom software and ensure that they use four-digit dates in all custom applications in the future.
Though Microsoft and other vendors have been publishing information for some time about the Y2K problem, customers are seeking more specific information. They have educated my company about the scope and detail of information they need so they could devise orderly plans.
As a result, my company recently upgraded our Year 2000 website, http://microsoft.com/ year2000. The site includes technical and business recommendations and results of compliance testing for Microsoft's core software titles.
Our primary advice is that, because of the scope of the affected systems, companies should examine their business processes and technical systems from end to end.
Companies that began working on the problem several years ago may be able to inventory, analyse and fix all of their systems in time.
Others may be able to replace their older applications.
From today forward, "triage" is the order of the day. Companies need to identify all their potential problems and prioritise their importance.
Here are a few things that you can do:
It won't be an easy task. Every piece of hardware and software in a company - your company - must be examined for how it handles dates.
Ultimately, the goal is to make the problem a non-event. It's going to take hard work by IT professionals all over the world. The IT guys in Europe have an especially difficult challenge. With tight resources, any company in Europe also has to implement financial systems that can handle the common European currency, scheduled to begin on January 1, 1999.
If everyone does a good job, the New Year celebration will be about what didn't happen. We'll be celebrating the fact that our computers just kept on running.