PI29729: DSNB207I WITH REASON=17080002 SHOWS UP BECAUSE OF WRONG I OR J DATA SET NAME. ABED04E RC00C200E2 DSNB1OST WITH 17080002.

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• DSNB207I with REASON=17080002 shows up because of wrong I or J
  data set name. ABED04E RC00C200E2 DSNB1OST with 17080002 is also
  recorded in LOGREC.
   PB0INPFX=ON was on but the instance name in PB0DSNM starts with
  "I" incorrectly though it should start with "J". PB0 would have
  been initially built with PB0INPFX=OFF, and PB0INPFX got turned
  on during a subsequent physical open when the PB0 already
  existed. A drain request would drive a physical open, creating
  a PB0.
   Member 1 had the "J" instance correctly open, but it got closed
  before all of this happened. Then the DDL drain request
  incorrectly tried to physically open the "I" instance. That open
  would have failed, which should have failed the drain. DB2 has
  got a PB0 with the wrong instance. Subsequent requests to open
  the part now pass in the correct prefix flag, but that doesn't
  cause DB2 to fix the dataset name.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: DB2 data sharing users.                      *
  ****************************************************************
  * PROBLEM DESCRIPTION: Open failure for a table space or index *
  *                      due to the use of the wrong data set    *
  *                      name (instance node has incorrect "I"   *
  *                      or "J" qualifier).  The failure and the *
  *                      incorrect data set name may be shown    *
  *                      by MSGDSNB207I along with a logrec      *
  *                      entry for an ABEND04E RC00C200E2, or    *
  *                      by MSGDSNP012I.                         *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  In an unusual situation in data sharing, a job requesting a
  drain (typically a command, utility or DDL statement) may drive
  a "castout takeover" if it is trying to get control of a page
  set from a member who is unable to perform a necessary castout.
  In this case, the draining member may have to do a physical
  open using information gathered from the OBD.  This logic fails
  to check some critical OBD fields, notably those controlling
  whether the instance node of the data set name is prefixed by
  "I" or "J".  This can lead to an open failure and consequential
  drain failure if the wrong data set name is used.
  

Problem conclusion

• The castout takeover logic has been modified to check some
  additional critical OBD fields when performing a physical open.
  These include the instance type, GBPCACHE attribute, and the
  index compression and copy attributes.
  

Temporary fix

Comments

APAR Information

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

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

  UI24600 UI24601

Modules/Macros

•    DSNB1DRA
  

Fix information

• Fixed component name

  DB2 OS/390 & Z/

• Fixed component ID

  5740XYR00

Applicable component levels

• RA10 PSY UI24600

     UP15/02/07 P F502

• RB10 PSY UI24601

     UP15/02/07 P F502

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.