Finding messages sent to the IBM MQ - IMS bridge

Use this topic to understand possible causes for missing messages sent to the IBM MQ - IMS bridge.

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

    Is the IBM 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 IBM MQ connected to OTMA? Note: There are two IBM MQ messages used to establish whether you have a connection to OTMA. If message CSQ2010I is present in the job log of the task, but message CSQ2011I is not present, IBM MQ is connected to OTMA. This message also tells you to which IBM MQ system OTMA is connected. For more information about the content of these messages, see IBM MQ for z/OS messages, completion, and reason codes.

    Within the queue manager there is a task processing each IMS bridge queue. This task gets from the queue, sends the request to IMS, and then does a commit. If persistent messages are used, then the commit requires disk I/O and so the process takes longer than for non-persistent messages. The time to process the get, send, and commit, limits the rate at which the task can process messages. If the task can keep up with the workload then the current depth is close to zero. If we find that the current depth is often greater than zero you might be able to increase throughput by using two queues instead of one.

    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 we are not expecting?

Parent topic: Dealing with incorrect output on z/OS