PM79367: 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 V12 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 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
  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.
  

Temporary fix

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

Comments

APAR Information

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

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

  PM79773 PM79774 010PC2Ÿ UK91032

Modules/Macros

•    DSPURI60 DSPURM60 DSPUSTB2
  

Fix information

• Fixed component name

  IMS V12

• Fixed component ID

  5635A0300

Applicable component levels

• R200 PSY UK91032

     UP13/01/24 P F301 Ž

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.