The millennium approaches: Service providers can keep the year 2000 time bomb at bay by pre- and post-testing

The year 2000 dilemma has become a part of the business world's lexicon.

Poor planning and a short-sighted cost-saving measure 30 years ago in mainframe computer programming are wreaking the havoc.

Because software commonly carries the final two digits of each year, the impending millennial change has created a potential information technology disaster. Individuals, businesses, institutions and governments are working hard to make systems millennium-compliant and disable the year 2000 time bomb.

The problem Whether or not everyone believes the horror stories and doomsday predictions, the year 2000 can present an unpredictable and potentially expensive problem. Unless the problem is addressed, about 90% of business applications will fail in 1999 because of invalid date computations.

Companies are cringing at the thought of paying to change millions of lines of code in the next two years at an estimated $600 billion cost, according to analysts for The Gartner Group. However, starting work on the problem now will save companies time and money.

Every date-intensive system will need to be audited, tested in its real-world environment and probably revised. If revised, the software will need to be re-tested and re-integrated.

The problems are many. Software is likely to mix dates in the 1900 and 2000 ranges. Computer systems and other equipment using dates will fail, possibly shutting down operations. Worse yet, systems may continue to work while transmitting errors.

Billing systems will be unable to calculate the date properly, resulting in billing mistakes. Credit cards will show up expired, billing systems may show a 100-year-old-debt, and customer records based on birth dates or Social Security numbers could be lost. PCs and laptops will recalibrate to their creation date, usually 1980.

In some cases, software may fail immediately without completing any operations, or it may produce unnoticed errors. Not only can the millennial change affect internal operations-employees' Social Security, retirement benefits, salary changes, tax codes and maintenance schedules-it also can result in disastrous mistakes in customer correspondence and billing.

Companies could incur the expense of fixing the software, possibly adding millions of dollars to the cost and reducing profits for shareholders if the glitches are not corrected quickly and reliably.

Are there complications specific to telecom providers?

Several types of equipment and systems in the telecom market must be evaluated including telephone switching systems, custom applications, database management systems and computers, compiler assemblers and interpreters. Computer operating systems and the overall operation of LANs also must be tested.

Although no federal mandates exist, compliance is critical for continued smooth operations. A phone system's failure inevitably would cause confusion and chaos. Even after earthquakes, the phone system continues service foremergency and other vital calls.

Is more involved with fixing the problem other than choosing a year 2000 software vendor?

The problem should not be pushed to only information systems departments but recognized as a bottom-line business issue. Business risks- including the organization's potential inability to meet its obligations if information processing systems are affected-must be considered.

If billing is incorrect, customer service nightmares would arise, and thousands of hours would be needed to keep customers happy as well as fix the computer system dating problems.

Although telecom service providers are not necessarily at the greatest risk, their reliance on new systems containing microprocessor controls can cause greater potential for problems than exists in other industries.

Before choosing a software vendor to fix the problem, companies may consider enlisting a third-party testing company. Not all products or systems need to be fixed or are worth the time and monetary investment to do so.

Testing services can help ease the potential financial and organizational drain involved with year 2000 compliance by determining which products run the risk of failure.

In addition, companies should decide whether the equipment that needs to be revised is worth the cost of the changes or whether it should be replaced. Another option is to wait, as long as the potential problems are minimal.

I thought the year 2000 vendor provided testing. Why involve a third party?

Many but not all year 2000 software vendors perform post-testing. Unfortunately, many companies have been so overwhelmed by the threat of trouble that they have hired an outside software vendor to implement changes companywide.

However, pre-testing by a third-party organization-although not required-can help define what products need repair and prioritize their fine-tuning.

Scanning code and fixing tools are important, but it is vital that companies evaluate the need across their operation before choosing solutions. Once implemented, solutions should be rigorously tested to ensure smooth adherence and operation into the 21st century.

Based on product inspections and discussions with the manufacturer and the users, testing will help determine if products could be affected by the year 2000 problem. Often, if no clocks or time/date stamped software exists, the product does not need to be evaluated or changed. This is critical information for companies concerned about time and budgetary issues.

Added risks At-risk systems within a company need a second phase of evaluation. A testing center may assist the company in finding a competent vendor. Systems must be implemented and tested for four scenarios expected to cause problems between 1999 and 2000. These scenarios arise from problems caused by different dates in the time span.

The first scenario is whether the software and equipment will work in 1999 or whether the software was written to use 99 as a nil placeholder. This problem could show up on Jan. 1, 1999, when accounts and tasks are marked as nonexistent.

The second scenario is the most talked about-the rollover from Dec. 31, 1999 to Jan. 1, 2000. At that time, even if the rollover works, the question remains-creating the third scenario-whether the equipment will operate properly during 2000 and later.

The fourth scenario is the rollover from Feb. 28 to Feb. 29, 2000, because 2000 is a leap year-a problem software coding may fail to comprehend (Table 1).

This testing is complex because of the possibilities that need to be considered, such as the interconnection of various equipment and how Daylight Savings Time will affect any changed software. Many testing companies can determine the likelihood of such problems and prioritize fixes.

Post-testing A company should carefully choose a vendor proficient in implementing software, changing code and fixing bugs, and following up with testing and maintenance once the clock rolls over.

At least one year should be left for testing and tweaking to identify and fix any side effects.

The most effective way to avoid surprises is to simulate a system's operations with a series of planned tests. The tests depend on the type of system, its functions and operating environment, and interfaces to other systems that might supply or receive date- and time-stamped information. Testing should be run in a protected but authentic environment and include the programs' relationships to other systems.

World-class testing facilities can provide complex interoperability testing-linking multiple nodes of equipment from many suppliers to create an entire network.

These can include different suppliers' switching systems, test monitoring and simulation products and analysis tools. Multilab test configurations often are used to supply both product-to-product and network-to-network interoperability analyses.

Industry analysts estimate that the post-testing phase of a year 2000 project could require 45% to 80% of the overall project effort. Although many service providers have tested their solutions before putting them on the market, the important testing occurs before and after implementation-identifying enterprise-wide needs before buying solutions and ensuring compliance with the customer's network and operating systems after implementation.

Managers must secure a clear strategy, planning process, accurate analysis and effective personnel to make the transition work smoothly. Although the conversion is not expected to run seamlessly across all industries, the right strategy and tools can help telecom companies leap into the 21st century.