PK37245: UNEXPECTED SVSO PRIVATE BUFFER POOL EXPANSION DUE TO DMHR WITH DMHRNIDT NONZERO AT END OF RBA HASH ANCHOR. DMHR NOT STEALABLE.

APAR status

• Closed as program error.

Error description

• Customer BMP accessing SVSO data received unexpected status FR
  ( STATFR FRSTAT ) when NBA + OBA not exceeed.
  Problem in fact was inability to get a buffer from the SVSO
  LKASID pool for the SVSO area and was not at all related to
  BMP's actual useage of buffers.
  The pool had expanded to the absolute maximum, which is twice
  the limit specified by customer in DFSVSMxx pool definition.
  A SLIP taken when message DFS2831I was issued showed the BMP
  in process of extending the pool, despite the fact that there
  were many buffers available on the RBA hash anchor for the
  RBA the BMP was searching for. The BMP access intent was
  *NOT* PROCOPT=GO, so the algorithm used by DBFSGAB0 is to
  search the RBA hash anchor for a matching RBA, and if a match
  is not found, look on the available queue for an empty buffer,
  and finally, if no empty buffers available, steal the last
  buffer on the RBA hash anchor.
  In this case, there was no buffer on the RBA hash anchor
  containing the search RBA and there were no empty buffers
  on the available queue. An attempt was therefor made to
  steal the last buffer on the RBA hash anchor. In this case,
  DMHRNIDT was not zero, indicating the DMHR belonged to a RIS
  indoubt EEQE structure and should not be stolen.
  The algorithm in this case is to invoke buffer steal DBFCBHL0,
  to try and reclaim an available buffer from those already
  allocated to the dependent region, and if that fails, invoke
  buffer pool expansion. In this case, the BMP had no buffers to
  steal, so pool expansion was called. If pool expansion fails,
  as it will when the pool expands to the hard limit of twice
  user's specification, then DBFSGAB0 will set RC=12 and this
  will result in the DL/I call receiving status FR.
  Analysis of the log showed that the DMHR in question had in
  fact been part of a RIS EEQE structure some days earlier.
  ( CICS DBCTL access ) which was eventually resolved by ABORT.
  DBFDIDT0 sets DMHRNIDT to x'0001' when the UR goes indoubt and
  RIS is built. DBFSLG20 will decrement DMHRNIDT if UR is
  eventually committed but there appears to be no path to
  decrement DMHRNIDT if UR is aborted.
  The DMHR is released to the pool with DMHRNIDT not zero,
  which, in fact, does not prevent it's reuse when it is located
  by RBA by subsequent callers. The log shows in fact it is
  reused many times before the BMP eventually runs and fails.
  DMHRRTKN at time of failure is from the last use, not from
  the UR that went indoubt. However, this DMHR is not stealable,
  and when it migrates to the bottom of it's RBA hash anchor
  and becomes a steal candidate, it blocks steals off this anchor
  and will force buffer pool expansion when a steal off this
  anchor is required. This leads to overexpansion of the buffer
  pool and, depending on circumstances, a buffer obtain failure
  and status FR to a caller looking for an RBA that hashes to
  same anchor but for which there is no matching buffer actually
  on said anchor.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: IMSFP R910 Shared VSO ( SVSO ) users.        *
  ****************************************************************
  * PROBLEM DESCRIPTION: UNEXPECTED SVSO PRIVATE BUFFER POOL     *
  *                      EXPANSION DUE TO DMHR WITH DMHRNIDT     *
  *                      NONZERO AT END OF RBA HASH ANCHOR.      *
  *                      DMHR NOT STEALABLE.                     *
  ****************************************************************
  * RECOMMENDATION: INSTALL CORRECTIVE SERVICE FOR APAR/PTF      *
  ****************************************************************
  This service corrects the problem relating to a residual
  buffer indoubt field DMHRNIDT after the indoubt was aborted.
  In this case, customer BMP accessing SVSO data received
  unexpected status FR ( STATFR FRSTAT ) when NBA + OBA not
  exceed.  The DMHR had been part of a RIS EEQE structure earlier
  ( CICS DBCTL access ) which was eventually resolved by ABORT.
  DBFDIDT0 sets DMHRNIDT to x'0001' when the UR goes indoubt and
  RIS is built. DBFSLG20 will decrement DMHRNIDT if UR is
  eventually committed, but DMHRNIDT is not decrease when UR is
  aborted.  The DMHR releases  back to the pool with DMHRNIDT not
  zero.  If the RBA match, the buffer can be reuse by subsequent
  callers.  However, this DMHR is not stealable, and when it
  migrates to the end of it's RBA hash anchor and becomes a steal
  candidate, it blocks steals off this anchor.  This leads to
  overexpansion of the buffer pool and causes buffer obtain
  failure with status FR when a caller looking for a buffer with
  an RBA that hashes to the same anchor.
  

Problem conclusion

• AIDS: RIDS/FP RIDS/DEDB FP DEDB
    DEP: NONE
    GEN:
  
  *** END IMS KEYWORDS ***
  The following change has been made to correct the reported
  problem:
  
  DBFDLG20:  Code added in the indoubt abort case to reset
             the DMHR buffer indoubt field DMHRNIDT.
  

Temporary fix

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

Comments

APAR Information

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

  PK36712

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

  UK22226

Modules/Macros

• DBFDLG20
  

Fix information

• Fixed component name

  IMS V9

• Fixed component ID

  5655J3800

Applicable component levels

• R900 PSY UK22226

     UP07/02/23 P F702 Ž