There are two schools of thought regarding the Year 2000 (Y2K) problem. One predicts disaster, caused by millions of programs failing — "done in" because they use two-digit years or six-digit dates. The other sees the Y2K problem as a minor maintenance concern.

Having just completed analyzing the problem at Wisconsin Tissue, a paper manufacturer, I realize how the Year 2000 could be disastrous for a company that ignores the problem. On the other hand, the required maintenance can be relatively modest. But you don't know the problems you'll face without doing the analysis first.

At Wisconsin Tissue, our program for addressing the Y2K problem consists of four phases: assessment, planning, execution, and testing. At the moment, we've completed only the assessment phase, so it may seem premature to report on our experience. However, the assessment phase brought to light important information regarding all phases. For example, we learned that because some vendor programs aren't yet Y2K ready, our Y2K solution cannot be completed until we are much closer to the year 2000.

Assessment

Assessment had to satisfy two principal needs: Management needed immediate advice about the magnitude of the problem — that is, how many applications were affected and the amount of time, programmer resources, and money we'd need to revamp them to be Y2K compliant — and the IT department needed to integrate this added workload with major software replacement activity that was (and still is) under way.

In our assessment, we treated our third-party AS/400 software packages separately from our homegrown systems. We assumed all AS/400 vendors are making their packages Y2K compliant. However, we asked each vendor for a letter stating what versions of its software are or will be Y2K compliant because we needed to identify the software that vendors weren't making compliant. We have 700 RPG programs, 350 Lansa programs, and nearly 2,000 CL programs to examine. We discovered that whenever we had used a vendor's product to develop software, we had to examine both the vendor's product and the software we developed with it for compliancy.

We didn't use any of the available products that analyze software for two-digit date years. Some, I was sure, wouldn't analyze our Lansa programs, and the amount of effort required to test and thoroughly understand different analysis programs appeared to be about the same as the effort we'd need to analyze the problem manually.

A big advantage of the do-it-yourself approach lay in evaluating interim results, step-by-step, as we proceeded. Thus, when we had finished, we had a clear idea of what the results represented. "A Step-by-Step Analysis," below, explains how we assessed our Y2K problem.

Code Problems

The crux of the Y2K problem lies in the code, specifically in 99 or 00 dates. Although few users will be confused when reading these dates, they can cause other problems:

• the collating sequence may cause data normally at the front of a report to be at the back, causing end users to miss important information.

• opcodes SETLL and SETGT may access unwanted records, causing huge printouts and erroneous totals or other calculations. (Remember that a CHAIN is sometimes used to initiate sequential READs.)

• expedient conversions from two- to four-digit years may fail. (For example, 19 may be hard coded.)

• equal and not-equal comparisons function normally, but greater-than and less- than comparisons do the opposite of what you expect.

• arithmetic operations calculating date differences or adding days to a date may provide wrong results.

• 99 or 00 may have been used to indicate, for example, invalid record or memo- only transactions.

• date-validation routines may reject correct dates as invalid.

• as the creativity of programmers knows no bounds, so, too, do the opportunities for Y2K-related failures.

To complete our assessment, we used several tools to identify the above problems and the programs requiring conversion:

Hawkeye's Pathfinder. Each tool in Pathfinder's menu is also a command that you can use in a CL program or at the command line, helping to automate the testing process. These commands have options to produce output files, which are essential for getting various tools to work together.

Advanced Systems Concepts' Sequel. We used SQL statements to select records from a file or to relate records in two or more files. You could also use Query/400 to perform these tasks.

CL commands. The DSPOBJ (Display Object), DSPFD (Display File Description), and DSPFFD (Display File Field Description) commands all have options for creating output files.

CL, RPG, and Lansa programs. We used these whenever the above tools weren't sufficient for identifying date problems in programs and files or when we needed to automate the application of tools (e.g., step 6 in "A Step-by-Step Analysis", below).

Planning

Talking with colleagues, I've learned of different approaches to solving the Y2K problem. For example, one company changed all two-digit years to four-digit years. Another plans to change all six-digit date fields in files to eight digits and leave date fields in displays and reports unchanged. These companies envision an overnight change of all software.

However, I prefer a modular approach — upgrading clusters of files and programs as a unit because the files associated with the programs contain dates that must be expanded. These clusters may be much less than a whole system, so working with them puts less of the system at risk at a time. Clusters are easier to schedule and let you combine Y2K maintenance more easily with other maintenance. For us, this was the compelling consideration because we are overhauling and/or replacing major systems.

You needn't change all date fields to eight digits. If the range of dates spans less than 100 years, you can use the windowing method (where you change only the programs and not the database) to make most date changes. (If the dates span more than 100 years, you solved this problem long ago.) Adding a century field, or several, at the end of a record is another approach. Programs not requiring a century field need only be recompiled.

You can avoid altering existing files, such as large upgrade clusters, but at the cost of additional programming, temporary files, or additional running time. For example, you could make a file identical to an existing file but with expanded date fields. The new file is kept in sync with the old one by using a program and triggers. Programs not needing immediate change access the old file; those needing expanded dates access the new file. However, it's best to avoid such complicated solutions, although they could temporarily ease situations where clusters of programs and files are too large to be easily handled at one time. Another, more minimal approach would be to limit date-field expansion to just particular date fields (i.e., file or sort keys), where alternatives to change are least acceptable.

In deciding what fields to expand, Wisconsin Tissue will go somewhat beyond the minimal approach in anticipation of future applications. We recognize some fields are likely to be used as keys or in computations. Increasing those fields to eight digits may reduce future programming efforts and errors. Fields such as Order Date, Delivery Date, and Invoice Date are likely candidates for both computations and collations. This is the time for doing date expansions that may be more difficult later.

Another consideration is RPG IV conversion. Ultimately, we will convert all RPG III programs to RPG IV. In every case, we must determine whether we want to undertake the conversion along with the current maintenance (Y2K or other). The new date field type offers a special advantage in that it automatically validates the data. However, if you use a date field in a file, you must convert all programs using that file to RPG IV. The option of merely recompiling some of the programs no longer exists. So far, we're inclined to make the conversion right away. Considering that every change must be tested, it's hard to justify not applying all outstanding changes in one operation.

End-user involvement in our Y2K project is essential. IT must communicate the potential problems of Y2K to users early on. At Wisconsin Tissue, focus groups meet regularly to discuss the ongoing software changeover and how the Y2K problem figures into it. Knowing what to expect, users can find problems that our analysis has missed. Depending on how far ahead a company works, Y2K errors may start appearing long before the century turns. Educated end users can alert us to problems when they first occur, avoiding problems such as correcting prior months' business data.

Modifying files and programs in clusters is only half the plan; the other half is scheduling and vendor involvement. When a cluster of programs and files contains a vendor- maintained file, we can't conveniently make the cluster Y2K compliant until the vendor has upgraded the file. Major customization of vendor programs similarly impedes us — we can't update our software until we see what changes the vendor has made. Vendor considerations will significantly delay completion of our Y2K program, so it's important that we complete as much as possible ourselves early on.

Execution

Implementing new applications, performing routine and emergency maintenance, and converting code to RPG IV are enough challenge for our IT department. Add Y2K maintenance and testing to these tasks, and you have the potential for version confusion. You may need to do Y2K testing on complete systems, so the final testing may not occur at the same time as maintenance. These concerns convinced us to obtain a version-control tool, which will prevent having more than one person working on a piece of software, each unknown to the other. The tool keeps several versions of the same software on file at once so one person can be fixing a bug in a production version while another works on the Y2K upgrade.

Testing

What should we test and how should we test it? The Y2K problem presents two different kinds of risk. The first is that so many failures will occur that the available staff won't be able to repair them in a reasonable time. The second is that a cryptic failure will shut the company down or generate bad output. An aggressive program will eliminate the first risk; residual problems will be few.

Every day, we face the possibility of a cryptic failure and lengthy delays in restoring the system, and especially every time we do an upgrade. If we couldn't accept any risk of failure, we'd have to create an accurate simulation of all conditions and test all software on a machine with the system date adjusted.

We normally accept risk, however, when we install operating system upgrades without testing, and by extension, we assume the operating system and vendor packages will be Y2K compliant. Then, only our own applications will need testing, and we may have to run vendor software to generate the test data we need to appropriately test our own applications.

In addition, consider substituting job date for system date when you test programs. The job date normally defaults to the system date, but you can manually set job date for purposes such as testing. To do manual testing, you use the CHGJOB (Change Job) or SBMJOB (Submit Job) commands. We can change back to the system date, if necessary, after testing.

A program can retrieve the system date directly or indirectly. The direct method retrieves the system date into an RPG program using the TIME opcode and the *DATE system value; a CL program can retrieve the system value QDATE, QYEAR, or QCENTURY and replace these values with job date for testing. In RPG, UDATE is job date. Indirectly, a caller or a called program can retrieve the system date. If you can't replace the system date with the job date in the caller or called program (e.g., a vendor program), you can create a stand-in program that uses the job date.

Using the job date, Y2K testing will be little different than the testing we normally do. We'll have to compose appropriate test data with relevant dates, and we'll have to analyze date-sensitive cases that must be tested.

We realize that if we change our programs to use the job date and fail to find an instance where system date is used, our Y2K testing will probably fail. The system date will be the current date and not our simulation date. In other words, artificially substituting job date for system date tends to be a fail-safe procedure.

Waiting for Year 2000

However we test for the Year 2000 problem, it's only a simulation. When the real event arrives, there will be new conditions that didn't exist for our simulation. However, if we've done a reasonably good job of preparing, any problems we face will be limited in number and similar in scope to the problems we face on any other day. Isn't that the best we can hope for?

Byron J. Douglas is a consultant who was employed by Wisconsin Tissue, Menasha, Wisconsin, during this project. He has eight years of AS/400 experience and 38 years of computer application experience. You can reach Byron at (612) 893-3297.

A Step-by-Step Analysis

Here is the procedure, somewhat improved by 20/20 hindsight, that we used at Wisconsin Tissue to assess potential Year 2000 (Y2K) problems in our code. We assessed each type of code we had — RPG, LANSA, or CL — separately, but applied the same principles. The object is, first, to identify everything in your programs that may be date related, and then find potential problems. Find all the homegrown programs in current use. The DSPOBJ (Display Object) command's Date last used field can help you identify such programs. However, this field can be blank for a variety of reasons, even if the object has been used recently. Find all files all the programs use. You can extract these names from the source code with your own program or by using Pathfinder's DSPPGMOBJ command. Use the DSPFFD (Display File Field Description) command to create a file of field names and descriptions from all the files. Identify all date fields in the files. This is an imperfect process. For example, a search on field names containing DAT, DT, YY, and YM returns some field names containing DATA and DTA, which are not date related. A search of field descriptions for YEAR, YMD, MDY, and DATE returns some wrong choices, such as Year-to-date Sales. Manually edit the date-field list to eliminate false selections. This isn't as terrible as it sounds. The date fields are a small percentage of the whole, and a file editor makes it easy to scroll through the list and delete unwanted items. To simplify the task, we made a file of all fields and descriptions, eliminating duplicates and sorting them alphanumerically. We extracted six-digit fields separately and deleted all previously identified date fields from the extraction. We manually examined the residual to confirm that we missed no identifiable date fields. Don't spend excessive effort in finding all date fields. Sometimes an existing field will be drafted for use as a date field without changing its name or description. This sad practice makes it impossible to find them all. Write a program to analyze the programs' source code. Use the identified date fields to find program-defined date fields and undiscovered file date fields. In RPG, for example, if factor 1, factor 2, or the result is a date field, another of these three is probably also a date field. Pick up date fields from other clues. Certain opcodes require date fields, such as data Type D and Edit Code Y. Also, multipliers such as 10000.01, the use of *DATE and UDATE, and calls to date-manipulating programs imply the presence of date fields. For CL programs, we used a slightly different approach. First, we extracted a list of all CL commands used in all homegrown CL programs. From this list, we easily picked out the commands whose syntax had to be considered as problematic. Candidates included any command whose meaning might relate to date usage and any that, when prompted on the screen, were seen to contain dates. Determine whether comparisons, mathematical operations, and either sort keys or database keys use date fields. You must also examine fields used in calls to date- conversion or date-subtraction programs. You might expect the use of a date-manipulating program or an eight-digit date field to signify that statements using them are Y2K compliant. There is risk attached to this assumption, and we chose to include these statements in our review as an added precaution. Just because a program contains date fields doesn't mean it's at risk when the century turns. Many programs simply move dates around, from a file to a display or report, and these applications are probably benign; however, you should examine them to ensure they really are. Report the results of the analysis, including how many programs have no date fields, how many are thought to have benign date applications, and how many probably need some work. List the programs that need review with counts of date fields by category. List the date fields for each program. The program counts provide an overview of the magnitude of your company's Y2K problem. The detailed information about each program gives programmers a check-off list of the work to be done. How much actual work this represents depends on the number of cases needing modification and how you choose to modify them. — B.J.D.