HP OpenVMS Systems

These release notes identify certain conditions you should be aware of when preparing your OpenVMS environment for the year 2000. These kits contain minor modifications to several older and rarely used components of the operating system; other conditions are simply noted here, but require no changes. Release notes are included for the following facilities that run on the OpenVMS platform:

» Crash Log Utility Extractor (CLUE) (Alpha only)

» EXCHANGE Utility

» File System $QIO Interface

» ODS-1 File Format

» LIB$ Run-Time Library

» DEC C Run-Time Library (Version 7.1 only)

» TECO Editor

The TECO problem actually does not occur until 2028, but Andy figured he'd just go right ahead and fix it for you now because he expects to be retired by then!

All Year 2000 enhancements in these kits are included in the operating system starting with the release that follows OpenVMS VAX Version 7.1 and OpenVMS Alpha Version 7.1-1H1.

The CLUE history listing file contains a 2-digit year format in its file name, which has this format:

CLUE$node_ddmmyy_hhmm.LIS

This file format poses no year 2000 problem in itself, but the code that generates this date has been changed from using a subtract operation to using a modulo function so that the correct date will still be calculated in the year 2000. This change has no visible effect on the file name format.

When the EXCHANGE utility is used to transfer files between OpenVMS and RT-11 or DOS-11 systems, date problems could occur starting in the year 2004 for RT-11 and in the year 2036 for DOS-11.

---

Note

RT-11 volumes are also used as console storage media on certain older VAX systems.

---

This kit contains an enhancement to EXCHANGE that makes the RT-11 date format continue to function correctly until the year 2099.

---

Note

DIGITAL transferred the RT-11 operating system, along with other PDP-11 software, to Mentec in 1994.

---

The following sections describe conditions you should be aware of if you interoperate with RSX-11 or if you use RSX-11 software on your OpenVMS system.

File System $QIO Interface

The file system $QIO interface supports several attributes for RSX-11 compatibility. Of these, ATR$C_EXPDAT and ATR$C_ASCDATES return the file creation date, revision date, and expiration date using 2-digit years.

These attributes are not normally used by native code and can be replaced with the following documented, compliant interfaces:

• ATR$C_CREDATE
• ATR$C_EXPDATE
• ATR$C_REVDATE

The file system $QIO interface is provided by the following file systems:

• DIGITAL TCP/IP Network File System (NFS) client
• Distributed File System (DECdfs)
• Magnetic tape ACP
• OpenVMS ODS-1 file system
• OpenVMS ODS-2 file system
• Spiralog file system (Version 7.1, Alpha only)

ODS-1 File Header Format and Utility Support

For RSX-11 compatibility, OpenVMS VAX supports ODS-1 file format disk volumes. The ODS-1 file system uses a 2-digit year format internally, and current implementations have limitations for the year 2000.

The magnetic tape ACP also returns an ODS-1 format file header in response to an application request for the ATR$C_HEADER attribute. This feature is supported on both VAX and Alpha.

ODS-1 data structures use a 2-digit year ( ddmmyy) in the following items:

• ODS-1 file header:
  • FI1$T_CREDATE
  • FI1$T_CRETIME
  • FI1$T_EXPDATE
  • FI1$T_REVDATE
  • FI1$T_REVTIME
  
  
• ODS-1 home block: HM1$T_CREDATE

The OpenVMS file system and the following OpenVMS utilities that support the ODS-1 file system format have been modified to correctly interpret these 2-digit years until the year 2057:

• Analyze/Disk_Structure Utility
• Backup Utility
• Dump Utility
• Librarian (LBR) routines

---

Note

Even though we are updating the ODS-1 code for the year 2000, Compaq strongly recommends that users of ODS-1 formatted media move to a newer file format by the year 2000.

---

In the run-time library, the LIB$CONVERT_DATE_STRING routine allows the user to select a 2-digit year format (as well as many others). This routine interprets 2-digit years as belonging to the century in which the system is currently running (according to the system clock). For example, in the 1900s, 61 is interpreted as 1961, and starting January .1, 2000, 61 will be interpreted as 2061. If this behavior could produce unexpected results on your system, select one of the alternatives to the 2-digit year format.

---

Note

This behavior has been documented in the OpenVMS RTL Library (LIB$) Manual since Version 6.0, so we will not change the code. No customer should be penalized for reading the documentation and complying with our stated intentions!

---

The following release notes describe year 2000-related conditions in Version 7.1 of the DEC C Run-Time Library.

• In OpenVMS Versions 7.0 and 7.1, the DEC C Run-Time Library function times ( ) returns the number of clock ticks since boot time. A clock tick is 1/100th of a second, which allows the routine to represent approximately 250 days. Therefore, an error can occur if you set the system clock ahead more than 250 days to perform year 2000 testing.
  
  The DEC C Run-Time Library has changed the reference point from SYI$_BOOTTIME to JPI$_LOGINTIM to avoid this testing error.
  
  
• Some XPG4 locales in the DEC C Run-Time Library display dates with 2-digit years. These are coded in accordance with the X/Open Company Limited specification and cannot be changed. For your information, the following locale source files in the Alpha ACRTL facility and the VAX CRTL facility use %y to denote a 2-digit year:
  
  
  • DA_DK_ISO8859-1.LSRC
  • DE_CH_ISO8859-1.LSRC
  • DE_DE_ISO8859-1.LSRC
  • EN_US_ISO8859-1.LSRC
  • ES_ES_ISO8859-1.LSRC
  • FI_FI_ISO8859-1.LSRC
  • FR_BE_ISO8859-1.LSRC
  • FR_CA_ISO8859-1.LSRC
  • FR_CH_ISO8859-1.LSRC
  • FR_FR_ISO8859-1.LSRC
  • IS_IS_ISO8859-1.LSRC
  • IT_IT_ISO8859-1.LSRC
  • IW_IL_ISO8859-1.LSRC
  • NL_BE_ISO8859-1.LSRC
  • NO_NO_ISO8859-1.LSRC
  • PT_PT_ISO8859-1.LSRC
  • SV_SE_ISO8859-1.LSRC

This kit includes two minor changes to the TECO editor. (Who says you can't teach an old dog new tricks!)

• The date value in the TECO editor has been extended to a longword so that the year value returned by the Ctrl/B function will not overflow on 01-JAN-2028.
  
  
• This kit also fixes a TECO problem that is unrelated to dates. The UIC value returned by the 2EJ function was incorrect if the process UIC had a group or member number greater than 377.
  
  For compatibility reasons, the 2EJ value cannot be changed. However, the problem has been fixed by the following changes:
  
  
  • All group and member numbers that exceed a byte are now mapped to 377 (octal).
    
    
  • A 3EJ function has been implemented to return the longword UIC. The following TECO example demonstrates the change. NOTE: The ESCAPE (<ESC>) sequence can be entered on most keyboards by typing Ctrl/[.

    $ SET UIC [1234,567]
    $ TECO
    *3EJ/65536==<ESC><ESC>
    .1234

    *3EJ&65535==<ESC><ESC>
    
    567