The Year 2000 and 2-Digit Dates: Guide

INDEX
CHAPTER 4. IDENTIFYING 2-DIGIT-YEAR EXPOSURES . . . . . . . . . 4-1
Locating References . . . . . . . . . . . . . . . . . . . . . . . 4-1
Tracing References Back to Their Source . . . . . . . . . . . . 4-3
Determining the Impact of 2-Digit-Year Data Fields . . . . . . . 4-3
Investigating How Other Software Entities Use the Data . . . . . 4-4
Data Sharing . . . . . . . . . . . . . . . . . . . . . . . . . 4-4
Miscellaneous Date-Related Issues and/or Exposures . . . . . . . 4-5
Support for Expiry Dates . . . . . . . . . . . . . . . . . . . 4-5
Language Environment and Date Simulators . . . . . . . . . . . 4-6

CHAPTER 4.
IDENTIFYING 2-DIGIT-YEAR EXPOSURES

To identify the potential exposures caused by using 2-digit-year representations of dates, you first need to locate references to all date-related data.

LOCATING REFERENCES

Locating date-related data and code is itself a major piece of the work effort that you must address. The most complete method starts with an inventory of every element of your IS organization. (Of course, the scope of the Year2000 challenge is far greater than that contained in your IS center, but this book has a focus mostly limited to traditional software programming.) Once compiled, you can review each program individually. Alternatively, use the following, more systematic, approaches to locate 2-digit-year data and date-related code. (Solution Developer products are available to assist this effort. Refer to Appendix B, "Year2000-Ready Solution Developer Products" on page B-1 for a list of those Solution Developers and their products.)

1. Review the following documents for direct or indirect references to date-related data and formats. Then trace these references back to the application source code to locate references in that code as well.

    o   Requests for proposal
    o   Statements of work
    o   Planning documents that describe future IS needs
    o   Existing studies about the current system
    o   Software development standards and process documents
    o   Software quality assurance requirements
    o   System requirements specifications
    o   System design specifications
    o   Program specifications
    o   User instructions and procedures
    o   Data dictionaries

2. Review program information for date references to include, for example, date variables, date functions or routines, and character strings. Character strings might include the following in either your code or its comments:

         o   AS-OF,                   o   CURR,
             ASOF                         CURRENT
         o   BEGIN,                   o   DATE,
             BEG,                         DAT,
             BGN                          DTE,
         o   CCYY                         DT
         o   CYYDDD,                  o   DAY,
             CYYDDMM,                     DA,
             CYYMMDD                      DD
         o   DDMMYY,                  o   TIME
             DDDYY                    o TIMESTAMP,
         o   DIFFDATE                   TIME-STAMP
         o   DOB                      o   TIMEDATE
         o   DOH                      o   THISDATE
         o   END                      o   TOD,
         o   EXPIRE,                      T-O-D
             EXP                      o   WEEK
         o   JULIAN                   o   WEEKDAY
         o   MONTH,                   o   YEAR,
             MON,                         YR,
             MO,                          YY
             MMM                      o   YMD,
         o   MDY,                         YYMMDD,
             MMDDYY,                      YYDDD
             MMYY                     o   and
         o   START                        so
         o   TERM                         on.
  o   Data entry forms, screen display formats, report formats
  o   Definitions of data fields, records, structures, files, and databases
  o   Source code, computer program listings, cross-reference reports
  o   Command languages, for example, JCL, REXX, CLIST, EXEC, and CL
  o   Data indexes and catalogs, table sizes
  o   Data dictionaries
  o   Date/time service routines
  o   Sort routines

3. Use a test system.

Install an isolated, non-production system with a duplicated image of your system and application software. In large systems, this could be an LPAR (logical partition) of the mainframe, or for other platforms consider dedicating a separate machine, segregated (in either time or place) from any other system(s). This segregation is crucial to guarantee that you will avoid contamination due to system clock advancement or untested, and yet imperfect, modified code.

o With a changed date/time setting

Set the system date and time to a future date and time value after 2000-January-01. During such testing, be certain to use compatible data that is synchronized with the revised application software, that data crosses a 100-year boundary, and be certain to update your current operating procedures to reflect this new data requirement as well. For example, the 100-year window could be 1900-1999 or 1995-2094, or you could use both range types. The more you vary your window type(s), the more incorrect code you will uncover. This testing will help you identify many (but not all) Year2000 exposures.

o With changed data

If you only change date fields in a routine, you are not introducing new logic into that routine. Although the fields are increased from 2-digit to 4-digit fields, you only need to recompile the routine to generate those new field lengths. If you didn't change the logic, you needn't test that logic. Typical testing is appropriate in a separate test system using new data, but Year2000-specific testing is generally unnecessary. In this testing, ensure that the changes in the operand lengths produce the expected results. If the results match those produced prior to your changes, then the application is successfully performing data calculations using the new 4-digit data rather than the previous 2-digit data, and you have met your migration criteria.

Refer to Chapter 6, "Testing Techniques for Year2000 Changes" on page 6-1 for a more detailed discussion of testing techniques and issues.

4. Use a combination of the above approaches.

TRACING REFERENCES BACK TO THEIR SOURCE

For any potential exposure identified, identify all direct and indirect references of this exposure. You can do so by tracing the flow of the data to identify its immediate source and destination and then repeating the tracing process until all sources and destinations of all potential data exposures are identified.

DETERMINING THE IMPACT OF 2-DIGIT-YEAR DATA FIELDS

Once you have located date-related data fields by one or more of the above approaches, you can classify the use or reference of those fields into one of the following categories:

o Low Impact

- The program uses a 4-digit-year representation in all occurrences.

- The program uses a 2-digit-year representation within itself, but does not have any internal exposures, nor does it externalize the 2-digit year in any way.

- The program uses a 2-digit-year representation within a itself, but does not have internal exposures. The 2-digit year IS externalized, but can not be referenced (for example, for display-only) by any other program.

NOTE: Such output might be labelled as 'cosmetic only' and for interpretation by a human only, but this too might have its own set of ramifications.

- A municipality that tracks school-age children will more frequently begin 'inviting' centenarians to enroll in kindergarten. If a printout of residents reads: "Birthdate: 10/14/89", what would the clerk compiling a list of 6-year-old children in 1995 assume?

- Another type of exposure is externalized by 'display-only' dates that have been coordinated with a hard-coded '19' for the century. Such 2-digit exposures might exist for terminal display or special forms where the '19' is pre-printed. Therefore, be aware of, and consider, potential impact of date fields in all situations; these might not always be obvious exposures.

o High Impact

- The program uses a 2-digit-year representation within itself. It does not have internal exposures, but the 2-digit year is externalized and could be referenced by another program.

- The program uses a 2-digit-year representation and has internal exposures.

INVESTIGATING HOW OTHER SOFTWARE ENTITIES USE THE DATA

You also need to investigate the ways data is shared among software entities. The greater the degree and scope of data sharing, the more global is your task and the more critical is the need to prevent the further propagation of and data 'contamination' by 2-digit-year data. Except possibly in a rather small IS environment, you cannot know how output is used by all other programs that might access it. Several factors that affect how data is shared or used among software entities follow. These factors and the types of data sharing provide some of the links making up this data 'web'.

DATA SHARING

Three factors affect the sharing of data between modules:

1. The number of data items passed between modules. (The more data passed, the tighter the relationship.)

2. The amount of control data passed between modules. (The more control data passed, the tighter the relationship.)

3. The amount of global data elements shared between modules. (The more global data elements shared, the tighter the relationship.)

Several types of data sharing can occur between two modules in a program: Two modules can communicate:

o Through a variable or data structure (for example, array, table, or record) that is passed directly as a parameter between the two modules. The data is used for problem-related data processing not for program control purposes.

o Through a variable or data structure (for example, array, table, or record) that is passed directly as a parameter between the two modules. However, only part of the data in these composite data elements is needed in the call, that is, more data is passed than needed. A change in one of the data structures to accommodate a change in either the calling or called module can affect other modules as well.

o By passing data from one module to another to control the order of instruction execution. (For example, a control flag is set in one module and tested in a CASE or WHEN statement in another module).

o By passing data between modules through some mutually agreed upon location in a global data area (for example, FORTRAN COMMON and PL/I EXTERNAL features). A change in one module might then require changes in other modules sharing the same data area.

o By one module reaching into the internals of another module to get or deposit data or control its function. (For example, a branch from one module's code into another module. A change in either module might require a thorough analysis of the internals of both modules to determine how to deal with the consequences of the change.)

If contaminated data (2-digit-year data) is shared among modules, you must identify the exposure caused by the data sharing on the receiving side of the transaction.

Once you have identified Year2000 exposures, apply the appropriate techniques (as provided in Chapter 5, "Reformatting Year-Date Notation" on page 5-1) to reformat these date and time representations.

MISCELLANEOUS DATE-RELATED ISSUES AND/OR EXPOSURES

Various programming techniques and practices that relate to the use of dates and date fields might also require your consideration when identifying potential exposures. Such areas of concern are discussed below.

SUPPORT FOR EXPIRY DATES

For compatibility with existing function, to prevent accidental data loss, and the common usage of dates to indicate 'never expire', IBM products will continue to respect non-expiry dates, such as 99.365 and 99.366 as indicated here:

o MVS AND OS/390 - If an expiration date is stored as the last day in 1999 (whether 99.365, 1999.365, 99.366, 1999.366, or any of the packed decimal forms - mm/dd/yy or mm/dd/yyyy - 12/31/99 or 12/31/1999), the data set is considered as a "never-expiring" data set.

Data sets with their expiration dates set to "never expire" can be deleted in the same manner as deleting a data set whose expiration date has not yet occurred; for example, using the PURGE parameter with the DELETE command.

Various components of the operating environment minimize any impact to your system if you accidentally code 99.365 when you did not intend "never expire." For example, if you create a new data set using JCL, and you inadvertently provide a retention period (RETPD) number of days that when added to the creation date is 1999-December-31, MVS changes the expiration date to 2000-January-01.

When using System-Managed Storage, the management class stores the retention period and the creation date rather than calculate the precise date. This permits code in DFSMShsm (and formerly DFHSM) to allow data sets to have an expiration date of 1999-December-31, without being confused with the "never expire" value. Additionally, SMS permits specification of NO LIMIT to indicate that this data set does not expire and can only be deleted if special conditions are followed, such as using the PURGE parameter with the DELETE command.

When using DFSMSrmm (or DFRMM) to manage tape data sets, there are variable options within the defined policies to control data set expiration. Therefore, it is possible to determine whether to continue to recognize 99.365, 99.366, 1999.365 and 1999.366 as never expire dates or to use new indicators in the control data set (CDS) to determine if the data sets should be allowed to expire.

The current MVS and OS/390 environment allows you to continue to treat 99.365 (and its variants) as a "never expire" date while components such as SMS and DFSMS are moving to the use of flags to specify this condition.

o VSE/ESA - BAM, VSAM, and utility processing that build file creation dates and expiration dates and check for file expiration is extended to include the century field in the determination of the current date.

VSE/ESA will continue to respect files with an expiration date of 1999/365 as never expire, EXCEPT when the date was calculated from a retention period specification. That is, if the file creation date plus the retention period equal 99/365, VSE/ESA will expire the file on 1999-December-31.

o VM/ESA - Standard tape label processing supports the use of 99365 and 99366 as never expire dates. When a tape containing a label with one of these dates is mounted, an UNEXPIRED TAPE warning message is issued. The user can then either respond "IGNORE" (write to tape) or "ERROR" (do not write to tape).

For expiry dates of 99365 and 99366, the UNEXPIRED TAPE warning will continued to be issued even after 1999-December-31.

LANGUAGE ENVIRONMENT AND DATE SIMULATORS

ATTENTION:

Be aware that Date Simulators (as marketed by Solution Developers) should only be installed on a test version of DB2 (DATABASE 2) and Language Environment. These tools corrupt a module in both the DB2 and Language Environment products. This is acceptable for your Year2000 testing purposes, but the product is no longer warranted by IBM after you install such Date Simulator products. Therefore, install a separate copy of DB2 and Language Environment or both for use in Date Simulation testing than the copy used for production or final 'Time Machine' testing.