The Y2K readiness kits for specific OpenVMS releases prior to V7.1 are currently available to customers with an OpenVMS prior version support software support contract, and can also be purchased separately. The V7.1 Y2K readiness kits are presently available at the service area website:
http://search.service.digital.com/ http://www.compaq.com/support/For the official, most complete, and most current information on the status of Y2K compliance of Compaq hardware and software products, including that of OpenVMS and various OpenVMS layered products, please see:
http://www.compaq.com/year2000/ http://www.openvms.digital.com/openvms/products/year-2000/Information on the customer testing procedures recommended by OpenVMS Engineering are also accessable via the second URL above. Failure to follow the recommended Y2K testing procedures - particularly around the necessity for performing a disk BACKUP and restoration around any Y2K testing - can and has led to various problems at customer sites.
The VAX C "two digit" documentation for this area is in error, the VAX C Run-Time Library (RTL) returns a three-digit year.
The VAX C RTL and the other integrated RTLs are covered under the OpenVMS operating system Y2K evaluation. For curent information on the Y2K status of OpenVMS language compilers and layered products, see section Y2K1.
The C epoch typically uses a longword (known as time_t) to contain the number of seconds since midnight on 1-Jan-1970. At the current rate of consumption of seconds, this longword is expected to overflow (when interpreted as a signed longword) circa 03:14:07 on 19-Jan-2038 (GMT), as this time is circa 0x7FFFFFFF seconds since the C base date.
One could see this longword time value used in any C program that manipulates time using the standard C library routines, regardless of the particular operating system platform.
There is currently no standard mechanism for dealing with this overflow (short of promoting all longword integers to quadwords), as the format of the time_t value is implementation-specific. Some implementations and applications will treat time_t as an unsigned longword value, while others treat it as a signed longword value - the format of time_t is specifically left up to the C compiler implementation by the C standards.
Applications written in C will likely have to revisit something similar to the current Year 2000 evaluation process sometime prior to 2038.
The OpenVMS Y2K evaluation does not extend into 19-Jan-2038, or later.
For information on OpenVMS and 2038, please see the OpenVMS Y2K website.
[Steve Hoffman]
The year 2000 is a leap year. (That is, the year 2000 is a leap year in the Gregorian calendar, the calendar that is currently used in most parts of the world.)
The leap year algorithm that was created by Aloysius Giglio, Father Christopher Clavius, and the Coucil of Trent for the Gregorian Calendar dates back to the 16th Century. The algorithm is simple, but effective: the years that are evenly divisible by 4 are leap years, while the years that are divisible by 100 are not, while the years that are divisible by 400 are. Thus, 1800, 1900, and 2100 are not leap years, while 2000 is.
And whenever working with dates, please determine what the local calendar, timezone, and daylight savings time rules are: the Gregorian calendar was adopted in 1698 in some areas of the world, in 1752 in others, and in 1918 in yet others. The specific rules vary both by geography and by date.
For further details on this, please see the DECwindows Calendar Help, or the answer to SPR number 11-60903, dated 13-Oct-1983.
All supported components of OpenVMS are covered by the OpenVMS Y2K evaluation, including the language run-time libraries and the OpenVMS system-integrated products such as shadowing and RMS journaling.
For information on other Compaq products, or for additional details on the OpenVMS Y2K evaluation, please see http://www.digital.com/year2000/
It is quite possible to create an entirely a Y2K safe environment from tools and products that are not Y2K ready, just as it is also possible to have serious Y2K problems in an environment based entirely on Y2K ready products. In other words - short of knowing that the product has catestrophic Y2K failures, and short of learning where specific known Y2K problems lurk in the products - you cannot really determine with any certainty that your site is Y2K ready.
The only way to tell for certain that your site is Y2K safe is to test your systems and your applications. For some suggested testing procedures, please see the OpenVMS Y2K website.
The OpenVMS operating system is in good shape in regard to Y2K, but there are a few small areas of OpenVMS that do require an update for Y2K readiness - if you are certain that no local software is using any these areas OpenVMS, then you will likely not require the update. If you are not certain, then you have will likely need to test for Y2K problems at your site, and you will also likely want to acquire and install the update. For details on the update process and on what was found in OpenVMS, please see the information in the Y2K kits.
And you will obviously need to consider software products other than OpenVMS when making your Y2K readiness determination, as well.
Versions of INIT.EXE and MTAACP.EXE from VAX/VMS releases prior to V5.1-1 will potentially have problems properly processing ANSI magnetic tapes when Y2K and later dates are involved - the DCL INITIALIZE command is known to encounter access violation (ACCVIO) errors. The available solutions include upgrades, or setting the date back.
[Hoffman, Dachtera]
| Next | Back |