Today is the day that the year 2000 problem comes early for Digital OpenVMS adminstrators if they haven’t installed a patch that takes care of a date problem.
And though Digital has supposedly circulated a letter to current contract holders, it’s by no means certain that all New Zealand users of the affected versions of OpenVMS have been advised.
The problem relates to date-conversion glitches and stems from date and time restrictions imposed on Unix. Any applications running on a version of either Alpha OpenVMS or Vax OpenVMS earlier than 7.1 that has been ported from Unix will be in the firing line. In the letter, Digital describes the problem as resulting from a “delta time restriction” imposed on Unix at the time of its inception.
In order to manipulate and convert dates and times written into applications, OpenVMS relies on its runtime library. As with any application ported to OpenVMS, its date/time format must be reconciled with that in OpenVMS.
The problem occurs when OpenVMS attempts to do this with applications written in Unix.
In order to convert dates and times, the OpenVMS runtime library first has to communicate with various OpenVMS system services and library routines in order to find the number of days between the current date and the Unix base time. This base time was set at January 1, 1970.
Sounds simple enough, but the OpenVMS developers restricted the number of days on the values returned by these libraries to 9999 days. Unfortunately for all users of OpenVMS bar version 7.1, May 19, 1997, marks the anniversary of the 10,000th day of this date.
Date-sensitive applications such as Internet gateways, mail handling, and general business systems like payroll, will be the worst affected.
Compounding the problem even further, ironically, is one of OpenVMS’s key strengths.
OpenVMS lets users build programs using modules written in different languages. Therefore, many administrators who may not have participated in the original design of their organisation’s systems will have no knowledge which, and indeed if any of their current applications were originally ported from Unix.
Also ironically, OpenVMS was designed with enough fields to accommodate the turn of the century.
Digital discovered the problem two months ago. The company says it will provide ECOs (engineering change orders) on CD-ROM to customers with current support contracts.
The patch is also available at http://www.service.digital.com/html/patch_main.html
OpenVMS specialist John Rumsey, of Quorum Computing, says the patch is trivial to install. However, he wasn’t advised by Digital of the problem, but by Countercorp.
Independent Unix consultant Tom Livingstone, whose clients use several varieties of Unix, says he heard of the problem from Rumsey. One of his clients, Port of Wellington, is a
Digital user “but we haven’t seen any mail”.
The managing director of a long-term Digital business partner who doesn’t want to be identified was completely unaware of the looming problem.
However, Digital Asia-Pacific Unix business director Joel Berman says the problem has been widely communicated.
“It’s the same sort of thing we would do if there were a security issue,” he says. “We’ve written to customers, put it on Decus and on Internet user groups.
“The spin we’ve put on is probably more severe than necessary but we wanted them to upgrade to that ECO level [a common level would make support easier and cheaper for Digital].”
Berman says the Web site also contains a test program that can be run against binaries and identify what calls are affected.