4.5 Retrying GRECP and LPL recover in Db2 12 Although Db2 came a long way to automate GRECP and LPL recovery, Db2 typically tries to  perform auto recovery only once. Often, automatic recovery fails because of some transient  condition; for example, not all objects in GRECP are auto recovered because of contention  with other members during the group restart.  What typically happens is that after seeing the DSNI049I (GRECP/LPL recovery completed)  message, a  -DISPLAY DB  command is issued to list all the objects that are still in GRECP/LPL,  and then manual  -START DB  commands are issued for those objects. In most cases, the  transient condition, such as contention, is resolved by this time and the command now  succeeds in removing the GRECP/LPL condition.  Would it be useful if Db2 performs this retry if it typically has a good chance of being  successful? Db2 12 can perform that retry process because it automatically retries  GRECP/LPL recovery for you. Although Db2 12 provides the capability to retry the GRECP/LPL recovery after it failed  before, it does not retry indefinitely. In some cases, things can be broken, and there is no  point to retry as the  -STA DB2  command continues to fail and the problem must be analyzed  and addressed.  Db2 retries to automatically resolve GRECP/LPL conditions three times (from each member)  before giving up. In Db2 12, Db2 checks (the DBET) and generates an (internal) report of all  the page set or partitions in GRECP/LPL status every minute.  If one object’s failed recovery was retried or it was retried more than 3 minutes ago, Db2  starts the GRECP/LPL recovery process for the object. The retry counts are monitored and  each object has up to three retry opportunities. If the third retry still fails to recover a  GRECP/LPL contention, Db2 gives up and the GRECP/LPL condition must be resolved  manually by issuing the  -START DB  command or some other means. The retry LPL/GRECP recovery tasks are scheduled as system agents in the DBM1 address  space and are zIIP eligible. Retry tasks are scheduled for up to 100 objects at each one  minute interval. If Db2 detects that there are already 500 LPL/GRECP recovery tasks  running, it stops scheduling new tasks. The automatic GRECP/LPL recovery retry tasks use a  correlation ID of DRSTRT02. The same messages (DSNB320I, DSNB321I, DSNB322I, and DSNB323I) are used to report  GRECP status, and message DSNB250E is used to report LPL status. The same DSNI049I  message is used to indicate that the retry task completed. Also, the same data manager messages are used to report the start and completion of the  automatic GRECP and LPL recovery retries for individual objects (DSNI006I for the start of  GRECP/LPL recovery and DSNI021I for the successful recovery). As before, check for  message DSNI005I to find the reason why the GRECP/LPL recovery retry failed. When automatic GRECP/LPL recovery is triggered at the end of restart, it recovers all  GRECP/LPL object by using a single command. The Db2 12 automatic retry feature  schedules recovery in the following order: 146  IBM Db2 12 for z/OS Performance Topics GLYPH<SM590000> Schedule SYSLGRNX and its indexes (DSNLLX01, DSNLLX02) GLYPH<SM590000> Schedule all other DIRECTORY GRECP objects GLYPH<SM590000> Schedule all CATALOG GRECP objects GLYPH<SM590000> Schedule all users GRECP objects