IBM Support

PI25337: NO RESPONSE AND HIGH CPU AFTER DEFINE/DELETE PAGESET, AND BUFFERPOOL SEVERAL TIMES IN THE SAME RUN OF QMGR.

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • The customer added a new pageset 7 with new buffer pool 7 to
    queue manager CSQ1 dynamically using define command
    "DEFINE PSID BUFFPOOL(7) DSN(MY.PSID07) EXPAND(USER)"
    and
    "ALTER BUFFPOOL(7) BUFFERS(2000)"
    using CSQUTIL.
    .
    After definition was done, the customer tried to remove the
    pageset again with DELETE PSID. But the pageset 7 wasn't
    removed. Instead, there was a high cpu consumption of this
    queue mananger.
    .
    The change team has identified the issue which caused the high
    CPU and prevented the queue manager (qmgr) from stopping in
    this case.
    .
    The problem happens when a particular bufferpool and pageset
    are defined and deleted more than once during a run of the
    qmgr. When the bufferpool is deleted, some state for that
    bufferpool number is left in the qmgr control blocks. When a new
    bufferpool is defined with the same bufferpool number, the
    residual state causes the bufferpool's Deferred Write Processor
    worker task to terminate prematurely.
    .
    Without this task running, updated pages in the bufferpool will
    not be written back to the pageset. This could cause several
    symptoms, including a shortage of available buffers in the
    pool.
    .
    In the customer's case, the symptom seen was caused by the
    subsequent DELETE PSID command for a pageset using the problem
    bufferpool. The delete command tries to trigger the buffer
    pool's DWP task to flush updated pages for the pageset before
    it is deleted. Since the DWP task is not running, the DELETE
    PSID processing loops waiting for all its pages to be flushed.
    This is the process using the high CPU in the dump, and would
    also be the reason that the qmgr would not terminate
    normally.
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All users of WebSphere MQ for z/OS Version 7 *
    *                 Release 1 Modification 0.                    *
    ****************************************************************
    * PROBLEM DESCRIPTION: A command to delete a page set hangs    *
    *                      and the queue manager uses high CPU.    *
    *                      The queue manager does not respond to   *
    *                      stop commands and needs to be           *
    *                      cancelled.                              *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    When a given page set is deleted, it causes deferred write
    processor tasks for buffer pools relating to the page set to be
    stopped. This is done by setting the fTermDWP flag for the
    relevant tasks.
    This flag is not reset, causing a subsequent deferred write
    processor task for that particular buffer pool number to be
    immediately stopped. If another attempt is made to stop the
    task, a tight loop will occur in CSQP9DWS and CSQPFSET.
    Note that the reuse of the buffer pool number and deferred
    write processor task needs to happen during the same run of
    the queue manager for the problem to occur.
    

Problem conclusion

  • The code was changed to correctly reset the shutdown flag for
    the deferred write processor task when it stops.
    100Y
    CSQP1DWP
    

Temporary fix

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

Comments

APAR Information

  • APAR number

    PI25337

  • Reported component name

    WMQ Z/OS V7

  • Reported component ID

    5655R3600

  • Reported release

    100

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    YesHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2014-09-09

  • Closed date

    2014-10-15

  • Last modified date

    2014-12-01

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

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

    PI27096 UI22204

Modules/Macros

  • CSQP1DWP
    

Fix information

  • Fixed component name

    WMQ Z/OS V7

  • Fixed component ID

    5655R3600

Applicable component levels

  • R100 PSY UI22204

       UP14/11/13 P F411 ¢

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.

[{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"7.1","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
01 December 2014