WebSphere Message Brokers
File: ae27020_
Writer: Bill Oppenheimer

Concept topic

This build: July 31, 2007 21:28:52

Serialization of input between separate execution groups running on the same broker on z/OS

This example demonstrates that only one MQInput node at a time is allowed to take messages from a shared queue when the same serialization token is used by message flows running in separate execution groups on the same broker.

An identical message flow MyFlowA is deployed to two execution groups called MYGroupA and MYGroupB on broker MQ01BRK.

In this case it is not a requirement that the queue manager participates in a queue sharing group. The input queue INQueue is defined as local with disposition QMGR.

As in Serialization of input between separate brokers on z/OS:
Illustration showing multiple execution groups in the same broker
A typical sequence of events for this example follows:
  1. Broker MQ01BRK starts and the first message flow to begin is MyFlowA in execution group MyGroupA. The MQInput node MyInputNode connects to queue manager MQ01 using the serialization token MyToken123ABC. The MQInput node successfully opens shared queue INQUeue and gets input messages.
  2. The second execution group MyGroupB starts and message flow MyFlowA in execution group MyGroupB begins. The MQInput node MyInputNode now attempts to connect to queue manager MQ01 using serialization token MyToken123ABC. The following SDSF console message is logged:
     BIP2656I MQ01BRK MyGroupB 11 UNABLE TO OPEN QUEUE
     'INQueue' ON WEBSPHERE BUSINESS INTEGRATION QUEUE 
     MANAGER 'MQ01':  BECAUSE SERIALIZATION TOKEN  
     MyToken123ABC is already in use. NO USER ACTION REQUIRED

    Message flow MyFlowA in execution group MyGroupB is unable to process input because the serialization token it has passed is already in use within the queue manager (by the MQInput node in message flow MyFlowA in execution group MyGroupA). This is indicated by the reason code 2271 (MQRC_CONN_TAG_IN_USE) in message bip2623.

  3. The first execution group is deleted or cancelled.

    If the first execution group is cancelled by the operator, abends, or is deleted during a redeployment of the broker configuration, then the input node in the second execution group is now able to get input messages from queue INQueue.

    A sequence of SDSF console messages is logged, of which the following one is relevant:
      BIP2091I MQ01BRK MyGroupB 11 THE BROKER HAS 
     RECONNECTED TO WEBSPHERE BUSINESS INTEGRATION 
     SUCCESSFULLY : ImbCommonInputNode(785)               

Message flow MyFlowA in execution group MyGroupB is now able to recover processing of messages from the shared queue INQueue.QSG.

Note that, although serialization of input can be achieved in a similar manner by configuring the input queue for exclusive input, this does not ensure message integrity during a recovery situation. This can be achieved only through the use of the serialization token as described in this example.

Related concepts
z/OS customization overview
Overview of message serialization on z/OS
Serialization of input between separate brokers on z/OS
Serialization of input within an execution group on z/OS
Notices | Trademarks | Downloads | Library | Support | Feedback

Copyright IBM Corporation 1999, 2007Copyright IBM Corporation 1999, 2007. All Rights Reserved.
This build: July 31, 2007 21:28:52

ae27020_ This topic's URL is: