PI33529: IN DATA SHARING GROUP, RBA RESET AND THEN COLD START ON ONE MEMBER BREAKS THE PEER LDSD CHAINS CAUSING UTILITY JOB HUNG

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• In a data sharing group, RBA reset and cold start is performed
  on one member which had been down for several months.
  
  After that, online REORG on the other members that do not have
  RBA reset abend with S0522 and appears to hang during the
  LOGAPPLY phase. The DB2 MSTR log shows that other threads time
  out due to resource held by the REORG job. If REORG is attempted
  on the member that has the RBA reset, it completes successfully.
  The following dumps are generated.
  
  DUMP TITLE=DB2A,ABND=04E-00E20029,U=TDB0STR ,M=N  ,C=101.SMC -D
             SNSFSTG,M=DSNJRX01,LOC=DSNJRE01.DSNSVBK +1CA8
  
  DUMP TITLE=DB2A,ABND=0C4-00000004,U=TDB0STR ,M=N  ,C=101.RLMC-D
             SNJPOPN,M=DSNJPOPN,LOC=DSNJL002.DSNJPOPN+0A04
  
  KEYWORDS:
  DB2DSHR IFCID306 LOOPDSNJR106 RC00E20029 RC00000004
  

Local fix

• N/A
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All data sharing users of DB2 for zOS.       *
  ****************************************************************
  * PROBLEM DESCRIPTION: A QRep thread reading the DB2 logs      *
  *                      with the IFI READS for IFCID 306        *
  *                      facility began looping in DSNJR106      *
  *                      after another DB2 member in the         *
  *                      data sharing group was going through    *
  *                      the RBA reset procedure including       *
  *                      a cold start back to RBA zero.          *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  A QRep thread was reading the DB2 logs with the IFC READS for
  IFCID 306 facility while another member in the data sharing
  group was doing a cold start to reset the log RBA back to
  RBA zero.  Processing an F-Call from the QRep thread, DB2 read
  the peer BSDS records for the COPY2 active logs right after
  the active log entries were reset to 'empty' (no RBA range)
  as a result of the peer member cold start.  Since no COPY2
  active logs contained an RBA range, DB2 freed the obsolete
  LDSD blocks but did not clear the COPY2 LDSD anchors for the
  log search routines.  A subsequent log inventory search then
  went into a loop in DSNJR106 as the LDSD storage had been
  reused.  The invalid LDSD anchors can also result in an
  ABEND0C4 in DSNJPOPN or an ABEND04E RC00E20029 in DSNSVBK.
  

Problem conclusion

• The logic error in DSNJPOPN has been corrected.
  

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:

  UI25211 UI25212

Modules/Macros

•    DSNJPOPN
  

Fix information

• Fixed component name

  DB2 OS/390 & Z/

• Fixed component ID

  5740XYR00

Applicable component levels

• RA10 PSY UI25211

     UP15/03/04 P F503 Ž

• RB10 PSY UI25212

     UP15/03/04 P F503 Ž

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.