PI37390: SSD BLOCKS IN ESQA NOT FREED

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• Customer observed high usage of SSD blocks in ESQA associated
  with WMB. It occurs when a thread invokes CSQMLOCT to locate an
  data-conversion table, and CSQMLOCT finds that there is another
  thread already trying to load the data-conversion table (in
  this case the conversion table is for 5123 to/from 1047, which
  does not actually exist). CSQMLOCT allocates a ROB to wait for
  the data-conversion table to be loaded, and then suspends on the
  ROB, which results in CSQVSRX allocating a pause-element (SSD).
  However, after CSQMLOCT has been resumed it does not release the
  ROB, which results in the ROB storage and the pause-element
  token being leaked.
  .
  Additional keywords:
  SP245 KEY0 Subpool 245 Key 0
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of WebSphere MQ for z/OS Version 8 *
  *                 Release 0 Modification 0.                    *
  ****************************************************************
  * PROBLEM DESCRIPTION: Leak of ROB control blocks and their    *
  *                      associated Pause Element's when the     *
  *                      queue manager loads conversion tables.  *
  *                      For long running applications, the      *
  *                      leak can lead to a build of SSD control *
  *                      blocks in ESQA, leading to shortages of *
  *                      common storage.                         *
  *                                                              *
  *                      In some cases abend 5C6-00E50079 can    *
  *                      also occur in CSQMCNVT.                 *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  When an application attempts a conversion for which no suitable
  conversion table is loaded, it queues a request to the
  conversion task to load the table.
  If multiple applications require the same table, only one
  request is queued, and the other tasks are suspended until the
  first task resumes them, however the ROBs used to suspend these
  additional tasks are not freed, leading to the ROBs being
  leaked. These ROB's also have associated Pause Elements, and
  consequently these are also not freed, leading to a build up of
  SSD control blocks in common storage if the application is long
  running.
  
  If STOP QMGR MODE(FORCE) is issued while a task is suspended
  waiting for a conversion table to be loaded, a timing window
  exists where a ROB can be freed prior to being resumed, leading
  to abend 5C6-00E50079 in CSQMCNVT.
  

Problem conclusion

• CSQMLOCT is changed to correctly free the ROBs associated with
  additional tasks waiting for a table to be loaded, and to
  prevent the ROB used by the initial task being freed prior to
  being resumed during STOP QMGR MODE(FORCE) processing.
  MQMSGPROP/K
  000Y
  CSQALOCT
  CSQMCNVT
  CSQMLOCT
  CSQXLOCT
  

Temporary fix

• *********
  * HIPER *
  *********
  

Comments

APAR Information

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

  PI36735

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

  UI27084

Modules/Macros

• CSQALOCT CSQMCNVT CSQMLOCT CSQXLOCT
  

Fix information

• Fixed component name

  WMQ Z/OS 8

• Fixed component ID

  5655W9700

Applicable component levels

• R000 PSY UI27084

     UP15/06/03 P F506 ¢

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.