Y2K Mission Control, Part 2

8 steps to prepare your systems

Last month, I began this two-part article about the Year 2000 (Y2K) problem by presenting eight steps you can take to solve the Y2K problem in your organization. Running Windows NT does not immunize your enterprise against the Millennium Bug. Even if you find you don't have enough time to ready all your systems for the new century--a distinct possibility, with only about 15 months remaining until 2000--you can develop and implement contingency plans.

Let's look briefly again at the eight steps.

1. Awareness. Recognize that no system is safe from Y2K problems.

2. Inventory. Make a detailed list of your company's data processing resources and the systems they connect to.

3. Assessment. Check every item on your inventory for Y2K compliance and determine where your problems lie.

4. Planning. Design a strategy for fixing the problems you encounter, focusing first on your most business-critical functions.

5. Remediation. Focus all your resources on fixing the business-critical processes you identified in Step 4.

6. Testing. Thoroughly test the processes you remediated.

7. Integration. When your systems test cleanly, integrate them and test functions and interfaces inside and outside your company.

8. Contingency planning. Devise plans to keep your business going in case the worst happens.

I concluded last month with an in-depth look at Step 1 through Step 4. Now let's look closely at Step 5 through Step 8.

Remediation
With the detailed strategic plan you wrote in Step 4 in place, you can start fixing your processes according to the priorities you've set, beginning with your most business-critical items. When you assessed your systems in Step 3, you identified the kinds of date problems your enterprise has. A variety of date-related problems are associated with Y2K, including many that will occur before January 1, 2000 (for a comprehensive listing of Y2K date problems, go to http://www.merlyn.demon.co.uk/critdate.htm). For example, September 9, 1999, is an interesting date from a data-processing perspective. In the 1960s and 1970s, programmers used a series of nines as an end-of-file condition. The date 9/9/99 will trigger some of these conditions in some systems.

With each date problem come various solutions. Table 1, page 163, lists some of these problems with suggested solutions. Choose the solutions that will work best for your business based on your Y2K conversion plan and your available programming talent. If you're lucky enough to have veteran programmers working for you, you're a step ahead of the game. These are the people who were programming before or during the new wave of structured programming that came about in the 1970s. Why are experienced programmers so valuable? Because they think in terms of COBOL, assembly language, PL/1, and FORTRAN. And they remember the tricks they used when they needed to conserve memory. The closer 2000 comes, the more these people are in demand--consider calling some of them out of retirement before other companies do.

You also need to update recent programs--even programs released as recently as last year. Programmers in the 1960s and 1970s weren't the only people who coded two-digit year fields--so did programmers in the 1980s and, yes, the 1990s. Because a program is written in Visual Basic (VB) or C++ (or other current programming languages) doesn't mean it contains four-digit year fields. And because a system is client/server-based doesn't mean it is designed for the client/server platform. Many companies superimposed a Windows look on their old systems to make them more presentable to customers. If your company chose this route and you haven't begun your Y2K project yet, you're in big trouble--legal trouble (for more information about Y2K legal considerations, see "The Legal Case," September 1998).

You don't need legacy programmers to resolve date problems with recent programs: Good 4GL programmers can do the job. However, 4GL programmers won't be cheap to hire or retain. Currently more than half a million programming jobs are unfilled in the US, and that number is increasing steadily. As 2000 approaches and more companies jump on the Y2K bandwagon, the number of vacant programming positions will rise faster and higher than anyone can predict.

You also need programmers to create bridge programs and enable windowing. Bridge programs will let you continue to use at least some of your current programs into 2000 by converting I/O to the appropriate format before those programs interface with other systems or programs. Windowing (e.g., moving the window of date validity from 1900 through 1999 to 1941 through 2040) and bridge programs can help you postpone the inevitable to give you enough time to properly convert your systems.

Testing
The primary rule for Y2K conversions is test, test, and test some more. General wisdom about Y2K is that January 1, 1999, is the time to start testing to ensure that you are ready for the millennium party. If your company is late out of the starting gate, testing, like assessment, can help you determine where to spend the time you have.

Unit tests. Programmers conduct unit tests to make sure each logic path in a program works. Unit tests check both the yes and no branches of an instruction's logic (e.g., whether you want to use encryption) and then follow each branch to ensure that it provides the correct results. This process is not as simple as it sounds, because straight-line logic is unusual in computer programs. The odds are that one conditional branch will lead to another, and then another, until the logic--and its testing--becomes severely convoluted.

Programmers who generate unit test scripts must be extremely familiar with the code they test. If a unit tester is the original coder or the programmer who made Y2K modifications to the code, the situation is good. If the unit tester is both the original coder and the Y2K-modification programmer, the situation is even better.

Package tests. Package tests combine programs that perform one function, (e.g., printing invoices). Programmers conducting package tests make sure that individual programs in a package still function correctly at the detail level and in their interfaces with other programs.

Test scripts for single-function packages are easier to prepare than unit test scripts but nevertheless can be complex. You need to test error conditions, exception conditions, and all options, in addition to the most common straight-forward paths. Be aware that in package testing you are not testing only date-related modifications--you need to test all other paths as well. You never know when a simple date-related change will alter the way another path works. The changes you don't expect are the changes that will kill your system.

When your smaller package functions test clean, you can attack the major package functions, such as billing and accounts receivable. Can you issue bills to the right clients on the right dates for the correct amounts? What happens if an invoice contains some items from 1999 and some from 2000? Can you accept and correctly credit money received for an invoice that covers items across the millennium change? Even more important, do all your non-date-dependent billing and accounts-receivable functions work the way they're supposed to?

Quarterly and year-end tests are easy to postpone, because they don't affect daily production. However, when the end of a quarter or a year comes around, you need to be ready. First, test what will happen if a fiscal quarter ends at the century change. Second, test across the century change (e.g., your fiscal quarter ends on January 31, 2000). Third, check both of these conditions for the fiscal year. Finally, check normal quarter-end and year-end conditions (e.g., 1998) to make sure that your Y2K changes don't change normal period-end processing.

System tests. System tests comprehensively examine all your system's functionality. You probably have regular scripts that you use to test your system for any system modifications. If so, you can add some Y2K-specific conditions to these tests. If you don't have system test scripts, you must write them. No other method exists to ensure that your system will still work after Y2K changes.

System testing is a massive undertaking, regardless of your system's size. System testing includes turning your staff loose on your system to try anything and everything they can think of. System testing means running tapes of function tests, loading the system heavily, and jamming it full. Mostly, system testing means trying to break your system, both on and off your network. Here are some of the questions your system testing needs to answer: What happens if you have an electrical crash--can your system recover in an orderly way? What happens when the year turns over to 2000? Can your system handle normal processing in the 21^st century when the system checks back to the 20^th century to perform certain calculations?

Your system testing needs to include performing day-end, week-end, month-end, quarter-end, and year-end processing. The goal, again, is to try to break your system.

Integration
After your system tests cleanly, discover how well the system works when you turn it over to your end users: that is, when you integrate it with any other systems it connects to (e.g., EDI systems, tax systems, or e-commerce systems) and when you run quality assurance. You also need to check the interfaces with supply lines to make sure that your new Y2K-compliant programs can handle the data that comes through those links.

Function tests. Function testing at the user level can unearth twists and turns in a program that the programmer never suspected. Supervisors and high-level user managers usually write the specifications from which to code a package. But how an end user actually uses the package can differ widely from a manager's assumptions about that use. End users can give your system a serious dose of reality testing. Don't limit end users in what they can test on your system, and they'll probably find most of your existing problems. If a serious end-user test doesn't unearth any functional problems, you can feel confident that your system will pass critical examination.

Interface tests. Interface tests check the interfaces with your supply lines to make sure that new Y2K-compliant programs can handle the data that comes to them. Interface tests also make sure that information such as EDI files transmit correctly to the institutions or agencies that require them and check to make sure that any bridge programs that handle interface inconsistencies work correctly. You need to write scripts to test each of these interface situations. In addition, you must write and run network tests. You need to create scripts that both load the bandwidth on the network and make sure that all network links remain fully operational across the century change. It might seem unlikely that a network is date-dependent in any way, but consider that Domain Name System (DNS) and Novell Directory Services (NDS) use date information, and most networks set users' system clocks from time servers.

Quality assurance tests. You run quality assurance tests to verify your final program versions, after you've fixed and rechecked any problems the function and interface tests found. Quality assurance tests verify that everything in your system works correctly and that all the Y2K fixes you added along the way haven't broken other functions. These tests check your bridge programs and your windowing solutions, your interfaces with other systems and programs, and your hubs and routers.

Contingency Planning
The Y2K problem is not solely an MIS problem. Your system could be in perfect working order on January 1, 2000, and large expanses of the US could lose electricity, or global communications shutdowns could occur. If some companies you electronically connect to experience major problems, regardless of the testing you've done, you'll also have a problem. You must make contingency plans to protect your business.

In Step 4, you mapped out your business processes and prioritized them. Go back to these plans now and, in priority order, work out how you can keep each process going if your system is down. Don't depend on any computer system to accomplish this task--develop manual plans, let go of nonessentials, and figure out how to get the basics done without a computer.

One contingency plan, for example, might be to manually issue checks--a horrendous task for many businesses, but one you might need to consider if the worst case occurs. How many people in your accounting department can you put to work writing checks? What kind of manual controls will you need to make sure check amounts are properly recorded? Will you have a current report of finances and checks due to be paid in the first week of January 2000? What other information will you need to handle checks manually?

Such approaches as these might seem archaic, but they are approaches you might be forced to implement. How can you handle the essentials without your computers? What extra reports will you need before year's end in 1999 so that you'll have crucial information if you have to operate your business manually in 2000? You must map out how your business can survive if all your planning and testing fail and your system goes down.

How Bad Is It?
When the president and vice president of the US complain to Congress about the lack of progress toward Y2K compliance by business and government, you know there is a problem. Everyone has reason to worry about what can happen when the century turns. But the real panic stems from the knowledge that there's no possibility of an extension. January 1, 2000, is going to occur on schedule. What percentage of your company's projects can make the same claim?