- Check your message flow in the workbench.
You might have accidentally connected the MQInput node failure terminal
to a successive node instead of the out terminal. The out terminal is the middle terminal of the three. Messages directed
to an unconnected out terminal are discarded.
- If the out terminal of the MQInput node is correctly connected
to a successive node, check in the local error
log for
the broker for a message indicating that message processing has been terminated
due to problems. Additional messages give more detailed information.
If the failure terminal of the MQInput node has been connected, for
example, to an MQOutput node, these messages do not appear.
Connecting
a node to a failure terminal of any node indicates that you have designed
the message flow to deal with all error processing. If you connect a failure
terminal to an MQOutput node, your message flow ignores any errors that occur.
- If the out terminal of the MQInput node is correctly connected
to a successive node, and the local error
log does
not contain any error messages, turn user tracing on for the message flow:
- Switch to the Broker
Administration perspective.
- In the Domain view, select the message flow, and right-click. (You might
have to refresh the view by clicking on the Refresh icon.)
- Click .
See Using trace for more
information.
This action produces a user trace entry
from every node that the message visits, and only those nodes.
On the
distributed platforms, you can retrieve the trace entries using the mqsireadlog command,
format them using the mqsiformatlog command,
and view the formatted records to check the path of the message through the
message flow. See Commands for
more information about these commands.
For z/OS,
edit and submit the job BIPJLOG in the COMPONENTPDS to
execute mqsireadlog and mqsiformatlog to
process traces. See z/OS utility jobs for more information about the utility commands.
- If the user trace shows that the message isn't taking the path
through the message flow that you expect, increase the user trace level to
Debug by selecting the message flow, right-clicking on it, and clicking .
Send your message into the message flow again. Debug level trace
produces much more detail about why the message is taking the route that it
is taking, and you can then determine the reasons for the actions taken by
the message flow.
Don't forget to turn tracing off when you have solved
the problem, or performance will be adversely affected.
- If the MQPUT command to the output queue defined on the MQOutput
node is not successful (for example, the queue is full or put is disabled),
the final destination of a message depends on:
- Whether the failure terminal of the MQOutput node is connected.
- Whether the message is being processed transactionally (which in turn
depends on the transaction mode setting of the MQInput node, the MQOutput
node, and the input and output queues).
- Whether the message is persistent or nonpersistent (transaction mode=automatic
only). All messages are treated as persistent if transaction mode=yes, and
as nonpersistent if transaction mode=no.
In general:
- If a path is not defined for a failure (that is, neither the catch terminal
nor the failure terminal of the MQInput node is connected):
- Non-transactional messages are discarded.
- Transactional messages are rolled back to the input queue for retry.
- If the backout count of the message is less than the backout threshold
(BOTHRESH) of the input queue, the message is retried and re-sent to the out
terminal.
- When the backout count equals or exceeds the backout threshold, the message
is placed on the backout queue (identified by the BOQNAME attribute of the
input queue) if specified, or to the dead-letter queue if there is no backout
queue defined or the MQPUT to the backout queue fails. If the MQPUT to the
dead-letter queue fails, or there is no dead-letter queue defined, the message
flow loops continuously trying to put the message to the dead-letter queue.
- If a path is defined for the failure (if both the catch terminal and the
failure terminal are connected, the message is propagated through the catch
terminal), that path defines the destination of the message.
- If your message flow uses transaction mode=yes on the MQInput
node properties, and the messages are not appearing on an output queue, check
the path of the message flow.
If the message flow has paths
that are not failures, but that do not end in an output queue (or other persistent
store), the message flow has not failed and the message is not backed out,
or put to an alternative destination (for example, the catch terminal, the
dead-letter queue, or the queue's backout queue).
Check
that all possible paths reach a final output node and do not reach a dead
end. For example, check that:
- You have connected the unknown terminal of a Filter node to another node
in the message flow.
- You have connected both the true and false terminals of a Filter node
to another node in the message flow.