Filter
Top Products
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