IBM Support

PI41015: TASK HUNG FOREVER IN ENQUEUE WAIT BECAUSE THE TASK THAT ORIGINALLY OWNED THE ENQ ENDED WITHOUT RELEASING THE ENQ

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • Multiple tasks are stuck in an ENQUEUE EXECSTRN wait because
    the task that used to own the resource ended without releasing
    the enq.
    .
    For example, here is the NQ=1 summary:
    .
                                             NQEA   Tran  Tran
             Enqueue Name          Len Sta Address   id   Num
    ------------------------------ --- --- -------- ---- -----
    IGZDBGIN                         8 Act 2604A9C0 TRN1 09575
                               Waiter :    260488C0 ABC5 07214
                               Waiter :    2604A780 ABC5 07092
                               Waiter :    2604A900 ABC5 07094
    .
    The formatter lists Tran num 09575 as the owner of the enq, but
    task 9575 has never done an ENQ for that resource.  The NQEA
    lists task 9575's TASENTRY as the owner.  What has happened is
    a prior task that used that same TASENTRY ended without
    releasing the ENQ.
    .
    Furthermore, in the NQEA there is the time the owner became the
    owner.  That time precedes the beginning of task 9575.
    .
    In the message log at the time given in the NQEA, there are
    these messages:
    .
    DFHRM0002  CICSABC  A severe error
    (code X'0206') has occurred in module DFHRMUW.
    .
    DFHAP0001  CICSABC  An abend (code
    ---/ASPB) has occurred at offset X'FFFF' in module DFHD2EX1.
    .
    DFHNQ0002  CICSABC  A severe error
    (code X'0215') has occurred in module DFHNQED.
    .
    DFHRM0001  CICSABC  An abend (code
    0C4/AKEA) has occurred at offset X'2F32' in module DFHRMUW.
    .
    DFHDS0002  CICSABC  A severe error
    (code X'0071') has occurred in module DFHDSSR.
    .
    These messages happen when a task was forcepurged while it was
    doing a SYNCPOINT ROLLBACK.  During the processing of the
    resulting abendASPB, a Handle Abend program did an ENQ .  When
    the task finally abended, its TASENTRY remained the owner of
    the ENQ.
    
    Additional Symptom(s) Search Keyword(s): KIXREVDWZ
    

Local fix

  • never use forcepurge
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All CICS users.                              *
    ****************************************************************
    * PROBLEM DESCRIPTION: Task hung forever in an ENQUEUE wait    *
    *                      after the original owner of the ENQUEUE *
    *                      finished without releasing it.          *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    A task was forcepurged during backout processing. Recovery
    manager had released the old UOW but was suspended on the RM
    domain lock as part of publishing the new UOW. This resulted in
    the task being abended ASPB, with no UOW associated with it.
    DFHRM0002 was issued with code 0206 (lock error). The abending
    application program had been compiled with the LE TEST option,
    which meant that during program termination a call was made to
    perform additional functions, one of which was an ENQUEUE. This
    failed with DFHNQ0002 code 0215 as there was no UOW associated
    with the task to hold the RMUX token value for the ENQUEUE.
    The task ended but the enq was never released. Subsequent tasks
    that ENQUEUE'd on the same resource waited indefinitely for it.
    KEYWORDS RM0002 NQ0002 abendaspb rmuw
    

Problem conclusion

  • DFHRMUW has been changed to extend forcepurge protection until
    after the new UOW has been published during backout processing.
    

Temporary fix

  • FIX AVAILABLE BY PTF ONLY
    

Comments

APAR Information

  • APAR number

    PI41015

  • Reported component name

    CICS TS Z/OS V5

  • Reported component ID

    5655Y0400

  • Reported release

    800

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2015-05-13

  • Closed date

    2015-06-15

  • Last modified date

    2015-07-01

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

    PI39098

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

    UI28615 UI28616

Modules/Macros

  • DFHRMUW
    

Fix information

  • Fixed component name

    CICS TS Z/OS V5

  • Fixed component ID

    5655Y0400

Applicable component levels

  • R800 PSY UI28615

       UP15/06/25 P F506

  • R900 PSY UI28616

       UP15/06/25 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.

[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSGMGV","label":"CICS Transaction Server"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"5.1","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}},{"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":"5.1","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
01 July 2015