|
The following STARS article provides the most complete technical
description I've seen. The key is the use of DECthreads, C or
certain system service calls.
I'd expect ALL-IN-1 v3.0, v3.1 and v3.2 to all be effected.
Dave Zaniewski
[OpenVMS] VAXLIBR & ALPLIR Delta Time Limit Questions and Answers
Any party granted access to the following copyrighted information
(protected under Federal Copyright Laws), pursuant to a duly executed
Digital Service Agreement may, under the terms of such agreement copy
all or selected portions of this information for internal use and
distribution only. No other copying or distribution for any other
purpose is authorized.
Copyright (c) Digital Equipment Corporation 1997. All rights reserved.
PRODUCTS: DIGITAL OpenVMS VAX, Versions 5.5 through 7.0
DIGITAL OpenVMS Alpha, Versions 6.1 through 7.0
SOURCE: Digital Equipment Corporation
INFORMATION:
OpenVMS Delta-Time Limit Q&A
(OpenVMS RTL Library Routines Time Restriction)
March 1997
Q1: I've heard that certain OpenVMS RTL Library (LIB$)
routines (described in the OpenVMS Delta-Time Limit
customer notification letter) have a documented time
restriction that can cause errors in some applications.
Can you tell me more about this?
A: The OpenVMS RTL Library (LIB$) time conversion routines
have a documented restriction that limits delta-time
arguments and return values to fewer than 10,000 days. The
date 19-MAY-1997 is 10,000 days from the UNIX and C base
date of 1-JAN-1970. Any software that uses these routines
to convert UNIX time to OpenVMS time will encounter run-
time errors upon reaching this limit, unless the software
handles the errors returned from these routines. Other base
dates will encounter this 10,000 day limit at other times.
DIGITAL has removed the 10,000 day limit in the OpenVMS
RTL Library routines and SYS$NUMTIM in OpenVMS Version 7.1.
Engineering Change Orders (ECOs) are available that remove
this same limit in earlier versions of OpenVMS.
Regardless of the OpenVMS version and regardless of the
installation of the ECO, application developers need to
investigate and potentially repair, recompile and relink
any local or third-party code that contains any instances
of calls that might exceed the 10,000 day delta-time
limits. Care is needed to relink those applications that
are explicitly linked against OpenVMS object libraries and
not against shareable images, because these applications
will require this relink to incorporate the changes made by
the ECO kit. See the Guide to the OpenVMS Delta-Time Limit,
available on the OpenVMS Homepage at
http://www.openvms.digital.com
Q2: Which OpenVMS RTL Library (LIB$) routines that have the
10,000 day restriction are having the restriction lifted?
A: The following OpenVMS RTL LIB$ routines have the
documented 10,000 day restriction. The ECOs remove this
restriction.
LIB$CVT_TO_INTERNAL_TIME LIB$ADD_TIMES
LIB$CVT_FROM_INTERNAL_TIME LIB$SUB_TIMES
LIB$CVTF_TO_INTERNAL_TIME LIB$MULT_DELTA_TIME
LIB$CVTF_FROM_INTERNAL_TIME LIB$MULTF_DELTA_TIME
LIB$CVT_VECTIM LIB$CONVERT_DATE_STRING
If your application calls the OpenVMS RTL Library (LIB$)
routines listed above or the SYS$NUMTIM system service,
you may encounter the 10,000 day restriction. Programs that
call the preceding routines and adhere to the documented
10,000 day restriction will not encounter any problems.
Applications that are written in DEC C and contain portable
code that calls only ANSI time functions are not impacted.
This is because the DEC C Run Time Library calculates time
locally and does not call OpenVMS RTL Library (LIB$) time
routines. These ANSI time functions are as follows:
ctime ftime
mktime strftime
fstat gmtime
stat time
The one exception to this list is the ANSI time function
sleep. The DEC C Run Time Library continues to enforce the
9999 day delta-time limit on sleep.
Q3: What applications are impacted by the OpenVMS RTL LIB$
time restriction?
A: The following OpenVMS components and software products
are known to be affected by the RTL Library time
restriction. The ECOs correct the problems observed in
these products. (Also listed are components about which
customers are most concerned.) N/A means that the component
or application was not part of the OpenVMS operating system
for that version.
Note that additional products will be added to these tables
as their impact by the delta-time limit becomes known.
Table 1 OpenVMS Components Likely to Be Impacted by the
________Delta-Time_Limit___________________________________
Component_____________________OpenVMS_Version______________
Pre- 5.0- 5.5- 6.0- 7.0 7.0
5.0 5.4-3 5.5-2 6.2 (Alpha) (VAX)
OpenVMS N/A N/A Yes Yes Yes Yes
DECthreads
(pthread interface)
OpenVMS N/A N/A No No Yes Yes
DECthreads
(CMA interface)
OpenVMS N/A N/A No No Yes No
SECURITY
Server_____________________________________________________
Table 2 OpenVMS Applications and Layered Products Likely to
________Be_Impacted_by_the_Delta-Time_Limit________________
Application___________________OpenVMS_Version______________
Pre- 5.0- 5.5- 6.0- 7.0 7.0
5.0 5.4-3 5.5-2 6.2 (Alpha) (VAX)
DECnet Phase IV No No No No No No
DECnet-Plus N/A N/A N/A Yes[1] Yes Yes
DECwindows N/A No No No Yes Yes
Motif for
OpenVMS
Distributed N/A N/A Yes Yes Yes Yes
Computing
Environment
(DCE) for OpenVMS
Any ADA No No No No Yes No
application________________________________________________
[1]DECnet-Plus is not supported on OpenVMS V6.0.
Other non-DIGITAL software products running on OpenVMS
might also experience errors stemming from the documented
time restriction in the OpenVMS RTL LIB$ routines. Contact
the appropriate software vendor for more information.
Q4: Which versions of the operating system are affected and
who needs to install the ECO?
A: DIGITAL strongly recommends that all customers running
the following versions of the OpenVMS operating system
install the appropriate ECO:
o OpenVMS Alpha Version 6.1 through Version 7.0
(inclusive):
OpenVMS Alpha V6.1, V6.1-1H1, V6.1-1H2, V6.2, V6.2-1H1,
V6.2-1H2 V6.2-1H3, V7.0
o OpenVMS VAX Version 5.5 through Version 7.0 (inclusive):
OpenVMS VAX V5.5, V5.5-1, V5.5-2, V5.5-2HW, V5.5-2H4,
V5.5-2HF, OpenVMS VAX V6.0, OpenVMS VAX V6.1, OpenVMS
VAX V6.2, OpenVMS VAX V7.0
Systems running OpenVMS Alpha Version 7.1 and OpenVMS VAX
Version 7.1 are not affected and do not need to install the
ECO.
Q5: We have several hundred systems spread across the
globe. How can I expedite checking of my applications to
see if they are impacted by this problem?
A: DIGITAL has provided instructions on how to check your
applications in the Guide to the OpenVMS Delta-Time Limit,
available on the OpenVMS Homepage at
http://www.openvms.digital.com
Q6: Are these ECOs available for versions prior to OpenVMS
VAX V5.5, or prior to OpenVMS Alpha V6.1?
A: DIGITAL is presently working on backporting the present
solution to earlier versions of OpenVMS (V5.0 thru V5.4).
The VAXLIBR06_070 and ALPLIBR05_070 ECOs apply to OpenVMS
VAX Versions 5.5 through 7.0, and to OpenVMS Alpha Versions
6.1 through 7.0, inclusive. (The ECO is not required for
Version 7.1 and later.) Until the new ECO is available, the
solution for older releases is to upgrade to Version 5.5
and apply the ECO.
Q7: Are there any recommendations, suggestions, etc., you
can make for those of us who are currently running older
versions of OpenVMS?
A: DIGITAL prefers that all customers upgrade to the latest
version of the OpenVMS (V7.1) but understands that this
is not possible for all customers. For these customers,
DIGITAL is presently working on back-porting the present
solution to earlier versions of OpenVMS (V5.0 thru V5.4).
For customers running earlier versions, DIGITAL believes
that it is unlikely that any OpenVMS-specific problems will
be encountered as a result of the delta-time restriction,
because the OpenVMS component most affected by this ECO,
DECthreads, is available only on OpenVMS VAX Version 5.5
and later and on OpenVMS Alpha Version 6.1 and later.
However, it is still possible that customer applications
could have problems prior to Version 5.5 if they did not
follow the documented restriction on the RTL LIB$ time
conversion routines.
Q8: What are the symptoms on systems running OpenVMS Alpha
V7.0 without this ECO?
A: On OpenVMS Alpha Version 7.0 systems, the following
error may be displayed on the console which will cause the
SECURITY Server to hang.
%CMA-F-EXCCOPLOS, exception raised: some information lost
-CMA-F-BADPARAM, parameter to DECthreads operation is invalid
%ADA-I-TASTERUNH, Task with ID %TASK 9 of type
Verify_Dependant_Tasks_type has terminated due to unhandled
exception
The above messages stem from the SECURITY Server. Service
is not denied, but security event messages are not
recorded. Problems with the OpenVMS Alpha Version 7.0
SECURITY Server typically commence only when the run-stop
state is changed by the system manager.
DECWindows Motif running on OpenVMS Alpha V7.0 systems
will cease to function on or around 19-MAY-1997. This will
prohibit users from logging into their workstations or from
starting any new applications.
Q9: Why is the OpenVMS SECURITY Server affected?
A: The SECURITY Server is affected only on OpenVMS
Alpha V7.0. (The VAX SECURITY Server is not affected
because VAX Ada does not implement threading support via
DECthreads.) An error can occur when the OpenVMS Alpha
SECURITY Server attempts to log a message on the console.
The date/time is handled as part of an exception that is
initially managed by the DEC ADA Run-Time Library and is
subsequently passed to DECthreads. DECthreads converts UNIX
time to OpenVMS time by calling LIB$CVT_TO_INTERNAL_TIME,
specifying the 10,000 day delta-time. LIB$CVT_TO_INTERNAL_
TIME returns an error to DECthreads on dates beginning on
or around 19-MAY-1997, resulting in the console errors.
Q10: What symptoms will be seen on systems running OpenVMS
Version 6.2 without the ECO?
A: The OpenVMS DCE RPC Daemon (DCE$RPCD) fails to start on
systems with the 10,000 day time restriction. In the files
DCE$RPCD.ERR and DCE$RPCD.OUT, the DCE$RPCD process logs
the following error:
%CMA-F-BADPARAM, parameter to DECthreads operation is invalid
This error is identical to the console scenario seen
by OpenVMS Alpha V7.0 systems. There may be additional
products or scenarios that yield this same result for the
10,000 day time restriction.
Q11: The information included in the Customer Letter
supplied by DIGITAL suggests that the delta-time limit
does not affect DCE except on OpenVMS Alpha V6.2. Is this
correct?
A: No. DCE (Distributed Computing Enviroment) is impacted
by the delta-time restriction on OpenVMS VAX and OpenVMS
Alpha Version 5.5 through 7.0.
Q12: What is the impact on threaded applications?
A: The 10,000 day issue only arises in cases where a
UNIX time is converted to an OpenVMS time. The original
implementation of the DECthreads interface did not involve
any UNIX time specifications on OpenVMS. These were
introduced with the implementation of the draft POSIX
interface, which was layered on top of the original,
proprietary (CMA) interface. Therefore, prior to Version
7.0, only software that uses the draft POSIX interface (and
which makes use of timed waits) is affected.
In OpenVMS Version 7.0 DECthreads provided an
implementation of the newly accepted POSIX standard
interface for threading services. The POSIX standard
interface became the core interface and the other
interfaces were reimplemented on top of it. Beginning in
OpenVMS Version 7.0, all software that uses timed thread
waits may encounter the 10,000 day time errors.
DECthreads source code is identical for OpenVMS VAX Version
7.0 and OpenVMS Alpha Version 7.0.
Q13: Do the ECOs affect the general delta-time system
behavior?
A: No, the basic user interface behavior and restrictions
still apply except in SYS$NUMTIM and the OpenVMS RTL LIB$
routines listed in Question 2. Delta-time specification
strings still retain their 4-digit (dddd) field format for
compatibility.
Q14: If my application uses delta-time, what changes do I
need to make in my code as a result of these ECOs?
A: None. The ECO extends a current restriction in very
specific areas that previously would have generated an
error.
Q15: Where is the existing delta-time limit documented?
A: The 9999 day limit is documented in the OpenVMS User's
Guide, Section 3.8.5. This information is viewable on the
OpenVMS homepage at
http://www.openvms.digital.com:81/ssb71/6489/6489p004.htm
Q16: Why do I still see a maximum of 10,000 days when I use
F$CVTIME in my command files? I thought this restriction
had been removed.
A: Routines that use ASCII delta-time strings will see
no change in their behavior or documented maximums.
Specifically, SYS$ASCTIM, SYS$BINTIM, and F$CVTIME retain
their current maximum sizes. These routines have and always
will have the 10,000 day restriction. Only the parameter
inputs to SYS$NUMTIM and the affected RTL LIB$ routines
will allow values greater than 9999 days.
Q17: How does a customer obtain the ECO?
A: Digital has provided the following ECOs (Engineering
Change Orders) that remove the time limit and resolve all
known instances of the error in OpenVMS:
For OpenVMS Alpha: ALPLIBR05_070
OpenVMS VAX: VAXLIBR06_070
The ECOs can be obtained from the following locations:
o DIGITAL Electronic Service Delivery Tools (such as
DSNlink, Web Information and Support Service (WIS),
and DIGITAL Dial- In Access (DIA))
o the World Wide Web at:
http://www.service.digital.com/html/patch_main.html
To download the Alpha ECO, access the following URL:
http://www.service.digital.com:8031/?categories=
All_Databases&query_string=ALPLIBR05_070
To download the VAX ECO, access the following URL:
http://www.service.digital.com:8031/?categories=
All_Databases&query_string=VAXLIBR06_070
o the following FTP address:
ftp://ftp.service.digital.com/public/vms/
Q18: What should a customer do if they cannot access the
ECO from the electronic mechanisms?
A: The customer should contact their normal support
channels.
Q19: If I am not sure if I will be affected by this delta-
time limit problem, should I still install the ECO?
A: Yes, Digital strongly recommends that all customers
running OpenVMS Alpha Version 6.1 through Version 7.0 and
OpenVMS VAX Version 5.5 through Version 7.0 install the
ECO.
Q20: If I do not install the ECO and my application trips
over this problem, what will happen if the error occurs in
privileged code? Program failure? System crash?
A: DIGITAL is not aware of any instances where the problem
addressed by the ECO could affect privileged code. That
is, none of the DIGITAL products or components affected by
the problem can be used by code that runs in a privileged
mode. It may be the case that third-party code that runs
in a privileged mode is subject to this problem. If so, the
exact effect of the problem depends on how that code reacts
to the error status returned from the RTL LIB$ routine.
Q21: I heard that there was a problem with the VAX V5.5-2
portion of the delta-time ECO, VAXLIBR05_070. Is this true?
A: Yes. After installing the VAX V5.5-2 version of the
remedial kit VAXLIBR05_070, a KRNLSTAKNV (Kernel Stack
Invalid) error can occur under either of the following
conditions:
o during startup (or shortly thereafter) of the POLYCENTER
(DECps) Data Collector
o after issuing RUN SYS$SYSTEM:AGEN$FEEDBACK (on systems
with one or more secondary page files)
Sites that have installed VAXLIBR05_070 under OpenVMS V5.5
through V5.5-2 inclusive should install VAXLIBR06_070.
Q22: What is Digital doing to resolve the V5.5-2 problems
with the VAXLIBR05_070 ECO?
A: Digital has created a new ECO, VAXLIBR06_070, to resolve
the reported problems with the earlier kit. VAXLIBR06_070
is available from:
http://www.service.digital.com:8031/?categories=
All_Databases&query_string=VAXLIBR06_070
Q23: If I have already installed VAXLIBR05_070 on VAX V5.5-
2, do I need to reapply the ECO?
A: If you have installed the initial V5.5-2 delta-time fix
from the old ECO kit (VAXLIBR05_070), you need to reapply
the new V5.5-2 fix from the VAXLIBR06_070 ECO as soon as
possible.
All other OpenVMS versions were not impacted by this
interdependency problem and do not need the ECO reapplied.
Q24: Does the customer have to do anything after the ECO
has been applied?
A: After the ECO has been applied, the system must be
rebooted. If you have other nodes in your OpenVMS Cluster,
they should also be rebooted.
Application programs that link against the OpenVMS
shareable images and the OpenVMS shareable image library
will pick up the ECO when the program is next run, and
should not need to be recompiled nor relinked.
Applications that explicitly resolve references to system
routines using object modules from STARLET.OLB instead
of shareable images from IMAGELIB.OLB must be explicitly
relinked in order to pick up the ECO. 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.
Q25: Do I need to reapply this ECO once I have applied it?
A: Yes, this ECO will need to be reapplied immediately
after each OpenVMS upgrade or update to any OpenVMS release
prior to OpenVMS V7.1.
This ECO should not be installed on OpenVMS V7.1 and later.
This ECO does not need to be applied to any intermediate
OpenVMS releases that might be involved during a sequential
series of OpenVMS upgrades. It should only be applied to
the final (pre-V7.1) OpenVMS release in the series.
Q26: How will customers be notified?
A: The OpenVMS Delta-Time Limit Notification Cover Letter
(which describes the documented time limits in the RTL
Library routines and the required correction) has been
included in the March 1997 OpenVMS SPL (Software Product
Library) update kit. The letter was mailed to all OpenVMS
MDDS (Media and Documentation Update Service) customers in
March 1997.
The Delta-Time Limit Notification Cover Letter is
also available on the WWW OpenVMS Homepage (http:/
/www.openvms.digital.com) along with this Q&A.
Q27: How can the system manager tell if the ECO has been
applied?
A: A DCL command procedure, SHOW10K.DCL, is available on
the OpenVMS Homepage that you can run on each system to
determine if the ECO is applied.
Q28: I downloaded the old SHOW10K.COM procedure previously
provided on the OpenVMS homepage and cannot get it to run
succesfully. What is the problem with this procedure and
what does DIGITAL plan on doing to fix it?
A: The PC web browsers interpret a .COM file suffix as a
binary file (.COM is an MS-DOS executable program). Binary
attributes were used on the file transfer which effectively
corrupted the SHOW10K.COM procedure during the download.
Digital has released the .COM procedure in text format
(SHOW10K.DCL) so browsers can handle the download
successfully.
Q29: Do the patch kits require the OpenVMS VAX system to be
configured with the PROG component?
A: Yes. The patches update STARLET.OLB, which is a
component of the PROG component. Use the VMSTAILOR
tailoring support to tailor the PROG component of OpenVMS
back on, then apply the patch. The PROG component set can
then be tailored back off.
Q30: I ran across the following problem with the
LIBRTL$ECO_DROP.COM contained in the ALPLIBR05_070 ECO.
What is the problem and how can it be resolved?
$ !
$ LIBRARY/REPLACE/OBJECT SYS$COMMON:[SYSLIB]STARLET.OLB
[SYSLIB]LIBRTL_OLD.OBJ
! Replace the objects (except message object)
%LIBRAR-W-OPENIN, error opening
DSVE_PAA_ROOT:[SYSLIB]LIBRTL_OLD.OBJ; as input
-RMS-E-DNF, directory not found
-SYSTEM-W-NOSUCHFILE, no such file
$ !
$ ! Cleanup
$ !
$ DELETE TSYS$COMMON:[SYSLIB]LIBRTL_OLD.OBJ;0
%DELETE-W-SEARCHFAIL, error searching for
TSYS$COMMON:[SYSLIB]LIBRTL_OLD.OBJ;0
-RMS-F-DEV, error in device name or inappropriate device type
for operation
A: Run the following command procedure to correct
LIBRTL$ECO_DROP.COM in ALPLIBR05_070:
$ File := SYS$UPDATE:LIBRTL$ECO_DROP.COM
$ Edit := Edit
$ Edit/Edt 'File'
s/ [SYSLIB]/ SYS$COMMON:[SYSLIB]/ ALL ' [SYSLIB]'
s/TSYS$COMMON/SYS$COMMON/ ALL 'TSYS$COMMON'
Exit
$ Exit
RELATED ARTICLES:
There are many articles in the OPENVMS Database that discuss these ECO
kits and related issues. Please review all the articles listed below
for a full understanding of this issue and its impact to your
system(s). To locate these articles please use the following search string:
delta-time 9999 days
|