WebSphere MQ-IMS bridge, not on queue, message, connection to WebSphere MQ, OTMA, value of, CURDEPTH, message flow, IMS" /> Finding messages sent to the WebSphere MQ-IMS bridge

 

Finding messages sent to the WebSphere MQ-IMS bridge

If you are using the WebSphere MQ-IMS bridge, and your message has not arrived as expected, consider the following:

Is the WebSphere MQ-IMS bridge running?

Issue the following command for the bridge queue:

DISPLAY QSTATUS (qname) IPPROCS CURDEPTH

The value of IPPROCS should be 1; if it is 0, check the following:

  • Is the queue a bridge queue?

  • Is IMS running?

  • Has OTMA been started?

  • Is WebSphere MQ connected to OTMA?
    Note:
    There are two WebSphere MQ messages that we can use to establish whether you have a connection to OTMA. If message CSQ2010I is present in the joblog of the task, but message CSQ2011I is not present, WebSphere MQ is connected to OTMA. This message also tells you to which WebSphere MQ system OTMA is connected. For more information about the content of these messages, refer to the WebSphere MQ Application Programming Reference manual.

If OTMA is running, the value for CURDEPTH should be 0 because the WebSphere MQ-IMS bridge removes the messages as soon as they arrive on the queue. If the CURDEPTH is greater than 0, check for error messages in the WebSphere MQ job log.

Use the IMS command

/DIS OTMA to check that OTMA is active.

If your messages are flowing to IMS, check the following:

  • Use the IMS command

    /DIS TMEMBER client TPIPE ALL to display information about IMS Tpipes. From this we can determine the number of messages enqueued on, and dequeued from, each Tpipe. (Commit mode 1 messages are not usually queued on a Tpipe.)

  • Use the IMS command

    /DIS A to show whether there is a dependent region available for the IMS transaction to run in.

  • Use the IMS command

    /DIS TRAN trancode to show the number of messages queued for a transaction.

  • Use the IMS command

    /DIS PROG progname to show if a program has been stopped.

Was the reply message sent to the correct place?

Issue the following command:

DISPLAY QSTATUS (*) CURDEPTH

Does the CURDEPTH indicate that there is a reply on a queue that you are not expecting?