Hi all,

We received good input from you on various Year 2000 issues, especially
related to the new date intrinsics, at IPROF and HPWORLD.  We have few
more important questions to ask you before we complete our coding.

  MPE/iX OS

     Our current design is to have 50 as the split year for handling
     TWO digit years. (i.e., 00..49 will be interpreted as 2000-2049
     and 50-99 will be interpreted as 1950-1999).  Note that all
     confusion can be eliminated by using four digit years, but we realize
     that it will be convenient for many applications to continue to
     support two digit years.  The following commands accept two digit
     years (and will accept four digit years too):
        (1) :STREAM ;DATE=mm/dd/yy
        (2) :FILE ;LABEL=expiration date
        (3) :SETCLOCK date-spec
        (4) :LISTSPF/SPOOLF ;SELEQ=[date=mm/dd/yy]
        (5) :STORE/RESTORE/VSTORE ;DATE=mm/dd/yy[yy]

     For the above commands, two digit year fields will always be interpreted
     using the YY:Split method.

     MPE will also include a new CI variable named HPYEARSPLIT that contains
     an integer between 0 and 100, which will be used in the new date
     intrinsics for split year interpretation.


     We recently learned that HP-UX adopted the X/Open Standard for YY split,
     which applies to the C library routines, and date, get, prs commands.
     Per the X/Open Standard document, getdate(3c) and strptime(3c) are
     the two routines that handles 2-digit years and standard recommends
     69 as the split year. (We do not currently have these routines in
     MPE/iX as we adopted POSIX.1, POSIX.2 standards).


     QUESTION #1

        In view of HP-UX choosing 69 as the split year per the X/Open
        Standard, do you still prefer to have 50 as the split year for
        MPE/iX, or do you prefer 69 as the split year?


  VPLUS on MPE/iX

     Our current design and implementation (available in 5.5 Exp 2) is
     to have 50 as the split year.

     This split year feature can be enabled by setting bit 14 to 1 in the
     new JCW VSETNEXTCENTURY.  This JCW is not initially defined and
     its absence implies that VPLUS treats all dates as having two
     digit years, and ALL two digit years are assumed to be in century 19.
     By default there is no YY:Split.  [Note: bit 15 of this same JCW
     controls whether or not VPLUS converts two digit user input years to
     four digit years.]  Additional enhancement already made to VPLUS
     include new instrinsics for handling four digit years and new ARB
     type YYYYMD for four digit years.

     QUESTION #2

        If we decided to change the split year to 69 for MPE/iX OS
        (Question #1), do you also want to change the split year for
        VPLUS from 50 to 69 to match MPE?


     We heard that some groups were not happy about the current
     JCW method as a means of configuring how VPLUS apps behave wrt
     Year 2000 issues.  The concern seems to be that the same VPLUS app can
     work differently depending on how a particular job or session
     defines the new VSETNEXTCENTURY JCW.  Also, some disappointment
     was expressed that the VPLUS team did not solicit feedback from
     the members of this list.

     QUESTION #3

        Do you prefer the current VPLUS design and implementation wrt
        the VSETNEXTCENTURY JCW?  Should there be some relation
        between VSETNEXTCENTURY and HPYEARSPLIT?  Should VPLUS, on 6.0
        and later, always assume two digit years will be split (either
        at 50 or at 69) rather than the current design which defaults
        all two digit years to century = 19?


   ALLBASE/SQL

       In view of being a database application, the current design is
       to have the split year as configurable value by setting the
       environment variable HPSQLsplitcentury between 0 to 100.

       It is considered too late to change our ALLBASE implementation.


I look forward to your feedback on this timely issue!

best regards,

Gopi ([log in to unmask])
CSY R&D India, Bangalore