You asked:
Is VMS Year 2000 Compliant???
The following statement is from OpenVMS Product Management:
What is the Year 2000 Problem? It stems from the common practice of using two
digits instead of four when writing dates and having multiple internal time
formats. When this practice is extended into computer hardware and software,
it causes arithmetic operations, comparisons, and data sorting procedures to
yield incorrect results when working with years beyond 1999.
As Digital's customers begin to consider the readiness of their computing
systems for the transition to the year 2000, many have begun asking what
impact it will have on their OpenVMS systems.
We are happy to answer that, because of insightful development by the
engineers who created it, OpenVMS was born ready. The OpenVMS operating
system base date uses a four digit format that is totally unaffected by the
transition to the year 2000.
Customers who have consistently used the system base date and the associated
system services that provide the ability to input and retrieve four digit
ASCII year strings, will make a seamless transition into the year 2000 when
accessing their data.
We are currently researching other "date sensitive" areas of the operating
system where additional enhancements would provide more robust support and
readiness. Our partner software groups, inside and outside of Digital are
also looking into the "year 2000 compliance" of layered products, to ensure
that they are tested and to provide consistent support for the turn of the
century.
In the coming months ahead, Digital Equipment will periodically provide all
the information that needed regarding how the OpenVMS operating environment
and other products deal with the transition to the year 2000.
OpenVMS' overall position on the issue can be summarized as follows:
* OpenVMS system base date will continue to be operational after the
date changes from calendar year 1999 to 2000 to 2001. We are currently
evaluating additional enhancements in specific "date sensitive" areas of
the operating system. These enhancements will be included in upcoming
releases of OpenVMS, available for use well in advance of the start of
the year 2000.
* While we know of no systematic way to ensure that all customer
code will also continue to work across the year 2000 boundary, we do allow
the clocks of our system to be set to times in the future to allow
customer testing of their software (a reboot is suggested to ensure
application time consistency).
* We are evaluating the possibility of engaging in system integration
contracts to support individual customers in reviewing their software for
problems of this sort.
* If we become aware of tools that seem generally applicable, we will work
with the suppliers to offer them on our platforms.
Customers can continue to depend on OpenVMS in the knowledge that it has been
proven in the most demanding environments. We will continue to bring them
enterprise system dependability, 24x365 availability, disaster tolerance,
scalability and the best cluster technology in the industry for many years to
come.
