IBM Support

PM56081: IPCONN_LOCK IS_LOCK ISCBCHN DEADLOCK HANG HUNG CEMT

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • After an attempt to set an IPCON out of service with CEMT,
    the CEMT task and the tasks running over the IPCON hang.
    .
      In the Lock Manager (LM) domain,
    in the section
     ==LM: LOCK WAIT QUEUE
    the CEMT task's KE_TASK number is listed in the
     KE_TASK
     OWNER
    column for the IPCONN_LOCK
    of the session being set out of service by CEMT.
    .
                                  KE_TASK
    LOCK      ADDRESS   -> NEXT   OWNER     MODE  SUSPEND
    NAME                                          TOKEN
    ----      -------   -------   -----     ----  -------
    IPCONN_LOCK
    <ipconn>  2B2731C8  2B273178            SHAR  039F0001
       ...
              2B2731DC  2B27318C            SHAR  03A10001
              2B27318C  00000000  2CCD4700  EXCL  03990001
    .
    where 2CCD4700 is the KE_TASK value for the CEMT task.
    .
    NOTE: The  KE_TASK OWNER    column
         does NOT mean that CEMT is the owner of the lock.
         It means that it WANTS to become the exclusive owner.
    Other tasks are waiting for a SHARe of the lock.
    .
      At the same time, one of the user tasks is also waiting
    for an exclusive lock on the IS_LOCK ISCBCHN lock
    with other tasks waiting for a SHARed of that lock:
    .
    IS_LOCK
    ISCBCHN
              2B2741E0  2B2741CC            SHAR  064F0001
       ...
              2B273150  2B27322C            SHAR  00730005
              2B27322C  00000000  2D1C2700  EXCL  04050001
    .
    These two tasks deadlock, waiting for their respective locks.
    They may not deadlock directly with each other.  But,
    the tasks waiting for a share of the locks hold other resources.
    And, those resources are needed by tasks that are waiting
    behind these two exclusive owners.  That causes the deadlock.
    .
      CEMT needs to be able to put an IPCONN out of service even
    when it is being used, with out getting stuck in a lock wait.
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All CICS Users                               *
    ****************************************************************
    * PROBLEM DESCRIPTION: When there aren't enough sessions to    *
    *                      cope with the work to remote            *
    *                      system, the tasks queueing for          *
    *                      available session won't free the        *
    *                      shared lock on ISCB before they         *
    *                      suspend.If CEMT SET IPCONN OUTSERV      *
    *                      is issued at this time,CEMT task        *
    *                      will hang.                              *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    The tasks that are running do a lot of work to remote
    systems and there aren't enough sessions to cope with
    them all running at once. At this time set the IPCONN
    out of service in CEMT before setting it to RELeased.
    CEMT hung because it tried to obtain the exclusive lock
    on ISCB. Unfortunately this ISCB is share-locked by
    several workload tasks queueing for available sessions.
    The correct order of execution is the IPCONN has to be
    in RELEASED state before it can be set OUTSERV otherwise
    an INVREQ should be returned.
    

Problem conclusion

  • A check (whether or not the SERVSTATUS can be changed) has been
    added before CEMT attempts to obtain the EXCLUSIVE lock in
    DFHISIC.
    The SET IPCONN OUTSERV will return with an servstatus_error if
    the IPCONN is not RELeased.
    

Temporary fix

  • FIX AVAILABLE BY PTF ONLY
    

Comments

APAR Information

  • APAR number

    PM56081

  • Reported component name

    CICS TS Z/OS V4

  • Reported component ID

    5655S9700

  • Reported release

    600

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2012-01-16

  • Closed date

    2012-03-29

  • Last modified date

    2012-05-02

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

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

    UK77489

Modules/Macros

  •    DESISIC  DFHISIC
    

Fix information

  • Fixed component name

    CICS TS Z/OS V4

  • Fixed component ID

    5655S9700

Applicable component levels

  • R600 PSY UK77489

       UP12/04/11 P F204

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":"4.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":"4.1","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
02 May 2012