Inline batch AUTOMAP Compare, Analyze, Execute using RC/Compare
search cancel

Inline batch AUTOMAP Compare, Analyze, Execute using RC/Compare

book

Article ID: 53960

calendar_today

Updated On:

Products

RC Compare for DB2 for z/OS RC/Migrator for DB2 for z/OS

Issue/Introduction

How to create a RC/Compare for Db2 for z/OS (RCC) compare strategy, analyze it and execute it all in one batch job.

Resolution

This is done with one batch job with three steps: AUTOMAP Compare, ANALYZE, and EXECUTE.

Explanatory notes
Substitutions used during the example inside the JCL which will explain these names that you would change to suit yourself.

USERID                : Your own authid
USERID.NAME.BPCODE    : Your own dataset name for the analysis output used by batch processor.
USERID.NAME.RCMPARM   : Your own dataset name for additional sysin parms.
TESTTAB               : Your own strategy name
SSID                  : Your subsystem ID
USERID.EXECDDL        : Batch processor ID of your choice. This is a BPID.

Warnings
This batch job is able to be started again but will start from the beginning and delete and recreate the strategy. The result however if fully executed the first time, will not be the same the second time due to the changes in the target objects on DB2. In general you should check every part of this JCL to ensure that it remains valid each time it is submitted.

JCL SAMPLE

STEP 1
The AUTOMAP step creates a compare strategy called USERID.TESTTAB and uses DDL from USERID.NAME.BPCODE(xxxxxxxx) as input. This example has a create table statement in it for one table but it could contain any DDL. The dataset USERID.NAME.RCMPARM(yyyyyyyy) is used to optionally add extra compare PARM's to the strategy creation. It's just another way to add additional SYSIN cards to the job without actually hard coding them in the job. Standard JCL stuff. The contents of that dataset will be fed in as SYSIN cards along with the others like MASKNAME.

This optional PARM dataset could be left out. The parms could be listed with the other parms in the JCL following MASKNAME or in fact anywhere in the SYSIN. The dataset name used does not have to be the same as in this example.

In this example this parm dataset has just three cards but could contain others of your choice.

AUTHID       USERID           SPECIFIES DEFAULT PRIMARY DB2 ID
SQLID        USERID           SPECIFIES DEFAULT SECONDARY DB2 ID
STRTDESC     TEST DESCRIPTION STRATEGY DESCRIPTION

In this step make sure that valid RULESET , MASKSET and MODEL names are referenced below in the JCL.

//jobcard
//*
//AUTOMAP EXEC PGM=PTLDRIVM,PARM='EP=RML$CMAI'
//*
//STEPLIB  DD DISP=SHR,DSN=hlq.CDBALOAD
//         DD DISP=SHR,DSN=hlq.SDSNEXIT
//         DD DISP=SHR,DSN=hlq.SDSNLOAD
//PTILIB   DD DISP=SHR,DSN=hlq.CDBALOAD
//PTIPARM  DD DISP=SHR,DSN=hlq.CDBAPARM
//DDLIN    DD DISP=SHR,DSN=USERID.NAME.BPCODE(xxxxxxxx)
//PARMFILE DD *
STRATEGY   TEST   
CREATOR    USERID
REPLACE
SHAREOPT   U
STRTSSID   SSID
EXPOPT     A
TRGSSID    SSID
RULECRTR   USERID
RULENAME   @DEFAULT
MASKCRTR   USERID
MASKNAME   @DEFAULT
//         DD DISP=SHR,DSN=USERID.NAME.RCMPARM(yyyyyyyy)
//*
//CNTLFILE DD SYSOUT=*
//MSGFILE  DD SYSOUT=*
//*

Repeated execution of this JCL will replace the target DDL on USERID.NAME.BPCODE(xxxxxxxx) above and so this dataset could fill up unless it's space allocation is monitored.
Step 1 creates an RC/Migrator COMPARE strategy and can be seen like other compare strategies on the RC/Migrator Strategy services screen.

STEP 2
The ANALYZE step assumes an existing strategy called USERID.TESTTAB has been just created in STEP 1 so that the analysis can be performed. Step 2 performs the analysis and sends the resulting analysis output to a dataset called USERID.NAME.BPCODE(xxxxxxxx) in the example below.

//ANALYZE EXEC PGM=PTLDRIVM,PARM='SUFFIX=00,EP=RML@MAIN',REGION=0M
//*
//STEPLIB   DD DISP=SHR,DSN=hlq.CDBALOAD
//          DD DISP=SHR,DSN=hlq.SDSNEXIT
//          DD DISP=SHR,DSN=hlq.SDSNLOAD
//PTILIB    DD DISP=SHR,DSN=hlq.CDBALOAD
//          DD DISP=SHR,DSN=hlq.SDSNEXIT
//          DD DISP=SHR,DSN=hlq.SDSNLOAD
//PTIPARM   DD DISP=SHR,DSN=hlq.CDBAPARM
//ABNLIGNR  DD DUMMY
//PARMFILE  DD *
STRATEGY    TEST
CREATOR     USERID
STRTSSID    SSID
LOBTOO
RTNIMP
RTNIIO      N
SQLID       USERID
NOAUTHS
HEADER
REBIND
TRAILER
REPINDDL
MODEL4      @DEFAULT
MODEL4C     AUTHID
GLBLNAME    TEST1
GLBLCRTR    USERID
TBCB        -----02     -----A4
TBCR        -----02     -----A4
IXCR        -----02     -----A2
IXCB        -----02     -----A2
//RCMTOLR   DD SYSOUT=*
//MSGFILE   DD SYSOUT=*
//REPFILE   DD SYSOUT=*
//DDLFILE   DD DISP=SHR,DSN=USERID.NAME.BPCODE(xxxxxxxx)
//*

RC/Migrator allows users to create and save Global Change SET's in the RCM PROFILE, Option 3. These are stored on the RC/Migrator product database(PTDB). When a strategy is analyzed and a Global Change SET is referenced, the details of these SET's are copied into the analysis JCL before submission.......see after GLBLNAME in the above JCL.

As the JCL is hard coded in a PDS member any change to the stored Global Change SET on the RC/Migrator product Database would not be reflected in your PDS member. It's not a problem. It's something to be mindful of. In your JCL you might not want it to change at all.

STEP 3
The EXECUTE step then simply takes the DDL just produced in USERID.NAME.BPCODE(TESTTAB) and executes it as batch processor id USERID.EXECDDL. Doing this all at once does not give the user time to assess the impact before execution. This JCL will execute the generated DDL immediately!!!.

This execution step could obviously be detached and run separately if unsure of the resulting DDL.

//EXECUTE EXEC PGM=PTLDRIVM,REGION=4M,PARM='SUFFIX=00,EP=BPLBCTL'
//STEPLIB  DD DISP=SHR,DSN=hlq.CA.CDBALOAD
//         DD DISP=SHR,DSN=SSID.PRIVATE.SDSNEXIT
//         DD DISP=SHR,DSN=DB2.SDSNLOAD
//PTILIB   DD DISP=SHR,DSN=hlq.CA.CDBALOAD
//         DD DISP=SHR,DSN=SSID.PRIVATE.SDSNEXIT
//         DD DISP=SHR,DSN=DB2.SDSNLOAD
//PTIPARM  DD DISP=SHR,DSN=hlq.CA.CDBAPARM
//PTIXMSG  DD DISP=SHR,DSN=hlq.CA.XMESSAGE
//SYSOUT   DD SYSOUT=*
//PTIIMSG  DD SYSOUT=*
//UTPRINT  DD SYSOUT=*
//ABNLIGNR DD DUMMY SUPPRESS ABENDAID DUMPS
//SYSUT1   DD UNIT=SYSDA,SPACE=(CYL,(30,30))
//SYSREC   DD UNIT=SYSDA,SPACE=(TRK,(1,1))
//BPIIPT   DD DISP=SHR,DSN=USERID.NAME.BPCODE(TESTTAB)
//BPIOPT   DD *
.CONTROL BPID(USERID.EXECDDL) +
LOGID(SSID) UNIT(SYSDA)
.LIST SYSOUT(A,,X)
.OPTION NOERRORS NOSQLERRORS RETRY(88) NOBINDERRORS
.RESTART OVERRIDE
.CONNECT SSID

Note above that .RESTART OVERRIDE must always be set so that it executes the BPID(CA Batch processor ID) from the start each time.
The BPID is the identifier of this batch job during execution and must always begin from the start.

On the RC/Migrator Strategy Services Screen
Often with batch jobs we don't know what happened.
Where do you look?
What will it look like on the RC/Migrator screen if you went looking for it?
What do you look for?

The Strategy will look like this and there will be output on held output showing each step executing along with the execution. The search criteria will have "TESTTAB" as your strategy and it will have placed it on the SSID that you referenced in step 1 with the "TRGSSID" parm.

STRATEGY DESCRIPTION               CREATOR       P O
________ _________________________ USERID        _ N
TEST     TEST DESCRIPTION STRATE   USERID        C U
_ USERID.NAME.BPCODE(xxxxxxxx)

You can see that the description above matches that which came with the STRTDESC card on the AUTOMAP in Step 1 which was fed into your JCL by that RCMPARM dataset.

Additional Information

Compare the DDL File to a Target Subsystem

Comparison Strategies

Strategy Analysis

Execution Facility