PI11662: ALT CHANGE TO STOGROUP DOES NOT HANDLE THE CHANGES TO A VCAT NAME

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• The DB2 Administration Tool for z/OS' ALT function does not
  handle the change in the VCAT name when a change is made to
  an object STOGROUP.
  The ALT function should issue the same message as the AL
  function which states:
   Operation not allowed.  VCAT for new stogroup does not match
  VCAT
         for the current stogroup.  Use the Space Manager "MOVE"
  function
         to change the STOGROUP and to rename the object's data
  sets.
  

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:

  UI17973 UI17974

Modules/Macros

• ADBETEP
  

Fix information

• Fixed component name

  DB2 ADMIN TOOL

• Fixed component ID

  568851500

Applicable component levels

• RA20 PSY UI17973

     UP14/05/16 P F405

• RB10 PSY UI17974

     UP14/05/16 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.