| Hello,
I've installed the delta time patch on a VAX VMS V6.2 system locally.
Both VMS DmQ$V32B and DmQ$V21B tested normally.
The VMS folks also provided a nifty little program called TENSOR
which I attached a description to the end of this note. It searches
images for the possible offending modules. Even if it finds the
modules, it doesn't mean that the image will fail, just that it has
the potential to fail if the requested delta time is over 9999 days.
I ran TENSOR over all the images in DMQ$V32B and DMQ$V21B
and they were clean.
I would recommend the customer obtain the TENSOR utility and try
it on their application. They also should try the backout patch
(sys$unpdate:LIBRTL$ECO_DROP.COM) and they should also look very
carefully at the calling parameters for the pams_get_msgw to
verify the correct timeout value is being used.
Bruce
================================================================================
Note 238.232 VAXLIBR, ALPLIBR; 10K day delta-time; CMA DECthreads
STAR::AVERY 276 lines 7-MAY-1997 17:10
-< fyi - Tensor utility available >-
--------------------------------------------------------------------------------
Tensor Utility
Search Your Application for RTL LIB$ Time
Conversion Modules Linked Against STARLET.OLB
May 1997
Overview
The Tensor utility can help identify customer applications that
may need to be relinked in order to pick up the delta-time limit
ECO. Tensor can be run on OpenVMS VAX V5.0 and later or OpenVMS
Alpha V6.1 and later.
After you have installed the delta-time limit ECO, use the
Tensor utility to search image (.EXE) files for modules that
contain the OpenVMS RTL LIB$ time conversion routines and that
have been linked against STARLET.OLB to resolve references to
system functions. Note that if Tensor finds a match, that image
will not necessarily have a problem. An image containing the
modules may not be invoking the changed routines. A problem
will occur only if an affected RTL LIB$ routine is called with a
delta-time value exceeding 9999 days.
If sources are available, those sources should be searched and
the routines identified and checked. In cases where sources are
not available, relinking the image is the safest course.
See the Guide to the OpenVMS Delta-Time Limit for detailed
information about the impact caused by the method you use to
link your application.
NOTE
If you are running OpenVMS Version 7.1, you do not have to
install the ECO. However, you can use Tensor to determine
how your pre-V7.1 applications running on Version 7.1
were linked. (Applications linked under pre-V7.1 versions
of OpenVMS that pull in modules from STARLET.OLB must
be relinked. Applications with the 10,000 day problem
that were linked under pre-V7.1 versions of OpenVMS and
that pull in modules from STARLET.OLB must be relinked on
either a pre-V7.1 system containing the ECO or on a V7.1
system.)
Description
Normally, invocations of LIBRTL routines such as LIB$CVT_TO_
INTERNAL_TIME are implemented as calls into the LIBRTL.EXE
shareable image. However, it is possible to cause a copy of
an object module containing a set of routines to be inserted
directly into your image at link time. For example, the LINK
/NOSYSSHR option can be used so that a call to a LIB$ routine is
resolved by copying the object code module from the STARLET.OLB
object library into the resulting image. The LIBRTL routines
that have been modified to eliminate the 10,000 day delta-
time limit all reside in two object modules: LIB$DATE_CVT and
LIB$DATE_ARITHMETIC.
The Tensor utility allows you to find instances of the LIB$DATE_
CVT and LIB$DATE_ARITHMETIC modules embedded in an image. Tensor
searches image (.EXE) files for all released VAX and Alpha
versions of these routines.
Note the following:
o Tensor does not locate all uses of the affected RTL LIB$ time
conversion routines. It does not locate routines that have
been linked against the LIBRTL.EXE shareable image.
o Tensor cannot identify calls to individual routines within
the modules, so it is possible that an image containing the
modules may not be invoking the changed routines. That is,
the image may use the modules in a "safe" way. Tensor merely
helps locate images that require further attention. Without
further investigation, the safest action is to relink images
containing these modules.
How to Use the Tensor Utility
To use Tensor, the following files are required:
tensor.cld
tensor_vax.exe (for running on VAX)
tensor_alpha.exe (for running on Alpha)
The files can be found here:
BULOVA::SYS$PUBLIC:
TENSOR.CLD;3 1 25-APR-1997 12:15:34.00
TENSOR_ALPHA.EXE;1 78 2-MAY-1997 12:54:32.00
TENSOR_VAX.EXE;1 520 2-MAY-1997 12:53:15.00
Total of 3 files, 599 blocks.
Once these files have been copied to a directory such as
DISK$:[TENSOR], the following OpenVMS commands are required
to define the TENSOR command line:
$ SET COMMAND DISK$:[TENSOR]TENSOR.CLD
$ DEFINE TENSOR DISK$:[TENSOR]TENSOR_VAX.EXE (or TENSOR_ALPHA.EXE)
These commands are for a one-time use of the Tensor utility.
A simple TENSOR command line has the following form:
$ TENSOR filename [,filename...]
Filename is a standard OpenVMS filename, which may include wild-
card characters, logical names, or remote node names. The de-
fault file extension used by tensor is .EXE. Tensor searches the
files specified by the filename list for instances of LIB$DATE_
CVT and LIB$DATE_ARITHMETIC. For each file searched, Tensor
displays a message of the form:
Searching <filename>
When a match is found, Tensor reports it with a message of the
form:
Found <architecture> <module>
For example:
Found VAX LIB$CVT_ARITHMETIC
Two command qualifiers are allowed. The /NOLOG qualifier pre-
vents Tensor from reporting which files are being searched,
unless a match is actually found. The /OUTPUT=<filename> quali-
fier allows Tensor output to be directed to the specified file
rather than the terminal.
What follows is a sample of Tensor usage and output.
$ TENSOR CURR_RESD$:[UTIL.OBJ],SYS$LIBRARY:LIBRTL;*
Searching RES_DISK$:[UTIL.OBJ]CREATE.EXE;1
Searching RES_DISK$:[UTIL.OBJ]DYNSWITCH.EXE;1
Searching RES_DISK$:[UTIL.OBJ]QUEMAN.EXE;1
Searching RES_DISK$:[UTIL.OBJ]RENAME.EXE;1
Searching RES_DISK$:[UTIL.OBJ]RUNDET.EXE;1
Searching RES_DISK$:[UTIL.OBJ]SET.EXE;1
Searching RES_DISK$:[UTIL.OBJ]SETP0.EXE;1
Searching RES_DISK$:[UTIL.OBJ]SETWATCH.EXE;1
Searching RES_DISK$:[UTIL.OBJ]SHOW.EXE;1
Found VAX LIB$DATE_ARITHMETIC
Searching RES_DISK$:[UTIL.OBJ]SHWCLSTR.EXE;1
Searching RES_DISK$:[UTIL.OBJ]SUBMIT.EXE;1
Searching RES_DISK$:[UTIL.OBJ]TYPE.EXE;1
Found VAX LIB$DATE_CVT
Searching RES_DISK$:[UTIL.OBJ]UNLOCK.EXE;1
Searching RES_DISK$:[UTIL.OBJ]UTIL$SHARE.EXE;1
Searching SYS$COMMON:[SYSLIB]LIBRTL.EXE;2
Searching SYS$COMMON:[SYSLIB]LIBRTL.EXE;1
Found VAX LIB$DATE_CVT
Found VAX LIB$DATE_ARITHMETIC
Note that for the LIBRTL search, a wildcard version number was
specified on the command line, so all versions were searched.
Normally the SYS$LIBRARY:LIBRTL.EXE image will always contain
these modules. However, in this case, version ;2 includes the
latest versions with the "10K Day" fix, so Tensor does not
report a match.
Below is an example of using Tensor with a remote node on the
network.
$ TENSOR NODE7"system randompswd"::WORK$:[PUBLIC.*]
Searching NODE7"system password"::WORK213:[PUBLIC.BUILD]CREATE.EXE;3
Searching NODE7"system password"::WORK213:[PUBLIC.BUILD]MOVE.EXE;1
.
.
Searching NODE7"system password"::WORK213:[PUBLIC.TOOLS]LEXORA.EXE;6
Searching NODE7"system password"::WORK213:[PUBLIC.TOOLS]SAMP.EXE;7
Found Alpha LIB$DATE_CVT
Found Alpha LIB$DATE_ARITHMETIC
Searching NODE7"system password"::WORK213:[PUBLIC.TOOLS]TRIAL.EXE;1
.
.
================================================================================
|