In-Depth
Practical Y2K Suggestions from Practical Experience
ATPCO Environment
Hardware Systems: IBM Mainframe
Operating Systems: S/390 Parallel Sysplex
Data Bases: IDMS, DB2
Programs Reviewed: 4,850, 7.8 million lines of code
Programs Changed: 1,300
Airline Tariff Publishing Company (ATPCO), located in the suburbs of Washington D.C., is the world's leader in the collection and distribution of airline fares and related information. Over 550 airlines from around the world send their fare data to ATPCO to be distributed to Global Distribution Systems and Computer Reservation Systems. Because most fare data is date sensitive ATPCO's products could be severely impacted by the Year 2000 problem. ATPCO took on Y2K problem as a challenge to ensure no disruptions occur in the processing and distribution of fare data. This article provides a firsthand account of how ATPCO is converting its legacy applications to meet this challenge.
Awareness
Our awareness of the impending Year 2000 issue started years ago in the early 1980s when we started designing IDMS databases with date elements large enough to accommodate century rollover. However, many of our applications were not Y2K-compliant because the industry uses a two-digit year presentation. Because we deal with date-sensitive data, most of our processing involves date reconciliation in one form or another. Therefore, we used a common date module for converting dates into different formats. This common module was enhanced to operate on a sliding window (from 49 years backward to 50 years forward) when the century was not specifically given. Gradually all applications started using this date module.
Early 1990 marked the next step when DB2 made it a standard practice to use a century with all dates. All of our DB2 databases now were able to handle the century rollover. Still we were not Y2K-compliant. By the end of 1996, we had begun an all out effort to beat the December 31, 1999, deadline.
Also in 1996, the travel industry reached a general consensus that our system should be ready to start processing Y2K data by mid-1998 and that the transition should be transparent to users. The second requirement was significant. We needed to operate internally on a four-digit year, but all our communications and presentations to our customers were to remain limited to a two-digit year.
Strategy
The next challenge was to come up with management and technical strategies to solve this critical business problem. There were thousands of programs to review, the project was critical to ATPCO's survival, and it had to be done by late-1998.
The dynamics of this project were different from most other projects we do at ATPCO. This project had to start with testing to identify the problems. It ended with three levels of testing -- regression testing, testing for readiness to accept Y2K data and testing for rollover into Year 2000.
The different applications are very complex and tightly integrated. Changes to one subsystem could adversely impact other subsystems. Therefore, we knew that testing must be thorough. Another complication was that our systems are constantly changing because of the demands of the industry. Parallel development and change management were not new concepts to us, so we knew that good configuration management was essential to success. We already had a good tracking system in place, which was to our advantage.
Before formulating a common strategy we decided to do two small independent non-mission-critical systems and let our practical experience guide us. This hands-on evaluation phase resulted in the following strategy in Table 1.
TABLE 1: Y2K Strategy Made Simple
- Start with risk assessment and establish priority for conversion of different systems based on industry requirements and potential conflict with other ongoing development.
- Treat this project as we would any other project: establish concrete deadlines, schedule resources, and focus on the functionality.
- Add the century to historical files, but keep the database changes of operational files to a minimum through the use of windowing.
- Expose the vulnerability of each system by code analysis as well as testing. (Testing gave us a valuable by-product - a comprehensive regression test plan).
- Do initial analysis to break down the project into small manageable units that can be installed independently into production.
- Standardize the fixes to make coding easier. Since the nature of coding is repetitive but massive, consider outsourcing.
- Give special attention to performance of our highly visible and long-running products.
- Keep collating sequence and record layout unchanged even when date without century is part of the sort key.
- Place high priority on testing. Achieve the highest possible coverage of realistic functions by canvassing product experts in testing.
- Use date simulation tools for unit testing of rollover into Year 2000.
- Schedule drills for rollover into Year 2000 at our disaster recovery site after all systems pass the initial testing stage.
Techniques
The needs of the industry are such that we could not simply change the systems and begin accepting Y2K dates. The industry as a whole had to be ready for the change before the feature could be made available in production. We did not have the resources to do a massive install precisely when the industry announces its readiness. As a result, we designed a flexible yet date-sensitive cut over date for accepting Y2K data. We could then move the changes to production with the Y2K option inhibited until the industry was ready, at which time the option could be activated on short notice. To accommodate this option we hard coded a Y2K-switch, which was passed from the main menu down to all input screens. Only the main menu needed modification to turn on the Y2K-switch when the industry was ready. The Y2K switch was also date sensitive for date simulation testing (e.g., if today's-date > '12/31/1999' then y2k-switch = '1').
We used the new Y2 feature of DFSORT for handling two-digit year.
Example 1:
//*************************************************************
//* OPTION Y2PAST=1950 sets century window starting at 1950
//* from 1950 to 2049
//* OPTION Y2PAST=50 sets century window starting 50 years ago
//* from 1948 to 2047 if current year is 1998
//* FIELD FORMAT: Y2C - 2 byte character X'F9F9'
//* Y2Z - 2 byte zoned decimal X'F9F9' or X'F9C9'
//* Y2S - similar to Y2C or Y2Z for real numbers but
//* recognizes X'0000', X'FFFF', spaces
//* Y2P - 2 byte packed decimal X'099C' X'099F'
//* PD0 - similar to Y2P but ignore first digit X'?99C'
//* Y2D - 1 byte decimal X'99'
//* Y2B - 1 byte binary year 00 - 99 (X'00' - X'63')
//*************************************************************
//SORTIN DD DSN=MYDATA,DISP=OLD
//SORTOUT DD DSN=MYDATA,DISP=OLD
//SYSIN DD *
OPTION Y2PAST=1950
SORT FIELDS=(1,2,Y2C,A,3,3,CH,A) --> 9(5) julian X'F9F7F3F6F5'
SORT FIELDS=(6,1,Y2D,A,7,2,PD,A) --> 9(5) comp-3 julian X'97365C'
//*---------------------------------------------------------------*
Example 2:
//*************************************************************
//* HOW TO OVERRIDE INTERNAL COBOL SORT OPTIONS IN JCL ********
//* INLINE DATA SET DFSPARM REPLACES INTERNAL COBOL SORT VERB OPTIONS
//*************************************************************
//* COBOL CODE: SORT SORT-FILE ASCENDING KEY SORT-KEY
//* USING UNSORTED-FILE
//* GIVING SORTED-FILE.
//*************************************************************
//IGZSRTCD DD DUMMY
//DFSPARM DD *
OPTION Y2PAST=1950
SORT FIELDS=(1,26,CH,A, -- sort-key is col 1-42
29,2,Y2C,A,31,4,CH,A, -- col 29-36 is a date
37,2,Y2C,A,39,4,CH,A) -- col 37-42 is a date
/*
//*---------------------------------------------------------------*
Example 3:
//*************************************************************
//* HOW TO HANDLE MULTIPLE INTERNAL COBOL SORTS :
//* - ONLY ONE INLINE DATA SET ALLOWED FOR DFSPARM
//* - USE SEQL DATA SET OR PDS MEMBER FOR DFSPARM WITH FREE=CLOSE
//* FOR SERAILISING THE SORT OPERATION. LIMITATION IS THAT
//* THE FIRST ONE EXECUTED ALWAYS USES THE FIRST DFSPARM.
//*************************************************************
//DFSPARM DD DSN=&&PARM1,DISP=(,PASS),FREE=CLOSE
//DFSPARM DD DSN=MYPARM2,DISP=SHR,FREE=CLOSE
//DFSPARM DD DSN=SYSINLIB(PARM3),DISP=SHR,FREE=CLOSE
*//************************************************************
Example 4:
//*************************************************************
//* HANDLING DIS-DATE 999999 IN Y2K SORT :
//* - CHANGE 999999 TO 49999 BEFORE SORT AND THEN CHANGE BACK
//*************************************************************
//S01OF02 EXEC PGM=SORT,REGION=4M,PARM='FLAG(I)'
//SORTIN DD DSN=MYDATA,DISP=OLD
//SORTOUT DD DSN=MYDATA,DISP=OLD
//SYSIN DD *
OPTION COPY
OUTFIL OUTREC=(1,11, * copy col 1-11 unchanged
12,6, * col 12-17 may contain 99999
CHANGE=(6,C'999999',C'499999'), * convert 9'S TO 499999
NOMATCH=(12,6), * if not 9's copy col 12-17
18,63) * copy col 18-80 unchanged
/*
//S02OF02 EXEC PGM=SORT,REGION=4M,PARM='FLAG(I)'
//SORTIN DD DSN=MYDATA,DISP=OLD
//SORTOUT DD DSN=MYDATA,DISP=OLD
//SYSIN DD *
OPTION Y2PAST=1950
SORT FIELDS=(5,2,Y2C,A,7,4,CH,A, * sort by date1
12,2,Y2C,A,14,4,CH,A) * sort by date2
OUTFIL OUTREC=(1,11, * copy col 1-11 unchanged
12,6, * col 12-17 may contain 499999
CHANGE=(6,C'499999',C'999999'), * convert 499999 TO 9's
NOMATCH=(12,6), * if not copy col 12-17
18,63) * copy col 18-80 unchanged
/*
We ran into problems with COBOL-reserved words being used out of context while recompiling very old programs. Example 5 shows how we used COBOL verb REPLACE for getting around the problem caused by COBOL-reserved words used as IDMS record names. For example, 'REFERENCE' and 'REPLACE' are COBOL-reserved words now, but were not when the application was written. The IDMS record name REFERENCE or REPLACE would not compile today. This technique will apply to other situations.
Example 5:
COPY IDMS SUBSCHEMA-CONTROL.
y2kchg REPLACE ==REFERENCE== BY ==REF-ERENCE== .
COPY IDMS REFERENCE.
y2kchg REPLACE OFF.
y2kchg REPLACE ==REPLACE== BY ==REP-LACE== .
COPY IDMS REPLACE.
y2kchg REPLACE OFF.
*-----------------*
* BIND RUN UNIT *
*-----------------*
BIND RUN-UNIT.
y2kchg REPLACE ==REFERENCE== BY ==REF-ERENCE== .
BIND REFERENCE.
y2kchg REPLACE OFF.
y2kchg REPLACE ==REPLACE== BY ==REP-LACE== .
BIND REPLACE.
y2kchg REPLACE OFF.
We standardized fixes for date comparison (> or < only, not for =) by taking an exit to a common date conversion routine, thus not disturbing the normal path.
Example 6:
* If (parm-date >= start-date and
* parm-date <= end-date)
* perform within-range-start thru within-range-end.
MOVE parm-date TO OLD-DATE-YYMMDD1
MOVE start-date TO OLD-DATE-YYMMDD2
MOVE end-date TO OLD-DATE-YYMMDD3
PERFORM CONVERT-TO-YYYYMMDD-FORMAT
IF (Y2K-DATE-YYYYMMDD1 >= Y2K-DATE-YYYYMMDD2 and
Y2K-DATE-YYYYMMDD1 <= Y2K-DATE-YYYYMMDD3)
perform within-range-start thru within-range-end.
We use value '999999', '12/31/9999', and '31Dec99' for indicating the highest possible discontinue date. We paid close attention to the results when these different conventions were interacting together.
We searched CICS programs for EIBDATE usage. (EIBDATE pic s9(7) comp-3 format 0CYYDDDs where C indicates century with value 0 for 1900s and value 1 for 2000s.) There were instances where EIBDATE was saved into a 5-byte field and later used for date manipulation.
We minimized the database conversion efforts by changing the date format rather than expanding the index field (e.g., packed decimal 9(5) comp-3 was changed from Julian date format to number of days since 1900, value 99365 changes to 36525). We could have segmented the historical file on a date line and kept the earlier segment intact and added code in the programs to interpret the date format accordingly.
Segmentation was not necessary where the new date format would not disturb the clustering of data. In these cases update modules were just changed to use four-digit year for new data and retrieval modules were enhanced with logic to distinguish between two-digit year format and four-digit year format (e.g., if date > 1000000, then format is yyyymmdd, if date < 1000000 then format is yymmdd). These short cuts allowed a very smooth transition with no downtime, while keeping the option to convert the data later at our own pace.
Our DBA used IDMS Utility for expanding date field and user exits for manipulating date format. A lot of ingenuity was needed to add century to a date field that was part of six different indices, some of which would lose the placement by index rebuild. DBA built a utility to manipulate the index in place, thus avoiding the expensive index rebuild involving millions of records.
Date simulation tests unearthed some problems with date functions in a 4GL language and a Macro language. Since time was in our favor we contacted the vendors and requested a solution. While waiting for solution, we located all the places where the failing functions were used and made contingency plans for coding around the problem areas. Fortunately, we did not have to resort to the contingency plans.
One of the keys to the smooth transition and continuous system availability was our phased-in approach. Altogether we had 7.8 million lines of code constituting 4,850 programs out of which a little over 1,300 required changes. More than 80 percent of the changes were already in production by August 1998. The expected completion date is December 1998. A series of rollover tests are scheduled for 1999, to ensure that we are prepared to support the travel industry in Year 2000 and beyond.
We put in sincere efforts in choosing the right tool that best suited our needs and our environment. We concluded that there is no magical solution that eliminates the need for analysis and testing. Even the best tools are good only in the hands of a skilled analyst. Outsourcing can speed up the process, but there is no substitute for wise policy decisions made by those with in-depth knowledge of the systems.
About the Author:
Mano Mathai Application Development Coordinator for Y2K Project Airline Tariff Publishing Company (ATPCO).