Recovering units of recovery on another queue manager in the queue-sharing group

If a queue manager that is a member of a queue-sharing group fails and cannot be restarted, other queue managers in the group can perform peer recovery, and take over from it. However, the queue manager might have in-doubt units of recovery that cannot be resolved by peer recovery because the final disposition of that unit of recovery is known only to the failed queue manager. These units of recovery will be resolved when the queue manager is eventually restarted, but until then, they remain in doubt.

This means that certain resources (for example, messages) might be locked, making them unavailable to other queue managers in the group. In this situation, we can use the DISPLAY THREAD command to display these units of work on the inactive queue manager. If you want to resolve these units of recovery manually to make the messages available to other queue managers in the group, we can use the RESOLVE INDOUBT command.

When you issue the DISPLAY THREAD command to display units of recovery that are in doubt, we can use the QMNAME keyword to specify the name of the inactive queue manager. For example, if you issue the following command:

+CSQ1 DISPLAY THREAD(*) TYPE(INDOUBT) QMNAME(QM01) 

You receive the following messages:

CSQV436I +CSQ1 INDOUBT THREADS FOR QM01 -
NAME     THREAD-XREF        URID  NID
USER1    000000000000000000000000 CSQ:0001.0
USER2    000000000000000000000000 CSQ:0002.0
 DISPLAY THREAD REPORT COMPLETE

If the queue manager specified is active, WebSphere MQ does not return information about in-doubt threads, but issues the following message:

CSQV435I CANNOT USE QMNAME KEYWORD, QM01 IS ACTIVE

Use the WebSphere MQ command RESOLVE INDOUBT to resolve the in-doubt threads manually. Use the QMNAME keyword to specify the name of the inactive queue manager in the command.

This command can be used to commit or back out the unit of recovery. The command resolves the shared portion of the unit of recovery only; any local messages are unaffected and remain locked until the queue manager restarts, or reconnects to CICS, IMS, or RRS batch.