PI47964: CSQY291E CSQXDMPS SDUMPX FAILED, RC=00000208,ABN= 5C6-00E7014F, LOC=CSQXADPM.CSQXADPM+051DE

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• The dump show that CSQ7COLL is being called to
  collect accounting data related to the get of a
  message being put using the fast put optimization,
  this is occurring despite accounting trace being
  disabled because at the time the getter task
  started accounting trace was still enabled.
  Having located the correct WQSTATI for the queue
  (which exists due to an earlier get from the queue),
  CSQ7COLL attempts to recheck whether accounting is
  enabled for the queue using an incorrect index
  into the WHPV, and this results in the reported 0C4.
  
  .
  The problem only occurs if a queue is opened with
  accounting trace disabled, and the queue was
  previously used by the same task while accounting
  trace was enabled.
  This means that it should be possible to avoid
  the abend by either leaving accounting class 3
  enabled or by not enabling it at all (the joblog
  shows the trace is enabled and disabled several times).
  .
  
  Additional Symptom(s) Search Keyword(s):
  .
  ABN=0C4-00000011,U=MQSSTC  ,C=W9700.800.STAT-CSQ7COLL,
  M=CSQGFRCV,LOC=CSQ7LPLM.CSQ7COLL+000015AC
  

Local fix

• It should be possible to avoid the abend by either
  leaving accounting class 3 enabled or by not enabling
  it at all (the joblog shows the trace is enabled and
  disabled several times).
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of WebSphere MQ for z/OS Version 8 *
  *                 Release 0 Modification 0.                    *
  ****************************************************************
  * PROBLEM DESCRIPTION: Abend 0C4 in CSQ7COLL when class 3      *
  *                      accounting trace has been disabled.     *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  During the out of syncpoint put of a non-persistent message,
  CSQM1PFW determines that the message can be put directly to a
  waiting getter, and calls CSQ7COLL to do any necessary
  collection of accounting data for the MQGET it is about to
  satisfy.
  CSQ7COLL searches for a WQSTAT control block for the queue,
  and finds that one already exists, but is not in the WHPV
  for the getter, because accounting class 3 was not active
  when the getter last opened the queue. It then attempts
  to check if the ACCTQ attribute of the queue has changed,
  but uses an incorrect index into the MHPV array, leading to the
  reported 0C4.
  

Problem conclusion

• CSQ7COLL is changed to use the correct index into the MHPV when
  checking the ACCTQ attribute of a queue in this situation.
  000Y
  CSQ7COLL
  

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:

  UI31140

Modules/Macros

• CSQ7COLL
  

Fix information

• Fixed component name

  WMQ Z/OS 8

• Fixed component ID

  5655W9700

Applicable component levels

• R000 PSY UI31140

     UP15/10/08 P F510

Fix is available

• Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.