William is a senior development engineer at Intersolv specializing in year 2000 methodologies and remediation tools. Les is project manager/team leader for Intersolv Factory2000. They can be contacted at [email protected] and [email protected], respectively.
The bulk of year 2000 work involves determining which applications must be fixed first, coordinating their repair with other internal and external systems, and testing repairs. This is a lot of work, and selecting the right conversion method can lead to significant time savings and affect the success of remediation efforts. In this article, we'll discuss the analysis, conversion, and testing processes, providing examples in Cobol.
Date Field Analysis
Before the year 2000 conversion process can begin, all date fields must be located in the application. Regardless of what type of remediation tool is being used, the single most important step in the entire year 2000 date impact analysis and conversion process is the creation of the character string or pattern list. This list contains all of the possible date field patterns in the application (*-DATE, *-YY, for instance) and literally drives the entire impact analysis and conversion process.
Special care and consideration must be followed in the creation of the pattern list. If too many variations or combinations of date patterns are used, too many false positives (items marked as date fields that are not actually date fields) will crop up. If a pattern is inadvertently left out, the possibility exists for false negatives (missing a date field). The ultimate goal is to minimize false positives and eliminate false negatives. By testing sample code from the application, the pattern list can be fine-tuned to an acceptable tolerance of false positives/false negatives.
Missed date fields are difficult to identify during the initial search process. An essential step that aids in locating any missed dates is an analysis that occurs after completing the initial pattern search, a process known as "propagation" or "synonym" analysis. This technique discovers fields that do not have typical date field names, but are involved in date field actions (for example, MOVE WS-DATE TO WS-HOLD1). Chances are that the pattern search process would report on the entire line of code as a Y2K-impacted statement due entirely to the discovery of WS-DATE, but would not be capable of reporting on the line of code if WS-HOLD1 were then moved to another obscurely named field such as WS-HOLD2 (MOVE WS-HOLD1 TO WS-HOLD2, for example). Here we have two named date fields that would most likely be missed by the initial pattern-list search process. The potential for this type of situation requires that further analysis be done to discover any propagated or synonym fields. "Indirects" analysis independently searches for any parent/child/redefines/FD relationships in regard to the previously discovered date field, and adds any discovered date fields to the list of impacted items.
Another consideration when doing impact analysis is narrowing down the size of the fields to be searched. In Cobol, for instance, there are time stamps with lengths of up to 26 characters that contain potentially impacted dates. On the other end of the spectrum, fields with a length of one can usually be eliminated because they almost certainly have nothing to do with dates.
Date Conversion Methodologies
While there are several methods for handling date conversions, we'll focus on two -- expansion and windowing. Expansion involves converting the physical field sizes to store the century value, thus achieving full four-digit compliance in both the application and data. This requires changes to both the file structures and all associated application programs.
In Listing One the two YY fields were identified for expansion in the BILLCOM-REC. Based on the decision to follow a date-expansion methodology, these fields must be expanded to store the two-character century values. Listing Two is the revised code using expansion. When these two date fields are expanded from two to four bytes, it increases the overall size of the BILLCOM-RECORD from 100 to 104 bytes, thus creating the potential impact on all applications downstream that use the same BILLCOM-RECORD. Keep in mind that it is not a safe practice to subtract from any FILLER field, since another application could be using the FILLER area for a specific purpose.
With expansion of the Virtual Sequential Access Method (VSAM) file, Job Control Language (JCL) record lengths, blocking factors, and catalog parameters must be revised for all instances that use the expanded record. Expansion is a permanent solution. However, the level of effort and time required to analyze all interrelationships across applications -- including the reorganization and restructuring of files, copy books, and databases -- makes expansion a less viable option as the year 2000 approaches.
Even if a system has been fully converted using expansion, exposure still exists if the system is dependent on any external interface files coming in from other systems or companies. If those files have not been converted using the same expansion methodology that has been used in your applications, you must implement a bridging program that converts the incoming date to a format the converted target system can understand. Next, you must undergo the extremely risky task of deciding when to eliminate the bridging programs based on external system or interface file revisions.
The expansion scenario poses the greatest risk, especially this late in the game. Conversion takes the most time due to the interface analysis that must occur. It has the highest risk of failure due to errors of omission. Organizations with large applications that have not yet started the conversion process should not consider expansion, except for cases where expansion is the only possible choice.
Windowing
Windowing involves interpreting the century date field by inserting fixed or sliding windows into the application program logic. This enables programs to process two-digit dates without converting the files. Windowing based on a "pivot date" year (Year=30, for instance) is a reasonable approach that will:
- Achieve Y2K compliance in less time.
- Require less effort.
- Provide a targeted solution that will enable applications to function while plans are made to migrate the process to an environment that enables storing century values.
The windowing technique is fairly generic and can be adapted to any application by adjusting the pivot year date.
In Listing Three, a commitment must be made to retire the application's environment by the year 2029 or else rewindow the application as the year 2030 approaches. The rewindow effort may be more straightforward if the windowing code technique stores the pivot year literal as a field name in Working Storage and common routines are used to execute the window logic.
Suppose the value in POLICY-START-DATE is 290101 (January 1, 1929). In this case, Listing Three will conclude that the year is 2029. Now, suppose the value in POLICY-START-DATE is 300101 (January 1, 1930). In this case, Listing Three will conclude that the year is 1930.
Windowing's impact on data stored in files and databases varies depending on the application type (personnel, banking, insurance, telecommunications billing, and so on). All affected data stores must be thoroughly analyzed to identify those instances containing dates that will not fall within the 99 years that span the pivot year boundaries.
Windowing analysis is only concerned with cases such as
- Test date fields for greater than/less than conditions between fields and/or literals.
- Test date fields for equal conditions against date literals (equal tests between date fields are ignored).
- Subtracting a value from a year.
- Actions involving reference modification.
- Moving century literals.
- Existing window logic.
Windowing's primary advantage over expansion is that you don't have to worry about legacy data integrity other than finding the correct pivot date. But you still have to find every date-related manipulation function. For windowing to simplify matters when implementing a more permanent solution, care must be taken now in how the analysis results are documented. If done correctly, the window strategy will permit future rewindowing efforts to move the pivot year efficiently and in a timely manner. A rewindow effort would only involve revising the pivot year value stored in Working Storage, plus any unique workarounds documented during the original window implementation.
An effort to retire/rewrite the system should include a complete reengineering strategy to include all of the major system development life cycle (SDLC) phases of requirement analysis, functional design, detail specifications, and so on. During this reengineering effort, existing logic may be determined obsolete and formulas may prove outdated, in addition to reports/screens that may require total revamping or elimination. The Year 2000 effort will provide an accurate inventory of all system components that will be useful as a starting point for reengineering activity.
Determining Pivot Date
The pivot date year selected depends on the application or business requirements. It is usually determined by the oldest date that is processed and is also affected by any "forward date" processing logic.
To adapt the data to the pivot year criteria, unique approaches are required. These include logic that recognizes specific instances that have out-of-bound dates and proceeds to execute unique logic for those instances. For example, records with the year of 100101 (January 1, 1910) would incorrectly be windowed as January 1, 2010. In this scenario, the pivot year may be lowered to accommodate the early date but would reduce the future life span of the window. This would create extra expense for the company to have the window pivot year changed again in the near future. Two options available to work around this case are: 1) Identify these exception records to the program (social security number, account number). When an exception record is encountered by the program, special logic is executed that windows and processes the affected dates based on a nonstandard pivot year. 2) Create a file to store these exception records and process these records in a separate program. This requires extracting these records from the file; creating an identically formatted file to store only these exception records; selecting a pivot year based on the "oldest" date (usually pivot year = "01" is a preferred value); cloning the program that has become Y2K compliant and changing the pivot year value; and processing the standard file through the standard pivot year program; processing the exception file through the cloned program that contains the nonstandard pivot year.
These options are only suggestions. Unique cases will require the application's business and technical experts to devise strategies that solve cases that will not adapt to a 99-year window strategy.
External sorts based on dates require redefining the sort date location and identifying where the year is located. Several sort utility vendors offer add-ons that intercept the sort; append the century per the application rules (the pivot year); sort the file; strip the century; and generate the sort output file in the original format and correctly sequenced based on Y2K criteria.
Testing Date Fields
Window routines must test the date field for all 0s and all 9s. If this is the case, then the expanded field's century value is set to 00 or 99 per the input value (bypassing the pivot date test). Listing Four illustrates this.
When a year is equal to 00, the logic must decide if the value 00 represents an initialization or the year 2000. If a date is defined in the program (YYMMDD, YYDDD, and so on) and the original logic only deals with the year portion of the date field (that is, the YY value), then the unused part of the date field must still be evaluated. If the unused portion of the date (MMDD, DDD) is numeric and not equal to all zeroes or all nines, then the year portion of the date field contains valid data (for this case, year = 00 must be expanded to 2000). If the unused portion of the date is all zeroes (MMDD=0000, DDD=000), then the year equal to 00 is not a valid year and the century must be set to 00 not to 20.
Listing Five illustrates the original code that requires the technique explained above. The revised Y2K-compliant procedure division logic (windowing has been executed elsewhere, and is not shown in this example) is in Listing Six.
When dealing with situations similar to that in Listings Five and Six, it's best to comment out the original logic rather than delete it. The advantages of doing this are:
- To enable the code review to easily identify the obsolete logic;
- To provide a quick reference that aids in resolving problems detected during system testing;
- To permit rebuilding of original logic in a timely manner should the Y2K logic prove invalid or unnecessary.
Compound conditionals can be especially challenging. The original tests should be done before executing the window logic. Unconditional windowing of dates should be avoided. This eliminates the risk of receiving abnormal terminations (ABENDS) due to the failure of considering inclusive/exclusive AND and inclusive/ exclusive OR relationships.
Listing Seven illustrates this approach. The year 2000 logic must maintain the original logic's assumption that it is only 100 percent guaranteed that the date values will conform to the date field PIC clause when field B-CLM-STUS-CD = O. When B-CLM-STUS-CD has any other value than O, then the test will not occur and the content in the date fields is unknown and not impacted per the original logic.
Conclusion
The year 2000 may very well be the largest task an organization ever faces. Selecting the right techniques and tools can significantly affect your time savings. With the windowing method of date conversion, you can achieve compliance in less time with a manageable level of effort. At this point, every hour counts.
DDJ
Listing One
01 BILLCOM-RECORD. 05 B-EFF-DATE.
10 B-EFF-YY PIC 9(02) VALUE 0.
05 B-CONV-DATE.
10 B-CONV-YY PIC 9(02) VALUE 0.
05 FILLER PIC 9(96).
Listing Two
01 BILLCOM-RECORD. 05 B-EFF-DATE.
10 B-EFF-YY PIC 9(04) VALUE 0.
05 B-CONV-DATE.
10 B-CONV-YY PIC 9(04) VALUE 0.
05 FILLER PIC 9(96).
Listing Three
WORKING STORAGE SECTION.
01 POLICY-START-DATE.
05 POLICY-START-DATE-YY PIC 9(02) VALUE ZEROS.
05 POLICY-START-DATE-MM PIC 9(02) VALUE ZEROS.
05 POLICY-START-DATE-DD PIC 9(02) VALUE ZEROS.
01 WS-CONVERT-DATE.
05 WS-CENTURY PIC 9(02) VALUE ZEROS.
05 WS-CONVERT-YY PIC 9(02) VALUE ZEROS.
05 WS-CONVERT-MM PIC 9(02) VALUE ZEROS.
05 WS-CONVERT-DD PIC 9(02) VALUE ZEROS.
</p>
01 WS-PIVOT-DATE.
05 WS-PIVOT-YY PIC 9(02) VALUE 30.
</p>
PROCEDURE DIVISION.
</p>
MOVE POLICY-START-DATE-YY TO WS-CONVERT-DATE-YY
MOVE POLICY-START-DATE-MM TO WS-CONVERT-DATE-MM
MOVE POLICY-START-DATE-DD TO WS-CONVERT-DATE-DD
PERFORM VALIDATE-DATE-ROUTINE
EVALUATE TRUE
WHEN WINDOW-YES
IF WS-CONVERT-YY IS GREATER THAN OR EQUAL TO
WS-PIVOT-YY
MOVE '19' TO WS-CENTURY
ELSE
MOVE '20' TO WS-CENTURY
END-IF
END-EVALUATE
END-PERFORM.
Listing Four
VALIDATE-DATE-ROUTINE. (Performed by the Windowing routine)EVALUATE TRUE
WHEN WS-VALIDATE-DATE EQUAL ZEROS-YYMMDD
MOVE ZEROS-CC TO WS-VALIDATE-DATE-CENTURY
SET WINDOW-INDICATOR TO FALSE
WHEN WS-VALIDATE-DATE EQUAL NINES-YYMMDD
MOVE NINES-CC TO WS-VALIDATE-DATE-CENTURY
SET WINDOW-INDICATOR TO FALSE
END-EVALUATE.
Listing Five
01 WS-DATE. 05 WS-YY PIC XX.
05 WS-MM PIC XX.
05 WS-DD PIC XX.
01 WS-Y2K.
05 WW-YY-Y2K PIC X(4).
IF WS-YY < 75
PERFORM 1000-PRT-RTN.
Listing Six
******IF WS-YY < 75 If WS-YY-Y2K < 1975
PERFORM 1000-PRT-RTN.
Listing Seven
****************************************************************** ORIGINAL LINE OF CODE:
* IF B-CLM-STUS-CD = 'O' AND CLM-CLG-REOP-DT-HD (STATS)
* < TRN-ISS-DT-DRCO NEXT SENTENCE ELSE
*** Y2K START ***
IF B-CLM-STUS-CD = 'O'
MOVE CLM-CLG-REOP-DT-HD (STATS) TO WS-JULIAN-WORK-DT-Y2K
PERFORM JULIAN-DATE-RTN-Y2K THRU JULIAN-DATE-RTN-Y2K-EXIT
MOVE WS-JULIAN-WORK-DT-Y2K TO CLM-CLG-REOP-DT-HD-Y2K
MOVE TRN-ISS-DT-DRCO TO WS-JULIAN-WORK-DT-Y2K
PERFORM JULIAN-DATE-RTN-Y2K THRU JULIAN-DATE-RTN-Y2K-EXIT
MOVE WS-JULIAN-WORK-DT-Y2K TO TRN-ISS-DT-DRCO-Y2K.
* note the period
IF B-CLM-STUS-CD = 'O' AND CLM-CLG-REOP-DT-HD-Y2K
< TRN-ISS-DT-DRCO-Y2K NEXT SENTENCE ELSE
*** Y2K END ***
Copyright © 1998, Dr. Dobb's Journal
