At 06:59 PM 4/28/97 +0500, M Gopalakrishnan wrote:
/snip
>     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?

My preference would be to adopt the X/Open Standard and use 69 as the
split year.  It makes sense to be consistent rather than different.
Besides, users can utilize the VAR and override the default.  Also, later
on when someone starts complaining about 69 being the default we can
simply point to the standard... ;-)  Also, being consistent with the
X/Open standard would help avoid confusion as more and more Open
System applications are ported to MPE/iX....right?! ;-)


>  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?

Again, for the sake of less confusion and more consistency, I would vote
Yes. (Just look at how much confusion is periodically generated because of
the different 'clock' setting on the system.)

>     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?

Sorry, I don't feel that I can offer any useful feedback on this question
as I'm not a currently a VPLUS user.

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

From my perspective as a vendor it's not too late.  However, I think
feedback from application developers would be more meaningful from
your perspective.

Thanks for the opportunity (even though I'm late in responding...)!

/jf