DB2 Tools corner: Introducing the IBM-supported batch interface for change management in DB2 Administration Tool for z/OS V10.1 and DB2 Object Comparison Tool for z/OS V10.1

Now you can use the new batch interface enhancement for managing changes to DB2 for z/OS objects and authorizations with DB2 Administration Tool for z/OS and DB2 Object Comparison Tool for z/OS. This enhancement lets you create, customize, and reuse batch jobs to match how you manage changes to DB2 for z/OS.

John Dembinski (dembinski@us.ibm.com), Advisory Software Engineer, IBM

John Dembinski photoJohn Dembinski is a developer on the IBM DB2 Administration Tool for z/OS and DB2 Object Comparison Tool for z/OS team. Some of his focuses include DB2 for z/OS DDL reverse engineering and change management. He has contributed to a Redbook publication for change management using DB2 Administration Tool and DB2 Object Comparison Tool, and he has presented both products for several customers. John joined IBM in 2004 after completing his bachelor's degree in computer science at UCLA (University of California, Los Angeles).



10 May 2012

Overview

The user interface for the change management function in DB2 Administration Tool for z/OS V10.1 (DB2 Admin) and DB2 Object Comparison Tool for z/OS V10.1 (Object Comparison Tool) is ISPF panel based. In response to requests from customers, a batch interface for the change management function (CM batch) is now available in PTF UK76851 for DB2 Admin and PTF UK76861 for Object Comparison Tool. This article describes CM batch, lists the main benefits of CM batch, and shows how to use CM batch to manage a change to DB2 for z/OS across multiple target environments.

By using the ISPF user interface for the DB2 Admin and Object Comparison Tool change management function, you initiate an action for a change and specify options on ISPF panels. Then, the product builds a batch job to do the work in batch. This batch job is created for the requested change and for the DB2 subsystem to which the product is currently connected. You do these steps for each change on each DB2 target environment that needs the change. The ISPF user interface offers the following benefits:

  • Quick access to help information.
  • Organized options on each panel and across panels.
  • Options that are specified on a panel are stored in an ISPF profile and reused across DB2 Admin sessions.
  • Assistance for new users of change management through the various stages of managing a change.

Registering and managing multiple changes across multiple DB2 for z/OS target environments can be a repetitive process. CM batch provides an automated solution that enables you to define your own batch jobs to register and manage changes, and to reuse these jobs without using the ISPF user interface. CM batch helps to improve DBA productivity by providing support for the following features:

  • The main change management processes.
  • Parameter profiles that can be reused for different changes and on different DB2 subsystems.
  • Dynamic selection of the parameter profiles to use at run time based on a user-specified value (e.g., the DB2 SSID is used to determine the parameter profile to use).
  • Definitions of patterns for the parameters (e.g., naming patterns for data sets).
  • Storage of your DB2 TEMPLATE statements in a file that can be reused when managing multiple changes.
  • Reuse of the CM batch jobs for different changes or for managing a change across different DB2 target environments.

The following sections describe some of the main features of CM batch in more detail, and an example shows a technical illustration of how CM batch can be used to manage a change to DB2 for z/OS across multiple target environments.

Change management interfaces: Online, batch, or both

The CM batch interface can be used to manage changes that are imported (registered) by using CM batch, but it also can be used to manage a change that was created online by using the DB2 Admin ISPF user interface. Likewise, a change that was imported by using CM batch can be managed online (i.e., the change was imported by using CM batch, but it will be analyzed by using the DB2 Admin ISPF user interface). Because DB2 Admin supports the ISPF user interface and the batch interface interchangeably, you are not locked into using one interface or the other. Instead, you can choose which interface to use at any point in the change management process.

CM batch: What can it do?

The following table describes the functions of change management that are supported by CM batch:

Table 1. Change management functions that are supported by CM batch
ActionResult
Import maskImports DB2 Admin and Object Comparison Tool masking statements and stores them in the DB2 Admin and Object Comparison Tool change management database. The mask can be used when you import a change by referencing the mask name.
Import ignoreImports DB2 Admin and Object Comparison Tool ignore specifications and stores them in the DB2 Admin and Object Comparison Tool change management database. The ignore can be used when you import a change by referencing the ignore name.
Import (register) a changeImports the change statements (DDL or a DB2 Admin and Object Comparison Tool delta change file) into a new change entry in the DB2 Admin and Object Comparison Tool change management database.

Delta change files are created by DB2 Admin and Object Comparison Tool, and they record the essence of the change (e.g., insert new column C2 INT before C3). The next step, analyze, determines how to implement the change on the DB2 subsystem.

Analyze a changeDetermines how to implement the change on the DB2 subsystem, generates a report that describes each change to an object, and generates the statements (SQL, utilities, and so on) that are needed to implement the change.

For example, for a registered change that inserted a new column named C2, the analyze process determines that the table and its children objects need to be dropped and re-created, as shown in the following statements. These statements do not represent actual code.

Unload Table T1;
Drop Table T1;
Create Table T1 (with column C2);
Create index IX1 on T1 … ;
Etc.
Load table T1;
(other utilities that you requested such as 
runstats, image copy, rebinds, reorg, and so on.)
Run a changeImplements the change and runs the statements that are generated while the change is analyzed.

The run job is generated while the change is analyzed, and it is available before the change is implemented.

Recover a changeWithdraws a change. This function will undo a change.

The recover job is generated while the change is analyzed, and it is available before the change is implemented.

For example, the recover job for inserting column C2 would contain the following statements. These statements do not represent actual code.

Unload table T1;
Drop table T1;
Create Table T1 (without column C2);
Create index ix1 on t1 … ;
Etc.
Load table T1;
(other utilities that you requested such as 
runstats, image copy, rebinds, reorg, and so on.)

CM batch parameters: Customize how DB2 for z/OS object changes are managed

The CM batch interface has parameters to give you control of various aspects of change management, some of which include:

  • The data set prefix for data sets that are dynamically created by the CM batch interface.
  • The PDS name to store work statement list (WSL) files.
  • The PDS name to store JCL run jobs for running changes.
  • The default change owner when creating a new change.
  • The default change name when creating a new change.
  • Analysis report.
  • Utility options.
  • DB2 Admin templates.
  • And more.

Additionally, there are parameters that control which action that the CM batch interface will do when it is called. The following table shows actions that CM batch can do, the name of the parameter that sets the action, and the values that the parameter can have:

Table 2. List of CM batch actions
ActionParameter nameParameter values
Import maskaction_import_maskY|N
Import ignoreaction_import_ignoreY|N
Import changeaction_import_changeY|N
Analyze changeaction_analyze_ignoreY|N
Build run jobaction_build_run_jobY|N
Run changeaction_run_changeY|N
Recover changeaction_recover_changeY|N

One or more of these parameters can be specified at the same time. However, the recover change action must be done in its own job step (i.e., you cannot run and recover a change in the same invocation of CM batch).

Every CM batch parameter except for the SSID parameter has a product default value.

CM batch parameter profiles: Customize parameter settings once and reuse them

When CM batch is invoked it reads from two files to get the parameters. First, it reads from PROFPARM DD, and then it reads the PARMS DD. The following table shows examples of how each file is used:

Table 3. CM batch parameter files
File nameExample usage
PROFPARM
  • Parameter settings common across DB2 systems
  • Parameter settings that are for specific DB2 systems
PARMS
  • Parameter settings that are specific for one instance of CM batch

Examples

In the following example CM batch JCL procedure definition, the PROFPARM DD is defined to reference the COMMON.SYSTEM.PARMS data set. This data set contains parameter settings that are the default settings each time when CM batch is invoked. This data set is considered to be a parameter profile.

The PROFPARM DD is also defined to reference a PDS member. The PDS member name is resolved at run time when CM batch is invoked, and the member name is the SSID. The PDS member contains parameter settings that are specific to that SSID and are the default settings each time when CM batch is invoked on that SSID. Any parameter that is specified in the DB2.PARMS(&SSID) data set will override the parameter that is specified in the COMMON.SYSTEM.PARMS data set. This setup of dynamically resolving a PDS member name is an example of a parameter profile being dynamically selected at run time.

The following example shows a definition of a CM batch JCL procedure (GOCCM):

Listing 1. Example of the PROFPARM DD definition in a CM batch JCL procedure

//GOCCM   PROC SSID=,PLAN=,SPCUNIT=SYSDA              
//PROFPARM  DD DISP=SHR,DSN=COMMON.SYSTEM.PARMS
//          DD DISP=SHR,DSN=DB2.PARMS(&SSID) 
…
//GOCCM   PEND

The following example shows a sample job step to invoke the CM batch JCL procedure (GOCCM) with the PARMS DD. Any parameter that is specified in the PARMS DD will override the same parameter that is specified in the PROFPARM DD.

Listing 2. Example of the PARMS DD when CM batch is invoked

//CMBATCH  EXEC GOCCM,SSID=DSNA,PLAN=ADBDEV    
//PARMS DD *                                   
 parameters specified here override those specified in PROFPARM
/*

CM batch parameter symbol variables: Define your naming patterns or other patterns

A value that you specify for a parameter can contain symbol variables that are resolved at run time. Using symbol variables is optional, and you can use them in any CM batch parameter that is specified in the PROFPARM or PARMS files. When you use symbol variables, you can set naming patterns for data set names or any other parameter for which you want to define a pattern.

The symbol variable feature that is used in CM batch is based on the symbol variable feature for the DSN attribute of a DB2 TEMPLATE statement. For the symbol variables that are the same between CM batch and the DB2 TEMPLATE DSN attribute, the same symbol variable syntax is used to provide a consistent user experience.

Product-defined symbol variables

The following table shows symbol variables that are defined by the product:

Table 4. Product-defined symbol variables
Symbol variableDescription
&SSID. or &SS.The subsystem ID
&CURSQLID.The CURRENT SQLID
&CURTS.The CURRENT TIMESTAMP
&JOBNAME. or &JO.The z/OS job name
&USERID. or &US.The user ID of the person who is running the job
&YEAR. or &YE.The four-digit year (YYYY)
&MONTH. or &MO.The two-digit month (MM)
&DAY. or &DA.The two-digit day (DD)
&TIME. or &TI.The time in hours, minutes, and seconds (HHMMSS)
&HOUR. or &HO.The HH in &TIME.
&MINUTE. or &MI.The MM in &TIME.
&SECOND. or &SC.The SS in &TIME.
&CHGTAG.This symbol variable resolves to different values at different times depending on what type of change is being processed. When an original change is processed, the symbol variable resolves to C(change-ID). When a recover change is processed, the symbol variable resolves to R(change-ID). (Change-ID) is the ID of the original change.

The following examples show how symbol variables can resolve: For an original change with ID of 45, when processing the original change, &CHGTAG. resolves to C0000045. If this change has a recover change, when processing the recover change, &CHGTAG. resolves to R0000045.

  • For an original change with ID of 45, when processing the original change, &CHGTAG. resolves to C0000045.
  • If this change has a recover change, when processing the recover change, &CHGTAG. resolves to R0000045.

The following example shows a product-defined symbol variable:

prefix_for_data_sets = '&USERID.'

User-defined symbol variables

You can define your own symbol variable and use it just like you would use a product-defined symbol variable.

The following example shows a symbol variable that is defined by a user:

prefix_for_data_sets = '&USERID..&WORK#.'
symbol_name = '&WORK#.' symbol_value = 'W123';

If the TSO ID is U123, at run time prefix_for_data_sets will resolve to U123.W123. In this example, WORK# is a work item number that you define that is specific to your process.

CM batch: Setup overview

The CM batch setup requires you to customize the GOCCM SAMP member that is part of Object Comparison Tool. CM batch is implemented by using a JCL procedure, and GOCCM SAMP is a sample of this JCL procedure. The minimum setup that is required involves customizing GOCCM SAMP to set various data set names, such as your DB2 data set names, DB2 Admin and Object Comparison tool data set names, ISPF data set names, and so on.

In the following example, your customized GOCCM JCL procedure is assumed to be defined in ADB.CUST.PROCLIB. In actual implementation, you can choose the data set in which the GOCCM JCL procedure will be stored.

Example: Deploy a change to multiple DB2 for z/OS target environments

In a sample environment, two DB2 subsystems, DSNA and DSNB, access the same DASD. DSNA contains the model database D0 and two additional databases, D1 and D2. DSNB contains two databases, D1 and D2. The D1 and D2 databases in each subsystem are exact copies of the database model except they have different database names and schema names. Any change to the database model D0 must be done for databases D1 and D2 on DSNA and DSNB.

The following table shows a summary of a sample DB2 for z/OS environment:

Table 5. Summary of a sample DB2 for z/OS environment
DB2 subsystemDatabase nameSchema name
DSNA
D0SCH0
D1SCH1
D2SCH2
DSNB
D1SCH1
D2SCH2

The following definition is the starting definition of the model database:

Listing 3. Starting definition of the model database D0

SET CURRENT SQLID = 'SYSADM';
SET SCHEMA = 'SCH0';
CREATE DATABASE D0;
CREATE TABLE T1
 (C1 INT
 ,C3 INT)
 IN DATABASE D0;
CREATE UNIQUE INDEX IX1_T1
  ON T1 (C1);

When a change is imported into subsystem DSNA or DSNB for database D1, masking must be done for the database and schema names. The following table shows the required masking:

Table 6. Summary of masking for database D1
Mask typeFromTo
Database nameD0D1
Schema nameSCH0SCH1

The following syntax shows how to use DB2 Admin masking syntax to describe the masking:

DBNAME:D0,D1
SCHEMA:SCH0,SCH1

Similar masking must be done for database D2.

Step 1. Set up a CM batch parameter profile

A parameter profile will be defined to do the following actions:

  • Tell CM batch where the user-customized CM batch JCL procedure (GOCCM) is located.
  • Set the default naming pattern for a new mask or when a mask is used while importing a change to the following pattern:
    ‘MASK FOR DATABASE database-name
  • Enable the use of masking when importing a change.
  • Set the default naming pattern for a new change entry to the following pattern:
    work-item-#:database-name:current-timestamp

The COMMON.SYSTEM.PARMS data set stores these parameter settings, as shown in the following listing:

Listing 4. Content of the COMMON.SYSTEM.PARMS data set

JOB_JCLLIB_LINE_1='//LSCLIBS JCLLIB ORDER=ADB.CUST.PROCLIB' 
mask_owner = ‘ALLUSR’
mask_name = ‘MASK FOR DATABASE &TGTDB.’
use_mask_for_import_change = ‘Y’
change_name = ‘&WORK#.:&TGTDB.:&CURTS.’

The CM batch JCL procedure is customized so that the PROFPARM file references the COMMON.SYSTEM.PARMS data set (a parameter profile) each time when CM batch is invoked.

The following listing shows the content of the ADB.CUST.PROCLIB (GOCCM) data set:

Listing 5. Content of the ADB.CUST.PROCLIB(GOCCM) data set

//GOCCM   PROC SSID=,PLAN=,SPCUNIT=SYSDA              
//PROFPARM  DD DISP=SHR,DSN=COMMON.SYSTEM.PARMS 
…
//GOCCM   PEND

Some CM batch parameters in the examples reference the database name for the objects that are being changed. Referencing the database name is not required when you use CM batch and is mainly done to show how to use user-defined symbol variables.

Step 2. Define CM masks

In this step you define CM masks on DSNA and DSNB so that when a change is imported into DSNA or DSNB for a database, the predefined CM mask is used for that database.

The sample job in the following listing creates four masks. Two CM masks are created on DSNA; one is for database D1, and the other is for database D2. Two CM masks are created on DSNB; one is for database D1, and the other is for database D2.

Listing 6. Sample batch job to create masks for databases D1 and D2

//DEMO     JOB (&SYSUID),'DEMO',CLASS=B,       
//   MSGCLASS=H,MSGLEVEL=(1,1),NOTIFY=&SYSUID,TIME=5,  
//   REGION=0M                                             
//*                                                        
//LSCLIBS JCLLIB ORDER=ADB.CUST.PROCLIB
//*  
//*-----------------------------------------
//* DEFINE CM MASK FOR DATABASE D1 ON DSNA
//*-----------------------------------------
//MASK1    EXEC GOCCM,SSID=DSNA,PLAN=ADB 
//GOCCM.PARMS  DD *
  symbol_name = ‘&TGTDB.’ symbol_value = ‘D1’;
/* 
//GOCCM.IMMASK DD *
DBNAME:D0,D1
SCHEMA:SCH0,SCH1
/*
//*-----------------------------------------
//* DEFINE CM MASK FOR DATABASE D2 ON DSNA
//*-----------------------------------------
//MASK2    EXEC GOCCM,SSID=DSNA,PLAN=ADB 
//GOCCM.PARMS  DD *
  symbol_name = ‘&TGTDB.’ symbol_value = ‘D2’;
/* 
//GOCCM.IMMASK DD *
DBNAME:D0,D2
SCHEMA:SCH0,SCH2
/*
//*-----------------------------------------
//* DEFINE CM MASK FOR DATABASE D1 ON DSNB
//*-----------------------------------------
//MASK3    EXEC GOCCM,SSID=DSNB,PLAN=ADB 
//GOCCM.PARMS  DD *
  symbol_name = ‘&TGTDB.’ symbol_value = ‘D1’;
/*
//GOCCM.IMMASK DD *
DBNAME:D0,D1
SCHEMA:SCH0,SCH1
/*
//*-----------------------------------------
//* DEFINE CM MASK FOR DATABASE D2 ON DSNB
//*-----------------------------------------
//MASK4    EXEC GOCCM,SSID=DSNB,PLAN=ADB 
//GOCCM.PARMS  DD *
  symbol_name = ‘&TGTDB.’ symbol_value = ‘D2’;
/*
//GOCCM.IMMASK DD *
DBNAME:D0,D2
SCHEMA:SCH0,SCH2
/*

The following table summarizes the CM masks that will exist after the sample job completes:

Table 7. CM masks that were created
DB2 subsystemCM mask owner and name
DSNA
“ALLUSR”.”MASK FOR DATABASE D1”
“ALLUSR”.”MASK FOR DATABASE D2”
DSNB
“ALLUSR”.”MASK FOR DATABASE D1”
“ALLUSR”.”MASK FOR DATABASE D2”

Step 3. Define a change for work order W001

Defining a change, which is the step before CM batch imports a change, can be done in several ways. In this example, the developer and the DBA do the following steps:

  • The developer checks out the latest definition of database D0 in DDL format.
  • The developer sends the DDL file to a DBA after the DDL file changes are made and are ready to be deployed.
  • The DBA compares the DDL file that was sent by the developer to the model database D0 on DSNA. The compare is done by using Object Comparison Tool and choosing to generate a delta change file.
  • The DBA uses CM batch to import the delta change file on each subsystem for each database and uses CM batch to manage the change until the change is implemented in DB2.

The diagram in the following figure shows how the change is defined and how a delta change file is created:

Figure 1. How a change is defined and a delta change file is created
Source DDL file and target database D0 on DSNA are compared to get a delta change file

The DDL file in the following listing is from the developer. The developer inserted column C2 before column C3.

Listing 7. The DDL file sent from a developer to a DBA

SET CURRENT SQLID = 'SYSADM';
SET SCHEMA = 'SCH0';
CREATE DATABASE D0;
CREATE TABLE T1
 (C1 INT
 ,C2 INT
 ,C3 INT)
 IN DATABASE D0;
CREATE UNIQUE INDEX IX1_T1
  ON T1 (C1);

This article does not contain step-by-step instructions for doing the compare. Using Object Comparison Tool to do the compare involves ISPF panels to set up the source, target, and other options. The result of this compare is a compare report that describes each change to an object and the delta change file. The delta change file records the essence of the change.

In this example the delta change file created by the compare is USERID.W001.CHG, and inserting column C2 INT before column C3 is the only change.

In the following steps CM batch is used to implement this delta change on each database in the sample DB2 environment.

Step 4. Update the model database D0 with the work order W001 changes

In the following listing, a sample CM batch job imports, analyzes, and runs the change for work order W001 on the model database D0 on DSNA. When the job completes, the work order W001 changes are implemented for database D0 on DSNA. In a previous step, use_mask_for_import_change = ‘Y’ was set in PROFPARM as the default value, but masking is not needed on the model database. To disable the use of masking, the use_mask_for_import_change = ‘N’ parameter is specified in the PARMS DD to override use_mask_for_import_change = ‘Y’.

Listing 8. Sample batch job to import, analyze, and run the changes on database D0

//DEMO  JOB (&SYSUID),'DEMO',CLASS=B,       
//   MSGCLASS=H,MSGLEVEL=(1,1),NOTIFY=&SYSUID,TIME=5,  
//   REGION=0M                                             
//*                                                        
//LSCLIBS JCLLIB ORDER=ADB.CUST.PROCLIB 
//*                                                        
//GOCCM     EXEC GOCCM,SSID=DSNA,PLAN=ADB 
//GOCCM.PARMS  DD *
  use_mask_for_import_change = ‘N’
  action_run_change = ‘Y’
  symbol_name = ‘&TGTDB.’ symbol_value = ‘D0’;
  symbol_name = ‘&WORK#.’ symbol_value = ‘W001’;
/* 
//GOCCM.IMCHG001 DD DISP=SHR,DSN=USERID.W001.CHG
/*

When the job completes, work order W001 is implemented on the model database D0. The following table shows questions and answers about implementing the work order on a database:

Table 8. Questions and answers about implementing the work order on database D0
QuestionAnswer
Which CM batch parameter settings were used?The following CM batch parameters were used:
JOB_JCLLIB_LINE_1='//LSCLIBS JCLLIB ORDER=ADB.CUST.PROCLIB'
mask_owner = ‘ALLUSR’
mask_name = ‘MASK FOR DATABASE &TGTDB.’
use_mask_for_import_change = ‘Y’
change_name = ‘&WORK#.:&TGTDB.:&CURTS.’
use_mask_for_import_change = ‘N’
action_run_change = ‘Y’
symbol_name = ‘&TGTDB.’ symbol_value = ‘D0’;
symbol_name = ‘&WORK#.’ symbol_value = ‘W001’;
Why were these CM batch parameter settings used?When CM batch reads in the parameters, it first reads from the PROFPARM file, and then from the PARMS file.

In Step 1. Set up a CM batch parameter profile, the PROFPARM file was set to data set COMMON.SYSTEM.PARMS in the CM batch JCL procedure (GOCCM):

//GOCCM   PROC SSID=,PLAN=,SPCUNIT=SYSDA              
//PROFPARM  DD DISP=SHR,DSN=COMMON.SYSTEM.PARMS 
…
//GOCCM   PEND

In section Step 1. Set up a CM batch parameter profile, the COMMON.SYSTEM.PARMS data set was populated with the following information:

JOB_JCLLIB_LINE_1='//LSCLIBS JCLLIB ORDER=ADB.CUST.PROCLIB'
mask_owner = ‘ALLUSR’
mask_name = ‘MASK FOR DATABASE &TGTDB.’
use_mask_for_import_change = ‘Y’
change_name = ‘&WORK#.:&TGTDB.:&CURTS.’

When CM batch was invoked, the PARMS file contained the following settings:

//GOCCM.PARMS  DD *
  use_mask_for_import_change = ‘N’
  action_run_change = ‘Y’
  symbol_name = ‘&TGTDB.’ symbol_value = ‘D0’;
  symbol_name = ‘&WORK#.’ symbol_value = ‘W001’;
/*

When PROFPARM is concatenated with PARMS, the following result is produced:

JOB_JCLLIB_LINE_1='//LSCLIBS JCLLIB ORDER=ADB.CUST.PROCLIB'
mask_owner = ‘ALLUSR’
mask_name = ‘MASK FOR DATABASE &TGTDB.’
use_mask_for_import_change = ‘Y’
change_name = ‘&WORK#.:&TGTDB.:&CURTS.’
use_mask_for_import_change = ‘N’
action_run_change = ‘Y’
symbol_name = ‘&TGTDB.’ symbol_value = ‘D0’;
symbol_name = ‘&WORK#.’ symbol_value = ‘W001’;
Can I override a parameter that is specified in PROFPARM?Yes. Step 4. Update the model database D0 with the work order W001 changes shows how to override a parameter that is specified in PROFPARM.

First, CM batch reads in PROFPARM followed by PARMS to internally build one list of parameters. Then, it processes the list of parameters. A parameter can be specified multiple times in the same file, or in PROFPARM and PARMS. The last reference to a parameter is the one that is used by CM batch.

For example, to override use_mask_for_import_change = ‘Y’ to not use masking when importing a change, you can specify use_mask_for_import_change = ‘N’ in the PARMS file.

Action_import_change = ‘Y’ was not specified, but the change was imported. Why?If action_import_change is not specified or blank, the default value is ‘Y’, if the IMCHG001 file is defined and not empty.

In this example the IMCHG001 file is defined, and it is not empty, so the value of action_import_change is ‘Y’ by default.

Action_import_change = ‘Y’ was not specified, but the change was analyzed. Why?If action_analyze_change is not specified or blank, the default value is ‘Y’, if action_import_change = ‘Y’ is specified by default or by a user.

In this example, action_analyze_change is ‘Y’ by default.

Why was the new change name “W001:D0:2012-03-17-13.43.23.82341”?The following CM batch parameters were used:
JOB_JCLLIB_LINE_1='//LSCLIBS JCLLIB ORDER=ADB.CUST.PROCLIB'
mask_owner = ‘ALLUSR’
mask_name = ‘MASK FOR DATABASE &TGTDB.’
use_mask_for_import_change = ‘Y’
change_name = ‘&WORK#.:&TGTDB.:&CURTS.’
use_mask_for_import_change = ‘N’
action_run_change = ‘Y’
symbol_name = ‘&TGTDB.’ symbol_value = ‘D0’
symbol_name = ‘&WORK#.’ symbol_value = ‘W001’;

Because change_name = ‘&WORK#.:&TGTDB.:&CURTS.’, and given the user symbol variables above, the new change name resolved to “W001:D0:2012-03-17-13.43.23.82341”.

What are the default values of the mask_name and change_name parameters if they are not set by a user?Every CM batch parameter (except SSID) has a product default value. The following values are the product default values for these two parameters:
mask_name = ‘AUTO:&CURTS.’
change_name = ‘AUTO:&CURTS.’

In this example, masking was not used, so the mask_name value was not used.

The following listing shows the model database with work order W001 implemented.

Listing 9. Current definition of model database D0

SET CURRENT SQLID = 'SYSADM';
SET SCHEMA = 'SCH0';
CREATE DATABASE D0;
CREATE TABLE T1
 (C1 INT
 ,C2 INT
 ,C3 INT)
 IN DATABASE D0;
CREATE UNIQUE INDEX IX1_T1
  ON T1 (C1);

Step 5. Import and analyze the work order W001 for databases D1 and D2 without running it

In this step, CM batch imports and analyzes work order W001 (delta change file USERID.W001.CHG) but does not implement it. The changes will be run in another step. The work order changes can be implemented in one step, like the one-step implementation that was done for the model database D0, but the implementation is done separately for databases D1 and D2 to show that the run can be done separately, which is how many DB2 for z/OS production environments implement changes.

The following listings show sample jobs that import the change into DSNA and DSNB for databases D1 and D2. The jobs could be done in one job with four different job steps. However, they are done in four different jobs to show that the jobs can be run in parallel, as long as different job names are used.

The following listing shows the first job, which imports and analyzes work order W001 (delta change file USERID.W001.CHG) into DSNA for database D1:

Listing 10. Sample job for database D1 on DSNA that imports and analyzes W001

//DEMO  JOB (&SYSUID),'DEMO',CLASS=B,       
//   MSGCLASS=H,MSGLEVEL=(1,1),NOTIFY=&SYSUID,TIME=5,  
//   REGION=0M                                             
//*                                                        
//LSCLIBS JCLLIB ORDER=ADB.CUST.PROCLIB 
//*                                                        
//GOCCM     EXEC GOCCM,SSID=DSNA,PLAN=ADB 
//GOCCM.PARMS  DD *
  symbol_name = ‘&TGTDB.’ symbol_value = ‘D1’;
  symbol_name = ‘&WORK#.’ symbol_value = ‘W001’;
/* 
//GOCCM.IMCHG001 DD DISP=SHR,DSN=USERID.W001.CHG
/*

The following table shows questions and answers about the results of submitting this sample job:

Table 9. Questions and answers about importing and analyzing the work order for database D1 on DSNA
QuestionAnswer
Which CM batch parameter settings were used?The following CM batch parameters were used:
JOB_JCLLIB_LINE_1='//LSCLIBS JCLLIB ORDER=ADB.CUST.PROCLIB'
mask_owner = ‘ALLUSR’
mask_name = ‘MASK FOR DATABASE &TGTDB.’
use_mask_for_import_change = ‘Y’
change_name = ‘&WORK#.:&TGTDB.:&CURTS.’
symbol_name = ‘&TGTDB.’ symbol_value = ‘D1’;
symbol_name = ‘&WORK#.’ symbol_value = ‘W001’;
Why were these CM batch parameter settings used?When CM batch reads in the parameters, it reads from the PROFPARM file first, and then it reads from the PARMS file.

In section Step 1. Set up a CM batch parameter profile, the PROFPARM file was set to data set COMMON.SYSTEM.PARMS in the CM batch JCL procedure (GOCCM):

//GOCCM   PROC SSID=,PLAN=,SPCUNIT=SYSDA              
//PROFPARM  DD DISP=SHR,DSN=COMMON.SYSTEM.PARMS 
…
//GOCCM   PEND

In section Step 1. Set up a CM batch parameter profile the COMMON.SYSTEM.PARMS data set was populatedwith the following information:

JOB_JCLLIB_LINE_1='//LSCLIBS JCLLIB ORDER=ADB.CUST.PROCLIB'
mask_owner = ‘ALLUSR’
mask_name = ‘MASK FOR DATABASE &TGTDB.’
use_mask_for_import_change = ‘Y’
change_name = ‘&WORK#.:&TGTDB.:&CURTS.’

When CM batch was invoked, the PARMS file contained the following settings:

//GOCCM.PARMS  DD *
  symbol_name = ‘&TGTDB.’ symbol_value = ‘D1’;
  symbol_name = ‘&WORK#.’ symbol_value = ‘W001’;
/*

When PROFPARM is concatenated with PARMS, the following result is produced:

JOB_JCLLIB_LINE_1='//LSCLIBS JCLLIB ORDER=ADB.CUST.PROCLIB'
mask_owner = ‘ALLUSR’
mask_name = ‘MASK FOR DATABASE &TGTDB.’
use_mask_for_import_change = ‘Y’
change_name = ‘&WORK#.:&TGTDB.:&CURTS.’
symbol_name = ‘&TGTDB.’ symbol_value = ‘D1’;
symbol_name = ‘&WORK#.’ symbol_value = ‘W001’;
The change was imported and analyzed, but it was not run. Why?If action_run_change is not specified or blank, the default value is ‘N’. You must always explicitly request a change to be implemented.

In this example, the action_run_change parameter was not specified, so the value defaults to ‘N’.

How does CM batch know which mask to use during import change?The following CM batch parameters were used:
JOB_JCLLIB_LINE_1='//LSCLIBS JCLLIB ORDER=ADB.CUST.PROCLIB'
mask_owner = ‘ALLUSR’
mask_name = ‘MASK FOR DATABASE &TGTDB.’
use_mask_for_import_change = ‘Y’
change_name = ‘&WORK#.:&TGTDB.:&CURTS.’
symbol_name = ‘&TGTDB.’ symbol_value = ‘D1’;
symbol_name = ‘&WORK#.’ symbol_value = ‘W001’;

Because use_mask_for_import_change = ‘Y’ is specified, a mask is used during import change. The mask that is used is defined by mask_name = ‘MASK FOR DATABASE &TGTDB.’. Given the user-symbol variables that are specified, the mask that is used is "ALLUSR"."MASK FOR DATABASE D1".

The following listing shows the second job, which imports and analyzes work order W001 (delta change file USERID.W001.CHG) into DSNA for database D2. This job is the same as the previous job except that the value of the &TGTDB. symbol variable is changed to D2.

Listing 11. Sample job for database D2 on DSNA that imports and analyzes W001

//DEMO    JOB (&SYSUID),'DEMO',CLASS=B,       
//   MSGCLASS=H,MSGLEVEL=(1,1),NOTIFY=&SYSUID,TIME=5,  
//   REGION=0M                                             
//*                                                        
//LSCLIBS JCLLIB ORDER=ADB.CUST.PROCLIB 
//*                                                        
//GOCCM    EXEC GOCCM,SSID=DSNA,PLAN=ADB 
//GOCCM.PARMS  DD *
  symbol_name = ‘&TGTDB.’ symbol_value = ‘D2’;
  symbol_name = ‘&WORK#.’ symbol_value = ‘W001’;
/* 
//GOCCM.IMCHG001 DD DISP=SHR,DSN=USERID.W001.CHG
/*

The following listing shows the third job, which imports and analyzes work order W001 (delta change file USERID.W001.CHG) into DSNB for database D1:

Listing 12. Sample job for database D1 on DSNB that imports and analyzes W001

//DEMO    JOB (&SYSUID),'DEMO',CLASS=B,       
//   MSGCLASS=H,MSGLEVEL=(1,1),NOTIFY=&SYSUID,TIME=5,  
//   REGION=0M                                             
//*                                                        
//LSCLIBS JCLLIB ORDER=ADB.CUST.PROCLIB 
//*                                                        
//GOCCM    EXEC GOCCM,SSID=DSNB,PLAN=ADB 
//GOCCM.PARMS  DD *
  symbol_name = ‘&TGTDB.’ symbol_value = ‘D1’;
  symbol_name = ‘&WORK#.’ symbol_value = ‘W001’;
/* 
//GOCCM.IMCHG001 DD DISP=SHR,DSN=USERID.W001.CHG
/*

The following listing shows the fourth job, which imports and analyzes work order W001 (delta change file USERID.W001.CHG) into DSNB for database D2. This job is the same as the previous job except the value of the &TGTDB. symbol variable is changed to D2.

Listing 13. Sample job for database D2 on DSNB that imports and analyzes W001

//DEMO    JOB (&SYSUID),'DEMO',CLASS=B,       
//   MSGCLASS=H,MSGLEVEL=(1,1),NOTIFY=&SYSUID,TIME=5,  
//   REGION=0M                                             
//*                                                        
//LSCLIBS JCLLIB ORDER=ADB.CUST.PROCLIB 
//*                                                        
//GOCCM    EXEC GOCCM,SSID=DSNB,PLAN=ADB 
//GOCCM.PARMS  DD *
  symbol_name = ‘&TGTDB.’ symbol_value = ‘D2’;
  symbol_name = ‘&WORK#.’ symbol_value = ‘W001’;
/* 
//GOCCM.IMCHG001 DD DISP=SHR,DSN=USERID.W001.CHG
/*

The output for each of the previous jobs contains the details of the change (e.g., the analyze report describing the change to each object, the change name, the change status, the location of the run job, and so on). After the four jobs are run, work order W001 is imported and analyzed, but it is not implemented on DSNA and DSNB for databases D1 and D2. The following tables show the changes that were created. The state of each change is ANALYZED, which means the change is ready to be run (implemented). The run job contains the statements (SQL and utilities) that are needed to implement the change in DB2. In the examples in these tables, USER123 is the TSO user ID.

The following table shows a summary of created changes:

Table 10. Summary of changes that were created and their current status
DB2 subsystemChange nameChange status
DSNA
W001:D0:2012-03-17-13.43.23.82341COMPLETE
W001:D1:2012-03-17-13.44.14.48829ANALYZED
W001:D2:2012-03-17-13.45.03.32154ANALYZED
DSNB
W001:D1:2012-03-17-13.45.11.74561ANALYZED
W001:D2:2012-03-17-13.45.20.03451ANALYZED

The following table shows a summary of run job locations:

Table 11. Summary of the run job locations for each change
Change nameLocation of run job
W001:D0:2012-03-17-13.43.23.82341‘USER123.DSNA.RUN.JCL(C0000001)’
W001:D1:2012-03-17-13.44.14.48829‘USER123.DSNA.RUN.JCL(C0000002)’
W001:D2:2012-03-17-13.45.03.32154‘USER123.DSNA.RUN.JCL(C0000003)’
W001:D1:2012-03-17-13.45.11.74561‘USER123.DSNB.RUN.JCL(C0000001)’
W001:D2:2012-03-17-13.45.20.03451‘USER123.DSNB.RUN.JCL(C0000002)’

Step 6. Use CM batch to implement work order W001 for databases D1 and D2

To implement a change, the run job for the change must be submitted. The run job was created for each change during the analyze step. In this example, the run job for each change was created in the previous step. To run the changes, submit each run job.

After the run jobs are submitted, the change (column C2 inserted before C3) is implemented for databases D1 and D2 on DSNA and DSNB, and the status of each change is set to COMPLETE.

The following table shows a summary of the change statuses:

Table 12. Summary of changes that were created and their current status
DB2 subsystemChange nameChange status
DSNA
W001:D0:2012-03-17-13.43.23.82341COMPLETE
W001:D1:2012-03-17-13.44.14.48829COMPLETE
W001:D2:2012-03-17-13.45.03.32154COMPLETE
DSNB
W001:D1:2012-03-17-13.45.11.74561COMPLETE
W001:D2:2012-03-17-13.45.20.03451COMPLETE

Conclusion

CM batch enables you to create, customize, and reuse CM batch jobs to match how you deploy and manage changes in your DB2 for z/OS environment. CM batch helps you to automate the deployment, management, and tracking of changes to DB2 for z/OS. CM batch provides the following features:

  • Support for the main change management processes (import, analyze, run, and recover).
  • Parameter profiles in CM batch allow you to define your parameter settings once and can be reused across multiple DB2 for z/OS subsystems.
  • Dynamic parameter profile selection enables you to set up CM batch so that parameter profiles are selected based on the DB2 for z/OS subsystem in use or other user defined criteria.
  • Parameter symbol variables allow you to define your data set naming patterns or patterns for other CM batch parameter settings.
  • Changes can be deployed to multiple databases on the same DB2 for z/OS subsystem. You can even deploy and manage changes on multiple DB2 for z/OS subsystems by just changing the SSID parameter.
  • Because CM batch uses the existing change management function in DB2 Admin and Object Comparison Tool, you can access the tracking and audit ability of changes (e.g., change status, change creator ID, create and alter time stamps, and more).

To use the CM batch enhancement, apply PTF UK76851 for DB2 Administration Tool for z/OS V10.1, and PTF UK76861 for DB2 Object Comparison Tool for z/OS V10.1.

Resources

Learn

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Information management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Information Management
ArticleID=813867
ArticleTitle=DB2 Tools corner: Introducing the IBM-supported batch interface for change management in DB2 Administration Tool for z/OS V10.1 and DB2 Object Comparison Tool for z/OS V10.1
publish-date=05102012