In the XCF Activity Report shown in Figure 1, the “REQ
REJECT” columns under “OUTBOUND FROM sysname” and under “LOCAL”
indicate the number of times a request to send a message was rejected
because XCF could not obtain a message buffer. This count is presented
for each remote system, by transport class.
Note that “REQ REJECT” can be incremented more than once
for a single message. Some multisystem applications might retry to
send a message one or more times before taking some other action (such
as setting a timer to retry later). Thus, REQ REJECT reflects the
number of attempts to send one or more messages without success.
If outbound messages are being rejected,
- Check the corresponding inbound path at the receiving system.
If that system is periodically non-operational, it can cause messages
to back up on the outbound path of the sending system. To resolve
the problem, you can reduce these outages on the receiving system
or increase the message buffer space to allow the messages to be accepted
for delivery during these non-operational periods.
- Use the XCF Activity Report shown in Figure 2, to
see if any of the members in the groups using the transport class
have had an unusually high number of send message requests. This might
indicate that an error condition is causing the members of that group
to generate too many messages. Or perhaps the workload that the group
must process simply requires a large number of messages. Resolving
the error condition, changing the workload, or providing additional
message buffer space are possible solutions.
- Look at RMF™ reports for the remote system to determine
if that system was experiencing inbound message buffer constraints.
Such constraints could cause delays in receiving messages and therefore
cause outbound messages to back up.
- For local message traffic, message request rejections are most
likely due to a runaway sender, delays in receiving messages (such
as scheduling delays), or simply not enough space.