PM85679: DBET SET GRECP STATE INCORRECTLY DURING DB2 RESTART

A fix is available

Subscribe

You can track all active APARs for this component.

APAR status

Closed as program error.

Error description

A GRECP object was found not to be recovered by the auto-GRECP
recovery engine. There were no messages DSNB320I , DSNB321I ,
DSNB322I or DSNB323I to indicate the object was put into GRECP
during the restart and the object had already been in LPL prior
to the DB2 restart. The log record analysis showed that DBET set
the GRECP state incorrectly.
Additional symptoms: MSGDSNB320I MSGDSNB321I MSGDSNB322I
MSGDSNB323I
Potential backlevel page condition.
rc00C90101 in DSNKINSL erqual5033
rc00c90205 in DSNIONX2 erqual5005

Local fix

Issue the START DATABASE command manually.

Problem summary

****************************************************************
* USERS AFFECTED: All DB2 for z/OS data sharing users of *
* partitioned objects that are placed in LPL *
* state *
****************************************************************
* PROBLEM DESCRIPTION: During DB2 restart, partitioned objects *
* that are in LPL may mistakenly pick up *
* a phantom GRECP state, despite no group *
* buffer pool issues *
****************************************************************
* RECOMMENDATION: *
****************************************************************
During DB2 restart, a partitioned object that was in LPL
mistakenly picked up the GRECP state, when it should have been
only in LPL state. This happened internally only, meaning there
were no GRECP-related messages on the console (MSGDSNB320I,
MSGDSNB321I, MSGDSNB322I or MSGDSNB323I).
So after the restart, -DISPLAY DATABASE on the object showed LPL
and GRECP, when only LPL should have been on.
This error may occur during DBET clean up processing, because
DBET was incorrectly using a flag which did not apply to
partitioned objects, when determining which DBET piece entries
were in LPL.
This issue can only happen to partitioned objects that are in
LPL and that happen to have some kind of internal inconsistency
in their DBET structure with regard to the LPL state (due to
to a prior abend or cancel of some kind). The code that
mistakenly turned on GRECP simply meant to correct the internal
inconsistency with regard to the LPL state in the structure.
Until this fix is applied, the -START DATABASE SPACENAM command
can be issued on the object, which will drive recovery from LPL
business as usual, as well as remove the "phantom" GRECP state.

Problem conclusion

DBET code has been fixed to ensure that GRECP does not get
mistakenly turned on during restart.
Additional keywords: DB2DSHR SYSPLEXDS