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

Use this topic to identify, and manually recover units of recovery on other queue managers in a 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 are 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. To resolve these units of recovery manually to make the messages available to other queue managers in the group, you can use the RESOLVE INDOUBT command.

When we 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 we 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, IBM MQ does not return information about in-doubt threads, but issues the following message:

CSQV435I CANNOT USE QMNAME KEYWORD, QM01 IS ACTIVE

Use the IBM 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.

Parent topic: Recovering units of work manually