PK59457: /STO ADS CAUSED HUNG-UP OF DEDB PREOPEN PROCESSING

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• /STO ADS command was issued for a ADS during DEDB PREOPEN
  processing. Then command and PREOPEN process hung up.
  1. Some preopen ITASKs are waiting on SYNC Share latch from
   DBFMLOP0. Owner is DBFCST00 ITASK. These are non SVSO AREAs.
    DFSDYA00->DBFCMOC0->DBFCMOC1->MAKE_AUTHLST->DBFCOMC1-CMOC1OPN
     ->CALLOPEN->DBFMLOP0->DBFSYNL0->GET_SHR->DFSISERW
  2. Some preopen ITASKs are waiting on VUNLOAD LOCK SHR from
   DBFMLOP0. Owner is DBFCST00 ITASK. These are SVSO AREAs.
    DFSDYA00->DBFCMOC0->DBFCMOC1->MAKE_AUTHLST->DBFCOMC1-CMOC1OPN
     ->CALLOPEN->DBFMLOP0->DBFXSVC0->DBFLRH00->DFSLMGR0
  3. DBFCST00 ITASK hold both SYNC latch EX and VUNLOAD lock EX,
  and waiting on unallocation request.
  But unallocation request was not processed because DYA ITASKs
  were waited as above.
    DBFCST00->DBFARD20->DBFMFLG0->DBFMLCL0->DBFPFDS0->DBFMDA00
     ->DFSMDA10->DFSISERW
  Additional Symptom:
  System hang with DPST holding DBFSYNL SHR,
  and waiting for dynamic allocation of ADS to complete.
  Checkpoint ITASK waiting for DBFSYNL EXCL.
  DYA ITASK corresponding to DMAC_AOC_TCB_NUM for
  the dynamic allocation waiting for DBFSYNL SHR
  behind EXCL checkpoint request
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: IMSFP V10 DEDB users.                        *
  ****************************************************************
  * PROBLEM DESCRIPTION: DEADLOCK OCCURS BETWEEN DEPENDENT       *
  *                      REGION AND PREOPEN OF ALL AREAS AFTER   *
  *                      RESTART.                                *
  ****************************************************************
  * RECOMMENDATION: INSTALL CORRECTIVE SERVICE FOR APAR/PTF      *
  ****************************************************************
  This service corrects two problems involved Fast path DEDB
  preopen processing:
  
  1:  After an emergency restart, Area preopen was started and a
    list of AREAs were being opened under the DFSDYA00 TCBs.
    In addition, dependent regions were started and as requests
    for access to AREAs were made, additional open requests were
    issued that resulted in Deadlocks for the AREA Lock.
      The module flows involved were:
    DBFMCLX0, DBFMRQC0, DFSMCTL0, DBFMSSA9, DBFMGRF0, DBFMBED0,
     DBFMLOP0, DBFPALC0, DBFMDA00,   DBFMDA00,DFSISERW
    This is for the dependent region which holds the AREA lock
    that this DFSDYA00 flow is waiting for:
    DFSDYA00, DBFCMOC0, DBFCMOC1,MAKE_AUTHLST,DBFCMOC1,
    CALLOPEN,DBFMLOP0,MLOPGULK,DBFLRH00,DFSLMGR0
    The dependent region is waiting for a DFSDYA00 ITASK to run
    its request and all 10 DFSYDAY00 ITASKS are in a wait for a
    resource owned by a dependent region.
      Other IMS systems are also waiting for the AREA locks owned
    by the dependent region ITASKs.
      The problem is that DBFMLOP0, in the dependent region found
    DMAC_AOC_FLAG2,DMAC_AOC_FLAG2_OPEN_B set (as a result of
    processing by DBFCMOC1 under the DFSDYA00 Flow) so it sets
    DMAC_AOC_FLAG2,DMAC_AOC_FLAG2_OPEN_DR(which was checked
    earlier by DBFCMOC1 and found not to be set).
      After this DBFMLOP0 in the dependent region gets the AREA
    lock before DBFCMOC1 is able to request it under the DFSDYA00
    ITASK and this leads to the Deadlock.
  
  2:  System hang with dependent region holding DBFSYNL SHR,
    and waiting for dynamic allocation of ADS to complete.
    Checkpoint ITASK waiting for DBFSYNL EXCL.
    DYA ITASK corresponding to DMAC_AOC_TCB_NUM for
    the dynamic allocation waiting for DBFSYNL SHR
    behind EXCL checkpoint request.
  

Problem conclusion

• AIDS: RIDS/FP RIDS/DEDB FP DEDB
    GEN:
  
  *** END IMS KEYWORDS ***
  
  The following changes have been made to correct the
  reported problem:
  
  DBFMLOP0: Add code in case AREA lock has been obtained for
            normal open processing.  If the AREA is being opened
            by bulk processing, releases the AREA lock, waits
            for 1 second, and then go back to get the AREA lock.
  
  DBFSYNL0: Add code to allow DYA itask to obtain the SYNC latch
            in share mode when there is waitor for exclusive
            mode.
  

Temporary fix

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

Comments

APAR Information

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

  PK17084

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

  UK34561

Modules/Macros

• DBFMLOP0 DBFSYNL0
  

Fix information

• Fixed component name

  IMS V10

• Fixed component ID

  5635A0100

Applicable component levels

• R010 PSY UK34561

     UP08/03/21 P F803 Ž

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.