Compaq AA-Q88CE-TE manual RTR log messages E-11

RTR log messages

%RTR-F-QIROVERFLOW, No more QIRs left

Explanation: This status is used to indicate an inadequacy in the static reservations for the internal query initiation descriptors. Make a note of all QRM counters using SHOW RTR /COUNTER=QRM* Send SPR with the corresponding RTRACP dump.

%RTR-F-RAEOVERFLOW, No more RAEs

Explanation: This status is used to indicate an inadequacy in the static reservations for the internal response acceptor elements. Make a note of all QRM counters using SHOW RTR /COUNTER=QRM* Send SPR with the corresponding RTRACP dump.

%RTR-F-RDEOVERFLOW, RDE table has overflowed

Explanation: This status is used to indicate an inadequacy in the static reservations for the internal response dispatch elements. Make a note of all QRM counters using SHOW RTR /COUNTER=QRM* Send SPR with the corresponding RTRACP dump.

%RTR-E-REQDIED, Client exited, incomplete transaction aborted

Explanation: Indicates that a client exited before completing a transaction.

%RTR-E-REQDIEDPREP, Client exited after calling rtr_prepare_tx, transaction unresolved

Explanation: Indicates that a client exited after preparing a transaction.

%RTR-E-REQDIEDVOT, Client exited after issuing rtr_accept_tx, awaiting transaction result

Explanation: Indicates that a client died after accepting, but before completion of a transaction.

%RTR-W-ROLESMISMATCH, Node role definitions do not match for this facility

Explanation: The facility exists, but the definition of the role for the remote node is not the same as the one in the local node. The system manager has probably incorrectly defined the facilities on the two nodes concerned.

%RTR-E-ROUTERUNAVAILTMO, FE discarded transaction due to router unavailability timeout

Explanation: In rare circumstances, a transaction can be aborted by an RTR frontend with the status RTR_STS_ROUTERUNAVAILTMO. This can occur if an RTR client application has accepted the transaction, but the link to the router is lost before the RTR frontend has received a response from the router. If no RTR router becomes available for more than 8 minutes, then the transaction will be aborted by the frontend. This is to prevent the transaction being duplicated by RTR, since the router will unanimously decide the outcome of accepted transactions that have lost their frontends after about

10 minutes. The correct procedure in this case is for the client application to check whether the transaction has been completed once the link to a router is re-established.

%RTR-I-RQEQUALS, Transaction client was [A] on node [A]

Explanation: Displays the process name of the client [A] and its node address [B] in messages relating to transactions.

RTR log messages E–11