IC72546: DEFECTS FIXED IN WEBSPHERE MQ FIX PACK 7.0.1.3

APAR status

• Closed as program error.

Error description

• DEFECTS FIXED IN WEBSPHERE MQ FIX PACK 7.0.1.3
  

Local fix

Problem summary

• ****************************************************************
  USERS AFFECTED:
  See detailed description in the Problem Summary section.
  
  Platforms affected:
  All Distributed (iSeries, all Unix and Windows) +Java
  ****************************************************************
  PROBLEM SUMMARY:
  PM09004J Abstract:  CORRELID) AND MSG REACHES BACKOUT THRESHOLD
  AND IS QUEUED TO BACKOUT Q.
  
  Users Affected:  This issue affects all users with
  message-driven beans using shared queues that use the WebSphere
  MQ v7 Resource Adapter and either connect to a WebSphere MQ v6
  queue manager on z/OS or use a connection factory that has the
  PROVIDER property set to "6".
  
  Platforms affected:
  All Distributed (iSeries, all Unix and Windows) +Java
  
  Error Description:  Prior to MQ V6, the message listener would
  always use MQMO_MATCH_MSG_ID to locate a message from a message
  reference. This would be used for both the normal case of doing
  a destructive get prior to calling the MDB's onMessage method
  and for the case of a bad message being got prior to putting it
  to a backout queue or a dead letter queue. As the gets were
  always matching msgid, it was a requirement for shared queues
  being serviced by a message listener that the queue needed to be
  indexed by msgid. At MQ V6 and above, the introduction of msg
  token matching meant that the Version 2 listener changed the get
  processing prior to calling onMessage to use
  MQMO_MATCH_MSG_TOKEN. This removed the need to index shared
  queues for the working case.
  
  Problem Summary:  When a message-driven bean throws an
  exception or rolls back, and the queue agent thread in the
  Resource Adapter determines that the message should be requeued,
  the message is removed from the queue using the MsgId so that it
  can be put to the requeue queue. If the queue is a shared queue
  in an MQ Queue Sharing Group on z/OS the removal of the message
  fails with MQRC 2206 if the queue is not indexed by MsgId.
  
  Problem Conclusion:  The queue agent thread has been changed to
  get the message by msgtoken, allowing the queue to be indexed by
  keys other than MsgId.
  
  ----------------------------------------------------------------
  136587 Abstract:  QUEUE MANAGER CAN APPEAR ACTIVE ON MORE THAN
  ONE NODE IN A MULTI-INSTANCE QUEUE MANAGER ENVIRONMENT
  
  Users Affected:  Windows users that are taking advantage of
  multi-instance queue managers.
  
  Platforms affected:
  Windows
  
  Error Description:  When control passes from a an active node
  to a standby node, it is possible that both nodes will report as
  being active.
  
  The "dspmq -x" command can be used to check for active queue
  manager instances.
  
  Problem Summary:  The method used for file locking was
  incorrect and this led to a situation whereby two queue managers
  could appear as being active.
  
  Problem Conclusion:  The code was reworked to use an
  alternative locking strategy which was shown in testing to fix
  the problem.
  
  ----------------------------------------------------------------
  

Problem conclusion

• The defects described above are fixed in fix pack 7.0.1.3.
  
  ---------------------------------------------------------------
  
  AdditionalKeywords: APARNOPUB
  

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

• R700 PSY

     UP