RTR V2.2D RTRVVME0422D Reliable Transaction Router VAX ECO Summary
NOTE: An OpenVMS saveset or PCSI installation file is stored
on the Internet in a self-expanding compressed file.
The name of the compressed file will be kit_name-dcx_vaxexe
for OpenVMS VAX or kit_name-dcx_axpexe for OpenVMS Alpha.
Once the file is copied to your system, it can be expanded
by typing RUN compressed_file. The resultant file will
be the OpenVMS saveset or PCSI installation file which
can be used to install the ECO.
Copyright (c) Digital Equipment Corporation 1996, 1997. All rights reserved.
PRODUCT: Reliable Transaction Router for OpenVMS VAX (RTR)
OP/SYS: OpenVMS VAX
SOURCE: Digital Equipment Corporation
ECO INFORMATION:
ECO Kit Name: RTRVVME0422D
ECO Kits Superseded by This ECO Kit: RTRVVME0322D
RTRVVME02D22
RTRVVME01D22
ECO Kit Approximate Size: 11025 Blocks
Saveset A - 252 Blocks
Saveset B - 5796 Blocks
Saveset C - 3843 Blocks
Saveset E - 1134 Blocks
Kit Applies To: RTR V2.2, V2.2A, V2.2B, V2.2C, V2.2D
OpenVMS VAX V5.5-2 or higher
NOTE: RTRVVME0422D is a complete V2.2D kit.
A previous version of RTR V2.2 does
not need to be installed before
installing this kit. However, a valid
license must be installed.
System/Cluster Reboot Necessary: No
ECO KIT SUMMARY:
An ECO kit exists for Reliable Transaction Router on OpenVMS VAX V5.5-2
or higher. This kit addresses the following problems:
Problems addressed in the RTRVVME0422D kit:
o The Reliable Transaction Router ACP could crash if a set of
concurrent servers performed a failover to a standby and the
failing node's journal was not accessible.
o A failover to a standby node that was not in the same cluster
could sometimes result in the RTR ACP process looping and
application processes hanging.
o Monitoring a remote node that had many applications running
could result in the error message "too much data" instead of a
display. The amount of data that can be handled by remote
monitoring has been increased to avoid this problem.
Problems addressed in the RTRVVME0322D kit:
o In the previous ECO version of RTR V2.2, the ASTPRM parameter was
not being returned properly by the event AST.
o Aborted transactions were causing loss of BYTLM quota when a server
was using DDTM.
o Some rare crashes could occur (with LIB$_BADTAGVAL or
LIB$_BADBLOADR) caused by double deallocation of dynamic data
structures during some race conditions on network link cleanup.
o DECnet/OSI related crashes could occur due to corrupted data
packets (e.g., after node shutdown).
o A rare refusal of a node to re-establish a connection (due to a
DECnet/OSI problem with corrupted optional data in connect request
packets) has been corrected.
o On rare occasions, a DELETE FACILITY or TRIM FACILITY command could
hang due to a race condition in the internal lock manager.
o A crash could occur in the Remote Client Handler when TCP/IP
Services for OpenVMS (UCX) was improperly started on a node.
Now RTR just recognizes the condition and does not use TCP/IP in
the Remote Client Handler. The Remote Client Handler needs to be
restarted after the UCX problem is cleared, otherwise remote
clients using TCP/IP will fail to connect.
o The RTR$_ABORT reason status RTR$_REPLYDIFF was not documented.
RTR may abort a transaction with this status when there has been a
failover from one instance of a server to another (for example, to
a shadow server) and the replies from the second server do not
exactly match those already received from the first server. RTR
aborts the transaction in case the client application context
depended upon a single server instance. The client application
should restart the transaction.
Problems addressed in the RTRVVME02D22 kit:
o A rare ACP crash caused by an uninitialized network buffer pointer
during a network "glitch" such as a network shutdown on a remote
node.
o More graceful handling of network "glitches" such as corrupted
network packets.
o Incorrect setting up of the ASTPRM on event delivery.
Problems addressed in the RTRVVME01D22 kit:
o On a primary/standby configuration involving multiple router nodes
where the backend and frontends were on different nodes, a network
link "glitch" could sometimes cause a problem. The transactions
would be replayed to the standby backend node, and these
transactions would then cause the systems to hang.
o In a shadow server configuration, if one of the sites became
unavailable during certain multiple failure scenarios, or if the
surviving site was in the minority, the servers would remain
waiting for the other site to come back.
NOTE: This occurred because the surviving site should recover the
transactions stored in the other node's journal.
This was a problem if the other site was really down, since there
was no manual override of this wait.
In order to fix this problem, the TRIM FACILITY command has been
modified so that if the other site is removed from the surviving
site's configuration, then the servers will start processing online
transactions.
Note that this TRIM FACILITY command should be executed on all the
nodes in the surviving site. Also, a corresponding EXTEND FACILITY
should be executed on these nodes immediately prior to bringing the
failed site back on line.
NOTE: Please see the Release Notes supplied with this ECO for more
details regarding RTR V2.2D.
INSTALLATION NOTES:
Before the installation of this ECO, RTR must be stopped.
The system does not need to be rebooted after this kit is installed.
If you are using RTR in a cluster, you need to execute the following
command
@SYS$STARTUP:RTR$STARTUP
on all nodes in the cluster other than the installation node. This
command will be executed by the installation procedure on the
installation node.
This patch can be found at any of these sites:
Colorado Site
Georgia Site
Files on this server are as follows:
rtrvvme0322d.README
rtrvvme0422d.CHKSUM
rtrvvme0422d.CVRLET_TXT
rtrvvme0422d.a-dcx_vaxexe
rtrvvme0422d.b-dcx_vaxexe
rtrvvme0422d.c-dcx_vaxexe
rtrvvme0422d.e-dcx_vaxexe
|
