| <<< TURRIS::DISK$NOTES_PACK2:[NOTES$LIBRARY]DIGITAL_UNIX.NOTE;1 >>>
-< DIGITAL UNIX >-
================================================================================
Note 4628.1 Discussion: YEAR 2000 1 of 5
namix.fno.dec.com::jpt "FIS and Chips" 59 lines 6-MAR-1996 14:24
-< one statement >-
--------------------------------------------------------------------------------
I thought I swa this here, but couldn't find it in 1 minute so I
post it here as your Title is descriptive. So, here's the
statement:
-jari
------
I revised the Digital UNIX Year 2000 customer statement to reflect comments
from Kent, Tom Szcz and Dave Smith regarding committing to tools; and also
comments from Alan Nemeth regarding confusing wording around new releases.
Otherwise everyone agreed with the statement so it should be ok for use.
Thanks,
Vince Mamone
Revised statement follows:
--------------------------------------------------------------------------
Digital UNIX Date Support for the Year 2000 and Beyond
In preparation for the arrival of the year 2000 we have looked into the
readiness of Digital UNIX for date support in the new century. Overall
Digital UNIX is well positioned for this support.
An investigation has been conducted that examined date and time support on
Digital UNIX. The system was found to roll-over into the next century with no
problems. We have also identified several areas where additional enhancements
would provide more robust date and time support and readiness for the year 2000
and beyond. These enhancements will be included in a new release of Digital
UNIX currently in planning. This release is expected to be available during
calendar year 1997.
The current design utilizes opaque data types such as time_t or the timeval
structure which are not century specific. This approach has minimized
the opportunity for problems with internal time calculations and the turn-
of-the-century.
The date command, and system management GUI utilities, will be enhanced, as
part of the new release of Digital UNIX, to allow setting the system date
beyond the year 2000 and back. Even though the system correctly moves into the
new century, the current date command can set the system date only up to
31-dec-1999.
The existing 2 digit year input accepted by the date command is consistent with
current standards (POSIX, XPG4, SPEC1170, etc). Digital will participate with
and track evolving standards, ensuring that these enhancements to Digital UNIX
are consistent with our commitment to standards.
Digital has also looked into the needs of layered products to address the
Year 2000 date issue. Digital will be working with partner software groups,
inside and outside the company, so that these layered products are tested and
ensured of providing a consistent level of date support for the turn-of-the-
century. Customers will be able to take advantage of the enhanced date support
in the new release expected in calendar year 1997 to test the readiness of
their applications for the turn-of-the-century well ahead of time with minimal
disruption.
|
| > From: NAME: John Corne <[email protected]@PMDF@INTERNET>
> To: NAME: 'BAT' <BAT@SMURF@MRGATE@RDGMTS@REO>
> The year2K question has been raised again......
> I'm not sure who is handling this for MLS+ nowadays
Neither am I. Unless of course you mean, who is going
to do the work? In which case, it is uz, the people you meet
here in this cozy corner just off Exit 23 on information highway.
> Will MLS+ V3.1a ever be year2K compliant (I expect not:-)
It was not on the "list" last year.
MLS+ land had a discussion on Year 2000 this past Fall
I'm now paraphrasing the position taken at that time
(see 760.6 in smurf::ultrix_mls_plus):
"MLS+ Based on Digital UNIX --
- We will incorporate the date command patch that is currently
available into MLS+ V4.0 (done).
- Full yr 2K compliance is planned for Digital Unix for
November 1998. We will backport those changes some time
after they are available."
"MLS+ Based on ULTRIX --
- When ULTRIX completes the date patch, we will make sure it works
with ULTRIX MLS+ and make it available to our ULTRIX MLS+
customers."
Whether the above position still applies to life in this not-so-fast
lane (the breakdown lane?), I do not know. Phil Becker is the best
(most optimistic :-) person to ask. That's [email protected] to you.
Why the "algorithm" we used above for ULTRIX MLS+ and Year 2000
does not apply to MLS+ V3.1A, however, I'm not sure.
My attitude is: if the code that MLS+ is based on
gets any fixes, we'd backport them. V3.1A is based on
an OSF V3.2B kernel and OSF V2.1 libraries, utilities, etc.
Provided of course that a customer wanted them.
Now, if DU is not going to backport their fixes to V3.2B or
V2.1 then we (engineering) are not likely to either. But
sources are sources, and all programmers have brown paper
bags on their head, and I'm sure that anything could be done
if money were changing hands.
> Will Digital ever list a set of known Y2K problems for V3.1a?
I repeat: anything for a fee. Fee, I said, not FREE :-)
My understanding is that the basic problem you have is layered
products. Provided the code doesn't store or parse and work on
anything in external date format, but instead uses the "clock
ticks since January 1 1970", then you are all set.
I would suspect that if you looked at the submits that will
take place (and actually some have already been taking place)
against the DU code pools as part of Y2K, you would be able to apply
the same, more or less precisely, to V3.1A. Your problem is going
to come about with layered software to which neither we nor your
customer has the source code, should there indeed be a problem
with that.
|