Y2K Mission Control, Part 2

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.