PK89398: FASTPATH PORTION OF RIS REBUILT BY /ERE OR XRF TRACKING LOST. INDOUBT EEQE LEFT, NOT RESOLVABLE

APAR status

• Closed as program error.

Error description

• A DBCTL thread that had made DEDB updates completed Phase I
  of syncpoint ( 5610, 5611 logged ) before CICS forced a
  U0210 abend. IMS correctly built a RIS and created INDOUBT
  EEQEs for the updated DEDB CIs. The EEQE build was logged
  as x'2508' log records. During the RIS build, a x'3805'
  log record was cut by DFSDRIS0. IMS then failed ( an XRF
  TKO occurred ). XRF tracking / ERE processing correctly
  found the UR indoubt at log EOF, and built a new RIS,
  as well as rebuilding the EEQEs. However, processing of the
  x'3805' record by DBFERSY0 incorrectly deleted the FastPath
  resources in the RIS ( the assumption, invalid, is that a
  x'38xx' means an abort ). The RIS was thus no longer linked
  to the EEQE. A /CHA CCTL COMMIT command was eventually
  issued and the RIS 'committed' ( but it had no resources, so
  this was essentially a NOOP ). The INDOUBT EEQEs remained.
  This problem happened in an XRF environment but could also
  occur during /ERE if IMS fails after RIS build and before the
  RIS is checkpointed in a x'4030' record and is included in
  a restart checkpoint.( In other words, if /ERE processes
  the x'3805' ).
  DBFERSY0 needs to recognize the special x'3805' built by
  DFSDRIS0 and ignore it.
  

Local fix

• The only way to delete the EEQEs is to either zap memory
  ( DMACEEQE, SCDEEQEP, etc ) or shutdown, delete EEQE from
  DBRC, and cold-start.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: IMSFP V9 DEDB DBCTL users.                   *
  ****************************************************************
  * PROBLEM DESCRIPTION: FASTPATH PORTION OF RIS REBUILT BY      *
  *                      /ERE OR XRF TRACKING LOST.              *
  *                      INDOUBT EEQE LEFT, NOT RESOLVABLE.      *
  ****************************************************************
  * RECOMMENDATION: INSTALL CORRECTIVE SERVICE FOR APAR/PTF      *
  ****************************************************************
  A DBCTL thread that had made DEDB updates completed Phase I
  of syncpoint ( 5610, 5611 logged ) before CICS forced a
  U0210 abend. IMS correctly built a RIS and created INDOUBT
  EEQEs for the updated DEDB CIs. The EEQE build was logged
  as x'2508' log records. During the RIS build, a x'3805'
  log record was cut by DFSDRIS0. IMS then failed ( an XRF
  TKO occurred ). XRF tracking / ERE processing correctly
  found the UR indoubt at log EOF, and built a new RIS,
  as well as rebuilding the EEQEs. However, processing of the
  x'3805' record by DBFERSY0 incorrectly deleted the FastPath
  resources in the RIS ( the assumption, invalid, is that a
  x'38xx' means an abort ). The RIS was thus no longer linked
  to the EEQE. A /CHA CCTL COMMIT command was eventually
  issued and the RIS 'committed' ( but it had no resources, so
  this was essentially a NOOP ). The INDOUBT EEQEs remained.
  This problem happened in an XRF environment but could also
  occur during /ERE if IMS fails after RIS build and before the
  RIS is checkpointed in a x'4030' record and is included in
  a restart checkpoint.( In other words, if /ERE processes
  the x'3805' ).
  

Problem conclusion

• GEN:
  KEYWORDS:
  
  *** END IMS KEYWORDS ***
  
  The following change has been made to correct the
  reported problem:
  
  DBFERSY0: Code modified to process log record x'3801' instead
            of X'38' which included x'3805' coincidentally.
  

Temporary fix

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

Comments

APAR Information

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

  PK87678

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

  UK49097

Modules/Macros

• DBFERSY0
  

Fix information

• Fixed component name

  IMS V9

• Fixed component ID

  5655J3800

Applicable component levels

• R900 PSY UK49097

     UP09/08/14 P F908 Ž