PM88255: BMP REGION GOT ABENDU1033 WHEN MANY DEDB FLD CALLS WERE MADE

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• After application of PM60126, some BMP region got ABENDU1033.
  These BMPs issued many DEDB FLD calls and issued SYNC call when
  they got statusFW. During SYNC process, FLD calls were
  reprocessed and needed additional buffers. Finally, buffer usage
  exceeded NBA + OBA and ABENDU1033 happened.
  Originally, IMS needed to reserve the buffers which are used
  to reprocess FLD calls during SYNC. But the fix in PM60126 made
  these buffers available to be reused for other purpose.
  When IMS returned statusFW, other DL/I calls stealled these
  buffers already, and enough buffers were not available already.
  --------------------------------------------------
  Sample Case-1;  BMP ABENDU1033.   NBA=4 and OBA=1
    1. FLD call;  DMHR1 was used to read CI-A
                  DMHR2 was used to save DFLD logics.
    2. FLD call;  DMHR3 was used to read CI-B
                  DMHR2 was used to save DFLD logics.
    3. GHU call;  DMHR4 was used to read CI-C
    4. REPL call; DMHRNALT was updated in DMHR4.
    5. GHU call;  DMHR3 was stolen to read CI-D
    6. REPL call; DMHRNALT was updated in DMHR3.
    7. FLD call;  DMHR1 was stolen to read CI-E
                  DMHR2 was used to save DFLD logics.
    8. SYNC call;  ( DMHR2, DMHR3 and DMHR4 are not stealable. )
         DBFSFLD0 reprocessed FLD calls using DFLDs.
            DMHR1 was used to read CI-A
            DMHR5 was obtained from OBA !!! to read CI-B
            additional buffer was requested to read CI-E, but no
            OBA buffer remained.
            BUSE = NBA+OBA already and DBFCBHL0 returned RC=12
        <-------
      ABENDU1033
  ----------------------------------------------------------------
  During analysis of this problem, we found another problem at
  prior level than PM60126. Timing of statusFW was wrong.
  StatusFW tells application program to the recommended timing of
  SYNC call. Our expectation is when all NBA buffers were used and
  prior to get OBA buffers.
  But when statusFW was returned to BMP, OBA buffers were used and
  OBA lock was held unexpectedly. This is because
  IMS is missing to consider the fact that these buffers with
  DMHRFFPR flag on cannot be stolen.
  ----------------------------------------------------------------
  Sample Case-2;  Prior to PM60126, statusFW       NBA=4 and OBA=1
    1. FLD call;  DMHR1 was used to read CI-A  :DMHR1 has DMHRFFPR
                  DMHR2 was used to save DFLD logics.
    2. FLD call;  DMHR3 was used to read CI-B  :DMHR3 has DMHRFFPR
                  DMHR2 was used to save DFLD logics.
    3. GHU call;  DMHR4 was used to read CI-C
    4. REPL call; DMHRNALT was updated in DMHR4.
    5. GHU call;  DMHR5 was obtained from OBA to read CI-D
                                           <== OBA lock held
        <------ StatusFW
    6. SYNC call;
         DBFSFLD0 reprocess FLD calls using DFLDs.
            DMHR1 used to read CI-A
            DMHR3 used to read CI-B
  ----------------------------------------------------------------
  StatusFW should be returned at above REPL call.
  

Local fix

• Increase OBA to bypass ABENDU1033.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: IMSFP V13 users with FLD calls.              *
  ****************************************************************
  * PROBLEM DESCRIPTION: BMP regions get ABENDU1033 when         *
  *                      several FLD calls are issued.           *
  ****************************************************************
  * RECOMMENDATION: INSTALL CORRECTIVE SERVICE FOR APAR/PTF      *
  ****************************************************************
  BMPs issued many DEDB FLD calls and issued SYNC when they
  got statusFW. During SYNC process, FLD calls were reprocessed
  and they needed additional buffers. Finally the buffer usage
  exceeded NBA + OBA and the ABENDU1033 occurred.
  Previous service had made these buffers available to be reused
  for other DL/I calls so when statusFW was issued and needed
  more buffers, they had already been exhausted. Hence, the
  ABENDU1033.
  
  Also, the timing of statusFW is incorrect. StatusFW advises
  the application to time SYNC calls appropriately. The
  expectation is the application would get the STATUS FW when NBA
  buffers are all used and prior to using OBA buffers.
  But when the statusFW was returned to the BMP the OBA buffers
  were used and the OBA lock was held unexpectedly.
  

Problem conclusion

• GEN:
  KEYWORDS:
  
  *** END IMS KEYWORDS ***
  
  **********
  DBFIRC10 *
  **********
  Code added to check if Procopt=GO buffers exist and can be
  stolen in addition to the DMHRFFPR (prevent buffer steal) flag
  set off before made available to the region.
  
  **********
  DBFMFL00 *
  **********
  Code changed to turn DMHRFFPR ON to reserve this DMHR until
  SYNC. DBFSFLD0 needs this DMHR to reprocess the FLD call.
  

Temporary fix

Comments

APAR Information

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

  PM79711

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

  UK94367

Modules/Macros

•    DBFIRC10 DBFMFL00
  

Fix information

• Fixed component name

  IMS V13

• Fixed component ID

  5635A0400

Applicable component levels

• R300 PSY UK94367

     UP13/05/22 P F305

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.