PI97111: INCORRECT STATUS GP GPSTAT STATGP RETURNED WITH DEDB SIX DOING GNP PROCESSING, AND BUFFER STEAL OCCURS

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• Application using DEDB Secondary Index FPSI DEDB SIX does
  GN processing through DEDB. The SIX is on a field in root
  segment and the GN of root segment is qualified on SIX key.
  The application then does GNP of 1st and 2nd level child
  segments. Sporadically, the one of these GNPs gets an incorrect
  status GP - the child does in fact exist, and was read, but
  DBFMSIX0 checks the full concatenated key using data in
  buffers ( via MLTECLOC ). In fact, with a non-update process
  it is possible the higher level parent segments are in different
  CIs and the DMHR/buffer/lock may have been stolen when the
  child segment was read and caused NBA to be reached.
  It appears DBFMSIX0 will need code to re-read the CI if
  MLTECLOC is zero.
  Additional symptom: AbendS0C4 DBFMSIX0
  on EX instruction CHECKDEP when MLTECLOC
  ( which is also EPCBCLOC ) is zero.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED:                                              *
  * IMSFP V15 DEDB Fast Path Secondary Index FPSI users.         *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  * INCORRECT STATUS GP GPSTAT STATGP RETURNED WITH DEDB SIX     *
  * DOING GNP PROCESSING, AND BUFFER STEAL OCCURS.               *
  ****************************************************************
  * RECOMMENDATION:                                              *
  * INSTALL CORRECTIVE SERVICE FOR APAR/PTF                      *
  ****************************************************************
  Application using DEDB Secondary Index FPSI DEDB SIX does GN
  processing through DEDB. The secondary index is on a field in
  root segment and the GN of root segment is qualified on SIX key.
  The application then does GNP of 1st and 2nd level child
  segments. Sporadically, the one of these GNPs gets an incorrect
  status GP - the child does in fact exist, and was read, but
  DBFMSIX0 checks the full concatenated key using data in buffers
  ( via MLTECLOC ) In fact, with a non-update process, it is
  possible the higher level parent segments are in different CIs
  and the DMHR/buffer/lock may have been stolen when the child
  segment was read and caused NBA to be reached.
  

Problem conclusion

• The following change has been made to correct the reported
  problem:
  DBFMSIX0: Add code to read the CI if the segment is not in
  storage (MLTECLOC or MLTECLOC64 is zero) .
  

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:

  PI97151 UI56898

Modules/Macros

• DBFMSIX0 DBFMPGO0
  

Fix information

• Fixed component name

  IMS V15

• Fixed component ID

  5635A0600

Applicable component levels

• R500 PSY UI56898

     UP18/07/03 P F807 ¢

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.