| The previous reply is a letter which will be presented to VAXELN
customers currently under a support contract.
We're almost to May 19. We believe that most customers will not
experience any problems. However, for compatibility, the VMS routines
which are emulated by VAXELN will receive the same fix that the real
VMS routines got.
A patch will be available very soon. It's currently in the final stages
of verification. For the odd application that may be affected, we hope
that the patch will get to them on time or, at least, be available to
them immediately after discovering a problem. We plan to make the patch
available on the DIGITAL external web site. More info on that later.
I'm working on a longer explanation of the problem. Please find it in
succeeding replies.
|
| VAXELN Delta Time Limit Notification Cover Letter
May 1997
Dear VAXELN Customer,
The following is important information concerning a documented delta time
restriction in VAXELN.
The VAXELN operating system has a documented delta time limit that may cause an
error in some applications beginning on or around 19-MAY-1997. DIGITAL has
provided an update to VAXELN V4.6 that addresses some aspects of the delta time
limit.
Applications likely to experience errors are those that pass delta time
arguments with values exceeding 9999 days to system-supplied date routines. A
possible date that these errors will occur is 19-MAY-1997, which is 10000 days
after the common UNIX time origin of 1-JAN-1970.
The following routines are affected:
LIB$SUB_TIMES
LIB$MULT_DELTA_TIME
LIB$MULTF_DELTA_TIME
LIB$ADD_TIMES
An update is available for VAXELN V4.6 which removes the restriction for these
routines. Please contact your normal DIGITAL support channel for further
information.
Routines that use ASCII delta time strings will not be updated. The following
routines accept or return ASCII delta time strings in which the "Days" field
must not exceed 9999 days.
ELN$TIME_VALUE
ELN$TIME_STRING
TIME_VALUE (EPascal and Ada only)
TIME_STRING (EPascal and Ada only)
SYS$BINTIM
SYS$ASCTIM
The remainder of this article provides detailed answers to questions you may
have concerning this issue. DIGITAL appreciates your cooperation and patience.
We regret any inconvenience applying this update may cause.
Q: I've heard that certain VAXELN routines have a documented time restriction
that can cause errors in some applications. Can you tell me more about this?
A: Some routines in the VAXELN operating system have a documented limit of ten
thousand (10000) days on delta times. Any software that uses these routines to
process a time interval of 10000 or more days will encounter run-time errors
upon reaching this limit. The date 19-May-1997 is 10,000 days from the UNIX and
C base date of 1-Jan-1970. Applications using the routines with the delta time
restrictions in conjunction with the UNIX or C base date may encounter problems
with the conversion of the 19-May-1997 date and later dates. These dates exceed
10000 days and exceed the documented four-digit limit of the "Day" field in
delta times. Other base dates will encounter this ten-thousand day limit at
other times. DIGITAL has removed the 10000 day limit in some of the affected
routines with an update to VAXELN V4.6.
Q: What is a delta time?
A delta time is a time interval. An absolute time is a date. For example, one
second (0000 00:00:01.00) is a delta time and midnight on May 19, 1997
(19-MAY-1997 00:00:00.00) is an absolute time. On VAXELN, both are represented
internally as a 64 bit count of clock ticks. The LARGE_INTEGER data structure
is provided for use with the various routines which accept or return an
internal time value. Absolute times are not affected by this restriction.
Q: Why does the 10000 day limit exist in the first place?
A: It was a design decision made long ago. The format for the ASCII
representation of a delta time was defined to be "dddd hh:mm:ss.cc". Delta
times were never intended to be used for long periods of time. On VAXELN, the
most common use of a delta time is to pass to ker$wait_any() to specify a short
interval on which to delay.
Q: What are the VAXELN routines that have the 10000 day restriction?
A: The following routines have been updated to allow the internal
representation of a delta time to exceed 10000 days:
LIB$SUB_TIMES
LIB$MULT_DELTA_TIME
LIB$MULTF_DELTA_TIME
LIB$ADD_TIMES
The following routines will continue to have the restriction:
ELN$TIME_VALUE
ELN$TIME_STRING
TIME_VALUE (EPascal and Ada only)
TIME_STRING (EPascal and Ada only)
SYS$BINTIM
SYS$ASCTIM
Q: Why are some routines updated but not all of them?
A: The routines being updated deal strictly with the 64 bit internal
representation of time. An update is possible to these routines without
changing any data structures visible to user applications and without causing
any undesirable side effects. The routines which are not being updated convert
internal time to an ASCII string and vice versa. DIGITAL believes that
increasing the size of the string which holds the ASCII representation (to add
an extra "Day" digit) could break more applications than it fixes. The size of
the string will remain unchanged for compatibility reasons.
Q: What are the symptoms of the problem on systems running VAXELN V4.6 without
this update?
A: If your application uses any of the routines being updated with a delta time
greater than 9999 days, an appropriate error status is returned to the
application indicating that an error has occurred. An example of an application
which might be affected is one which attempts to convert the VAXELN
representation of the current time into a number of seconds since January 1,
1970. If it tried to subtract the absolute time equivalent to January 1, 1970
from any absolute time after May 19, 1997 (using LIB$SUB_TIMES, for example)
the result will be a delta time greater than 10000 days. An error status will
be returned by LIB$SUB_TIMES.
Q: For those routines which are not updated, what are the symptoms of the
problem and what can I do about it?
A: The restriction on the internal time to ASCII conversion routines is
well-documented on VAXELN. When these routines are supplied with a delta time
greater than 9999 days, an exception is raised indicating the error. If your
application uses these routines in such an unsupported manner, it will have to
be modified. This is a permanent restriction.
Q: What if my application calls both the routines being updated and the
routines not being updated?
A: If your application calls any of the routines being updated with a delta
time greater than 9999 days, that call will succeed once the patch has been
applied. If you then pass that delta time to any of the routines not being
updated, it will fail as documented. The 9999 days limit is a permanent
restriction for the mentioned time/string conversion routines.
Q: Which versions of VAXELN are affected and who needs to install the update?
A: Versions of VAXELN starting with V4.3 are affected. The LIB$ routines being
updated were new in V4.3. DIGITAL recommends that all customers running VAXELN
V4.6 apply the update.
Q: What about versions V4.3, V4.4 and V4.5?
A: Only VAXELN V4.6 is currently supported. If you are running a older version
and have not updated for some reason, contact your local DIGITAL office.
Q: If my application uses any of the routines being updated, what changes do I
need to make in my code as a result of this update.
A: None. This update removes a restriction in very specific areas that
previously would have generated an error.
Q: How will customers be notified?
A: Customers with current support contracts for VAXELN will be notified that a
patch exists for this problem with instructions on how to obtain it.
Q: How do customers without support contracts obtain the update?
A: The patch will be on the DIGITAL web site at the following address:
http://www.digital.com/info/oem/products/vaxeln-delta.htm
Q: How do I install the patch?
A: The patch contains the following files:
README.TXT ! this text
LIBMSC.EXE ! shareable library update
LIBSUBTIMES.OBJ ! object library update
To apply the update, first save the existing versions of RTLSHARE.OLB,
RTLOBJECT.OLB and LIBMSC.EXE in case you ever want to revert to the pre-update
behavior:
$ SET DEF ELN$
$ COPY RTLSHARE.OLB RTLSHARE.OLB_V46
$ COPY RTLOBJECT.OLB RTLOBJECT.OLB_V46
$ COPY LIBMSC.EXE LIBMSC.EXE_V46
Next, apply the patch:
$ SET DEF ELN$
$ LIB/REP RTLSHARE SYS$LOGIN:LIBMSC.EXE
$ COPY SYS$LOGIN:LIBMSC.EXE LIBMSC.EXE
$ LIB/REP RTLOBJECT SYS$LOGIN:LIBSUBTIMES.OBJ
Q: Does I have to do anything after the update has been applied?
A: Yes. After the update has been applied, the application must be linked, the
system image must be rebuilt and the target system must be rebooted.
Q: Do I ever need to reapply this update once I have applied it?
A: If you ever choose to re-install VAXELN V4.6, the update needs to be
re-applied.
Q: How can the System Manager tell if the update has been applied?
A: LIBMSC.EXE has a unique "image file identification." To find it, use the
following command:
$ ANALYZE/IMAGE ELN$:LIBMSC.EXE
The "image file identification" will be under the "Image Identification
Information" section. The updated image identification is "VAXELN V4.6-05."
LIBSUBTIMES.OBJ has a unique module identification. To find it, use the
following command:
$ LIB/LIST/FULL ELN$:RTLOBJECT
Look for the module "LIB$DATE_ARITHMETIC." The identification for the updated
version is "X-2."
Q: Does this update contain any other functional changes or bug fixes to VAXELN
V4.6?
A: No.
|
| This is the final version of the customer notification letter and Q&A
for this problem. The update to VAXELN V4.6 is on the Digital corporate
web site as of today. See the Q&A for the URL. Send questions to
HELIX::REALTIME.
VAXELN Delta Time Limit Notification Cover Letter
May 1997
Dear VAXELN Customer,
The following is important information concerning a documented delta time
restriction in VAXELN.
The VAXELN operating system has a documented delta time limit that may cause an
error in some applications beginning on or around 19-MAY-1997. DIGITAL has
provided an update to VAXELN V4.6 that addresses some aspects of the delta time
limit.
Applications likely to experience errors are those that pass delta time
arguments with values exceeding 9999 days to system-supplied date routines. A
possible date that these errors will occur is 19-MAY-1997, which is 10000 days
after the common UNIX time origin of 1-JAN-1970.
The following routines are affected:
LIB$SUB_TIMES
LIB$MULT_DELTA_TIME
LIB$MULTF_DELTA_TIME
LIB$ADD_TIMES
An update is available for VAXELN V4.6 which removes the restriction for these
routines. Please contact your normal DIGITAL support channel for further
information.
Routines that use ASCII delta time strings will not be updated. The following
routines accept or return ASCII delta time strings in which the "Days" field
must not exceed 9999 days.
ELN$TIME_VALUE
ELN$TIME_STRING
TIME_VALUE (EPascal and Ada only)
TIME_STRING (EPascal and Ada only)
SYS$BINTIM
SYS$ASCTIM
The remainder of this article provides detailed answers to questions you may
have concerning this issue. DIGITAL appreciates your cooperation and patience.
We regret any inconvenience applying this update may cause.
Q: I've heard that certain VAXELN routines have a documented time restriction
that can cause errors in some applications. Can you tell me more about this?
A: Some routines in the VAXELN operating system have a documented limit of ten
thousand (10000) days on delta times. Any software that uses these routines to
process a time interval of 10000 or more days will encounter run-time errors
upon reaching this limit. The date 19-May-1997 is 10,000 days from the UNIX and
C base date of 1-Jan-1970. Applications using the routines with the delta time
restrictions in conjunction with the UNIX or C base date may encounter problems
with the conversion of the 19-May-1997 date and later dates. These dates exceed
10000 days and exceed the documented four-digit limit of the "Day" field in
delta times. Other base dates will encounter this ten-thousand day limit at
other times. DIGITAL has removed the 10000 day limit in some of the affected
routines with an update to VAXELN V4.6.
Q: What is a delta time?
A delta time is a time interval. An absolute time is a date. For example, one
second (0000 00:00:01.00) is a delta time and midnight on May 19, 1997
(19-MAY-1997 00:00:00.00) is an absolute time. On VAXELN, both are represented
internally as a 64 bit count of clock ticks. The LARGE_INTEGER data structure
is provided for use with the various routines which accept or return an
internal time value. Absolute times are not affected by this restriction.
Q: Why does the 10000 day limit exist in the first place?
A: It was a design decision made long ago. The format for the ASCII
representation of a delta time was defined to be "dddd hh:mm:ss.cc". Delta
times were never intended to be used for long periods of time. On VAXELN, the
most common use of a delta time is to pass to ker$wait_any() to specify a short
interval on which to delay.
Q: What are the VAXELN routines that have the 10000 day restriction?
A: The following routines have been updated to allow the internal
representation of a delta time to exceed 10000 days:
LIB$SUB_TIMES
LIB$MULT_DELTA_TIME
LIB$MULTF_DELTA_TIME
LIB$ADD_TIMES
The following routines will continue to have the restriction:
ELN$TIME_VALUE
ELN$TIME_STRING
TIME_VALUE (EPascal and Ada only)
TIME_STRING (EPascal and Ada only)
SYS$BINTIM
SYS$ASCTIM
Q: Why are some routines updated but not all of them?
A: The routines being updated deal strictly with the 64 bit internal
representation of time. An update is possible to these routines without
changing any data structures visible to user applications and without causing
any undesirable side effects. The routines which are not being updated convert
internal time to an ASCII string and vice versa. DIGITAL believes that
increasing the size of the string which holds the ASCII representation (to add
an extra "Day" digit) could break more applications than it fixes. The size of
the string will remain unchanged for compatibility reasons.
Q: What are the symptoms of the problem on systems running VAXELN V4.6 without
this update?
A: If your application uses any of the routines being updated with a delta time
greater than 9999 days, an appropriate error status is returned to the
application indicating that an error has occurred. An example of an application
which might be affected is one which attempts to convert the VAXELN
representation of the current time into a number of seconds since January 1,
1970. If it tried to subtract the absolute time equivalent to January 1, 1970
from any absolute time after May 19, 1997 (using LIB$SUB_TIMES, for example)
the result will be a delta time greater than 10000 days. An error status will
be returned by LIB$SUB_TIMES.
Q: For those routines which are not updated, what are the symptoms of the
problem and what can I do about it?
A: The restriction on the internal time to ASCII conversion routines is
well-documented on VAXELN. When these routines are supplied with a delta time
greater than 9999 days, an exception is raised indicating the error. If your
application uses these routines in such an unsupported manner, it will have to
be modified. This is a permanent restriction.
Q: What if my application calls both the routines being updated and the
routines not being updated?
A: If your application calls any of the routines being updated with a delta
time greater than 9999 days, that call will succeed once the update has been
applied. If you then pass that delta time to any of the routines not being
updated, it will fail as documented. The 9999 days limit is a permanent
restriction for the mentioned time/string conversion routines.
Q: Which versions of VAXELN are affected and who needs to install the update?
A: Versions of VAXELN starting with V4.3 are affected. The LIB$ routines being
updated were new in V4.3. DIGITAL recommends that all customers running VAXELN
V4.6 apply the update.
Q: What about versions V4.3, V4.4 and V4.5?
A: Only VAXELN V4.6 is currently supported. If you are running an older version
and have not updated for some reason, contact your local DIGITAL office.
Q: If my application uses any of the routines being updated, what changes do I
need to make in my code as a result of this update.
A: None. This update removes a restriction in very specific areas that
previously would have generated an error.
Q: How will customers be notified?
A: Customers with current support contracts for VAXELN will be notified that a
update exists for this problem with instructions on how to obtain it.
Q: How do customers without support contracts obtain the update?
A: The update will be on the DIGITAL web site at the following address:
http://www.digital.com/info/oem/software/vaxeln46-dt-update.zip
Q: How do I install the update?
A: The update is shipped in a "zip" file. You must have the VMS version of the
UNZIP utility installed on your system. For more information, see the following
web site:
http://www.openvms.digital.com/openvms/freeware/cd.html
After you have installed UNZIP, you can extract the files to your SYS$LOGIN
directory like this:
$ SET DEF SYS$LOGIN
$ UNZIP VAXELN46_DT_UPDATE.ZIP
The following files will be extracted to your SY$LOGIN:
README.TXT ! this text
LIBMSC.EXE ! shareable library update
LIBSUBTIMES.OBJ ! object library update
To apply the update, first save the existing versions of RTLSHARE.OLB,
RTLOBJECT.OLB and LIBMSC.EXE in case you ever want to revert to the pre-update
behavior:
$ SET DEF ELN$
$ COPY RTLSHARE.OLB RTLSHARE.OLB_V46
$ COPY RTLOBJECT.OLB RTLOBJECT.OLB_V46
$ COPY LIBMSC.EXE LIBMSC.EXE_V46
Next, apply the update:
$ SET DEF ELN$
$ LIB/REP RTLSHARE SYS$LOGIN:LIBMSC.EXE
$ COPY SYS$LOGIN:LIBMSC.EXE LIBMSC.EXE
$ LIB/REP RTLOBJECT SYS$LOGIN:LIBSUBTIMES.OBJ
Q: Do I have to do anything after the update has been applied?
A: Yes. After the update has been applied, the application must be linked, the
system image must be rebuilt and the target system must be rebooted.
Q: Do I ever need to reapply this update once I have applied it?
A: If you ever choose to re-install VAXELN V4.6, the update needs to be
re-applied.
Q: How can the System Manager tell if the update has been applied?
A: LIBMSC.EXE has a unique "image file identification." To find it, use the
following command:
$ ANALYZE/IMAGE/INTER ELN$:LIBMSC.EXE
The "image file identification" will be under the "Image Identification
Information" section. The updated image identification is "VAXELN V4.6-05."
LIBSUBTIMES.OBJ has a unique module identification. To find it, use the
following command:
$ LIB/LIST/FULL ELN$:RTLOBJECT
Look for the module "LIB$DATE_ARITHMETIC." The identification for the updated
version is "X-2."
Q: Does this update contain any other functional changes or bug fixes to VAXELN
V4.6?
A: No.
|