RTR V3.1D RTRAVME07D31 Reliable Transaction Router Alpha ECO Summary
TITLE: RTR V3.1D RTRAVME07D31 Reliable Transaction Router Alpha ECO Summary
Copyright (c) Compaq Computer Corporation 1998. All rights reserved.
Modification Date: 28-JAN-98
Modification Type: Reloaded Kit to proper directories.
PRODUCT: Reliable Transaction Router V3.1D for OpenVMS Alpha (RTR)
OP/SYS: DIGITAL OpenVMS Alpha
COMPONENTs: RTR.EXE
LIBRTR.EXE
SOURCE: Compaq Computer Corporation
ECO INFORMATION:
ECO Kit Name: RTRAVME07D31
ECO Kits Superseded by This ECO Kit: RTRAVME06D31
RTRAVME04D31
RTRAVME03D31
ECO Kit Approximate Size: 18320 Blocks
Kit Applies To: RTR V3.1D for OpenVMS Alpha
OpenVMS Alpha V6.1, V6.2, V7.0, V7.1
NOTE: RTRAVME07D31 is a complete V3.1D kit.
A previous version of RTR V3.1 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 Alpha V6.1
through V7.1. This kit addresses the following problems:
PROBLEMS ADDRESSED IN RTRAVME07D31:
This kit is contains the following corrections to RTR V3.1D (189) ECO4:
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 RTRAVME07D31:
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 RTRAVME06D31:
Known Problems
o 14-3-66 DECnet Plus and upgrading RTR
DECnet Plus users may encounter connection difficulties when upgrading
from RTR V2.x to V3.x or downgrading from V3.x to V2.x. This problem
can be avoided by deleting the appropriate objects when shutting down
the old version and before starting up the new one. In V2.x, the
DECnet+ object created by RTR is called RTR$ACP. In V3.x, the object
is simply referred to by its number, "11". To delete the object, use
an NCL command as follows:
- after shutting down RTR V2.x
NCL> delete session control application rtr$acp
- after shutting down RTR V3.x
NCL> delete session control application 11
NOTE: You may want to initially verify that the object still exists by
using the NCL SHOW command.
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-625 RTR Version 3 and RTR Version 2 on same machine.
RTR Version 3 cannot be run in system-mode on a machine on which RTR
Version 2 is already running. If this is attempted the RTR-V3 ACP
process will fail. Please make sure RTR Version 2 has been stopped
before attempting to install and run RTR Version 3.
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 re-entrancy in an OpenVMS threaded
application.
ECO-6 corrects the following problems.
o 14-1-202 Quadword 8-byte numeric key segments are now implemented.
o 14-1-204 Some fields in MONITOR RSCBE were truncated or garbled
The monitor file now requests separate states instead of the sum of
the state on all nodes and partitions, (which was meaningless when
more than one partition was monitored). The field sizes have been
adjusted slightly. The date previously contained a new line, and was
wrong on AIX.
o 14-1-216 MONITOR GROUP showed incorrect transaction count.
MONITOR GROUP picture has been changed to include
rtr_mt_msg1_uncertain messages in its "txn cnt" field.
o 14-3-114 TRIM FACILITY and frontend/router node problems.
Executing a TRIM FACILITY command on a node with frontend and router
roles caused the frontend to be unable to connect to the router on the
same node. Once in this condition, starting client channels would be
o 14-1-251 Intermittent failure to compile MONITOR files.
RTR could sometimes fail to compile any monitor pictures; this problem
has been fixed.
o 14-1-252 RTR Error message severity codes.
RTR error messages are displayed with a severity code (e.g. %%RTR-S-
for success and %%RTR-W- for a warning). In previous versions of RTR
V3, all messages of warning, error and fatal were displayed with the
severity level "fatal". Messages are now consistent with their
descriptions in the System Manager's Manual and elsewhere.
o 14-1-259 Additional journal status messages.
Several new, more specific, status messages have been created to
pinpoint why a particular device is unsuitable for journals, or why an
attempt to access a journal file has failed. These are: DISKACCDEN,
JOUDISKFULL, JOUREADINC, JOUREADONLY, JOURAMDISK, JOUCD-ROM,
JOUREMOTDEVIC, JOUDEVICEUNKNOWN.
o 14-1-260 Key range bound displayed correctly in SHOW commands.
Key range low and high bounds are now displayed properly as a
comma-separated list of numbers and C-style strings.
o 14-1-267 New qualifier /AUTOISOLATE.
The SET NODE qualifier /ISOLATE and SET LINK qualifier /SUSPECT have
both been superseded by /AUTOISOLATE. Any RTR node may disconnect a
remote node if it finds the remote node is unresponsive or congested.
The normal behavior following such action is automatic network link
reconnection and recovery.
Node autoisolation allows a node (the isolator) to disconnect a
congested or unresponsive remote node (the isolatee) in such a way
that when the congested node attempts to reconnect, it receives an
instruction to close all its network links and cease connection
attempts. A node in this state is termed isolated.
Some applications require that a node that is suspected of causing
congestion (that is, not processing network data sufficiently quickly)
is isolated from the rest of the network, so as to cause minimum
disruption. The node autoisolation feature meets this requirement.
Remote node autoisolation may be enabled (at the isolator) where it
applies to all links using SET NODE/AUTOISOLATE, or for specific links
only with the SET LINK/AUTOISOLATE command. An isolated node
(isolatee) remains isolated until you carry out one of the following
actions:
1) Enable the link to the isolated node on all nodes that have
isolated it, that is set link [isolated-node] /enable
2) Exit the isolated state on the isolated node, that is set
node/noisolate
Autoisolation is disabled (at the isolator) using the /NOAUTOISOLATE
qualifier.
o 14-1-269 The SHOW SEGMENT command no longer displays invalid data in
the Data Type field.
o 14-1-272 Improved journal read/write performance.
Journal throughput performance has been improved on OpenVMS. Also,
asynchronous I/O has been introduced on Digital UNIX 4.0, AIX, and
Solaris 5.6.
o 14-1-275 Multiple server channels and message sequence.
In previous versions of RTR V3, when a transaction was sent to a
server process with multiple concurrent channels, it was sometimes
possible for the new transaction to be presented to the server before
the "rtr_mt_accepted" message from the previous transaction had been
delivered to the server. This has been corrected.
o 14-1-276 SHOW QUORUM introduced, MONITOR QUORUM corrections.
In previous versions of RTR, MONITOR QUORUM would sometimes display
inconsistent or confusing output when a quorum problem existed. This
has now been fixed. MONITOR QUORUM now displays the state (quorate,
bad_cfg, uncertain or not_cncted) as well as the name of the node
causing the problem. The erroneous display of "CFG" as the quorum
state when a role does not exist on a node has also been corrected.
In addition a new RTR command "SHOW QUORUM" has been implemented which
lists detailed information about the expected quorum view a node
should have, and any discrepancies between the actual and expected state.
o 14-1-284 DELETE FACILITY command could cause a crash.
On rare occasions, RTRACP process could fail following the deletion of
a facility. This has been corrected.
o 14-1-299 The CALL RTR_REQUEST_INFO command now processes lists of
items supplied with the /GETITMS qualifier (previously, only the first
item in the list was processed).
o 14-1-316 If the link between a router and secondary backend fails and
comes back, the router may not re-send the "pri_vote" message to the
secondary during commit. As a result, the secondary keeps writing a
VOTE record to the journal until the journal is full. This has been
corrected.
o 14-1-356 Routers losing quorum did not disconnect frontends
Routers running earlier versions of RTR would not update their
connected frontend nodes when the router lost role quorum in a
facility, thus denying the front ends the opportunity to seek a better
connected router. This problem has been corrected.
o 14-1-358 Deadlock deleting incompletely created journal
Previously, when an attempt to create a journal failed for any reason,
(for example, insufficient disk quota on OpenVMS, the RTR command
server would enter a deadlock while attempting to delete the journal.
This affected all platforms that use non-recursive locks.
The journal is now deleted using the lock that is already held to
create it.
o 14-1-370 Symbol substitution and last element of a command.
RTR allows the value of environment variables (or logical names) to be
substituted into command lines typed at the RTR prompt. Symbol
substitution did not work if the symbol was the very last element of
the command line.
o 14-1-386 RTR would sometimes continue to write log-file messages to the
old log file after a new one had been specified with RTR SET LOG/FILE.
This has now been corrected.
o 14-1-387 RTR could return an incorrect event number zero when
delivering NODSTFNDEVT events to a V2 client application. This has
now been fixed so that the correct event number (114) is delivered.
o 14-1-396 The RTR ACP process could crash on rare occasions when a
router or backend role was removed from the node's configuration with
a "TRIM FACILITY" command. This has been fixed.
o 14-1-397 The RTR ACP could fail on rare occasions if a facility was
deleted while a network write operation was in progress. This has
been fixed.
o 14-1-400 Shadows servers stuck in state lcl_rec In prior versions of
RTR it was occasionally possible for shadow servers restarted after
all servers for a partition had died to remain permanently in state
lcl_rec processing a recovery transaction in voted state. This has
been fixed.
o 14-1-402 The RTR ACP process could occasionally fail if a facility was
deleted whilst an client application was sending a transaction. This
has been fixed.
o 14-3-125 Standby servers stuck in lcl_rec_fail
In previous versions, it was possible for a standby server which was
attempting to take over after failure of the node which contained the
previously-active server to become permanently stuck in state
lcl_rec_fail. This would happen if the node which had failed had been
both (1) not in the same cluster cluster as the node containing the
standby, and (2) if the failed node had also been the quorum-master
router for the standby backend. This problem has now been fixed.
o 14-3-135 The command SET ENVIRONMENT /CLUSTER is now available on
OpenVMS and Windows NT clusters and on Digital UNIX TruCluster.
o 14-3-17 Correction to journal behavior.
RTR would occasionally fail in an attempt to flush records to a
recently closed journal file. This has been corrected.
o 14-3-77 MONITOR QUEUES display corrected.
If a transaction on a backend was aborted before being played to a
server, then the MONITOR QUEUES display did not correctly update its
count of queued transactions and messages. MONITOR QUEUES would
indicate that transactions were queued even though there may be no
outstanding transactions on the server.
o 14-3-81 Improved flow control.
Flow control mechanisms have been adjusted to provide for better
throughput when using very large messages and slow communications
lines.
o 14-5-27 Performance improvements when running many applications
The scalability of RTR has been improved by increasing performance and
reducing the memory requirements when running many (that is, a hundred
or more) application processes. Maximum throughput can be achieved by
combining multiple applications with multiple channels and multiple
threads.
o 14-5-33 Performance improvements in monitoring and rtr_request_info()
The performance of rtr_request_info() and the MONITOR and SHOW
commands has been improved. The performance impact of using these
commands on RTR ACP is now greatly reduced.
o 14-5-39 RTR performance has been improved when handling many
transactions on Alpha and other RISC platforms by eliminating a
hotspot involving byte arithmetic.
o 14-7-751 Transport protocol checks improved
Additional checks have been implemented at facility creation time to
check for (and report on the absence of) any specified transports or
required or optional name to address lookups on specified or available
transports. Errors or warnings are issued to the terminal session,
and also recorded in the RTR log file.
o 14-8-100 RTR ACP failure after transaction abort
In rare circumstances, if RTR aborted a transaction that was being
recovered from journal then it could result in the RTR ACP failing.
This has now been fixed.
o 14-8-57 Event delivery
The delivery of the RTR_EVTNUM_SRPRIMARY event sometimes arrived at an
application in Shadow Secondary mode before the completion of the
pending transaction. This had the result of the same transaction
being played to both of two shadow sites in secondary state. This
problem has been corrected by ensuring that the event is delivered
only between transactions.
o 14-1-408 In prior versions of RTR-V3 it was occasionally possible for
the command-server process to crash whilst attempting to connect to a
remote node in order to execute an RTR command on that node.
o 14-1-50 New command FLUSH NAME_CACHE.
Network links could become unstable if a Distributed Name Service
(DNS) was configured improperly or the service was slow in
responding. During extreme DNS latency, RTR on connected nodes
could time-out the connections to nodes waiting for a DNS response.
An internal node-name-to-id cache has been implemented which
reduces RTR's exposure to degraded name servers. The contents of
the cache can be deleted if desired with the new system management
command FLUSH NAME_CACHE.
o 14-1-250 Use of detached process discontinued.
Previous versions of RTR would start a detached process upon creation
of the first facility to modify the attributes of the DECnet
object/application dynamically. When RTR is not running in group
mode, the use of a detached process has been discontinued in favor of
an entry for the RTR$ACP object in the startup file RTR$STARTUP.COM.
(Group mode operation remains unchanged.)
o 14-1-318 Improved performance when using the V2 API.
Several changes have been made to improve the performance when using
the V2 API. This is seen as reduced CPU consumption by applications
and an improved transaction processing rate.
o 14-1-336 Badly formed filename caused command server failure.
Incorrectly entering SET LOG/FILE=name with unmatched OpenVMS
directory delimiters now produces a BADFILE error message (instead of
causing the RTR command server to fail).
o 14-1-339 Network protocol failover not working with DECnet-Plus.
Specifying link names as IP network names on OpenVMS systems running
DECnet-Plus configured with domain name lookup enabled used to result
in an unexpected lack of network connectivity. Such systems would try
to connect first over DECnet; if the connection was explicitly
rejected by the remote node, RTR would not failover to TCP/IP, and no
connection would result.
o 14-1-369 The command RTR SHOW RTR/NODE=DNA. used to cause
the command server to crash.
o 14-1-378 V2 API and RTR counters.
In cases where a transaction was rejected, counter values for $VOTE_TX
could be updated instead of those for $COMMIT_TX. This did not have
any effect upon user applications, but could lead to displaying
inaccurate information, e.g. in RTR MONITOR V2CALLS.
o 14-3-123 Performance of single-threaded applications has been
significantly improved by an optimization to reduce latency in
inter-process communication within RTR.
o 14-3-132 ACP failed if defined journal sizes not equal.
Previous versions of RTR would suffer from a crash of the RTR ACP
process if the RTR journal had been created with /MAXIMUM_BLOCKS
greater than /BLOCKS and RTR attempted to extend the journal beyond
the initial size. This has now been corrected.
o 14-3-144 RTR would sometimes crash when a facility was added on an
OpenVMS machine with Multinet installed as TCP/IP transport. This has
been fixed.
o 14-3-73 Previous versions of RTR would fail to start IP networking if
logical UCX$INET_DOMAIN was not defined. This has been fixed.
o 14-3-94 V2 API - memory leak corrected.
Applications using the V2 compatibility layer could sometimes be
affected by a memory leak that could occur on requester channel
closure ($DCL_TX_PRC(W)/SHUTDOWN).
o 14-3-98 V2 API - RTR$M_INHNOSRVWT now functioning correctly.
The RTR$M_INHNOSRVWT flag (used with the RTR V2 call SYS$DCL_TX_PRCW)
had no effect: the call was blocked if no server existed on the
facility. This has been corrected.
o 14-3-145 RTR would erroneously omit the server information from a SHOW
SERVER/ID=pid command if the pid contained alphabetic characters.
This has been fixed.
PROBLEMS ADDRESSED IN RTRAVME04D31:
The following restrictions apply to this kit:
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. (14-1-285)
The values for partition bounds are (as in previous versions)
returned as binary values. A future version of RTR V3 will return
these values as textual data. (14-1-260)
An application's wakeup routine may be called more often than
necessary. (14-3-67)
This kit is contains the following corrections to RTR V3.1D ECO3 (176):
The RTR$L_EVT_ASTPRM field is defined in the RTR$_EVT structure, and
the RTR$L_EVT_ARGNO field is set with the new value of RTR$K_EVTAST_ARGNO(7).
The $COMMIT_TX(W) call returns SS$_NORMAL in the txsb.RTR$L_TXSB_STATUS field,
not RTR$_COMMIT. This has been corrected.
The MONITOR ACTIVE command now displays correct values.
A memory leak which occurred when an acp on another backend
in a cluster remained unreachable for long periods has been fixed.
The default value for the upper keyrange bound for a $DCL_TX_PRC
issued at the command line was incorrectly calculated. This has been
corrected.
The failure to open a remote node's journal resulting from an
incorrect node-id comparison has been fixed.
Broadcast messages are now received on channels for which the evtmsk
parameter to $DCL_TX_PRC was defaulted.
Illegal flags specified on a server's $ENQ_TX are now ignored.
Support for SET FACILITY /BROADCAST_MINIMUM_RATE has been added.
A problem causing an application to crash on image exit has been corrected.
The RTR$M_NODSTFNDIGN flag can now be specified on a requester's $ENQ_TX
call.
Broadcasts could be delivered with corrupted contents under certain
conditions. This has been corrected.
A requester's $ENQ_TX call to a partition without a server could
complete with RTR$_ABORT status and its completion AST could fire.
It now returns RTR$_ABORTPEND.
An application could hang (completion AST fail to fire) despite
the fact that RTR MONITOR CALLS showed that there were messages
pending for it. This has been fixed.
A transaction whose "rtr_mt_rejected" message had not
yet been received by a client application's call to
rtr_receive_message() could prevent further transactions
from being issued on that channel. This has been corrected.
Applications failing to open a channel using DECdtm could
crash. This has been fixed.
If a facility included multiple nodes which had only DECnet
Phase-IV configured as a network transport it was sometimes
possible for backends in the facility to fail to gain quorum,
or for servers to remain permanently in state lcl_rec_fail. This
has been corrected.
A node could fail to gain quorum if it connected to its quorum
master after it had established a stable quorum state. This has
been fixed.
Running a V2 application from an account that does not have
RTR info privilege no longer causes the application to crash.
Various counters connected with the delivery of broadcast
events have been added:
Facility counters: fdb_cn_bm_transit_brd_lost
fdb_cn_bm_transit_brd_delivered
fdb_cn_bm_dest_brd_lost
fdb_cn_bm_dest_brd_delivered
Link counters: ndb_cn_bm_transit_lost
ndb_cn_bm_transit_delivered
Process counters: bm_brd_lost
bm_brd_delivered
In addition, this kit contains the following corrections to RTR V3.1D (165)
that were previously released as RTR V3.1D (176) ECO3:
RTR could drop network links under conditions of high load when
using DECnet as the transport protocol, leading to degraded system
performance. (14-3-72)
The RTR ACP no longer crashes due to insufficient memory caused by
sending more data than necessary in response to a call to
rtr_request_info(), as could be seen for example when SHOW
TRANSACTION was executing on a node with many thousands of active
transactions. (14-8-99)
Broadcast event delivery to V2 client applications; user events
sent from server applications using RTR V3 can now be delivered to
client applications using RTR V2.2. (14-3-63)
Servers using the RTR V2 interface on RTR V3 could erroneously
remain in state "lcl_rec". (14-3-79)
In a standby server configuration consisting of only two
router/backend nodes on a clustered system where both nodes are
configured as router and backend (with no other routers or backends
in the configuration), after a failure of the active server node the
standby server could occasionally fail to open the journal belonging
to the failed node. (14-8-93)
Using previous versions of RTR, unthreaded application programs that
used the RTR V2 API and also used ASTs that call certain LIB$ or C
runtime library functions could have experienced unexpected
deadlocks or program aborts. (14-3-86)
The RTR ACP no longer fails due to insufficient memory caused by a
memory leak triggered by, for example, either (1) process
termination (application process or RTR command server) or (2)
connection failure (as occurs when facility definitions are
inconsistent across nodes). (14-8-81)
Remote Commands and DO commands could hang when the output contained
empty line. (14-3-85)
When a router node in quorum "uncertain" state experienced a state
transition, it would sometimes erroneously enter "inquorate" state.
(14-1-264)
PROBLEMS ADDRESSED IN RTRAVME03D31:
The following restrictions apply to this kit:
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. (14-1-285)
The values for partition bounds are (as in previous versions)
returned as binary values. A future version of RTR V3 will return
these values as textual data. (14-1-260)
An application's wakeup routine may be called more often than
necessary. (14-3-67)
This kit is contains the following corrections to RTR V3.1D (165):
RTR could drop network links under conditions of high load when
using DECnet as the transport protocol, leading to degraded system
performance. (14-3-72)
The RTR ACP no longer crashes due to insufficient memory caused by
sending more data than necessary in response to a call to
rtr_request_info(), as could be seen for example when SHOW
TRANSACTION was executing on a node with many thousands of active
transactions. (14-8-99)
Broadcast event delivery to V2 client applications; user events
sent from server applications using RTR V3 can now be delivered to
client applications using RTR V2.2. (14-3-63)
Servers using the RTR V2 interface on RTR V3 could erroneously
remain in state "lcl_rec". (14-3-79)
In a standby server configuration consisting of only two
router/backend nodes on a clustered system where both nodes are
configured as router and backend (with no other routers or backends
in the configuration), after a failure of the active server node the
standby server could occasionally fail to open the journal belonging
to the failed node. (14-8-93)
Using previous versions of RTR, unthreaded application programs that
used the RTR V2 API and also used ASTs that call certain LIB$ or C
runtime library functions could have experienced unexpected
deadlocks or program aborts. (14-3-86)
The RTR ACP no longer fails due to insufficient memory caused by a
memory leak triggered by, for example, either (1) process
termination (application process or RTR command server) or (2)
connection failure (as occurs when facility definitions are
inconsistent across nodes). (14-8-81)
Remote Commands and DO commands could hang when the output contained
empty line. (14-3-85)
When a router node in quorum "uncertain" state experienced a state
transition, it would sometimes erroneously enter "inquorate" state.
(14-1-264)
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.
Installation Overview
---------------------
The Reliable Transaction Router installation procedure uses the
POLYCENTER Software Installation Utility (PCSI). For details on
using PCSI, refer to the OpenVMS System Manager's Manual, Section
"Installing with the POLYCENTER Software Installation Utility".
The logical name PCSI$SOURCE is used to define the location of the
software kits you want to install. For example, if the Reliable
Transaction Router software is located in DISK1:[KITS], enter the
following at the DCL prompt (or include the line in the system
manager's login command file):
$ DEFINE PCSI$SOURCE DISK1:[KITS]
When running the installation procedure for Reliable Transaction
Router, you can choose whether to install the ODBC Over RTR Oracle7
Server. This is an RTR server used for supporting ODBC-enabled
applications on Windows. You should not install the ODBC Over RTR
Oracle7 Server unless you already have Oracle7 installed.
To start the installation, type the command:-
$ PRODUCT INSTALL RTR
You will see a display similar to the following:-
The following product has been selected:
DEC AXPVMS RTR V3.1-D198 [Available]
Do you want to continue? [YES]
Press . You may safely accept the installation default
options.
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:
dec-axpvms-rtr-v0301-d198-1.README
dec-axpvms-rtr-v0301-d198-1.CHKSUM
dec-axpvms-rtr-v0301-d198-1.CVRLET_TXT
dec-axpvms-rtr-v0301-d198-1.exe
|
