IV59264: ABN=0C4-00000004 in CSQMCPRH when using the WebSphere MQ classes for Java

Fix Pack 8.0.0.1 for WebSphere MQ V8.0
Fix Pack 7.1.0.6 for WebSphere MQ V7.1
8.5.5.6: WebSphere Application Server V8.5.5 Fix Pack 6
8.5.5.7: WebSphere Application Server V8.5.5 Fix Pack 7
8.5.5.8: WebSphere Application Server V8.5.5 Fix Pack 8
8.5.5.9: WebSphere Application Server V8.5.5 Fix Pack 9
8.5.5.10: WebSphere Application Server V8.5.5 Fix Pack 10
8.5.5.11: WebSphere Application Server V8.5.5 Fix Pack 11
8.5.5.12: WebSphere Application Server V8.5.5 Fix Pack 12
8.5.5.13: WebSphere Application Server V8.5.5 Fix Pack 13
8.5.5.14: WebSphere Application Server V8.5.5 Fix Pack 14
8.5.5.15: WebSphere Application Server V8.5.5 Fix Pack 15
8.5.5.17: WebSphere Application Server V8.5.5 Fix Pack 17
8.5.5.20: WebSphere Application Server V8.5.5.20
8.5.5.18: WebSphere Application Server V8.5.5 Fix Pack 18
8.5.5.19: WebSphere Application Server V8.5.5 Fix Pack 19
8.5.5.16: WebSphere Application Server V8.5.5 Fix Pack 16
8.5.5.21: WebSphere Application Server V8.5.5.21

APAR status

• Closed as program error.

Error description

• When running a WebSphere MQ classes for Java application within
  WebSphere Application Server for z/OS V8.5.5.0, an 0C4 ABEND is
  generated which brings down the application server processes and
  generates an SVC dump. Analysis of the SVC dump shows the
  following:
  
  TITLE PQM1,ABN=0C4-00000004,U=WPSRU,C=R3600.710.CMC -CSQMCPRH,
  M=CSQGFRCV,LOC=CSQMCGLM.CSQMCPRH+00001816
                                                                .
  CSQMCPRHPREQHAND_A20130722UK96026
  
  .
  TIME=15:24:33.3 5C6 REASON CODE: 00E50002
  
  CONSTANT('00E50002'X); /* UNLATCH REQUEST AND
                                     LATCH NOT OWNED BY
                                     REQUESTING EB
  TIME=15:24:33.3
  5C6 REASON CODE: 00E50002
  

Local fix

Problem summary

• ****************************************************************
  USERS AFFECTED:
  This issue affects users of:
  
  - The WebSphere MQ V7.1 classes for Java
  - The WebSphere MQ V7.5 classes for Java
  
  who have multi-threaded applications that create MQQueueManager
  objects which provides a connection to a queue manager using the
  BINDINGS transport, and then use that MQQueueManager object from
  two different threads at the same time.
  
  
  Platforms affected:
  z/OS
  
  ****************************************************************
  PROBLEM DESCRIPTION:
  When using the WebSphere MQ classes for Java, applications
  create an MQQueueManager object which represents a connection
  handle (also known as an hconn) to a queue manager, and then use
  that MQQueueManager object to access resources on the queue
  manager. The methods provided by the MQQueueManager class, and
  the methods on the classes that can be created from the
  MQQueueManager object (such as an MQQueue) will all make
  WebSphere MQ API calls to interact with the queue manager using
  the connection handle associated with the MQQueueManager object.
  
  For example, when an application calls
  MQQueueManager.disconnect, an MQDISC API call is flowed from the
  WebSphere MQ classes for JMS to the queue manager. Similarly,
  when an application calls MQQueue.close(), the WebSphere MQ
  classes for JMS will flow an MQCLOSE API call to the queue
  manager using the connection handle associated with the
  MQQueueManager object that the MQQueue was created from.
  
  Multiple application threads can use the same MQQueueManager
  object simultaneously. In this situation, the WebSphere MQ
  classes for Java provide some synchronization which ensures that
  only one WebSphere MQ API call will be flowed to a queue manager
  on a given connection handle at any one time.
  
  The WebSphere MQ V7.1 and V7.5 classes for Java did not
  correctly perform this synchronization for RRS enabled
  environments. This resulted in two threads making WebSphere MQ
  API calls to a queue manager using the same connection handle at
  the same time.
  
  If one thread was calling MQQueueManager.disconnect() at the
  same time as another thread was calling MQQueue.close() on an
  MQQueue object created from the MQQueueManager object, the
  control blocks for the connection handle could be cleaned up by
  MQDISC API call made by the the MQQueueManager.disconnect()
  method just before the MQQueue.close() method tried to use that
  connection handle to issue an MQCLOSE. As the control blocks for
  the connection handle were no longer valid, an 0C4 ABEND would
  occur in CSQMCPRH.
  

Problem conclusion

• The WebSphere MQ V7.1 and V7.5 classes for Java have been
  updated to prevent multiple WebSphere MQ API calls to be made on
  the same connection handle at the same time for applications
  running in an RRS enabled environment. If two threads within an
  application issue WebSphere MQ API calls on the same connection
  handle at the same time, one of the WebSphere MQ API calls will
  block until the other call has completed.
  
  ---------------------------------------------------------------
  The fix is targeted for delivery in the following PTFs:
  
  Version    Maintenance Level
  v7.1       7.1.0.6
  v7.5       7.5.0.5
  v8.0       8.0.0.1
  
  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 LIN X86 V7

• Fixed component ID

  5724H7224

Applicable component levels

• R710 PSY

     UP