CHAPTER 2.
THE YEAR 2000 - A TRANSITION

Although 2000-January-01(1) is still several years away, you need to plan for and address the 1999 to 2000 date change well in advance of that date. Even before we reach 2000-January-01, your computing environment might not work as expected because your systems and/or application programs might not properly process dates beyond 1999-December-31. Consider the following scenarios to help put the problem into perspective. All stock exchanges close down indefinitely because of invalid transactions; credit card companies refuse most transactions because cardholders appear delinquent on their payments; mortgage companies are besieged by angry borrowers who have just received delinquency notices in error and been charged extra interest; and utility companies cut off service to many customers due to apparent late bill payments.

The potential exposure mostly comes from, but is not limited to, the use of a 2-digit-year (YY) format, instead of a 4-digit (YYYY) format, for year representation within programs, files, databases, and processes. For example, the year 1996 is represented as '96', the year 1999 as '99', and so on. Thus, 2000-January-01 is represented as 01/01/00 (if using MMDDYY format in your data) and might be interpreted as 1900-January-01 rather than 2000-January-01. This might cause programs that perform arithmetic operations, comparisons, or sorting of date fields to yield incorrect results when manipulating year-date data of 2000 and beyond. The potential exposures that might be encountered, and their variations (listed in Section "Year2000 Exposure Classification" on page 2-2) have been referred to by IBM as the Year2000 challenge.

The scope of the Year2000 challenge spans the entire Information Technology industry. A data mismatch can exist in any level of hardware or software, from microcode to applications, in files and databases, and can be present on ANY (IBM and non-IBM) Information System (IS) platforms.

Some general MISCONCEPTIONS of the Year2000 challenge include:

1. This is a problem that occurs only when/after the century rolls over.(2)

(1) Although currently not in popular usage throughout the world, ISO Standard 8601 defines acceptable date formats as yy-mm-dd or yyyy-mm-dd. To apply that standardization and some consistency to this document, when a date is used in a general (non-technical, non-product-specific) manner, the date is written in a similar format (yyyy-month-dd).

(2) IBM recognizes that the 21st century begins at 0000 hours, 2001-January-01, but for purposes of this document, we are defining the 20th--21st century boundary to be between 2400 hours, 1999-December-31 and 0000 hours, 2000-January-01. This allows a discussion of the 21st

The challenges of handling the Year2000 changes can occur well before the year 2000 arrives. Typically, forecasting applications that deal with future dates will encounter problems well in advance of the year 2000. In fact, applications are already facing the problem; for example, the financial applications that deal with life insurance or bond policies that have expiration dates that go beyond the year 2000. In such an application, the programs need to handle the dates beyond the year 2000 when checking policy expiration.

2. This is a hardware clock problem that should be resolved by the computer vendors.

In fact, it is both a hardware and software problem. The problem resides mostly, however, in application programs and data using two digits for year representations.

3. This is a problem that only occurs on mainframe systems and/or legacy applications.

Any system or program can be affected if it uses only two digits for year representation: any file, database, log with 2-digit-year fields, and any data entry, query, update and output processing that employs 2-digit-year fields. It can also affect programs, systems, databases, and other functions and processing that receive input from these programs and data.

YEAR2000 EXPOSURE CLASSIFICATION

The Year2000 phenomenon is further compounded by the numerous variations used to express year and date notation in data and the mathematical calculations performed on those date notations. These variations can be classified as the following exposure types in these examples:

o Incorrect century

Problems can occur when the first two digits in a year are assumed to be 19 and:

- Ignored during data entry and update, or
- Hard-coded for output.

o Dates used as a special value:

Special values of the last two digits in a year might be used for special purpose, for example 99, 9/9/99, 365/99, or 12/31/99 (31/12/99) might be used to indicate "no expiration date" or 00 to indicate an "unknown year."

o Incorrect field format determination:

century to include all dates with a 20yy format inclusive of the year 2000. Hence, the year 2100 is likewise relegated to the 22nd century.

Some existing programs determine the date-time format (that is, MMDDYY, DDMMYY, YYMMDD) by testing an appropriate part of the date field. For example, checking if the first two characters of the date field are values within an acceptable month, day, or year range (such as 1-12, 1-31, or r32).

o Arithmetic calculation:

The arithmetic calculations that operate on dates with 2-digit year representations might have potential exposures. For example, a person with a birthday of 1961-November-10 will be considered to be -61 years old rather than 39 years old on 2000-November-10 if the years 1961 and 2000 are represented by 61 and 00, respectively (that is 00-66=-61). Generally, a program that is not expecting a signed value, will ignore the sign; thus, in this example, the -61 might be interpreted as the absolute value 61. Not only is the value still incorrect, it is even less detectable than the incorrect -61. Further, if such incorrect data is then stored in a data base, it is considered a data integrity exposure.

o Sequence:

When only two digits are used to represent a year, programs that collate year data will sort that data out of sequence in some cases. For example, the year 2000 (if represented as 00) will be ordered prior to the year 1999 (if represented as 99).

o Data integrity:

In programs where historical dates are used, all events occurring in, for example, 1800, 1900, and 2000 are not distinguishable when the years are represented by only 2 digits.

o Leap year calculation:

A specific year is a leap year if it is either evenly divisible by 400 OR evenly divisible by 4 and not evenly divisible by 100. For example, the years 1700, 1800, 1900, and 1995 were not leap years but the years 1600, 1996, and 2000 are leap years. Some potential exposures caused by the identification of the year 2000 as a non-leap year are:

- Day-in-year calculations. The year 2000 has 366 days, not 365.

- Day-of-the-week calculations. 2000-February-28 is a Monday and March-01 is a Wednesday, not a Tuesday which is 2000-February-29.

- Week-of-the-year calculations. The 11th week of the year 2000(3) is March 13 through 19, not March 14 through 20.

(3) ISO Standard 8601 provides the following: 1) a week begins on a Monday and 2) the first week of a year is the first week containing four or more days (that is, the first week containing a Thursday).

o Date fields on hardcopy forms:

Although not directly a Year2000 exposure, the format used on hardcopy forms to record date data will, in many cases, require change. Examples include, the date field on a bank check which is typically printed as follows:

___________________ 19____

The century, "19", is pre-printed, and the format for day and month is non-restrictive, thus allowing any day-month ordering and any month indication (numeric, abbreviated or full character spelling, Roman numeral, or any other indication of date provided at the writer's whim). Minimally, the "19____" must be changed or deleted. But the non-restrictive date field only helps propagate non-standard date formats and might cause misinterpretation when the data is later input into a database. Therefore, if you are required to change your stock of forms, consider structuring the date fields they contain to match your proposed database changes.

SCOPE OF YEAR2000 TRANSITION

The computing environment(4) today is mostly constructed and integrated around the theme of heterogeneous, open, distributed, and client-server computing. The computers from different vendors are networked together to provide an integrated and distributed computing environment. Even though there are many different kinds of platforms in such an environment, they all tend to have the following common components:

 COMPUTER HARDWARE

 o   CPUs
 o   storage devices
 o   input/output devices
 o   communication devices
 o   and so on

 COMPUTER SOFTWARE

 o   Microcode

 o   Operating systems

(4) However, the Year2000 challenge is not restricted to the computing environment alone; it goes far beyond the traditional "computing environment" or "IT structure." Potentially, the Year2000 challenge extends into any piece of machinery that contains a microchip to include elevators, traffic lights, telephone systems, power supplies, cooling systems, security access control, fax machines, photocopiers, and so on. This book focuses on traditional IT software systems, and limits its attention to hardware as presented in the appendices.

o Middleware, such as database management systems, telecommunication control programs, transaction monitoring programs, and so on.

o Programming languages, such as COBOL, Fortran, PASCAL, PL/I, C, and Assembler

o Solution Developers and '3rd party' software providers

o Application programs

PEOPLE

Those who develop and maintain the system, those who operate the system, those who provide its input and use its output, those who manage and ensure the quality of the system, and those who provide manual processing activities in a system. These people include:

 o   End users
 o   Management
 o   Auditors, quality assurance people
 o   System analysts
 o   System designers
 o   Programmers
 o   Operations personnel

DATA

The information that the system records and processes.

PROCEDURES

Formal policies and instructions for operating the system.

Figure 2-1 illustrates these components in an organization's networked computing environment. At each computing node (viewing the figure vertically), information systems (IS) personnel follow procedures to access the data by means of computer software and hardware. The computing nodes (viewing the figure horizontally) are networked together by communication hardware and software to communicate to other computing nodes internal and/or external to the organization. The data is thereby accessible anywhere and anytime while the computing nodes are connected.

The Year2000 phenomenon potentially has both vertical and horizontal impact on such a computing environment as pictured above. Vertically, the Year2000 phenomenon can originate from or affect the key components of the computing systems, that is, hardware, software, people, data, and procedures. Horizontally, the phenomenon can propagate as the contaminated data flows to other computing systems inside and outside of the organization. In short, the scope spans the entire information technology industry.

Although this is a complicated and far-reaching problem, it is not a technically difficult problem to resolve when viewed on a module-by-module or routine-by-routine basis. The degree of complexity is directly related to the inter-relationships between routines and programs and the data passed between them. THIS IS NOT A TRIVIAL PROGRAMMING EXERCISE. Your realization of a Year2000-ready system demands immediate management commitment, dedicated resources (personnel and hardware), strategic planning, rapid development, acceptance testing, a well-planned migration, and an adequate budget. The following chapters address these issues and provide basic approaches for some specific issues.