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

Defining the Scope and Process for the Project

We used the following processes to define the scope of the project and break it down into manageable pieces:
  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.
    Back Forward

    » Return to Guidelines for Year 2000 Code Investigations home page