PI06114: STOGROUP VCAT CHANGE RESULTS IN DSNT500I REASON 00D70024 TYPE 00000220 AS REORG IS OUT OF SEQUENCE

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• The DB2 Object Comparison Tool for z/OS does not product a
  REORG step in the right order when dealing with a change to a
  STOGROUP's VCAT resulting in the DB2 COPY utility failing with
  a message:
  DSNT500I   DSNUGBAC - RESOURCE UNAVAILABLE
                        REASON 00D70024
                        TYPE 00000220
                        NAME
  >new_vcat<.DSNDBC.>database<.>spacename<.I0001.A001
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: Users of the DB2 Administration Tool         *
  *                 and DB2 Object Comparison Tool for z/OS      *
  *                 who use 'ALT Alter Table' (ALT) or Object    *
  *                 Compare to alter a table space or index      *
  *                 to use another STOGROUP which has a          *
  *                 different VCAT from the previous one.        *
  ****************************************************************
  * PROBLEM DESCRIPTION: When altering a table space or index    *
  *                      to use another STOGROUP which           *
  *                      has a different VCAT name from the      *
  *                      previous one, the following utilities   *
  *                      like COPY TABLESPACE or RUNSTATS        *
  *                      INDEX will fail with an error message:  *
  *                                                              *
  *                      -DSNT500I    317 10:20:34.41 DSNUGBAC   *
  *                      - RESOURCE UNAVAILABLE                  *
  *                            REASON 00D70024                   *
  *                            TYPE 00000220                     *
  *                           NAME >dataset_name<                *
  *                                                              *
  *                      because they try to find the data sets  *
  *                      for this table space or index by using  *
  *                      the new VCAT name as the high           *
  *                      qualifier but these data sets have      *
  *                      not been allocated.                     *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  In DB2 Administration Tool for z/OS and DB2 Object Comparison
  Tool for z/OS, when altering a table space or index to use
  another STOGROUP which has a different VCAT name from the
  previous one, the following utilities like COPY TABLESPACE
  or RUNSTATS INDEX will fail with an error message:
  
  -DSNT500I    317 10:20:34.41 DSNUGBAC
  - RESOURCE UNAVAILABLE
        REASON 00D70024
        TYPE 00000220
       NAME >dataset_name<
  

Problem conclusion

• The Batch Restart Program ADBTEP2 has been modified to perform
  the following:
  
  1. Rename the data sets of the table space or index to use the
  new VCAT name as the high qualifier after the execution of the
  ALTER TABLESPACE/INDEX ... USING STOGROUP ...statement at run-
  time. If rename fails, then the ALTER statement also has to
  fail.
  
  2. Perform a deferred REORG or REBUILD utility for the table
  space or index automatically after the execution of the
  ALTER TABLESPACE/INDEX ... USING STOGROUP ... statement
  at run-time because DB2 requires a REORG or REBUILD to
  recognize STOGROUP changes for a table space or index.
  
  NOTE:
  
  1. ADBTEP2 can only support changing the
  VCAT name in the cases that the two VCAT
  names are defined within the same catalog
  structure. For other cases, please use the
  Move function of Space Management to
  move a page set from VCAT-defined to
  STOGROUP-defined or to change the VCAT
  name in a STOGROUP.
  2. Besides a deferred REORG or REBUILD
  being issued by ADBTEP2, an explicit REORG
  or REBUILD within the worklist may be run
  later if previously requested by the user.
  
  3. A follow-on APAR PI16739 will support new
  parameters to control whether performing a
  deferred REORG or REBUILD automatically
  during the execution of ADBTEP2.
  

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:

  UI17986

Modules/Macros

• ADBETEP  ADBTEPI  ADBTEP2  ADB5000
  

Fix information

• Fixed component name

  DB2 ADMIN TOOL

• Fixed component ID

  568851500

Applicable component levels

• RA20 PSY UI17985

     UP14/05/17 P F405

• RB10 PSY UI17986

     UP14/05/17 P F405

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.