Conference vmszoo::rms_openvms

2000.0. "YEAR 2000: RMS fully Y2K compliant" by STAR::EWOODS () Sat May 17 1997 15:53

  I received a couple of inquiries last week whether RMS had a problem
  with Year 2000.  It seems appropriate to nip any rumors to the contrary
  by adding a notes entry on the subject in the RMS notes conference. 
  Since there appears to be a proliferation of notes on the subject of
  Year 2000, I ask that this note be confined to questions, comments and 
  information on the topic relevant to RMS file and record I/O.

  I want to state unequivocably in this first entry that RMS is fully 
  Year 2000 compliant.  This conclusion is based on a line-by-line inspection 
  of all the RMS and FAL code (and RMS utilities) by the RMS engineers.

  There are two changes related to Year 2000 that RMS is planning to include 
  in the next version of OpenVMS after V7.1.   Both changes are being added 
  as "enhancements" that provide options for RMS users which may facilitate 
  efforts to make their own code or data files Year 2000 compliant:

      1.   Segmented collated key support

	   Some users have ASCII date keys in their RMS indexed data
	   files that are based on a 2-digit year (for example,
	   YYMMDD or a Julian date of YYddd).  By adding segmented 
	   support to the existing collated key type, the 2-digit year 
	   could be reordered as 80, 81, ..., 98, 99, 00, 01, ... 79, 
	   without adding a century prefix to the existing date field.   
	   	   
      2.   FAL 128-bit UTC binary date/time support

      	   OpenVMS RMS and FAL exchange date and time information about 
	   files (e.g., file creation or revision dates and times) using 
	   a 2-digit year in accordance with the Data Access Protocol (DAP, 
	   Version 7.2, Section 5.15).  Currently, OpenVMS RMS and FAL 
	   implement this by pivoting the YY year field around the year 1970.  
	   That is, YY's from 70 to 99 map to 1970 through 1999 and YY's from 
	   00 to 69 map to 2000 through 2069.  Since the year is pivoted, 
	   OpenVMS will not see any problems with DECNET FAL access to file 
	   dates until the year 2070.  In other words, it is year 2000 
	   compliant.

	   However, non-VMS clients of OpenVMS FAL (DOS FAL for example) 
	   have the potential of breaking at the year 2000 if they haven't 
	   built a similiar pivoting algorithm into their code.  For this 
	   reason, as an enhancement for non-VMS clients, support will be 
	   added to OpenVMS RMS and FAL for passing dates using the 128-bit 
	   Coordinated Universal Time (UTC).  Support for UTC was added to 
	   Version 7.2.3 of the DAP specification.  A client of OpenVMS FAL 
	   must enable the system capabilities (SYSCAP) bit 65 in order to 
	   indicate any dates exchanged should be expressed in the UTC format.

	   Implementing this capability will not introduce any 
	   incompatibilities with existing clients of OpenVMS RMS and FAL 
	   since the old method will still remain intact.  

  Again I emphasize that OpenVMS RMS is fully Year 2000 compliant without 
  either of these changes.

  RMS is also willing to backport both of these enhancements starting with 
  OpenVMS V6.1 through an existing distribution media: the RMS remedial
  TIMA kits.

  The first enhancement is currently being tested by a customer.  To quote
  him, he thinks this change will save his company "quite a wad of money."  
  Not only will it save them from having to add a century prefix to many data
  files, but more importantly from having to modify code in a number of
  applications.  He is now testing it with their applications to verify
  whether he is correct.  

  I should note, however, that the usefulness of the first enhancement is 
  language dependent for applications that use language RTL I/O
  rather than direct calls to the RMS services.  The basis for file and 
  record I/O that this customer will be using is the FORTRAN RTL.  This 
  change (segmented collated key type) is transparent for existing files to 
  FORTRAN RTL.  It will not work with COBOL.  In fact, COBOL does not support 
  a collated key type -- segmented or not -- in an RMS indexed file.  

  Elinor Woods
  PL, OpenVMS RMS Engineering
  May 17, 1997
    

    Within a few minutes of my posting .0 on a Saturday, Hein responded.
    He felt this topic might be popular enough to merit a special place.
    
    Leave it to Hein to come up with this very easy number to remember.
    With a few nips and snips (nice to own a notes conference), it was made
    possible.
    
    Thanks, Hein!

  Elinor,
    It might be a good idea to place this in one or both of EVMS::Y2K and
  siog::year2000. (I don't know why there are 2 conferences).

						John Gillings, Sydney CSC

:    It might be a good idea to place this in one or both of EVMS::Y2K and
:  siog::year2000. (I don't know why there are 2 conferences).

   EVMS::Y2K is the OpenVMS Engineering Y2K conference and is the
   right place for any OpenVMS discussions around the Year 2000.
   (The other conference is rather more generic in nature.)

    
    Elinor, thanks for that update, that is the kind of thing that will
    save customers $$$'s.
     I'm curious as to how the  "Segmented collated key support" will be
    added to RMS while remaining transparent, can you share an overview of
    how the change will look to application developers who use RMS?
    
    brian

  brian --

  I will write up the details and post them but it may not be for a week or 
  two.  I have a few hot things on the fire and am pressed for time at the
  moment.  But I won't forget.

  -- Elinor