PM79774: EXCESSIVE NUMBER OF RLS DEADLOCKS WHEN MULTIPLE CHANGE.DBDS COMMANDS ARE PROCESSED IN PARALLEL

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• When running a vendor RELOAD utility for several areas in the
  same DEDB, an excessive number of MSGIGW10077I messages occurred
  indicating deadlocks.  This occurred during the step that issued
  a CHANGE.DBDS DB() AREA() ICON command.
  .
  
  If several CHANGE.DBDS for DBDSs that are in the same full
  function or HALDB or for the same AREAs that are in or AREA
  deadlocks can occur when attempting to update the DB record in
  RECON.  If enough jobs are involved this can lead to an unending
  set of deadlocks and retries.  This is in part because the
  CHANGE.DBDS processing gets the DB record with a share level
  lock and then, if it is determined an update is needed for that
  record, it will get an exclusive lock before doing the update.
  If two jobs do this at the same time, I deadlock occurs.  If
  several jobs are involved we can get into a situation were all
  the jobs eventually become the deadlock victim and then retry.
  This can continue endlessly
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All V13 IMS DBRC PRA user will be affected.  *
  ****************************************************************
  * PROBLEM DESCRIPTION: Excessive number of RLS deadlocks when  *
  *                      multiple CHANGE.DBDS commands are       *
  *                      processed in parallel.                  *
  ****************************************************************
  * RECOMMENDATION: INSTALL CORRECTIVE SERVICE FOR APAR/PTF      *
  ****************************************************************
  When running a vendor RELOAD utility for several areas in the
  same DEDB, an excessive number of MSGIGW10077I messages occurred
  indicating deadlocks. This occurred during the step that issued
  a CHANGE.DBDS DB() AREA() ICON command.
  
  If several CHANGE.DBDS for DBDSs that are in the same full
  function or HALDB, or the several AREAs in the same DEDB,
  deadlocks can occur when attempting to update the DB record in
  RECON. If enough jobs are involved, this can lead to an unending
  set of deadlocks and retries. This is in part because the
  CHANGE.DBDS processing gets the DB record with a share level
  lock and then, if it is determined an update is needed for that
  record, it will get an exclusive lock before doing the update.
  If two jobs do this at the same time, a deadlock occurs.  If
  several jobs are involved we can get into a situation where all
  the jobs eventually become the deadlock victim and then retry
  and this will continue endlessly.
  

Problem conclusion

• GEN:
  KEYWORDS:
  
  *** END IMS KEYWORDS ***
  DSPURI60 is changed to issue a slightly different message if the
  retry error was hit for a IDALKADD request. It will issue the
  DSP1190 message with a 'LKADD' request type if that was the last
  request. Also, if it was a timeout for LKADD, only issue the
  message every 25 times instead of every 5 times.
  
  DSPPRAB is changed to add a new message threshold constant
  PRAB_MSGTHOLD_LKADD used to special case timeout errors for the
  IDALKADD request.
  
  DSPURM60 was changed to get an EXclusive lock on the DSPRLOCT
  calls for DB and AAUTH records.
  
  DSPUSTB2 defines new MSGDSP1190.
  
  ================================================================
  ZES1310700
  -
  THE FOLLOWING TEXT DESCRIBES THE DOC CHANGE:
  -
  A new DBRC message is obtained for this apar. Please use the
  following text description for the new DBRC MSGDSP1190W.
  
  DSP1190W A request to obtain a VSAM lock on a record has
  timed out nnnn times.
  
  Explanation
  
   An attempt by DBRC to obtain a VSAM lock for serialization
   purposes has repeatedly timed out. A lock request might time
   out repeatedly for one of the following reasons:
  
   *DBRC instances from multiple IMS systems are performing
    similar actions, such as might occur when a large number
    of utilities are running in parallel.
  
   *A DBRC instance is processing a long-running request, such
    as a LIST.RECON command.
  
  System Action
  
   Processing continues.
  
  System programmer response
  
   Issue the DISPLAY SMS,URID(ALL) command to determine if a DBRC
   instance is holding a lock for an excessive amount of time. If
   one is, consider cancelling that job. If the timeouts are not
   caused by one of the previously listed reasons, collect a dump
   from all DBRC instances and call IBM support.
  

Temporary fix

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

Comments

APAR Information

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

  PM79367

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

  012AC3Ÿ UK92135

Modules/Macros

•    DSPURI60 DSPURM60 DSPUSTB2
  

Fix information

• Fixed component name

  IMS V13

• Fixed component ID

  5635A0400

Applicable component levels

• R300 PSY UK92135

     UP13/03/13 P F303 Ž

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.