Reliable Transaction Router
Release Notes

rtr> set facility FACILITY_NAME/REPLY_CHECKSUM

To turn off:

rtr> set facility FACILITY_NAME/NOREPLY_CHECKSUM

To view flag:

rtr> show facility FACILITY_NAME/CONFIG show facility FACILITY_NAME/FULL

Please notice the Reply Checksum: label in the following example. A yes value indicates that the "response matching feature" is enabled.

RTR> set facility miked/REPLY_CHECKSUM RTR> show facility miked/config Facilities: Facility: miked Configuration:- Frontend: yes Router: yes Backend: yes Reply Checksum: yes Router call-out: no Backend call-out: no Load balance: no Quorum-check off: no

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.

14-3-164 RTR_F_REP_INDEPENDENT flag needs to be specified even when superfluous
If the server channel has been opened with RTR_F_OPE_EXPLICIT_ACCEPT, then the RTR_F_REP_INDEPENDENT flag can only be used together with RTR_F_REP_ACCEPT.
If the server channel has been opened with implicit accept, then the use of RTR_F_REP_INDEPENDENT implies the use of RTR_F_REP_ACCEPT.

14-3-170 Terminal output is no longer unbuffered
On some platforms the output stream was unbuffered by default when bound to a terminal device (the normal case), and incurred a large number of buffered I/O operations. This was noticeably inefficient when using the Rtr command interface over certain kinds of packet-based network link. This problem has been resolved.

14-3-203 ACP crash when other nodes shutdown
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.

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 reestablished. This happened 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.

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 platform.

14-3-213 Facility names can be up to 30 characters
Although the FACNAMLON message states the facility name can only have 30 characters, prior versions of RTR V3 would allow the system manager to create facilities with names as long as 31 characters. It was however not possible to open channels to such facilities.
The documented maximum length of a facility name string is 30 characters. This limit is also now enforced by the 'create facility' command.
The application interface symbol RTR_MAX_FACNAM_LEN found in <rtr.h> still indicates a maximum length of 31 characters not including the string terminator at compile time, even though the system management interface in this release does not create such a facility. Applications should normally use rtr_open_channel() to check whether a facility name has valid length and characters, and has been created. This ensures that applications do not need to be recompiled should 31 character facilities be supported at runtime in a future release.

14-3-215 Rows dropped in monitor display with large # of rows
RTR will now display up to over 1000 rows, provided the values for the /ROWS qualifiers in the relevant *.mon file are edited.
This is most easily verified by redirecting the output to a file or pipe. If the output goes to a terminal, then you can use the SCROLL commands which are bound to various numeric keypad keys to scroll all except the last line of monitor output.

14-3-219 Unthreaded applications received repeated wakeups before next RTR API call
RTR now suppresses additional signal-based wakeups after the first until the next RTR API call. This caused a problem for an application that issued a write() to a pipe in the wakeup handler without first checking a flag to see if a read() had occurred since the last wakeup. The pipe could fill while the application was too busy to select on it and read it until empty, at which point the next write() would block and hang the application in the signal-based wakeup handler. This has been corrected.

14-3-224 ACP crash in 1 node config
RTR was aborting if it detected a length mismatch in the message passed to it. RTR has now been changed so that if this condition is detected, diagnostic information is written to the operator log and the link disconnected. RTR will not abort.

14-3-226 ACP crash, ncf_validate_fdbptr
After a facility is deleted, the RTR ACP can receive a message from an application that references the deleted facility. Verification that the facility had been deleted failed (rarely) causing the RTR ACP to abort. This has been corrected.

14-3-229 tx replay after reboot
If there is an error deleting records from the RTR journal, an error is logged. Previously, RTR would continue without logging the error.

14-3-239 Virtual address space full
RTR tries to extend the virtual address space of the ACP if there is insufficient space to allocate data structures when a client or server application is started. If the ACP failed to do this, it would crash. This has now been corrected. Any such failure will simply prevent the new application from starting rather than crashing the ACP.

14-3-241 Application crash trying to send large messages to unresponsive ACP
An application that is unable to send to the ACP due to resource shortage, for example if the ACP is alive but no longer receiving for whatever reason, now keeps trying indefinitely, and will now appear to hang rather than crash.

14-3-250 Flow control has negative 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.

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.

14-3-261 Assertion in knl_net_compare_ids() from ncf_accept_ast2()
Corruption of network messages passed during the link connect phase could cause failure of the receiving RTR ACP process. This has been corrected.

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.

14-3-266 ACP crash apparently caused by word shear of a packet.
Reception of an illegal or unrecognizable broadcast now causes a log file entry (BMHDRVSN) rather than demise of the ACP process. If such entries persist you may wish to consider checking the network for correct operation.

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 causes such nodes to reply to connection requests with an ID that is different from that determined by the initiator of the connection. This can cause refused connections, or only the first connecting facility gaining a current router.
This version of RTR has been changed to operate correctly in this partially configured environment.
It is also now possible to provide RTR with full configuration information about hosts with multiple adapaters through alias entries in the host's database. Provide alias entries corresponding to the alternate interface addresses, and refer to these aliases when defining the primary entry. If using a host's file on UNIX, the alias entries should be defined prior to any references to them.

14-3-289 TR failback imperfect
The implementation of frontend router failback has been improved. Frontend nodes are now more likely to maintain conections with their preferred routers. On systems with multiple similarly configured facilities, this will reduce the number of networks links required and consequently resource consumption will be lowered.

14-5-69 Journal record version control
V3.2 of RTR implements some changes in the format of records in the journal. Rolling upgrades from earlier versions of RTR V3 are handled automatically, except for clustered nodes operating standby servers - these configurations must be upgraded simultaneously.
Records written by RTR V3.2 cannot be used by earlier versions of RTR, so when installing an older version of RTR over RTR V3.2 you must create a new journal.

14-5-82 Update SHOW NODE to display inactivity timer
The format of the SHOW NODE command has been changed to include a display of the current inactivity timer setting for the node.

14-5-129 Improvements to netstat and connects monitor pictures
The Monitor Connects and Monitor Netstat pictures now include information in their summary sections indicating if all required links are connected or not.

14-7-751 Error handling for RTR_PREF_PROT violations
Additional checks have been implemented at facility creation time to check for and report on the absence of any specified transports, 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.

14-8-131 Failure to come up in remember mode
When a node in remember mode fails during recovery, it will return to remember mode. Previously a node in remember mode would undergo local shadow recovery, then shadow recovery failure, when it could not access the journal of the secondary node. RTR now knows that it was in remember mode during its recovery process and if the secondary is not available, it will return to remember mode.

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 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.

14-8-162 RTRACP (V3.1C) backend crash
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.

14-8-181 RTR ACP Crashes
RTR on a frontend could select a router as its current router immediately after that router had been trimmed from the facility. This could potentially leave the frontend in a 'connecting' state. This has been corrected.

14-8-199 Large monitor screen last line overwritten
In previous versions, RTR generated lines which were off the bottom of the physical screen. Most screens moved as far as they could to the last line when told to move off the bottom, so that you saw the last line and all subsequent lines superimposed on the bottom line. Usually the last line in the monitor file covered the others completely because none of the other lines were longer. This problem has been corrected.

14-8-204 Inquorate router could cause backend ACP failure
In previous versions of RTR, an inquorate router could send messages to backends informing them to change state at the same time that one or more quorate routers were asking them to change to or remain in a different state. In certain situations when network links are unreliable, this could sometimes cause a buildup of messages in the RTR ACP process on the backend node that caused it to fail due to lack of memory.
This problem has been corrected by not allowing an inquorate router to send state update messages to backends.

14-8-207 Concurrent timer cancellation could cause data corruption
Internal RTR data could get corrupted when timers for the same events were scheduled concurrently (within the same 1 second time slice). This should have occurred only under unusual circumstances or when RTR is consistently denied access to resources due to privilege constraints. RTR has been corrected to avoid this occurrence even under extreme circumstances.

14-8-214 Potential distributed loop
It was possible for a distributed loop to occur between a backend and two or more routers. The problem occurred when one router suggested the backend go into active mode, but another suggested standby. When the backend accepted the standby suggestion, it entered standby mode and broadcast its decision to the routers. This occurred regardless of whether the backend was already in standby mode (and therefore had already broadcast its status to the routers) or not. The routers would then respond to the backend with their suggestions.
RTR now does not broadcast when a standby-to-standby transition occurs, as the routers will have already been informed of the backend's status.

1.3 Known Problems with Workarounds

14-1-293 Incorrect values for /BLOCKS and /MAXIMUM_BLOCKS
RTR does not reject incorrect values for /BLOCKS and /MAXIMUM_BLOCKS of the CREATE JOURNAL or MODIFY JOURNAL commands.
The workaround is to use values less than 524280 for these qualifiers.
14-1-419 SPUJOUFIL advice to CREATE JOURNAL/SUPERSEDE is dangerous
If the operator copies journal files or copies disks containing journal files without first remounting the source disk read-only, then these are SPURIOUS because RTR sees duplicates that it did not create. RTR then displays the SPUJOUFIL message, which advises the operator to use CREATE JOURNAL/SUPERSEDE to destroy the original and all copies of the journal files, and all the transactions contained in them on that node, and then submit an SPR for something that is not in fact an RTR problem.
This is not the correct action in situations like this.
The operator should examine the log file, which shows the duplicate filenames, and then move any unwanted duplicate copies of journal files to anywhere *other* than a rtrjnl directory at the top level of a writable disk file system visible to RTR, and then try again.
Only if SPUJOUFIL is caused by circumstances other than operator intervention should the operator consider making backup copies of the journal files, and only then abandoning the existing journal files and any transactions contained in them by using DELETE JOURNAL and CREATE JOURNAL, or the equivalent CREATE JOURNAL/SUPERSEDE.
14-1-455 Last line of batch procedure sometimes ignored.
The last line of a batch procedure or command file must explicitly end with <CRLF> added by pressing the Enter/Return key when creating the procedure. Without the explicit <CRLF>, RTR ignores the line. The workaround is to add a comment to the end of the file or to explicitly add <CRLF> to the end of the last line of the batch procedure.
14-1-462 MODIFY JOURNAL with list of devices does not give individual error messages
Although it now only lists all devices that were *successfully* modified, if some disk devices cannot be modified because they do not contain a journal file at all, then nothing at all is reported for those devices.
Workaround: identify the omitted devices by comparing the command parameters and the messages, or modify them one device at a time. Verify the modification with SHOW JOURNAL /FILES /FULL.
14-1-471 Refused network connect attempts on Windows
Network connection attempts over DECnet that get explicitly refused are not handled on Windows platforms until RTR times them out. This may make failover operations slower than required for some applications. If this is the case, the timeout period can be reduced by specifying revised values using the following environment variables:
RTR_TIMEOUT_CONNECT (default 60 s, minimum 5 s) RTR_TIMEOUT_CONNECT_RELAX (default 90 s, minimum 1 s)
Failover processing occurs after the combined values of these timers has elapsed.
14-1-641 Servers stuck in "local_recovery_fail" state
In RTR, because of the way a node shares a common journal file for all facilities on that node, if a node is configured as a backend for a given facility but is not started on that node, then servers on other nodes can get stuck in "local_recovery_fail" state. The workaround is to issue a SET PARTITION xxxx/IGNORE_RECOVERY command to get the server going.
14-3-207 Client application in questionable flow control when RTR journal fills
There is a known issue with flow control when the journal starts filling up. There is a race condition where, if the client can send more data than can be placed in the journal before flow control kicks in, then the transaction is aborted with the correct error notification. However, if flow control kicks in first, then a deadlock occurs where the journal space never frees up and hence RTR does not allow the client to proceed with the transaction. There are two workarounds: either specify a timeout with the transaction, or increase the size of the journal.

1.4 Restrictions

14-1-103 Using rtr_set_wakeup() in a threaded program
After calling rtr_set_wakeup() in a threaded program, you should also call rtr_set_wakeup(NULL) wherever your program can exit. This will prevent any wakeups in other threads while the main thread is already running the RTR exit handler, which could lead to a server core dump when trying to stop the server.
14-1-263 Non-English character sets are not supported for identifiers
The supported character set for RTR identifiers such as facility names is ASCII, with lowercase and uppercase letters equivalent.
Eight bit characters are not supported because the name might not interoperate with RTR processes using a different locale or running another RTR version.
14-3-33 Partition per facility now 500
The previous releases supported only up to 100 partitions per facility. The current release augments this to 500 but is not extendable beyond that.
14-3-74 RTR use with multi-homed hosts
When using the current version of RTR on multi-homed hosts (hosts with more than one network interface) care must be taken that the gethostbyname function returns a list of all the possible network addresses for the host. Otherwise RTR may not be able to recognise the host and will reject connections. Using a properly configured DNS will return the address list. Using the /etc/hosts file will not return the list of addresses.
If a tunnel separates the FEs from the TRs, then the FEs need to be configured on the TRs with the names coresponding to the pseudoadapter addresses assigned by the tunnel. If these are unpredicatable wild cards can be used on the routers.
If the tunnel separates the TR and BE nodes, configure each with respect to the other with the name prefix "tunnel."
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.
- The same rules apply in an RTR wakeup handler in a threaded application. 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.
14-5-86 RTR gives no warning when started with logging disabled
Compaq recommends that you use RTR SET LOG to enable logging before starting RTR. Important messages are only written to the log file and are lost forever if logging is not enabled.
As with any log file, the RTR log will grow with time. Log files should be located on a disk or file system where they will not interfere with operation. Should the log file become too big, you can start a new log file, and archive, compress or delete the old one.
14-7-24 Transaction size limits
The number of bytes in any application message (that is, a message sent with the rtr_send_to_server(), rtr_reply_to_client() or rtr_broadcast_event() outines) is currently restricted to 64000.
The number of messages sent (that is, using rtr_send_to_server()) in any single transaction is limited to 65534.
There is no fixed limit on the number of replies (that is, sent with rtr_reply_to_client() in any single transaction.
14-7-112 Restrictions on MODIFY JOURNAL command
MODIFY JOURNAL command now works (with some care).
It is no longer necessary to use DISCONNECT SERVER after MODIFY JOURNAL to commit the change, but use the SHOW JOURNAL /FULL /FILE command to verify that journal sizes have been modified as intended.
The MODIFY JOURNAL command incorrectly reports success even if there is no journal on the specified device(s).
RTR-S-JOURNALMOD should be taken to mean that any journals that have been found on the specified device(s) have been modified.
Note that the Disk name shown by SHOW JOURNAL is not updated when journals are moved physically, or if they are indirectly located using symbolic links, virtual drives or mounts.
14-8-149 Scrolling MONITOR and SHOW output
MONITOR operates in page mode, and can be scrolled. See RTR HELP SCROLL and RTR SHOW KEY/ALL for details.
There are currently no visual clues that lines are omitted or scrolled. The number of MONITOR rows is in fact limited by the /ROWS=50 qualifier in most of the *.mon files, and a hard-coded upper limit of 100 rows. The last row remains visible and is not scrolled with the rest. Unfortunately there is no workaround, because the 100 row page buffer applies even when the monitoring is redirected to a file with /OUTPUT or a pipe. These restrictions will be lifted in a forthcoming release.
SHOW produces text output which can be displayed in any suitable editor or scrolling window, or piped into a paging command such as 'more'. No scrolling or paging functionality for SHOW is planned within RTR.

Contents

Reliable Transaction RouterRelease Notes

1.3 Known Problems with Workarounds

1.4 Restrictions

Reliable Transaction Router
Release Notes