resynchronizing with WebSphere MQ, shared channels after DB2 failure" /> A DB2 system fails

 

A DB2 system fails

If a DB2 subsystem that WebSphere MQ is connected to fails, WebSphere MQ attempts to reconnect to the subsystem and continue working. If you specified a DB2 group attach name in the QSGDATA parameter of the CSQ6SYSP system parameter module, WebSphere MQ reconnects to another active DB2 that is a member of the same data-sharing group as the failed DB2, if one is available on the same z/OS image.

There are some queue manager operations that do not work while WebSphere MQ is not connected to DB2. These are:

Other WebSphere MQ API operations continue to function as normal for shared queues, and all WebSphere MQ operations can be performed against the queue manager private versions (COPY objects) built from GROUP objects. Similarly, any shared channels that are running continue normally until they end or have an error, when they go into retry state.

When WebSphere MQ reconnects to DB2, resynchronization is performed between the queue manager and DB2. This involves notifying the queue manager of new objects that have been defined in DB2 while it was disconnected (other queue managers might have been able to continue working as normal on other z/OS images through other DB2 subsystems), and updating object attributes of shared queues that have changed in DB2. Any shared channels in retry state are recovered.

If a DB2 fails, it might have owned locks on DB2 resources at the time of failure. In some cases, this might make certain WebSphere MQ objects unavailable to other queue managers that are not otherwise affected. To resolve this, restart the failed DB2 so that it can perform recovery processing and release the locks.