 |
We used the following processes to define the scope of the project and
break it down into manageable pieces:
- Made an inventory
First we created an inventory of all the
components and modules of code to be investigated. To do this, we
inventoried all the files that were used in the build of the OpenVMS
VAX and Alpha Version 7.1 release kits.
- Populated a database
We used the inventory data to populate a
database so that we could track investigation findings and chart our
progress toward completion.
- Identified areas of responsibility and assigned resources
Individuals were assigned to investigate the code they own and
these assignments were entered in our database. This exercise allowed
us to identify unassigned "orphan" modules (usually older code that is
not actively maintained), which were subsequently adopted by volunteer
investigators.
- Set investigation boundaries among dependent components
Where
the status of one piece of code is dependent upon the status of another
piece of code, we established boundaries of responsibility for
individual investigators and then coordinated the findings of each to
resolve dependencies.
- Established standard ratings for investigated code
Investigators were asked to rate investigated code (modules,
interfaces, routines, and global cells) as follows:
- N/A: The investigated piece of code does not contain or manipulate
date or time data.
- PASS: The investigated piece of code contains date/time-related
coding that will continue to function without error as the date changes
from December 31, 1999 to January 1, 2000, and well beyond that. Such
code meets the following requirements:
- The code correctly processes, calculates, compares, and sequences
date data within and between the 20th and 21st centuries, including
leap year calculations.
- All date calculations, representations, and translations are
correct for any date data within the date range covered by the
investigation. (The OpenVMS date range is
defined later in these guidelines.)
- The code provides 4-digit year interfaces and APIs, or, in the
case of 2-digit year representations, the code includes an encoding and
decoding mechanism that allows unique and unambiguous representation of
years over a range that spans the latter portion of the 20th century
and extends well into the 21st century. (For example, OpenVMS Alpha
allows the use of system global cell EXE$GL_TRANSITION_YEAR.)
NOTE:
Displays that use 2-digit fields to display years in dates are not a
problem unless an application parses the year value and uses it as a
date. To be safe, you may wish to convert all output year fields to
4-digit year fields where possible. You may also need to make
corresponding adjustments to any applications that parse these fields.
- Any dependency on external code is on code that has also been
investigated and found to be Year 2000 ready.
- FAIL: Some aspect of the code is not Year 2000 ready.
A piece
of code must be classified FAIL if it does not function properly with
date data beyond December 31, 1999.
NOTE: We also allowed the FAIL
status to be used to flag situations where enhanced documentation would
be helpful; for example, 4-digit alternatives might exist for 2-digit
year dates, but the alternatives could be better documented.
- DEPENDS: The code itself is Year 2000 ready, but it calls an
interface or routine whose status is not yet known.
NOTE: We tried
to schedule investigations so that the status of dependencies was
publicly available before dependent code was investigated.
- RETIRED: Code is for a component that is retired/unsupported or
will be retired/unsupported as of January 1, 1999, and the product
manager has explicitly stated that the code need not be investigated.
- Set 2038 as the boundary for achieving Year 2000 readiness
We determined that the Year 2000 Initiative would address any date/time
problems up to, but not including, the year 2038. We specified 2038 as
the cutoff date for the Year 2000 evaluation because another
industry-wide, date-related problem is likely to occur on
.19-JAN-2038 at 03:14:07 GMT. The Year 2038 problem is
analogous to the Year 2000 problem, but results from overflows
in the storage of time and date values in C programs. The Year
2038 problem is expected to have minimal adverse effects for the OpenVMS
operating system because the C date format is not the native date
storage format used
on OpenVMS. Generally speaking, OpenVMS has been designed to
function properly through the year 9999.
» Return to Guidelines for Year 2000 Code Investigations home page
|
