SEARCH CONTACT US SUPPORT SERVICES PRODUCTS STORE
United States    
COMPAQ STORE | PRODUCTS | SERVICES | SUPPORT | CONTACT US | SEARCH
gears
compaq support options
support home
software & drivers
ask Compaq
reference library
support forum
frequently asked questions
support tools
warranty information
service centers
contact support
product resources
parts for your system
give us feedback
associated links
.
} what's new
.
} contract access
.
} browse patch tree
.
} search patches
.
} join mailing list
.
} feedback
.
patches by topic
.
} DOS
.
} OpenVMS
.
} Security
.
} Tru64 Unix
.
} Ultrix 32
.
} Windows
.
} Windows NT
.
connection tools
.
} nameserver lookup
.
} traceroute
.
} ping
RTR V2.2D RTRVVME0922D Reliable Transaction Router VAX ECO Summary

TITLE: RTR V2.2D RTRVVME0922D 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) Compaq Computer Corporation 1997, 1999. All rights reserved. Modification Date: 03-SEP-1999 Modification Type: Updated Kit Supersedes RTRVVME0822D PRODUCT: Reliable Transaction Router for OpenVMS VAX (RTR) OP/SYS: OpenVMS VAX SOURCE: Compaq Computer Corporation ECO INFORMATION: ECO Kit Name: RTRVVME0922D ECO Kits Superseded by This ECO Kit: RTRVVME0822D ECO Kit Approximate Size: 10962 Blocks Saveset A - 189 Blocks Saveset B - 5796 Blocks Saveset C - 3843 Blocks Saveset E - 1134 Blocks Kit Applies To: RTR V2.2D OpenVMS VAX V6.1, V6.2, V6.2-0HF, V7.0 and V7.1 System/Cluster Reboot Necessary: No ECO KIT SUMMARY: An ECO kit exists for Reliable Transaction Router V2.2D on OpenVMS VAX V6.1 through V7.1. This kit addresses the following problems: Problems addressed in the RTRVVME0922D kit: o When the last block of a contiguous set within the journal contains a particular pattern, with a valid record followed by an invalid one, journal re-reads the last record over and over again. This caused ACP to loop while trying to read a journal. Problems addressed in the RTRVVME0822D kit: o 14-8-258: An error in RTR V2.2D-ECO7 could cause the RTRACP process to intermittently BUGCHECK while it was processing network i/o. This has now been corrected. o 14-8-263: An error in RTR V2.2D-ECO7 could cause the RTRACP process to crash while it was reading the RTR journal file if the journal data from a previous run of RTR happened to end in a particular location. This could result in an inability to restart RTR after a failure, or cause the RTRACP to crash when taking over activity on behalf of another cluster node which had been stopped. This has now been corrected. Problems addressed in the RTRVVME0722D kit: o Network problems could lead to nodes becoming and remaining semi-connected. This state could lead to difficulties establishing quorum, as well as frontend to router connectivity problems. o Long facility names (31 characters) could sometimes cause the RTRACP process to crash with SS$_BADPARAM. o During periods of network disruption when the DNS was not available, some network connections were being rejected because the address-to-name translations were failing. Code has been added to improve this situation. o Some records in the journal could not be deleted, sometimes leading to transactions being seen when not expected. Problems addressed in the RTRVVME0622D kit: o During a server failover from main to standby nodes, it was sometimes possible for the standby server to get permanently stuck in a WAIT_JNL state. This was mostly noticed on systems using multiple data partitions and error-prone communication links between the backends and routers. o During server failover to a standby node, some standby servers would get stuck in a STANDBY state permanently. This effect was most pronounced when there was a short network link loss between one of the routers and the standby node immediately after the main node failed. o Several errors during creation of a journal file, especially when duplicate or spurious journal files existed. o Some crashes caused by RTR's inability to cope with DECdtm recovery. o Transaction hangs caused by network glitches involving shadowed multi-participant transactions. 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: This ECO kit called RTRVVMECO0922D or RTRAVMECO0922D is a replacement for any previously installed RTR kit. Standard VMS installation procedures are applicable, as described in the RTR installation guide. If you are using RTR in a cluster, you need to execute the SYS$STARTUP:RTR$STARTUP.COM procedure on all nodes in the cluster, apart from the one where the VMSINSTAL is actually performed. A system reboot is not necessary. Note: The OpenVMS VAX kit for RTR V2.2D ECO09 (and previous OpenVMS VAX kits) have 4 savesets, i.e. A, B, C, E. The "D" saveset is intentionally missing.



This patch can be found at any of these sites:

Colorado Site
Georgia Site



Files on this server are as follows:

rtrvvme0922d.README
.CHKSUM
rtrvvme0922d.a-dcx_vaxexe
rtrvvme0922d.b-dcx_vaxexe
rtrvvme0922d.c-dcx_vaxexe
rtrvvme0922d.e-dcx_vaxexe
rtrvvme0922d.CVRLET_TXT

privacy and legal statement