RTR V3.1D RTRI210 RTR for Windows NT and Windows 95 3.1D ECO Summary
TITLE: RTR V3.1D RTRI210 RTR for Windows NT and Windows 95 3.1D ECO Summary
Copyright (c) Compaq Computer Corporation 1998. All rights reserved.
Modification Date: 18-DEC-98
Modification Type: Updated Kit: Supersedes RTRI196
PRODUCT: Reliable Transaction Router V3.1D
OP/SYS: Windows NT and Windows 95
SOURCE: Compaq Computer Corporation
ECO INFORMATION:
ECO Kit Name: RTRI210
ECO Kits Superseded by This ECO Kit: None
ECO Kit Approximate Size: 3847 Blocks
1969664 Bytes
Kit Applies To: RTR V3.1D
Windows NT V4.0
Windows 95 V4.0
Installation Rating: INSTALL_UNKNOWN
ECO KIT SUMMARY:
An ECO kit exists for Reliable Transaction Router (RTR) V3.1D
on Windows NT and Windows 95. This kit contains the following
corrections to RTR V3.1D (196) ECO7 (note that some corrections
apply only to platforms other than Window NT or Windows 95 and
are shown here for completeness).
PROBLEMS ADDRESSED IN RTRI210:
o 14-3-222 rtr_start_tx() failures
Calls to rtr_start_tx() in the Windows platforms would fail
with the error condition INVFLAGS. Attempts to use the RTR
V1.1 client API rtr_error_text() would also fail. This problem
is evident in RTR V3.1D ECO6 and subsequent kits, but has now
been corrected.
o 14-8-144 RTR crash when ASYNC cable disconnected
Disconnecting a cable that was being used by an asynchronous
DECnet link to a remote machine could result in an ACP failure
when the transport marked the sockets as invalid. RTR has been
changed to handle this error by temporarily suspending all network
activity on the affected node. Network activity will resume as soon
as the network is found to be usable again.
o 14-8-154 Router crash when link to Frontend disconnected
Router ACPs configured to accept anonymous clients could under
circumstances fail when handling a network link loss event. This
has been corrected.
o 14-8-155 New environment variables for setting connection timeout
parameters
Two new environment variables have been created to give operators
greater discretion in determining how long to wait before retrying
a network connection attempt.
The RTR_TIMEOUT_CONNECT variable controls how long a connecting
node will wait for a response from the connectee to its link
initiation request. This value defaults to 60 seconds.
If the RTR_TIMEOUT_CONNECT period expires without a response from
the connectee, RTR will wait an additional period determined by
the RTR_TIMEOUT_CONNECT_RELAX variable. This variable defaults
to a value of 90 seconds. The purpose of the "relax" period is
to allow the connector to accept a connection request from the
connectee node, if any are forthcoming. It is important not to
set this value too low on Backends and Routers, as such machines
are likely to be receiving connection requests from many other
machines. On machines configured to use only the Frontend role,
however, you can safely set RTR_TIMEOUT_CONNECT_RELAX to just a
few seconds so that the node can be free to attempt to connect to
another router as quickly as possible.
The minimum value for RTR_TIMEOUT_CONNECT is 5 and the minimum
for RTR_TIMEOUT_CONNECT_RELAX is 1.
The following restrictions apply to this kit:
o 14-1-285: A temporary inconsistency in shadow server state can occur
during initial facility startup of a shadowed configuration. A
shadow server can erroneously remain in state "sec_act" until the
rest of the facility has been started.
o 14-3-67: An application's wakeup routine may be called more often
than necessary.
o 14-7-785: RTR applications are not thread safe.
The current implementation of RTR for OpenVMS is not thread-safe and
applications may not call RTR V3 or V2 API routines from more than
one thread. A threaded RTR shared image for OpenVMS Version 7 has
been developed and may be made available on request.
If you are using or considering using a threaded application, please
refer to the documentation for DECthreads, and note the extra
conditions concerning AST reentrancy in an OpenVMS threaded application.
PROBLEMS ADDRESSED IN RTRI196:
o 14-1-416: V2 CLI completion status.
In prior versions of RTR V3 it was possible for an RTR V2 call made
from the RTR command line to erroneously report the completion
status for some other prior call issued with the /NOWAIT qualifier.
o 14-1-418: V2 API $DEQ_TX() call hanging.
In previous versions of RTR V3 it was possible for a server
$DEQ_TX() call to hang permanently if it was (erroneously) issued
prior to completion of the previous $VOTE_TX() call.
o 14-5-45: MONITOR JOURNAL corrected
Counts for transactional entries and records were erroneously being
calculated as if the counters included the non-transactional records
and entries. The latter are counted separately, so negative
numbers could result.
The calculation has been corrected to reflect the fact that
transactional and non-transactional entries are counted separately.
The following labels also have been changed:
JNL_LCL_ENTRIES to JNL_LCL_TX_ENTRIES
JNL_LCL_RECORDS to JNL_LCL_TX_RECORDS
JNL_RMT_ENTRIES to JNL_RMT_TX_ENTRIES
JNL_RMT_RECORDS to JNL_RMT_TX_RECORDS
o 14-1-444: RTR and OpenVMS Version 6.1.
Some released and Field Test kits would not run on OpenVMS Version
6.1 (VAX & Alpha).
o 14-5-77: Using multiple network adapters.
Use of systems with multiple network adapters where the DNS was not
configured to return all addresses for such machines could result in
RTR rejecting network connections from other RTR systems. Whilst
this is primarily a network management issue, RTR has been changed
to render this misconfiguration less likely to disrupt RTR
connectivity.
o 14-1-409: TRIM FACILITY and ACP failure.
Previous versions of RTR V31D would occasionally suffer a crash of
the RTR ACP process if a node was trimmed from a facility just after
an attempt by the trimmed node to establish a network connection had
failed.
o 14-1-438: Frontend router search and TRIM FACILITY
The expiration of a frontend's router search timer following a
facility trim could lead to an ACP process failure.
o 14-3-151: RTR application compiler errors
For previous versions of RTR, compiling RTR applications with the
VAX C compiler generated compiler errors, since the VAX C compiler
does not recognize the signed keyword used in RTR.H. The workaround
is to define away signed.
This has now been fixed. The signed keyword is no longer defined in
RTR.H if compiling with the VAX C compiler.
o 14-1-326: Signed and unsigned quadwords are now fully supported.
Previously, quadword keys could not be displayed OpenVMS VAX or
OpenVMS Alpha.
o 14-1-414: JOUNOTAVA log messages
In prior versions of RTR Version 3 it was possible for large numbers
of "JOUNOTAVA" messages to be written to the RTR log file in quick
succession when a server performed a recovery operation during a
period of network instability. These are now suppressed.
o 14-1-307: The REMOTE JOURNAL(S) column of the MONITOR JOURNAL
display has been renamed to STANDBY JOURNAL(S) to avoid confusion.
o 14-1-436: Transactions erroneously not being "forgotten".
A fix introduced in V3.1D ECO6 to an earlier bug (14-8-100) meant
that transactions in "done" state that were recovered from the
journal were not being correctly forgotten. These done transactions
would not be cleared from the journal. This bug has now been fixed.
o 14-3-195: The emulation of the RTR V2 API on V3 has been improved to
correctly reflect V2 behaviour for channels which were idle at the
time of ACP failure. Subsequent calls on such channels now fail
immediately with the status RTR$_NOACP.
o 14-3-102: MODIFY JOURNAL command
The Release Notes incorrectly state that the RTR command MODIFY
JOURNAL cannot be issued when the RTR ACP is running and one or more
facilities have been defined. Note however, that MODIFY JOURNAL
defaults to modifying the journal on SYS$DISK, not the active
journal.
The following restrictions apply to this kit:
o 14-1-285: A temporary inconsistency in shadow server state can occur
during initial facility startup of a shadowed configuration. A
shadow server can erroneously remain in state "sec_act" until the
rest of the facility has been started.
o 14-3-67: An application's wakeup routine may be called more often
than necessary.
o 14-7-785: RTR applications are not thread safe.
The current implementation of RTR for OpenVMS is not thread-safe and
applications may not call RTR V3 or V2 API routines from more than
one thread. A threaded RTR shared image for OpenVMS Version 7 has
been developed and may be made available on request.
If you are using or considering using a threaded application, please
refer to the documentation for DECthreads, and note the extra
conditions concerning AST reentrancy in an OpenVMS threaded
application.
INSTALLATION NOTES:
The Reliable Transaction Router Version 3.1D ECO7 installation procedure
is the same as the installation procedure for RTR Version 3.1D. Refer to
the Installation Guide for further information.
All trademarks are the property of their respective owners.
This patch can be found at any of these sites:
Colorado Site
Georgia Site
European Site
Files on this server are as follows:
rtri210.README
rtri210.CHKSUM
rtri210.CVRLET_TXT
rtri210.exe
