Updates to DB2 Administration Tool for z/OS V11.1 User's Guide

Product documentation


Abstract

Updates that apply to DB2 Administration Tool for z/OS V11.1 User's Guide (SC19-4134-02)

Content

The most recent update is listed first.




Table of Contents

Update 3: August 20, 2014
Update 2: July 24, 2014
Update 1: April 29, 2014



Update 3
Date of change: August 20, 2014

Topic: Overview of Change Management
Change description: Information on option GETDB2ZP='Y' was added

Start of changeYou need the DB2 system parameter (DSNZPARM) values to write the version file. Specify the input option GETDB2ZP='Y' in the Change DB2 Admin Defaults panel so that GEN calls the DB2 stored procedure DSNWZP to get the DB2 system parameter (DSNZPARMS) values. End of change


Change description: Clarification of CM Batch parameters auto reorg and auto rebuild in adbtep2 automated utilities.

Topic: Making changes using Change Management batch interface, Parameter definitions
adbtep2_advisoryautorebuild
The adbtep2_advisoryautorebuild parameter specifies whether the product, when a change is run, initiates a REBUILD when an object is in certain rebuild pending states. For the complete description and list of values see Using the Batch Restart programs: ADBTEP2 and ADBTEPA.
Values:
YES
The product automatically attempts a REBUILD if the object is in the ARBDP state.

Start of changeHowever, if the parameter run_reorg_rebuild was specified as 'A - All relevant' to generate an explicit REBUILD during the change flow, then the value NO is passed to ADBTEP2. The NO value prevents an automatic REBUILD that duplicates the explicit REBUILD.End of change

NO
The product does not automatically attempt a REBUILD if the object is in the ARBDP state.
Default:
NO
adbtep2_advisoryautoreorg
The adbtep2_advisoryautoreorg parameter specifies whether the product, when a change is run, initiates a REORG when an object is in certain reorganization-pending states. For the complete description see Using the Batch Restart programs: ADBTEP2 and ADBTEPA.
Values:
YES
The production automatically attempts a REORG if the object is in AREOR or AREO* state.

Start of changeHowever, if the parameter run_reorg_rebuild was specified as 'A - All relevant' to generate an explicit REORG during the change flow, then the value NO is passed to ADBTEP2. The NO value prevents an automatic REORG that duplicates the explicit REORG. End of change

NO
DB2 Admin does not automatically attempt a REORG if the object is in AREOR or AREO* state.
Default:
NO
adbtep2_autorebuild
The adbtep2_autorebuild parameter specifies whether the product, when a change is run, initiates a REBUILD when an object is in certain rebuild pending states. For the complete description see Using the Batch Restart programs: ADBTEP2 and ADBTEPA.
Values:
YES
The product automatically attempts a REBUILD if the object is in one of these states: RBDP, RBDP*, or PSRBD state.

Start of changeHowever, if the parameter run_reorg_rebuild was specified as 'M - Mandatory' or 'A - All relevant' to generate an explicit REBUILD during the change flow, then the value NO is passed to ADBTEP2. The NO value prevents an automatic REBUILD that duplicates the explicit REBUILD.End of change

NO
The product does not automatically attempt a REBUILD if the object is in one of these states: RBDP, RBDP*, or PSRBD state.
Default:
YES
adbtep2_autoreorg
The adbtep2_autoreorg parameter specifies whether the product, when a change is run, initiates a REORG when an object is in certain reorganization-pending states. For the complete description see Using the Batch Restart programs: ADBTEP2 and ADBTEPA.
Values:
Start of change
YES
The product automatically attempts a REORG if the object is in the REORP state.

However, if the parameter run_reorg_rebuild was specified as 'M - Mandatory' or 'A - All relevant' to generate an explicit REORG during the change flow, then the value NO is passed to ADBTEP2. The NO value prevents an automatic REORG that duplicates the explicit REORG.

NO
The product does not automatically attempt a REORG if the object is in the REORP state.
End of change
Default:
YES

Topic: Parameters passed to the ADBTEP2 program
Parameters passed under the DD name of ADBTEPIN

The following parameters are generated automatically and are passed to the ADBTEP2 program in a data set with a DD name of ADBTEPIN:

Advisory Auto Rebuild
The Advisory Auto Rebuild parameter determines if the Batch Restart Program initiates a REBUILD of an index when an object is in the ARBDP state.

  • Start of changeYES - A REBUILD is attempted. However, if the parameter Run REORG/REBUILD was specified as 'A - All relevant' to generate an explicit REBUILD during the change flow, then the value NO is passed to ADBTEP2. The NO value prevents an automatic REBUILD that duplicates the explicit REBUILD. End of change
  • NO - A REBUILD is not attempted.

No is the default.

For more information about the rebuild-pending states, see the DB2 V10 Utilities Guide.

Tip: To prevent the ADBTEP2 program from scheduling any automatic REBUILDs, you must set both the Auto Rebuild and Advisory Auto Rebuild parameters to No.
Advisory Auto Reorg
The Advisory Auto Reorg parameter determines if the Batch Restart Program initiates a REORG of a table space when an object is in the AREOR,AREO* state.

  • Start of changeYES - A REORG is attempted. However, if the parameter Run REORG/REBUILD was specified as 'A - All relevant' to generate an explicit REORG during the change flow, then the value NO is passed to ADBTEP2. The NO value prevents an automatic REORG that duplicates the explicit REORG. End of change
  • NO - A REORG is not attempted.

No is the default.

For more information about the rebuild-pending states, see the DB2 V10 Utilities Guide.

Tip: To prevent the ADBTEP2 program from scheduling any automatic REORGs you must set both the Auto Reorg and Advisory Auto Reorg parameters to No.
Auto Rebuild
The Auto Rebuild parameter determines if the Batch Restart Program initiates a REBUILD of an index when an object is in the RPDB. RPDB*, or PSRBD state.

  • Start of changeYES - A REBUILD is attempted. However, if the parameter Run REORG/REBUILD was specified as 'M - Mandatory' or 'A - All relevant' to generate an explicit REBUILD during the change flow, then the value NO is passed to ADBTEP2. The NO value prevents an automatic REBUILD that duplicates the explicit REBUILD. End of change
  • NO - A REBUILD is not attempted.

No is the default.

For more information about the rebuild-pending states, see the DB2 V10 Utilities Guide.

Tip: To prevent the ADBTEP2 program from scheduling any automatic REBUILDs, you must set both the Auto Rebuild and Advisory Auto Rebuild parameters to No.
Auto Reorg
The Auto Reorg parameter determines if the Batch Restart Program initiates a REORG of a table space when an object is in the REORP state.

  • Start of changeYES - A REORG is attempted. However, if the parameter Run REORG/REBUILD was specified as 'M - Mandatory' or 'A - All relevant' to generate an explicit REORG during the change flow, then the value NO is passed to ADBTEP2. The NO value prevents an automatic REORG that duplicates the explicit REORG.End of change
  • NO - A REORG is not attempted.

No is the default.

For more information about the reorg-pending states, see the DB2 V10 Utilities Guide.

Tip: To prevent the ADBTEP2 program from scheduling any automatic REORGs you must set both the Auto Reorg and Advisory Auto Reorg parameters to No.



Topic: Making changes using Change Management batch interface, Parameter definitions
Change description: CM Batch parameters needed for REORG INDEX were added.

util_reorg_index_clone
The util_reorg_index_clone parameter specifies the CLONE option for generated REORG INDEX utility statements.
Values:
Y
Clone is added.
N
Clone is not is added.
Default:
N

util_reorg_index_fastswitch
The util_reorg_index_fastswitch parameter specifies the FASTSWITCH option for generated REORG INDEX utility statements.
Values:
Y
FASTSWITCH YES is added.
N
FASTSWITCH NO is added.
blank
The FASTSWITCH option is not added.
Default:
blank

util_reorg_index_flashcopy
The util_reorg_index_flashcopy parameter specifies the FLASHCOPY option for generated REORG INDEX utility statements.
Values:
Y
FLASHCOPY YES is added.
C
FLASHCOPY CONSISTENT is added.
N
FLASHCOPY NO is added.
blank
The FLASHCOPY option is not added.
Default:
blank

util_reorg_index_leafdistlimit
The util_reorg_index_leafdistlimit parameter specifies the LEAFDISTLIMIT option for generated REORG INDEX utility statements.
Values:
A valid LEAFDISTLIMIT value for REORG INDEX, blank
A valid LEAFDISTLIMIT value for REORG INDEX
LEAFDISTLIMIT is added with the specified value.
blank
The LEAFDISTLIMIT option is not added.
Default:
blank

util_reorg_index_preformat
The util_reorg_index_preformat parameter specifies the PREFORMAT option for generated REORG INDEX utility statements.
Values:
Y
PREFORMAT is added.
N
PREFORMAT is not added
Default:
N

util_reorg_index_reportonly
The util_reorg_index_reportonly parameter specifies the REPORTONLY option for generated REORG INDEX utility statements.
Values:
Y
REPORTONLY is added.
N
REPORTONLY is not added.
Default:
N

util_reorg_index_reuse
The util_reorg_index_reuse parameter specifies the REUSE option for generated REORG INDEX utility statements.
Values:
Y
REUSE is added
N
REUSE is not added.
Default:
N

util_reorg_index_shrlevel
The util_reorg_index_shrlevel parameter specifies the SHRLEVEL option for generated REORG INDEX utility statements.
Values:
N
SHRLEVEL NONE is added.
C
SHRLEVEL CHANGE is added. However, the option might not be specified, or might be converted to SHRLEVEL REFERENCE for some generated REORG index statements. SHRLEVEL CHANGE is processed based on SHRLEVEL REFERENCE restrictions that are described in the DB2 Utility Reference manual.
R
SHRLEVEL REFERENCE is added. However, the option might not be specified for some generated REORG index statements. SHRLEVEL REFERENCE is processed based on SHRLEVEL REFERENCE restrictions that are described in the DB2 Utility Reference manual.
blank
The SHRLEVEL option is not added.
Default:
blank

util_reorg_index_sortdevt
The util_reorg_index_sortdevt parameter specifies the SORTDEVT option for generated REORG INDEX utility statements.
Values:
A valid SORTDEVT value for REORG INDEX, blank
A valid SORTDEVT value for REORG INDEX
The SORTDEVT option is added with the specified value, for example the SORTDEVT device-type value.
blank
The SORTDEVT option is not added.
Default:
space_unit_name

util_reorg_index_sortnum
The util_reorg_index_sortnum parameter specifies the SORTNUM option for generated REORG INDEX utility statements.
Values:
A valid SORTNUM value for REORG INDEX, blank
A valid SORTNUM value for REORG INDEX
The SORTNUM option is added with the specified value.
blank
The SORTNUM option is not added.
Default:
4




Update 2
Date of change: July 24, 2014

Topic: Worksheets: Gathering parameter values for Tools Customizer
Change description: Field labels are shortened to allow for an increase in the length of the input field.

Required parameters
Parameter
Required?
Discovered?
Default value
Your value
DB2 Administration Tool load library
      The DB2 Administration Tool load library that's being installed.

      You can specify multiple values for this parameter.

Yes No No default  
Start of changeAdmin Tool SADBEXECEnd of change
      The DB2 Administration Tool REXX library that's being installed.

      You can specify multiple values for this parameter.

Yes No No default  
Start of changeCustomized Table libEnd of change
      Enter the table library that contains the Customized table ADBTPARM. In general, this is the Target Customized table library that's specified during the DISCOVER process. For new installs, the DISCOVER option is not applicable. Therefore, it is recommended to specify the DB2 Administration Tool table library.
Yes No No default  
Start of changeAdmin Tool HLQEnd of change
      The high-level qualifier of the DB2 Administration Tool data sets that will be used by the generated customization jobs.
Yes No ADBB10  
.
.
.
Steps and parameters for the General customization task
Step or parameter
Required?
Discovered?
Default value
Your value
Customize
      Creates the job that defines the general DB2 Administration Tool parameters.
Yes No Selected  
Start of changeCM Batch PROCLIBEnd of change
      Enter the name of the library that will contain DB2 Admin JCL procedures. If left blank the default is (Admin HLQ).ADBTCZ.PROCLIB.
Yes Yes, if specified in V10.2. Otherwise, no. ADBB10.ADBTCZ.

PROCLIB

 
Start of change
Object Comparison Tool HLQEnd of change
      Enter the high-level qualifier of the DB2 Object Comparison Tool. This is used to customize change management jobs and procedures.
Yes -
.
.
.

Start of changeUser cmds lib(mbr)End of change
      User commands library and member.
Yes - No default  
.
.
.

Start of changeREXX user exit libEnd of change
      The data set names for the REXX user exits used to specify overwrite values for masking fields DSSIZE, PRIQTY, SECQTY, DEFER, and DEFINE.

      You can specify multiple values for this parameter.

Yes Yes No default  
Enable DB2 Cloning Tool
      Launch DB2 Cloning Tool from within DB2 Administration Tool as an optional choice for migrating objects/data. Select YES to enable this option, NO to disable.
Yes Yes, if specified in V10.2. Otherwise, no. NO  
Start of changeCloning Tool CLIST libEnd of change
      Specify the CLIST library that contains the DB2 Cloning Tool invocation CLIST.
Yes Yes, if specified in V10.2. Otherwise, no. No default  
Enable DB2 Table Editor
      Launch DB2 Table Editor from within DB2 Administration Tool as an optional choice to quickly access, update, and delete data. Select YES to enable this option, NO to disable.
Yes Yes, if specified in V10.2. Otherwise, no. NO  
Start of changeTable Editor CLIST(mbr)End of change
      Specify the startup clist used to invoke the DB2 Table Editor. For example: hlvlqual.SETISAMP(ETI)
Yes Yes, if specified in V10.2. Otherwise, no. No default  
Start of changeAdmin Tool SADBLLIBEnd of change
      Specify the data set name of the DB2 Admin Tool load library. This input field is optional if the LIBDEF(YES) option is used during startup time of DB2 Admin Tool. However, it is required if the LIBDEF(NO) option is used.

      You can specify multiple values for this parameter.

Yes Yes, if specified in V10.2. Otherwise, no. No default  
Start of changeAdmin Tool SADBMLIBEnd of change
      Specify the data set name of the DB2 Admin Tool message library. This input field is optional if the LIBDEF(YES) option is used during startup time of DB2 Admin Tool. However, it is required if the LIBDEF(NO) option is used.

      You can specify multiple values for this parameter.

Yes Yes, if specified in V10.2. Otherwise, no. No default  
Start of changeAdmin Tool SADBPLIBEnd of change
      Specify the data set name of the DB2 Admin Tool panel library. This input field is optional if the LIBDEF(YES) option is used during startup time of DB2 Admin Tool. However, it is required if the LIBDEF(NO) option is used.

      You can specify multiple values for this parameter.

Yes Yes, if specified in V10.2. Otherwise, no. No default  
Start of changeAdmin Tool SADBSLIBEnd of change
      Specify the data set name of the DB2 Admin Tool skeleton library. This input field is optional if the LIBDEF(YES) option is used during startup time of DB2 Admin Tool. However, it is required if the LIBDEF(NO) option is used.

      You can specify multiple values for this parameter.

Yes Yes, if specified in V10.2. Otherwise, no. No default  
Start of changeAdmin Tool SADBTLIBEnd of change
      Specify the data set name of the DB2 Admin Tool table library. This input field is optional if the LIBDEF(YES) option is used during startup time of DB2 Admin Tool. However, it is required if the LIBDEF(NO) option is used.

      You can specify multiple values for this parameter.

Yes Yes, if specified in V10.2. Otherwise, no. No default  
Start of changeAdmin Tool SADBCLSTEnd of change
      Specify the data set name of the DB2 Admin Tool CLIST library. This input field is optional if the LIBDEF(YES) option is used during startup time of DB2 Admin Tool. However, it is required if the LIBDEF(NO) option is used.

      You can specify multiple values for this parameter.

Yes Yes, if specified in V10.2. Otherwise, no. No default  
Start of changeAdmin Tool SADBEXECEnd of change
      Specify the data set name of the DB2 Admin Tool REXX exec library. This input field is optional if the LIBDEF(YES) option is used during startup time of DB2 Admin Tool. However, it is required if the LIBDEF(NO) option is used.

      You can specify multiple values for this parameter.

Yes Yes, if specified in V10.2. Otherwise, no. No default  
Start of changeAdmin Tool SADBDBRMEnd of change
      Specify the data set name of the DB2 Admin Tool DBRM library. This input field is optional if the LIBDEF(YES) option is used during startup time of DB2 Admin Tool. However, it is required if the LIBDEF(NO) option is used.

      You can specify multiple values for this parameter.

Yes Yes, if specified in V10.2. Otherwise, no. No default  
.
.
.
Task: Change Management database
Description
Creates or updates Change Management database objects.

This task is required.

Jobs generated
This task generates the following jobs:

  • ADBCHAab, where ab are alphanumeric characters assigned by Tools Customizer. This job is based on the ADBCHANG template and is in the job_sequence_numberCHANDB2_entry_ID member.
  • ADBCMBAT. This job is based on the ADBCMBAT template and is in the job_sequence_numberCMBAT member.
  • ADBCMBab, where ab are alphanumeric characters assigned by Tools Customizer. This job is based on the ADBCMBSS template and is in the job_sequence_numberCMBSDB2_entry_ID member.

Required authority
The user ID that runs these jobs must have SYSADM or equivalent authority.

Steps and parameters for the Change Management database task
Step or parameter
Required?
Discovered?
Default value
Your value
.
.
.

Start of changeOne PROCLIB for multiple SSIDsEnd of change
      Specify whether the CM Batch producere should support multiple DB2 subsystems.
Yes No YES  
.
.
.
Task: Bind Plans and Packages
Description
Binds plans and packages.

This task is required.

Jobs generated
ADBBINab, where ab are alphanumeric characters assigned by Tools Customizer. This job is based on the ADBBIND template and is in the job_sequence_numberBINDDB2_entry_ID member.
Required authority
The user ID that runs the job must have SYSADM or equivalent authority.

Steps and parameters for the Bind Plans and Packages task

Step or parameter
Required?
Discovered?
Default value
Your value
Customize
      Customize this task with the following parameters.
Yes No Selected  
Start of changeAdmin Tool SADBDBRMEnd of change
      The DB2 Administration Tool library name that contains the database request modules (DBRMs). These DBRMs are inputs to the bind process. Enter a fully-qualified valid data set name.
Yes - ADBB10.SADBDBRM  
BIND OWNER
      Specify the Authorization ID of the Plan and Package owner.
Yes No No default  


Topic: Using table utilities
Change description: New input fields, ERRDDN, DISCARDDN and DISCARDS, are
supported on the LOAD Utilities panel ADB2UTC.

Figure 2. Specify Utility Options - LOAD panel (ADB2UTC)
ADB2UTC n ------------- DSNB Specify Utility Options - LOAD ------------- 18:36
Command ===>                                                                  
                                                                             
Execute utility on table ELACZ.TBTEST1                                        
 using the following options:                                                
                                                                  More:     +
Utility ID . . . . .                                                          
Unloaded data  . . .                                                          
Unloaded how?  . . .            (U - Unload Utility, R - Reorg Utility)        
Table/Col info . . .                                                          
PRESORTED  . . . . . NO         (Yes/No)  
PARALLEL . . . . . .            (Yes, 0-32767)                                
RESUME . . . . . . .            (Yes/No)                                      
SHRLEVEL . . . . . .            (N - None, C - Change)                        
REPLACE  . . . . . .            (Yes/No)                                      
 COPYDDN1 . . . . .            (Primary copy DD name)                        
 COPYDDN2 . . . . .            (Backup copy DD name)                          
 RECOVERYDDN1 . . .            (Remote primary copy DD name)                  
 RECOVERYDDN2 . . .            (Remote backup copy DD name)                  
                                                                               
TABLE schema   . . .           >                                              
     name . . . . .                     > (ALL or ? for table look up)        
SAMPLE . . . . . . .            (Percent to sample during RUNSTATS: 1-100)    
COLUMN name  . . . .                     > (ALL or ? for column look up)      
COLGROUP name  . . .                     > (? for column look up)              
 FREQVAL  . . . . .            (Yes/No)                                      
   COUNT  . . . . .            (1-65535)                                      
   OCCUR  . . . . .            (M - Most, B - Both, L - Least)                
 HISTOGRAM  . . . .            (Yes/No)                                      
   NUMQUANTILES . .            (1-100, default 100)                          
INDEX ALL  . . . . .            (Yes/No)                                      
 HISTOGRAM  . . . .            (Yes/No)                                      
   NUMCOLS  . . . .            (1-64, default 1)                              
   NUMQUANTILES . .            (1-100, default 100)                          
REPORT . . . . . . .            (Yes/No)                                      
UPDATE . . . . . . .            (A - All, P - Accesspath, S - Space, N - None)
                                                                               
FLASHCOPY  . . . . .            (Y - Yes, N - No, C - Consistent)              
KEEPDICTIONARY . . .            (Yes/No)                                      
REUSE  . . . . . . .            (Yes/No)                                      
LOG  . . . . . . . .            (Yes/No/NOC - NOCopypend)                      
WORKDDN1 . . . . . .            (DD name for temporary work file 1)            
WORKDDN2 . . . . . .            (DD name for temporary work file 2)            
SORTKEYS . . . . . .            (Estimated no. of keys for parallel sort or NO)
ENFORCE  . . . . . .            (Yes/No)                                      
ERRDDN . . . . . . .            (DD name for error processing)                
DISCARDDN  . . . . .            (DD name for discarded records)                
DISCARDS . . . . . .            (0 to 2147483647)
                    SORTDEVT . . . . . .            (Device type for sort work files)              
SORTNUM  . . . . . .            (Number of sort work files)                    
SORTWK . . . . . . .            (0-4)                                          
RBALRSN_CONVERSION              (N - None, B - Basic, E - Extended)            
DECFLOAT ROUNDING  .            (Ceiling, Down, Floor, HalfDown, HalfEven,    
                                 HalfUp, Up)                                  
IMPLICIT_TZ  . . . .            (+/-hh:mm)
                                     

Topic: Migrating DB2 objects, data, views, and catalog statistics, Step 2. Generate batch jobs
Change description: Use of the LOAD utility option REPLACE and RESUME to control how the data is loaded into the target system

Start of changeIf you choose to migrate only the data, then use the LOAD utility option REPLACE and RESUME to control how the data is loaded into the target system. Customize the LOAD utility options, as needed, using the UO - Customize utility option command. Set the option 'Use customized utility options' to YES. If customized utility options are not used and 'Use customized utility options' is set to NO, then Migrate uses the default REPLACE and RESUME option generated by the DB2 UNLOAD utility or the High Performance Unload ( HPU ) utility. Other considerations for the REPLACE and RESUME option are as follows:
  • DB2 does not allow using LOAD REPLACE on certain types of tables. When LOAD REPLACE is not allowed but is specified, the REPLACE option is converted to RESUME YES.
  • If not all the tables under a multi-table table space are selected for migration on the source system, the REPLACE option for LOAD utility, if specified, is converted to RESUME YES.
  • If all the tables under a multi-table table space are selected for migration on the source system, the REPLACE option for LOAD utility, if specified, is used. Any additional tables under the table space on the target system remain empty after migration.End of change

Topic: Option K. Packages
Change description: Enhance Option K - Packages (panel ADB21K) to show all plan table rows for a package.

Figure 1. Packages panel (ADB21K)
  ADB21K in ------------------- DB2X Packages --------------- Row 1 to 30 of 104
Command ===> ________________________________________________ Scroll ===> PAGE
                                                                               
Commands:  BIND  REBIND  FREE  VERSIONS  GRANT  ALL  PLANMGMT                          
Line commands:                                                                
 DP - Depend  A - Auth  T - Tables  V - Views  X - Indexes  
 S - Table spaces  Y - Synonyms  Q - Sequences  RB - Rebind  F - Free  B - Bind  
 BC - Bind copy  EN -Enab/disab con  PL - Package lists  P - Local plans  
 GR - Grant  I - Interpret  SQ - SQL in package  LP - List PLAN_TABLE
 
LPA - List all PLAN_TABLE   VE - Versions  D - Databases  RO - Role  
 DET - Package details
                                                         V I V O Quali-   R E D
S  Collection         Name     Owner    Version (trunc)  D S A P fier     L X R
   *                  *        *        *                * * * * *        * * *
-- ------------------ -------- -------- ---------------- - - - - -------- - - -
__ DSNTIAD            DSNTIAD  LLEGARD                   R S Y Y LLEGARD    N  
__ DSNREXX            DSNREXX  LLEGARD  V10R1            B S Y Y LLEGARD    N  
__ DSNREXUR           DSNREXX  LLEGARD  V10R1            B U Y Y LLEGARD    N  
__ DSNREXCS           DSNREXX  LLEGARD  V10R1            B S Y Y LLEGARD    N  
__ DSNREXRS           DSNREXX  LLEGARD  V10R1            B T Y Y LLEGARD    N  
__ DSNREXRR           DSNREXX  LLEGARD  V10R1            B R Y Y LLEGARD    N  
__ DSNTIAP            DSNTIAP  DB2ADM                    R   Y Y DB2ADM     N  
__ DSNESPCS           DSNESM68 DB2ADM                    R S Y Y DB2ADM     N  
__ DSNESPRR           DSNESM68 DB2ADM                    R R Y Y DB2ADM     N  
__ DSNESPUR           DSNESM68 DB2ADM                    R U Y Y DB2ADM     N  
__ DSNEDCL            DSNECP68 DB2ADM   V10R1            R S Y Y DB2ADM     N  
__ DSNUTIL            DSNUGSQL DB2ADM   V10R1            B S Y Y DB2ADM     N  
__ DSNUT101           DSNUGSQL DB2ADM   V10R1            B S Y Y DB2ADM     N  
__ DSNADM             DSNADMJF LLEGARD  V10R1            R S Y Y LLEGARD    N  
__ DSNADM             DSNADMTA LLEGARD  V10R1            R S Y Y LLEGARD  C N  
__ DSNADM             DSNADMTR LLEGARD  V10R1            R S Y Y LLEGARD  C N  
__ DSNADM             DSNADMTU LLEGARD  V10R1            R S N Y LLEGARD  C N  


Topic: DB2 Admin line commands
Change description: Add LPA to the list of special line commands

Table 2. DB2 Admin special line commands

Command
Description
LPA List all PLAN_TABLE rows for a package.

Topic: DB2 catalog records that have default masks
Change description: DB2 Administration Tool now has the ability to overwrite attributes
TRACKMOD and DATA CAPTURE using the GEN function, export changes function, multi-target changes or the WSL cloning function with masking for objects table spaces and tables.


DB2 Catalog record
Catalog column
Most specific mask names
Comments
SYSTABLEPART TSNAME TSNAME  
DBNAME DBNAME  
IXNAME IXNAME  
IXCREATOR OWNER  
IXOWNER  
STORNAME TSSGNAME  
VCATNAME VCATNAME  
COMPRESS COMPRESS  
HASHSPACE HASHSPC  
TRACKMOD TRACKMOD
SYSTABLES NAME TBNAME  
CREATOR OWNER  
TBOWNER  
DBNAME DBNAME  
TSNAME TSNAME  
EDPROC PGMNAME  
VALPROC PGMNAME  
TBCREATOR OWNER  
TBOWNER  
TBNAME TBNAME  
AUDITING AUDIT  
DATACAPTURE DCAPTURE

Topic: Supplying input to the batch restart program (ADBTEP2)
Change description: Added the functional comment statements: --#SET ACCEPT_RC (ON/OFF), and #SET MAXERRORS.

Functional comments
You can include the following functional comments:

--#SET ROWS_FETCH n
where n is a non-negative integer that indicates the maximum number of rows to be FETCHed for each subsequent SELECT statement. Use -1 to indicate that all rows should be fetched.

--#SET ROWS_OUT n
where n is a non-negative integer that indicates the maximum number of rows to be output for each subsequent SELECT statement. Use -1 to indicate that all rows should be output.

--#SET TERMINATOR n
where n is a one-byte character to be used to terminate the next SQL statement. Any character is valid, except blank, comma, single quotation, double quotation, underscore, and parentheses.

Start of change--#SET ACCEPT_RC (ON/OFF) m n
where mor n is the SQLCODE that can be accepted for the SQL statements before the program stops. The maximum number of SQLCODE that can be listed is 5. Using --#SET ACCEPT_RC m n can accept SQLCODE m or n for the following single SQL statement. Using --#SET ACCEPT_RC ON m n can accept SQLCODE m or n for the following multiple SQL statements until the next --#SET ACCEPT_RC OFF occurs. If no SQLCODE is provided after --#SET ACCEPT_RC (ON/OFF), it means all SQLCODEs can be accepted. End of change

Start of change--#SET MAXERRORS n
where n is the number of DSN commands that can fail before the program stops. Use -1 to indicate that the program should tolerate an unlimited number of errors for DSN commands. End of change

IBM® reserves the right to use additional parameters in these functional comment statements. These parameters might be present in the statements that DB2 Admin generates for ADBTEP2. Do not modify these statements unless you are requested to do so by your IBM service representative.


Topic: Parameters passed to the ADBTEP2 program
Change description: Added the parameters: SQLFORMAT, and SQLCOMNT.

Parameters passed under the DD name of ADBTEPIN

The following parameters are generated automatically and are passed to the ADBTEP2 program in a data set with a DD name of ADBTEPIN:

Advisory Auto Rebuild
The Advisory Auto Rebuild parameter determines if the Batch Restart Program initiates a REBUILD of an index when an object is in the ARBDP state.

  • YES - A REBUILD is attempted.
  • NO - A REBUILD is not attempted.

No is the default.

For more information about the rebuild-pending states, see the DB2 V10 Utilities Guide.

Tip: To prevent the ADBTEP2 program from scheduling any automatic REBUILDs, you must set both the Auto Rebuild and Advisory Auto Rebuild parameters to No.


Advisory Auto Reorg
The Advisory Auto Reorg parameter determines if the Batch Restart Program initiates a REORG of a table space when an object is in the AREOR,AREO* state.

  • YES - A REORG is attempted.
  • NO - A REORG is not attempted.

No is the default.

For more information about the rebuild-pending states, see the DB2 V10 Utilities Guide.

Tip: To prevent the ADBTEP2 program from scheduling any automatic REORGs you must set both the Auto Reorg and Advisory Auto Reorg parameters to No.


Auto Rebuild
The Auto Rebuild parameter determines if the Batch Restart Program initiates a REBUILD of an index when an object is in the RPDB. RPDB*, or PSRBD state.

  • YES - A REBUILD is attempted.
  • NO - A REBUILD is not attempted.

No is the default.

For more information about the rebuild-pending states, see the DB2 V10 Utilities Guide.

Tip: To prevent the ADBTEP2 program from scheduling any automatic REBUILDs, you must set both the Auto Rebuild and Advisory Auto Rebuild parameters to No.


Auto Reorg
The Auto Reorg parameter determines if the Batch Restart Program initiates a REORG of a table space when an object is in the REORP state.

  • YES - A REORG is attempted.
  • NO - A REORG is not attempted.

No is the default.

For more information about the reorg-pending states, see the DB2 V10 Utilities Guide.

Tip: To prevent the ADBTEP2 program from scheduling any automatic REORGs you must set both the Auto Reorg and Advisory Auto Reorg parameters to No.


Autocheck
Certain SQL or utility operations can place an object into check-pending state. If you set the Autocheck (AC) parameter value to YES, ADBTEP2 tracks the following statements and processes that can place an object in check-pending state. If a statement or process is encountered, ADBTEP2 performs an automatic CHECK DATA to remove the check-pending state. The default value for AC is NO.

ADBTEP2 tracks the following statements:

  • ALTER TABLE … ADD FOREIGN KEY
  • ALTER TABLE …. ADD CONSTRAINT
  • LOAD REPLACE
  • LOAD ENFORCE(NO)
  • RECOVER PIT

ADBTEP2 tracks the following processes:
  • COPY utility - perform auto-check prior to COPY
  • CHECK DATA utility – perform auto-check after CHECKEND
  • A final auto-check at the end of the SYSIN input stream
Restriction: DB2 Admin builds the CHECK DATA statement and all CHECK parameters used during auto-check processing. You cannot specify any other parameters.

BINDERROR(MAXE, SAVE, IGNORE)
Specifies how BIND or REBIND errors that are processed by ADBTEP2 are to be handled.
MAXE
The failing BIND or REBIND command is written to the ADBHOLD table. The value that is specified for the MAXE parameter determines whether ADBTEP2 continues to process the input stream:
  • If MAXE(0) is specified or if MAXE() is omitted, processing stops.
  • If MAXE(-1) is specified, processing continues.
  • If a value greater than 0 is specified for MAXE, the MAXE counter is incremented by 1, and processing stops if the number of errors has exceeded the maximum number of allowed failures.
SAVE
The failing BIND or REBIND command is written to the ADBHOLD table. ADBTEP2 continues to process the input stream.
IGNORE
The failing BIND or REBIND command is ignored and is not written to the ADBHOLD table. ADBTEP2 continues to process the input stream.

DB2 Pending Changes options (DB2 Version 10 New Function mode only):
The Check at DROP parameter controls if a check is made to avoid losing any DB2 pending changes as part of the DROP action.
  • YES - The DROP is not performed if a DB2 pending change exists.
  • NO - The DROP is performed without checking for pending changes.

Log DIAG
Controls whether diagnostic messages are written to the ADBDIAG file.
Yes
Messages are written to this file, which IBM® Software Support can use to determine the cause of a failure.
No
Messages are not written.

LOAD Summary Report
Controls if the LOAD summary report is produced as part of the ADBTEP2 run.
Yes
The LOAD Summary report is produced.
No
The LOAD Summary report is not produced.

LOB/XML IC Unload
Controls the behavior of UNLOAD TABLESPACE statements if an unload from an image copy of a table space is requested and a table in that table space contains a LOB or XML column.
E
The ADBTEP2 program should end with an error.
U
An unload of the base object should be performed instead.

Maxerrors
The number of DSN commands that can fail before the batch restart job ADBTEP2 is stopped:
-1
All errors are ignored. The batch job is not stopped for any error.
0
No errors are allowed. The batch job is stopped on the first error.
1-99
The specified number of errors are ignored. The batch job is stopped on the next DSN command that fails. For example, if you specify 5, the batch job is stopped when the sixth DSN command fails.

Any failing DSN commands that are ignored are skipped and are written to the ADBHOLD table. When the job ends, if any DSN commands have failed, the restart action field in the checkpoint table indicates that there are held records. Depending on the restart option, the held records are reprocessed when the job is restarted.

Missing IC Unload
Controls the behavior of UNLOAD TABLESPACE statements if an unload from an image copy of a table space is requested and no image copy can be found.
E
The ADBTEP2 program should end with an error.
U
An unload of the base object should be performed instead.

Start of changeSQLFORMAT
Specifies how ADBTEP2 pre-processes SQL statements before passing them to DB2. Currently, ADBTEP2 only supports option SQLCOMNT.
SQLCOMNT
This mode is suitable for all SQL, but it is intended primarily for SQL procedural language processing. When this option is in effect, ADBTEP2 does not discard SQL comments, and automatically terminates each SQL comment with a line feed character (hex 25) unless the comment is already terminated by one or more line formatting characters. Note that the option SQLFORMAT = 'SQLCOMNT' must be added manually to ADBTEPIN DD.End of change


Topic: Making changes using Change Management batch interface, Parameter definitions
Change description: The following new or modified CM Batch parameter can be used to manage the data set attribute identified by each parameter.

admin_dataset_bufno
The admin_dataset_bufno parameter specifies the BUFNO attribute of the TSO ALLOCATE statement for the DB2 Admin data set. The BUFNO attribute is for the number of buffers to be assigned for data control blocks. For more information, see the admin_dataset_type parameter.
Values:
An integer value 1-255, blank
blank
The BUFNO attribute is not specified for the ALLOCATE statement.
Default:
blank

admin_dataset_dataclas
The admin_dataset_dataclas parameter specifies the DATACLAS attribute of the TSO ALLOCATE statement for the DB2 Admin data set. The DATACLAS attribute is for the data class name. For more information, see the admin_dataset_type parameter.
Values:
A valid data class name
DB2 Admin does not validate this value. If an invalid value is specified, an error message is generated from TSO when the allocate of the data set is attempted. DB2 Admin then sets the RECFM, LRECL, and BLKSIZE attributes by specifying these attributes on the ALLOCATE statement. By default, DB2 Admin specifies the space attributes on the allocate statement but you can omit the space attributes from the ALLOCATE statement by specifying admin_dataset_space_priqty = '<NONE>' for the DB2 Admin.
blank
The DATACLAS attribute is not specified for the ALLOCATE statement.
Default:
blank

admin_dataset_device_unit
The admin_dataset_device_unit parameter specifies the device unit for the DB2 Admin data set. For more information, see the admin_dataset_type parameter.
Values:
A valid device unit, <NONE>
<NONE>
Specifies that the UNIT clause is omitted from the ALLOCATE statement.
Default:
space_unit_name

admin_dataset_dir
The admin_dataset_dir parameter specifies the DIR attribute of the TSO ALLOCATE statement for the DB2 Admin data set. The DIR attribute is for the number of directory blocks. For more information, see the admin_dataset_type parameter. This parameter is only used for the following types of DB2 Admin data sets: IFF, DELTA, DDL SRCVF, TGTVF, MTC.

If the SPACE(priqty,secqty) clause is omitted, then no default value is specified.

Values:
An integer greater than zero, blank
blank
If the SPACE(priqty,secqty) clause is not to be omitted, specifies that the following default values are used for the DB2 Admin data set type that is in effect:

  • IFF: 60. A user specified value for directory blocks that you specify only if the DB2 Admin default is insufficient for the change that is being analyzed.
  • DELTA: 60
  • DDL: 60
  • SRCVF: 60
  • TGTVF: 60
  • MTC: 60
Default:
blank

  admin_dataset_dsntype
The admin_dataset_dsntype parameter specifies the DSNTYPE attribute of the TSO ALLOCATE statement for the DB2 Admin data set. The DSNTYPE attribute is for the type of data set. For more information, see the admin_dataset_type parameter. This parameter is only used for the following types of DB2 Admin data sets: IFF, DELTA, DDL SRCVF, TGTVF, MTC.
Values:
LIBRARY, PDS, blank
blank
For data set type IFF, the default is PDS. Otherwise the DSNTYPE attribute is not added to the ALLOCATE statement.
Default:
blank

admin_dataset_expdt
The admin_dataset_expdt parameter specifies the EXPDT attribute of the TSO ALLOCATE statement for the DB2 Admin data set. The EXPDT attribute is an expiration date. For more information, see the admin_dataset_type parameter. This parameter is mutually exclusive with the admin_dataset_retpd parameter.
Values:
A valid expiration date as defined for the EXPDT attribute for the TSO ALLOCATE statement, blank
blank
The EXPDT attribute is not specified for the ALLOCATE statement.
Default:
blank

admin_dataset_maxvol
The admin_dataset_maxvol parameter specifies the MAXVOL attribute of the TSO ALLOCATE statement for the DB2 Admin data set. For more information, see the admin_dataset_type parameter.
Values:
A valid maxvol value as defined by the TSO ALLOCATE statement
DB2 Admin does not validate this value. If an invalid value is specified, an error message is generated from TSO when the allocate of the data set is attempted.
blank
The MAXVOL attribute is not specified for the ALLOCATE statement.
Default:
blank
   
admin_dataset_mgmtclas
The admin_dataset_mgmtclas parameter specifies the MGMTCLAS attribute of the TSO ALLOCATE statement for the DB2 Admin data set. The MGMTCLAS attribute is for the management class name. For more information, see the admin_dataset_type parameter.
Values:
A valid management class name
DB2 Admin does not validate this value. If an invalid value is specified, an error message is generated from TSO when the allocate of the data set is attempted.
blank
The MGMTCLAS attribute is not specified for the ALLOCATE statement.
Default:
blank

admin_dataset_retpd
The admin_dataset_retpd parameter specifies the RETPD attribute of the TSO ALLOCATE statement for the DB2 Admin data set. The RETPD attribute is a retention period specified in number of days. For more information, see the admin_dataset_type parameter. This parameter is mutually exclusive with the admin_dataset_expdt parameter.
Values:
An integer value representing the number of days, blank
blank
The RETPD attribute is not specified for the ALLOCATE statement.
Default:
blank

admin_dataset_space_priqty
The admin_dataset_space_priqty parameter specifies the primary quantity for the DB2 Admin data set. For more information, see the admin_dataset_type parameter.
Values:
A valid PRIQTY value, Start of change<NONE>, End of changeblank
Start of change<NONE> End of change
Specifies that the SPACE(priqty,secqty), unit of space clauses, and space directory attributes be omitted from the ALLOCATE statement.
blank
Specifies that the following default values are to be used for the indicated DB2 Admin data set type that is in effect:
  • CHG: 10
  • DDL: 10
  • DELTA: 10
  • IFF: 2
  • MTC: 10
  • SRCVF: 10
  • TGTVF: 10
Default:
blank

admin_dataset_storclas
The admin_dataset_storclas parameter specifies the STORCLAS attribute of the TSO ALLOCATE statement for the DB2 Admin data set. The STORCLAS attribute is for the storage class name. For more information, see the admin_dataset_type parameter.
Values:
A valid storage class name
DB2 Admin does not validate this value. If an invalid value is specified, an error message is generated from TSO when the allocate of the data set is attempted.
blank
The STORCLAS attribute is not specified for the ALLOCATE statement.
Default:
blank

admin_dataset_volume
The admin_dataset_volume parameter the VOLUME attribute of the TSO ALLOCATE statement for the DB2 Admin data set. For more information, see the admin_dataset_type parameter.
Values:
One or more serial numbers separated by a comma, blank
blank
The VOLUME attribute is not specified for the ALLOCATE statement.
Default:
blank





Update 1
Date of change: April 29, 2014
Change description: Checking syntax and the semantics of SQL statements

Topic: The Change Management process, Analyzing a change

Analyzing a change
A normal change must be analyzed before the change can be applied to the objects. When you issue the command to analyze a change, DB2 Admin generates a batch job that you submit.
The batch job analyzes how the change modifies existing objects, both in DB2 and in any of the prerequisite changes, and creates a work statement list (WSL) that will be used to run the changes. During the analyze process, the embedded SQL statements semantics are checked and DB2 Admin automatically generates two new base versions:
  • A target version, which represents the objects in the DB2 catalog plus any prerequisite changes
  • A source version, which is the target version plus the changes for the change that being analyzed
DB2 Admin then invokes DB2 Object Comparison Tool to compare the source and target base versions to generate a WSL that will be used in the run process to apply the changes. The base versions that are used in this process are temporary and are not saved.

Topic: Modifying a change

Modifying a change
You can modify the change statements in an existing change if the change is in INITIAL, DEFINED, or ANALYZED status.

About this task
However, modifying an existing change is considered a manual intervention and is not recommended for several reasons. When you modify an existing change, DB2® Admin cannot apply virtual changes or determine whether pending changes exist. Modifying an existing change can also impact other existing changes substantially. For example, the change you are modifying might be a pending change that was applied when another change was created.
During the process of modifying a change, DB2 Admin checks only the syntax of each change statements. When you modify change statements through the Change Statements panel (ADB2C1S) panel, for example, syntax checking is completed at the time that you exit the panel. Semantic checking is done during the analyze process.

Topic: Importing changes

Importing changes
You can create a change by importing SQL statements from a data set. When you import the statements, a new change is created and registered. You can import multiple delta changes as a group in one change.

About this task
When importing changes:

  • You can import SQL statements (DDL) and you can import delta changes as generated by the DB2® Object Comparison Tool.
  • DB2 Object Comparison Tool will create a delta change if "CHANGE" is specified for "Generate apply jobs" on panel GOC5 (this generates parameter CMDELTA for GOC2CMP).
  • Importing an DB2 Object Comparison Tool change data set that is not generated as a delta change can have unwanted side effects. This cannot be checked during import.
  • You can import a mix of SQL statements and delta changes (as long as they logically relate).

If the imported SQL statements affect objects for which pending changes exist, you determine whether the imported change becomes a prerequisite change for those pending changes or not.

You can create a single change by importing multiple files at the same time. Each file must be one of the types mentioned in the following list. All types can be part of the same Import.

The data sets from which you are importing the SQL statements must be either:

  • The delta changes data set that was generated when changes were promoted with Change Management from another system. Thus, you can import the changes that were promoted from another system that uses Change Management.
  • The delta changes data set that DB2 Object Comparison Tool generated when objects were compared. DB2 Object Comparison Tool uses the worklist name for this data set (qualifier1.worklist_name.CHG). The worklist name will be generated by specifying CHANGE in the "Generate apply jobs" field on panel GOC5. You can specify a data set name and optionally specify a member name if the data set is partitioned.
  • A data set that contains SQL statements that meets these requirements:
  • A fixed-block sequential data set (RECFM=Fx,LRECL=80)
  • A member of a partitioned data set with a logical record length of 80 (RECFM=Fx,LRECL=80)

During the import process, the syntax of each change statements in imported SQL statements is checked. However, semantic checking is done during the analyze process.

If you are importing a delta changes data set, the data set must represent one generated delta changes file. Concatenating or merging multiple data sets into one can cause unpredictable results because statements are reordered during the import process.

When you import SQL statements into a change, the subsystem being used for the IMPORT must support the SQL statements that you are importing..

Publication number

SC19-4134-02

Copyright date

2014

Original publication date

2014/3/31

Rate this page:

(0 users)Average rating

Add comments

Document information


More support for:

DB2 Tools for z/OS
DB2 Administration Tool

Software version:

11.1.0

Operating system(s):

z/OS

Reference #:

7041314

Modified date:

2014-08-21

Translate my page

Machine Translation

Content navigation