PI59710: CICS PROGRAM LIBRARY_LOCK IS HELD WHEN A PROGRAM CHECK OCCURS DURING A PROGRAM LOAD BY DFHLDLD1.

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• CICS TS in 5.2
  Tasks hang suspended on LMQUEUE for LIBRARY_LOCK after
  an abend occurred when CICS was loading a program.
  LIBRARY_LOCK is never released.
  Background:
  A user application program which calls  C
  entry points therefore it has to be stored as
  a program object in PDSE format. Otherwise the linkage
  editor fails with the error message
  IEW2606S MODULE INCORPORATES VERSION 3 PROGRAM OBJECT
  FEATURES AND CANNOT BE SAVED IN LOAD MODULE
  FORMAT .
  
  When the library was transferred to from one system
  to another a mishap occurred. The receipt of the library
  was automatically converted to PDS and the PDS dataset
  was concatenated to the CICS RPL.
  When the C subroutine is called by a CICS program now, the
  transaction abends with an AEXZ and several other
  transactions are left suspended in LMQUEUE resource.
  The affected CICS region becomes finally
  unusable and has to be recycled.
  .
  When the abendAKEX occurs we see in the CICS log :
  DFHLD0001 CICSAPID An abend (code 0F4/AKEX) has occurred at
  offset X'FFFF' in module DFHLDLD1.
  Analysis of the a SLIP sump on the abend0F4 showed :
  CICS tasks are suspended on LMQUEUE, one task wants
  EXCLUSIVE lock called LIBRARY_LOCK ( LD_LBLOK )
  .
  Lock Manager Waiter Queue
  .
  Lock     Address  -> Next  Owner    Mode Suspend
  Name                                     Token
  --------------------------------------------------
  LD_LBLOK          225859F0 00000000 SHAR 021F0001
  LD_LBLOK 225859F0 22585644 00000000 SHAR 02250001
  LD_LBLOK 22585644 22585B08 00000000 SHAR 016B0001
  LD_LBLOK 22585B08 22585C84 00000000 SHAR 02410001
  LD_LBLOK 22585C84 22585CE8 00000000 SHAR 02670001
  LD_LBLOK 22585CE8 00000000 23A49800 EXCL 02710001
  It seems that there is no EXCLUSIVE lock owner .. but the key
  point is that there is a SHARed flag on in the lock element
  This will prevent EXCLUSIVE access to the LOCK.
  The shared use on LIBRARY_LOCK was not released after the
  abend0F4.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All CICS users.                              *
  ****************************************************************
  * PROBLEM DESCRIPTION: A task which requires the DFHRPL Shared *
  *                      lock hangs after the abend of a prior   *
  *                      task.                                   *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  A task which has obtained and owns the DFHRPL Shared lock from
  DFHLDLD1 abends, driving the DFHLDLD1 recovery routine. Since
  this routine fails to release the Shared lock, the next task
  which requires the lock will not be able to obtain it and will
  hang forever.
  

Problem conclusion

• DFHLDLD1 has been changed so that the DFHRPL Shared Lock is
  released, if appropriate, in its recovery routine.
  

Temporary fix

• 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:

  PI63686 UI39087

Modules/Macros

•    DFHLDLD1
  

Fix information

• Fixed component name

  CICS TS Z/OS V5

• Fixed component ID

  5655Y0400

Applicable component levels

• R900 PSY UI39087

     UP16/07/09 P F607

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.