Redpaper - IBM Redbooks

In this instance, you should consider incorporating a policy for “cleaning up”
these messages.
One aspect of the availability of messages on shared queues which you should
consider is the effect of using a two-phase commit. For example, consider a unit
of work which retrieves a message from a shared queue, updates a DB2 table
based on the contents of the message, and returns a response to a shared
queue. A 2pc protocol is used to ensure that either all or none of the processing
happens, typically coordinated by Resource Recovery Services (RRS). If the
queue manager where this unit of work is running were to fail during the
two-phase commit, it is possible that the unit of work would be left indoubt in
WebSphere MQ.
In this case, the correct resolution of the unit of work cannot be determined until
the queue manager is restarted and can reconnect with RRS. It is therefore not
possible for the other queue managers to perform peer recovery for this unit of
work (this means, the input message cannot be rolled back by a peer for
processing via a different queue manager which has an impact on the availability
of the messages consumed and produced by that indoubt unit of work). The
availability of other messages on the shared queue is not impacted unless
serialization tokens are being used to ensure an ordering of processing
messages on this queue. This is further explained in WebSphere MQ for z/OS
System Administration Guide V5.3.1, SC34-6053-01.
Note: When messages are put to a shared queue, the data is logged on a
particular queue manager, but that process does not cause any kind of
message affinity to a queue manager. The affinity is between a unit of work
and a queue manager.
Table 2-3 outlines the issues you should consider when looking at shared queues
to support a highly available environment.
Table 2-3 Advantages and disadvantages of using WebSphere MQ shared queues
Advantages Disadvantages
Resilient support of HA over multiple
LPARs. Should a queue manager or a
Message Broker fail, other brokers
continue to retrieve messages.
Maximum message size of 63 KB. Even if
a current system does not have messages
of that size or above, it places a restriction
on the natural growth of the system.
However, this restriction is increased to
100 MB in the next release of WebSphere
MQ by further using DB2.
16 High Availability z/OS Solutions for WebSphere Business Integration Message Broker V5