IC66904: MESSAGES DESTINED TO A CLUSTER QUEUE ON A REMOTE QMGR THAT INCLUDE AN RFH2 HEADER ARE RECEIVED WITHOUT THE RFH2.

WebSphere MQ V7.0.1 for i5/OS Fix Pack 7.0.1.3
WebSphere MQ V7.0 Fix Pack 7.0.1.3

APAR status

• Closed as program error.

Error description

• Messages destined to a cluster queue on a remote queue manager
  that include an RFH2 header are received without the RFH2
  headers. This occurs when the destination cluster queue manager
  is stopped while messages are in the transmission queue and then
  restarted.  Messages transmitted before stopping the remote
  cluster queue manager were received with a proper RFH2 header.
  However, the messages transmitted after the remote cluster queue
  manager restart do not contain the RFH2 header. Instead the
  messages are sent as MQSTR format.
  
  The trace of the channel pooling process for the CLUSSDR channel
  shows that the RFH2 headers in the message had been stripped off
  prior to sending it to the remote cluster queue manager.
  

Local fix

Problem summary

• ****************************************************************
  USERS AFFECTED:
  All users of WebSphere MQ v7 cluster queue managers.
  
  Platforms affected:
  All Distributed (iSeries, all Unix and Windows)
  ****************************************************************
  PROBLEM SUMMARY:
  When the destination cluster queue manager is stopped while the
  messages are still in the transmission queue, the cluster
  repository manager receives a message that the cluster channel
  failed. Due to this, it reallocates the messages associated with
  the failed channel. During this step, it destructively gets the
  message from the cluster transmit queue and does an MQPUT on the
  target queue. This causes the message to be reallocated to a
  working channel.
  
  Under the above step, while the message is being destructively
  read from the cluster transmit queue, the "MQGMO_NO_PROPERTIES"
  MQGMO option is used. This causes the message properties to be
  ignored upon MQGET. When this message is put on the target
  queue again, it does not contain any RFH2 properties.
  This is the reason why the messages transmitted after the
  destination cluster queue manager restart do not contain any
  RFH2 properties.
  
  The problem stems from the fact that the repository manager uses
  the MQGMO option "MQGMO_NO_PROPERTIES" while reallocating the
  messages.
  

Problem conclusion

• The MQGMO options used while reallocating messages were altered
  such that the message properties are now read by the destructive
  MQGET call.
  
  ---------------------------------------------------------------
  The fix is targeted for delivery in the following PTFs:
  
                     v7.0
  Platform           Fix Pack 7.0.1.3
  --------           --------------------
  Windows            tbc_p700_0_1_3
  AIX                tbc_p700_0_1_3
  HP-UX (PA-RISC)    tbc_p700_0_1_3
  HP-UX (Itanium)    tbc_p700_0_1_3
  Solaris (SPARC)    tbc_p700_0_1_3
  Solaris (x86-64)   tbc_p700_0_1_3
  iSeries            tbc_p700_0_1_3
  Linux (x86)        tbc_p700_0_1_3
  Linux (x86-64)     tbc_p700_0_1_3
  Linux (zSeries)    tbc_p700_0_1_3
  Linux (Power)      tbc_p700_0_1_3
  
  The latest available maintenance can be obtained from
  'WebSphere MQ Recommended Fixes'
  http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006037
  
  If the maintenance level is not yet available, information on
  its planned availability can be found in 'WebSphere MQ
  Planned Maintenance Release Dates'
  http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006309
  ---------------------------------------------------------------
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  WMQ WINDOWS V7

• Fixed component ID

  5724H7220

Applicable component levels

• R701 PSY

     UP