Display outstanding units of work with the dspmqtrn command

You can use the dspmqtrn command with the -i parameter to display internally originated indoubt transactions.

While a database manager is unavailable, we can use the dspmqtrn command to check the state of outstanding global units of work involving that database.

The dspmqtrn command displays only those units of work in which one or more participants are in doubt. The participants are awaiting the decision from the queue manager to commit or roll back the prepared updates.

For each of these global units of work, the state of each participant is displayed in the output from dspmqtrn. If the unit of work did not update the resources of a particular resource manager, it is not displayed.

With respect to an in-doubt unit of work, a resource manager is said to have done one of the following things:

    Prepared
    The resource manager is prepared to commit its updates.

    Committed
    The resource manager has committed its updates.

    Rolled-back
    The resource manager has rolled back its updates.

    Participated
    The resource manager is a participant, but has not prepared, committed, or rolled back its updates.

When the queue manager is restarted, it asks each database having an XAResourceManager stanza for a list of its in-doubt global units of work. If the database has not been restarted, or is otherwise unavailable, the queue manager cannot yet deliver to the database the final outcomes for those units of work. The outcome of the in-doubt units of work is delivered to the database at the first opportunity when the database is again available.

In this case, the database manager is reported as being in the prepared state until resynchronization has occurred.

Whenever the dspmqtrn command displays an in-doubt unit of work, it first lists all the possible resource managers that might be participating. These are allocated a unique identifier, RMId, which is used instead of the Name of the resource managers when reporting their state with respect to an in-doubt unit of work.

Sample dspmqtrn output shows the result of issuing the following command:
dspmqtrn -m MY_QMGR
Figure 1. Sample dspmqtrn output
AMQ7107: Resource manager 0 is MQSeries.
AMQ7107: Resource manager 1 is DB2 MQBankDB.
AMQ7107: Resource manager 2 is DB2 MQFeeDB.
 
AMQ7056: Transaction number 0,1.
    XID: formatID 5067085, gtrid_length 12, bqual_length 4
         gtrid [3291A5060000201374657374]
         bqual [00000001]
AMQ7105: Resource manager 0 has committed.
AMQ7104: Resource manager 1 has prepared.
AMQ7104: Resource manager 2 has prepared.

where Transaction number is the ID of the transaction which can be used with the rsvmqtrn command. See AMQ7xxx: IBM MQ product messages for further information. The XID variables are part of the X/Open XA Specification ; for the most up-to-date information about this specification see: https://publications.opengroup.org/c193.

The output in Sample dspmqtrn output shows that there are three resource managers associated with the queue manager. The first is resource manager 0, which is the queue manager itself. The other two resource manager instances are the MQBankDB and MQFeeDB Db2 databases.

The example shows only a single in-doubt unit of work. A message is issued for all three resource managers, which means that updates were made to the queue manager and both Db2 databases within the unit of work.

The updates made to the queue manager, resource manager 0, have been committed. The updates to the Db2 databases are in the prepared state, which means that Db2 must have become unavailable before it was called to commit the updates to the MQBankDB and MQFeeDB databases.

The in-doubt unit of work has an external identifier called an XID (transaction id). This is a piece of data given to Db2 by the queue manager to identify its portion of the global unit of work.

Parent topic: Considerations when contact is lost with the XA resource manager