HP OpenVMS Systems

Year 2000

HP OpenVMS Systems

OpenVMS information

» What's new on our site
» Upcoming events
» Configuration and buying assistance
» Send us your comments

HP OpenVMS systems

» OpenVMS software
» Supported Servers
» OpenVMS virtualization
» OpenVMS solutions and partners
» OpenVMS success stories
» OpenVMS service and support
» OpenVMS resources and information
» OpenVMS documentation
» Education and training

OpenVMS software

» Operating system
» OpenVMS clusters
» OpenVMS Galaxy
» e-Business products
» Opensource tools
» Networking
» System management
» Storage management
» Security products
» Application development and integration
» Software licensing
» SPD listings
» Whitepapers
» Ask the wizard
» Training
» OpenVMS books

Evolving business value

» Business Systems Evolution
» AlphaServer systems transition planning
» Alpha RetainTrust program

Related links

» HP Integrity servers
» HP Alpha systems
» HP storage
» HP software
» HP products and services
» HP solutions
» HP support
disaster proof
HP Integrity server animation
HP Integrity server animation
Content starts here

Testing for the Year 2000 with OpenVMS

While testing cannot substitute for investigating code for year 2000 problems, you can identify potential year 2000 problems by testing software in an artificial environment that simulates future dates. The OpenVMS operating system allows you to set the system clock forward and backward, which provides an appropriate environment for system testing. The following procedure describes a technique for protecting your environment while testing applications for the Year 2000.

Many system applications and layered products are affected by any substantial modification of system time, independent of the change to the Year 2000. The following procedure includes guidelines that minimize side-effects that may occur due to these time modifications. Digital recommends that you follow these guidelines to ensure system integrity.


Do not perform Year 2000 tests or widely vary the system clock on a system in a production environment.

Follow this procedure to test your system:

  1. Ensure that installed Product Authorization Keys (PAKs) will not expire during the testing period. If your system has temporary PAKs, contact your application vendor.

  2. Perform a complete backup of the system disk and associated data disks. (If possible, back up to spare disks.)

  3. Remove the system to be tested from the production environment to ensure data integrity during the test session. For example, shut down all network connections as well as any local NTP or DECdts processes before changing the system clock. Nodes running NTP or DECdts clients or servers participate in maintaining system time across the network; their presence could either reset the clock to the current time or could serve a future time to all other nodes in the network.

  4. To ensure that the system time is reset before any application code is started, use the following commands to perform a conversational boot of your backup copy of the system disk:

    On VAX:

    >>> b/r5:1

    On Alpha:

    >>> b -fl 0,1

    Also set the SETTIME system parameter to 1:


    Then respond to the time prompt later in the bootstrap operation.

    Some VAX or Alpha consoles may require different commands. Consult the OpenVMS installation and upgrade documentation for your specific Alpha or VAX processor.

  5. Once the system has bootstrapped, mount the backup copies of any other necessary data disks.

  6. Initialize and complete tests for your specific environment. Among other dates, we have found the following transition dates interesting to test:

    • September 9, 1999 to September 10, 1999 to confirm correct translation of 9/9/99)

    • December 31, 1998 to January 1, 1999 (to check whether 99 is used to mean "no expiration date")

    • December 31, 1999 to January 1, 2000 (to check century transition; January 1 should be a Saturday)

    • February 28, 2000 to February 29, 2000 (to verify leap year calculation; Tuesday, February 29, 2000 is a valid date in the Gregorian calendar)

    • February 29, 2000 to March 1, 2000 (to verify leap year calculation; March 1 should be a Wednesday)

    These dates are only suggestions; more testing of later dates might be required to thoroughly test your applications.

    NOTE: DIGITAL recommends limiting all Year 2000 testing to dates prior to 19-JAN-2038. Another industry-wide, date-related problem will likely occur on that date 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.

  7. When testing is complete, shut down the system. Then mount and/or restore the original system disk and all associated data disks. (If you backed up your disks on tape instead of disk, restore the original system disk and all original data disks from your backup tapes.)

  8. Reboot the restored system. To ensure that the rebooted system has the correct time loaded, DIGITAL recommends that you perform a conversational bootstrap operation with the SYSGEN parameter SETTIME set to 1:

    On VAX:

    >>> b/r5:1

    On Alpha:

    >>> b -fl 0,1


»  Return to OpenVMS Year 2000 home page