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 V3.1D RTRI231 RTR for Windows NT _ 95 3.1D Intel ECO Summary

TITLE: RTR V3.1D RTRI231 RTR for Windows NT _ 95 3.1D Intel ECO Summary Modification Date: 07-MAY-99 Modification Type: New Kit Copyright (c) Compaq Computer Corporation 1999. All rights reserved. PRODUCT: Reliable Transaction Router (RTR) V3.1D OP/SYS: Windows NT and Windows 95 SOURCE: Compaq Computer Corporation ECO INFORMATION: ECO Kit Name: RTRI231 ECO Kits Superseded by This ECO Kit: None ECO Kit Approximate Size: 3959 Blocks Kit Applies To: RTR V3.1D System/Cluster Reboot Necessary: Unknown Rolling Re-boot Supported: Information Not Available Installation Rating: INSTALL_UNKNOWN Kit Dependencies: The following remedial kit(s) must be installed BEFORE installation of this kit: None In order to receive all the corrections listed in this kit, the following remedial kits should also be installed: None ECO KIT SUMMARY: An ECO kit exists for Reliable Transaction Router (RTR) V3.1D on Windows NT V4.0. This kit addresses the following problems: Problems Addressed in the RTRI231 Kit (ECO-14): o 14-1-239 WSAEventSelect 10055 knl_env line 1339 RTR was not handling some errors that could be returned when an asynchronous DECnet line would shut down. This has been corrected. o 14-3-118 TX on pri_act not being played on sec_act If RTR is configured with servers on backends that are running DECnet Phase V, then under certain conditions, local recovery from the remote node's journal would not be performed. For example, local and shadow recovery would appear to work correctly in a shadow server configuration after the primary shadow would go down, but in actual fact any transactions in the remote node's journal would not be recovered. This can only occur if the backends are all using DECnet Phase V as the primary RTR transport, and if the DECnet addresses of the nodes concerned match a particular pattern. Note that this is a static DECnet configuration issue. If recovery works in your particular configuration, then it will always work so long as the DECnet network configuration is not changed. This has now been fixed. o 14-3-124 Bug in V2 load balance In earlier versions of RTR it was occasionally possible for a router to become permanently incapable of accepting new incoming frontend connections if router load-balancing had been enabled by specifying the /BALANCE qualifier, and a frontend happened to connect to the router during a quorum state transition. This has been corrected. o 14-3-131 $DCL_TX_PRC crash when no privs Running a V2 application from an account that does not have RTR info privilege no longer causes the application to crash. o 14-3-132 Extend journal failure 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-134 More Broadcast message counters required Various counters connected with the delivery of broadcast events have been added: Facility counters fdb_cn_bm_transit_brd_lost and fdb_cn_bm_transit_brd_delivered, link counters ndb_cn_bm_transit_lost and ndb_cn_bm_transit_delivered, and process counters bm_brd_lost and bm_brd_delivered. o 14-3-140 RTR V3 $DCL_TX_PRC does not complete correctly when no TXSB is supplied Using the V2 API verbs on V3 would not always generate the same result as V2 when using undeclared or invalid channels. This has been corrected. o 14-3-150 RTR applications hang on trying to continue after ACP restarted If the application tries to open a channel again after seeing the status RTR_STS_ACPNOTVIA, it hangs on the subsequent rtr_receive_message call. This affects applications on threaded RTR platforms, especially Win32 and AIX. If the application tried to open a channel again after seeing the status RTR_STS_ACPNOTVIA it could hang on the subsequent rtr_receive_message call. This problem has been corrected for threaded UNIX platforms. It is no longer necessary to restart any RTR application for UNIX after restarting RTR. o 14-3-151 'signed' identifier not in VAX C 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. This has now been fixed. The signed keyword is no longer defined in RTR.H if compiling with the VAX C compiler. o 14-3-161 MONITOR CALLS/ID=n where 'n' is not a valid id - monitors all ids Use of the monitor command with any of the qualifers /link, /process, /facility or /partition would generate an empty display if the requested entity did not exist. This was unlike V2 behavior, and was considered by some to be misleading. V2 behavior has been restored. o 14-3-165 Shadow servers experience deadlock using 2 partitions If two shadowed server partitions were set up with primary and secondary roles transposed on the two backends involved and the servers for these partitions acccessed the same database rows it was occasionally possible for a distributed deadlock to occur in which servers on each site waited forever for locks held by the primary server for the other partition to be released. his has now been corrected. o 14-3-167 Corruption in large monitor pictures Spurious and missing characters were seen in larger monitor pictures displayed to a terminal window or terminal. The corruption was particularly dramatic if a terminal escape sequence was affected. The corruption appeared to occur when more than 8k of data was buffered without a newline or explicit flush, e.g. when monitoring with a recent kit in which Rtr terminal output was changed to line-buffered for efficiency. The output always seemed to be correct when using MONITOR /OUTPUT, or when monitoring remotely from an Rtr platform other than VAX, or when buffering more than BUFSIZ 64k of output on OpenVMS Alpha. Investigation so far indicates that Rtr was buffering the output correctly, and that there would seem to be an error in the OpenVMS VAX runtime libraries. RTR now flushes output more frequently so as not to provoke this problem. o 14-3-168 How to calculate required quotas? There is no easy way to calculate the required UAF and SYSGEN parameters needed by RTR. The following information may be used to estimate virtual memory size requirements of the RTR ACP process. The base virtual memory requirement of an unconfigured RTR ACP process is approximately 5.8 Mbytes. To this should be added allowances for the following: - for each link, add 202 kBytes - for each facility, add 13 kBytes, plus 80 bytes for each link in the facility - for each client or server application process, add 190 kBytes for the first channel - for each additional application channel, add 1350 bytes It is also necessary to make allowance for the number of active transactions in the system. Unless your client applications are programmed to initiate multiple concurrent transactions, this number will not exceed the total number of client channels in the system, but you should verify this with your application providers. It is also necessary to determine the size of the transaction messages in use. For each frontend: - add 1 kByte per active transaction - add 250 bytes per message per transaction - plus the size of all the messages For transaction routers, allow about 1 kByte for each active transaction. For backends, allow: - 1 kByte per active transaction - 50 bytes for each message of a transaction. - plus to size of all replies The total of all contributions detailed above will yield an estimate of the likely virtual memory requirements of the ACP. Apply a large factor for safety - it is better to grant RTR resource limits exceeding its real requirements than to risk a loss of service in production as a result of insufficient resource allocation. Divide the result by VM size in pages to obtain the virtual memory requirement. You should set process memory and page file quotas to accommodate at least this much memory. Process quotas for the ACP process are controlled by qualifers to the 'start rtr' command. See the RTR System Manager's Manual for further information. For more control, you may individually set all process quotas for the ACP by using the appropriate qualifer with the 'start rtr' command. For a more holistic approach, 'start rtr' accepts '/links' and '/processes' as qualifers which can be used to specify the expected number of links and application processes in the configuration. The values supplied are used to calculate reasonably safe minimum values for the following ACP process quotas: - astlm - biolm - fillm - diolm - pgflquota The default value for '/links' is 512. This is high, but is chosen to protect RTR routers against a failover scenario where the number of frontends is large and the number of surviving routers becomes small. The default value for '/processes' is 64. This is large for frontend and router nodes, but you may need to specify a larger value on a backend hosting a complex application. You may use an explicit process quota qualifier to specifiy a value larger than that calculated through use of '/link' and '/process', but you may not specify a smaller value. Use of /link and /process do not consider memory requirement for transactions. If your application passes a large amount of data from client to server or vice-versa, you should include this in your sizing calculations. o 14-3-174 $ENQ ACCVIOs with bad channel message Calls to the V2 API specifying an invalid channel identifier would cause an access violation in LIBRTR. This has been corrected. o 14-3-195 $START_TX when ACP died The emulation of the RTR V2 API on V3 has been improved to correctly reflect V2 behaviour for channels which 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-196 $START_TX from AST w/o ACP" Application calling $START_TX at AST level while the ACP died would cause the application to crash inside LIBRTR. This has been corrected and SYS$START_TX will simply return to the caller a message indicating that the ACP is not available. o 14-3-197 ACPNOTVIA error returned if RTR command $DCL_TX_PRC issued On RTR V3.1D (194-SWX01) ECO7-FT1 if the RTR command $DCL_TX_PRC is issued for a non-existent facility, an ACPNOTVIA error is returned. This does not happen the first time - only subsequent times if RTR is stopped in between. API verbs called from the RTR command line interpreter would fail with the status ACPNOTVIA if RTR was stopped and restarted without restarting the command server. This has been corrected. The problem can be avoided on earlier vesions of RTR by issuing the command 'disconnect server' after stopping RTR. o 14-3-203 ACP router crash when other nodes shut Configurations where more than 100 frontends were connected to any particular router may experience an ACP failure whilst managing quorum loss. This has been corrected. Automatic router failback has been restored for RTR V2 frontends connecting to RTR V3 routers. o 14-3-205 Inconsistent TR TX timeout if no link to FE Using previous versions of RTR, if a router lost a connection to a frontend that had a transaction active in enqueuing state, then the router would abort the transaction after a period of about one minute if the frontend link was not re-established. This even if the client had specified a transaction timeout much less than this when starting the transaction. This is now fixed, so that a transaction in enqueueing state on the router would be aborted after the interval specified by the client (if it's less than one minute) if the router loses its connection to the frontend. o 14-3-210 START RTR qualifiers from V2 Attempts to use obsolete V2 qualifiers to the 'start rtr' command cause a warning to be issued. Qualifiers affected are 'partitions', 'cache_pages', and 'relations'. Warnings are also generated if an OpenVMS qualifier is used on a non-OpenVMS o 14-3-211 Long facility names were truncated in SHOW FACILITY output Facility names near or at the maximum now push the next column to the right instead of being truncated. Slightly shorter names are still preferred to prevent the SHOW FACILITY columns becoming ragged. o 14-3-213 Fac name can be 31 chars? Although the %RTR-E-FACNAMLON message states the facility name can only have 30 characters, it can take up to 31. The documented maximum length of a facility name string is 30 characters. Prior versions of RTR permitted facility names as long as 31 characters. This has been corrected. o 14-3-217 Unthreaded UNIX applications using rtr_set_wakeup can fail, e.g., in malloc When an unthreaded UNIX RTR application calls rtr_set_wakeup, the non-reentrant RTR shared library -lrtr with which it is linked installs a signal handler. This signal handler called functions internal to RTR which could occasionally call runtime library functions such as malloc() that are not async-safe, according to the relevant standards. See man (4) signal. In practice this may appear to work most of the time, but break for no apparent reason when the signal happens to occur while background code is also in a runtime library call such as malloc. The problem in RTR has been corrected. The small penalty for this is that RTR no longer makes any attempt to try to ensure that messages available are not just housekeeping. Applications must always be prepared for a timeout return status on calling rtr_receive_message with a zero timeout, even after a wakeup suggests that a message ought to be available. Application writers are reminded that their RTR wakeup handlers are subject to the same restrictions: routines like printf, malloc, and the entire RTR API may not be used directly or indirectly from within a signal handler. A workaround for applications with unsafe wakeup handlers can be to link with the reentrant version of the library -lrtr_r because different rules apply for wakeups in a thread: applications should not call anything that is not thread-safe, or anything that might block indefinitely, such as rtr_send_to_server, rtr_reply_to_client, rtr_broadcast_event, or rtr_receive_message with a non-zero timeout. o 14-3-218 Microsoft Visual C compiler options /Gz (stdcall) and /Gr (fastcall) supported The RTR API functions in are now declared with the __cdecl attribute so they can be used in applications compiled with calling conventions other than the /Gd (cdecl) default. o 14-3-250 Flow control has -ve credit Applications with multiple channels engaged on more than one facility could experience flow control difficulties causing indefinite delays in transaction completion. This has been corrected. o 14-3-253 Restrictions on the RTR wakeup handler The use of rtr_reply_to_client, rtr_send_to_server, or rtr_broadcast_event in an RTR wakeup handler is not recommended. They may block when they need transaction ids or flow control. This will cause undesired behavior. Functions permitted in an rtr_set_wakeup() handler: In an RTR wakeup handler in an AST in an unthreaded OpenVMS application, the use of rtr_reply_to_client(), rtr_send_to_server(), rtr_broadcast_event(), or rtr_receive_message() with a non-zero timeout is not recommended. They may block when they need transaction ids or flow control, which will cause the whole application to hang until the wakeup completes. In an RTR wakeup handler in a threaded application the same rules apply. Note that wakeups are unnecessary in a threaded paradigm, but they may be used in common code in applications that also need to run on OpenVMS. Please note that your mainline code continues to run while your wakeup is executing, so extra synchronization may be required. Also note that if the wakeup does block then it does not generally hang the whole application. In an RTR wakeup handler in a signal in an unthreaded UNIX application, no RTR API functions and only the very few asynch-safe system and library functions may be called, because the wakeup is performed in a signal handler context. An application can write to a pipe or access a volatile sig_atomic_t variable, but using malloc() and printf(), for example, will cause unexpected failures. Alternatively, on most UNIX platforms, you can compile and link the application as a threaded application with the reentrant RTR shared library -lrtr_r. For maximum portability the wakeup handler should do the minimum necessary to wake up the mainline event loop. You should assume that mainline code and other threads might continue to run in parallel with the wakeup, especially on machines with more than one CPU. o 14-3-255 Multiple broadcast or data received on wrong channel When running W95/NT with Pathworks installed, RTR would not detect that the client had closed its channel when the client application was aborted by closing the window. RTR now detects when the client has aborted the channel and closes the channel. o 14-3-258 Stop inquorate standby from going active When there is a network segmentation in an active/standby configuration, the segment in the minority would become active. This behavior resulted in two active servers for the same partition. RTR now puts the inquorate or minority server in wt_quorum state and the majority server in active state. o 14-8-185 o 14-3-259 Slow or hanging applications using large messages and discarded broadcasts The threshold for flow control has been increased from 100000 to 1000000, and can also now be changed by defining the environment variable RTR_MAX_CHANNEL_WAITQ_BYTES to e.g. 10000000 when starting the ACP. When too many data bytes are queued to be sent to a destination process then the flow control feature is activated. The sender application may then be forced to wait for a while in the next api call that sends data, or broadcasts may be discarded, until the queue reduces and flow control credit is freely granted again. You should increase this parameter if your application sends large broadcasts or sends or replies with large amounts of data per transaction. Because broadcasts are subject to discarding you should not use them to send large amounts of data reliably. You may wish to consider using a sequence number and providing a read-only transaction in your application to detect and request re-transmission of any discarded broadcast data. There is also a hard limit parameter with the default 100000000 (10^8). The channel will be closed immediately if the send wait queue exceeds this. These tunable flow control parameters are provisional and subject to change. o 14-3-265 Successive ACP crashes Reception of a corrupt network message could cause a failed assertion and demise of the RTR ACP process. The behavior has been changed to yield a log file entry (BADNETMSG), followed by a reset of the link concerned. If such log file entries persist for a particular pair of nodes, it may mean that a network problem exists, and you should consider checking the network hardware for correct operation. The RTR KNL subsystem log entry has also been improved to better identify the link on which it reports errors. o 14-3-272 RTR no longer disables the TCP/IP Nagle algorithm with TCP_NODELAY The TCP_NODELAY option which disables the Nagle algorithm was previously enabled on all RTR platforms except Solaris. This change improves network throughput under load. Response time may be slightly longer under some conditions. The option can be activated by defining the environment variable RTR_TCP_NODELAY. This restores the old behavior on most platforms. o 14-3-274 Opening channel for non-existent facility causes crash An uninitialized variable caused this crash which was seen in recent Field Test kits (214) and (218) for AIX and Solaris. This has been corrected. o 14-3-275 aio not available makes RTR fail with unresolved errors for kaio_rdrw etc. RTR for AIX exploits Asynchronous I/O for increased journal performance. By default, aio is only `defined', i.e., disabled, instead of `available'. Aio can be configured with the system management tool: # smit aio. The RTR installation procedure post_i script now makes aio available, and ensures that aio will also be available after a restart. o 14-3-276 SHOW TRANSACTION on FE after current TR trimmed and before FE reconnected causes ACP dump Executing the command RTR SHOW TRANS on a frontend immediately after trimming the current router from the facility could infrequently cause the ACP to crash. This has been corrected. o 14-8-173 o 14-3-282 Dual ported TCP router not establishing facility links" Problems can arise if nodes in your configuration have multiple network adapters and the IP name server is not configured to return all the configured IP addresses for such nodes. This results in such nodes replying to connection requests with an ID that is different to that determined by the initiator of the connection. This can result in refused connections, or only the first connecting facility to gain a current router. This version of RTR has been changed to operate correctly in such a partially configured environment. o 14-3-283 Image identification shows previous rtr version Some versions of the OpenVMS/VAX kit for RTR V3.1D ECO10 were shipped with a shared library showing an incorrect version ID. This has now been corrected. o 14-3-285 OpenVMS process quotas artificially constained Prior versions of RTR would limit the maximum values that could be specified for the ACP process quotas to 64K. This restriction has been removed. Warning messages are generated if the requested quotas conflict with the system wide WSMAX parameter, of the remaining free page file space. o 14-3-82 Requester hangs in SYS$COMMIT_TXW with RTR V3.1D - null txn If rtr_start_tx() was called by a client followed immediately by rtr_accept_tx(), then the application would hang (unless rtr_start_tx() was called with a timeout). This has been corrected. The status returned in the rtr_mt_accepted data in such cases is RTR_STS_SYNCHCOMM (transaction committed synchronously). This also corrects the equivalent problem with the RTR V2 API. Also, the status returned in the TXSB for such transactions using the V2 API is RTR$_SYNCHCOMM. o 14-8-128 The RTR ACP now uses an asynchronous method when closing its links This version of RTR will defer the deassigning of its network channels during the closesocket routine. This change allows RTR to handle other requests while the channels are being run-down. RTR no longer appears to pause while a network link is being deassigned. o 14-8-131 Failure to come up in remember mode The non-availability of a remote journal at shadow recovery time will cause a partition that was previously processing in remember mode to resume processing in that mode. Prior versions of RTR would set the partition state to 'shawdow-recovery-fail', and transactions could not be processed until the configuration was manually corrected. o 14-8-144 When disconnected the ASYNC cable from the client, the RTR dump was generated on the client." Disconnecting a cable that was being used by an asynchronous DECnet link to a remote machine could cause 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 RTR Router Crash Router ACPs configured to accept anonymous clients could fail when handling a network link loss event. This has been corrected. o 14-8-162 Hanging servers Transaction recovery as a result of server failover could result in server applications getting hung in 'local recovery' state if it also happened that more than 10 client channels had simultaneously caused new transactions to be presented to the backend node. This has been fixed both by increasing the limit to 50 and by adding a check to make sure that recovery is complete before enforcing the limit, which is designed to keep a backend node from getting overwhelmed when transactions are coming in at a rate faster than it can handle. o 14-8-175 RTRACP core dump while idle When a Frontend node is trimmed from a Frontend/Router Facility Definition, the Facility Descriptor block is not fully deleted. This causes a core dump when RTR attempts to verify the facility after a network link loss. RTR now properly deletes the Facility Descriptor Block associated with the trimmed frontend. o 14-8-181 RTRACP Crashes It was possible that RTR on a frontend could select a router as it's current router immediately after that router had been trimmed from the facility. This could potentially leave the frontend in a 'connecting' state. This has now been corrected. 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. INSTALLATION NOTES: Please refer to the Installation Guide supplied with previous versions. Note that this kit runs only on Intel processors. The installation is the same for both Windows NT and Windows 95. From an empty directory, run the self-extracting RTRI231.EXE. Then run SETUP.EXE to install RTRI231. All trademarks are the property of their respective owners.



This patch can be found at any of these sites:

Colorado Site
Georgia Site



Files on this server are as follows:

rtri231.README
rtri231.CHKSUM
rtri231.CVRLET_TXT
rtri231.exe
rtri231.CVRLET_TXT

privacy and legal statement