HP OpenVMS Systems

The OpenVMS Year 2000 Initiative addresses the VAX and Alpha base operating systems and their layered products. This initiative is founded on formal, comprehensive, and detailed analyses of OpenVMS product code, followed by extensive testing.

This page provides a brief overview of the work we did to ensure Year 2000 readiness of the OpenVMS operating system. The procedures described here apply to the following OpenVMS versions:

• OpenVMS VAX Version 7.1
• OpenVMS Alpha Versions 7.1, 7.1-1H1, 7.1-1H2
• OpenVMS VAX Version 6.2
• OpenVMS Alpha Versions 6.2, 6.2-1H1, 6.2-1H2, 6.2-1H3
• OpenVMS VAX Versions 5.5-2, 5.5-2H4

These are the only old versions of OpenVMS that are supported for the Year 2000. Extended support of these versions is planned beyond the year 2000.

All of the enhancements included in the Year 2000 kits have been integrated into OpenVMS Version 7.1-2 and OpenVMS Version 7.2. In addition, all new or revised code for these versions and for all future releases is reviewed, certified, and documented by engineers for Year 2000 readiness. Similarly, any code or bug fixes checked into patch kits for the older versions of OpenVMS listed above and for all new versions of OpenVMS are also reviewed and certified for Year 2000 readiness.

OpenVMS Engineering has taken the Year 2000 issue very seriously. Work began in mid-1996 to plan, investigate, test, and, if necessary, update code to ensure Year 2000 readiness. Each piece of operating system code was inventoried and assigned to an investigating engineer. Engineers were issued a set of guidelines to ensure that the investigation was done in a thorough and consistent manner. In most cases, the investigation consisted of a line-by-line inspection of the code source. In very rare instances, where an engineer was extremely knowledgable about the code and determined that the code contained no date or time references, this requirement was waived.

The main focus of the OpenVMS Year 2000 Initiative was the source code investigation because we believe that testing alone cannot prove the Year 2000 readiness of very complex operating system software.

After the code inspection, we updated four mixed-architecture clusters in our OpenVMS test lab with the Year 2000 enhancements. Test environments for OpenVMS Version 7.1 systems included DECwindows Motif and DECnet-Plus for OpenVMS (Phase V). OpenVMS Version 6.2 and Version 5.5-2 systems ran with DECwindows Motif and DECnet for OpenVMS (Phase IV).

For each version of OpenVMS that we investigated, we ran the full OpenVMS regression test suite on these clusters and reviewed the output. This regression test suite is the same series of tests that is run on every major release of OpenVMS to ensure the integrity of the entire base operating system environment. The regression test suite consists of specific system service tests (including all time-related services), stress tests, and many tests that exercise the overall system.

We specifically tested these clusters for the following dates:

• Roll over from December 31, 1999 to January 1, 2000
• Roll over from February 29, 2000 to March 1, 2000
• Roll over from December 31, 2000 to January 1, 2001
• January 3, 2030 (final test date)

In addition, ad hoc testing of certain components included other dates, such as September 9, 1999 (9/9/99).

To augment the traditional set of regression tests, we did many additional tests, including the following:

• Backup and restore of files (including a check of time stamps)
• Queuing print and batch jobs to hold over the tested dates
• Audit server tests
• DECwindows operations, including calendar, clock, and others
• RMS Journaling functions
• Job Controller functions
• LMF Licensing functions
• Account and password expiration
• DCL commands
• Crash dumps written and analyzed
• Cluster configurations: added a satellite, starting on one date and finishing after the date rolled over
• XQP functions
• Magnetic tape ACP functions
• Matrix testing of a variety of installation scenarios

The results of our tests and investigations confirm that applications that consistently use the 4-digit year representations that OpenVMS produces or accepts as input will not be affected by the transition to the year 2000. Since OpenVMS is one of the few operating systems that allows users to advance system clocks to times in the future, you can test your own software now  for potential year 2000 problems. This web site also includes a document that offers guidelines for conducting your own code investigation.

In all investigated versions of OpenVMS, we found the same, few, trivial limitations in some older, rarely used components. These limitations are eliminated when the OpenVMS Year 2000 kits are applied.

Because the OpenVMS Year 2000 modifications are minor, we chose to distribute these changes in ECO kits rather than release new versions of the software. Kits are available for all versions listed at the top of this page. You can obtain these kits through the normal service channels and over the World Wide Web from Compaq's Digital Services. For more information about the kits, including kit names, refer to the OpenVMS Kits web page.

For customer convenience, all of the OpenVMS Year 2000 kits, plus kits for several layered products, are also available on media in an orderable OpenVMS Year 2000 Readiness Kit. (For information on the status of OpenVMS layered products, read the summary of our investigation findings on the Web.)

For more information on OpenVMS and the Year 2000, check the links on the  OpenVMS Year 2000 home page.