PI37981: LMQUEUE SUSPENDS FOR SMLOCK AND APDWE SUBPOOL LOCK 15/04/23 PTF PECHANGE

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• CICS tasks are hung in LMQUEUE suspends due to a deadlock or
  deadly embrace between 2 tasks. One task owns the SMLOCK and
  needs a Subpool lock, while the 2nd task owns the Subpool lock
  and needs the SMLOCK. The needed Subpool lock is for the APDWE
  domain. (You can determine which subpool lock is needed by
  using the Lock Token for the Subpool lock in Lock Manager's
  Allocated Locks summary. The Lock token will point within the
  SCA control block for the APDWE subpool in the SM domain).
  .
  The deadlock can occur when 2 tasks are simultaneously trying
  to get the APDWE subpool lock, running on different TCBs. The
  problem is in DFHICP, in the ICGETDWE routine. The DFHSMGFI
  macro includes a domain call to Lock Manager for an UNLOCK
  request, but the request expects R3 to point to DFHICP's static
  area. However, R3 has been used to save R2 and is currently
  pointing to DFHICP's stack. This causes the UNLOCK request to
  fail and the task ends up never releasing the Subpool lock.
  .
  Additional Symptom(s) Search Keyword(s):
  KIXREVSCB DWE SUBLOCK_GET START TSLOCK DFHTSPT HANG HUNG
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All CICS users with UI17604 applied.         *
  ****************************************************************
  * PROBLEM DESCRIPTION: Multiple tasks become suspended in      *
  *                      LMQUEUE suspends, waiting for a lock on *
  *                      the APDWE storage subpool.              *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  DFHICP needs to get a lock on the APDWE storage subpool in order
  to getmain a DWE. It successfully gets the lock, and performs
  the getmain. Meanwhile, another task also needs the APDWE
  subpool lock, and adds itself as a waiter for that lock.
  In the first task, DFHICP needs to perform a domain call
  to lock manager to release the lock, but due to a register
  conflict, that domain call is made with invalid data in the
  domain call parameter list.
  In the reported case, this led to the lock manager domain call
  incorrectly setting the LMLM_OWNER_TOKEN_X existence bit, and
  lock manager replying with an LMLM_EXCEPTION, reason code
  LMLM_NOT_LOCK_OWNER. The lock was not released, causing all
  future tasks requiring that lock to wait.
  .
  Additional Keywords: DFHSM0002 031E
  

Problem conclusion

• UI17604 UI19056
  The register conflict in DFHICP has been corrected, thereby
  enabling the APDWE storage subpool to be released correctly.
  

Temporary fix

• *********
              * HIPER *
              *********
  FIX AVAILABLE BY PTF ONLY
  

Comments

APAR Information

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

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

  PI39408 UI27452

Modules/Macros

• DFHICP
  

Fix information

• Fixed component name

  CICS TS Z/OS V5

• Fixed component ID

  5655Y0400

Applicable component levels

• R800 PSY UI27452

     UP15/05/15 P F505 ®

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.