RC/Compare for Db2 for Z/OS: Compare not finding source dependant objects in DDL

Products

• RC/Migrator for DB2 for z/OS

Issue/Introduction

When a DDL-SSID Compare is created the SOURCE dependant objects are not found or listed in the Strategy for compare to the subsystem objects. 

Environment

DB2 for Z/OS

Cause

The SOURCE DDL contains dependant objects that incorrectly do not form part of the dependency object tree of the primary object.

Resolution

For this example a COMPARE strategy is set at TABLESPACE level so the primary object is a TABLESPACE in this case. 

The SOURCE DDL contains a TABLESPACE, TABLE , two INDEXes and two Aliases on the table.

DATABASE  TABLESPACE   TABLENAME               TBCREATR    INDEXNAME               IXCREATR  ALIAS NAME       ACREATOR
CPS0004A  A14566TS     ACCT_ACT_14566          authid      A14566X1                authid    ACCT_ACT_14566   authid1
                                                           A14566X2                authid    ACCT_ACT_14566   authid2

In the SOURCE table CREATE DDL the IN statement has IN "CPS0004.A14566TS". The database name "CPS0004" should be "CPS0004A".
This means that the table does not belong to database CPS0004A and so is not included in the compare strategy.

The strategy would look like this after it is created.

---------------- RC/M Compare Explode Services ---------------- yy/mm/dd hh:mm
COMMAND ===>                                                  SCROLL ===> CSR

STRATEGY ===> CPS0004A             DESCRIPTION  ===> CPS0004A
CREATOR  ===> authid               SHARE OPTION ===> U (U,Y,N,X,L)
VIEW STRATEGY INFO ===> N          CREATE/DROP OBJECTS ===> N (U,Y,N)
--------------------------------------------------------------------- authid
SOURCE  SSID ===> IMPORTED DATASET      |   TARGET SSID ===> ssid
                                        |   TARGET LOC  ===> LOCAL
                                        |
    E TY                                | Ob Dep
S   X PE NAME         CREATOR  VERSION  | CH CH NAME         CREATOR  VERSION
_   X TS A14566TS     CPS0004A          |       A14566TS     CPS0004A

When the dependant object mapping is reviewed using the "X" command in the "EX" column above and then "Display all Dependent Objects ===> Y" is used on the next screen this can be seen:

---------------- RC/M Dependent Object Mapping ---------------- yy/mm/dd hh:mm
Command ===>                                                  Scroll ===> CSR

STRATEGY    ===> CPS0004A                 CREATOR     ===> authid
--------------------------------------------------------------------- authid
Source SSID . . IMPORTED DATASET        | Target SSID . . ssid
TABLESPACE  . . A14566TS            >   | TABLESPACE  . . A14566TS            >
DBNAME    . . . CPS0004A  >             | DBNAME    . . . CPS0004A  >

S   OBJ# TP NAME               CREATOR  | MAP# C TP NAME               CREATOR
_                                       | ____   T  ACCT_ACT_14566     authid
_                                       | ____   A  ACCT_ACT_14566     authid1
_                                       | ____   A  ACCT_ACT_14566     authid2
_                                       | ____   I  A14566X1           authid
_                                       | ____   I  A14566X2           authid

At the top the two tablespaces are matched on source and target BUT there are no dependant objects matched on the source!!
When the COMPARE strategy is updated only the TABLESPACE is matched with the target subsystem and the TARGET dependant objects are listed under the TARGET tablespace. 

The TABLE , INDEXes and Aliases of the SOURCE tablespace were not listed in the COMPARE Strategy as dependants of the TABLESPACE because the DDL of the TABLE incorrectly referenced a database name that was different than the database that the tablespace belongs to in this DDL.
This may happen in text DDL for a variety of erroneous reasons since it is only text. It could never happen on the DB2 subsystem of course. This can happen even if the two tablespace names are the same since two tablespace names can exist on two different databases at the same time.
 
This means that even though the objects are physically in the SOURCE DDL dataset, the TABLE is logically not a DEPENDANT object of the DATABASE.TABLESPACE and so not matched with the TARGET subsystem and ignored along with its other dependants. So, even in text DDL , ensure that the objects remain logically correct for comparison with a target subsystem.

The way to correct this problem is to change the table IN "CPS0004.A14566TS" statement to IN "CPS0004A.A14566TS" to match the database.tablespace name that the table is part of, the current strategy deleted and
the strategy recreated. 

The result then looks like this:

---------------- RC/M Dependent Object Mapping ---------------- yy/mm/dd hh:mm
Command ===>                                                  Scroll ===> CSR

STRATEGY    ===> C2928229                 CREATOR     ===> authid
--------------------------------------------------------------------- authid
Source SSID . . IMPORTED DATASET        | Target SSID . . D12A
TABLESPACE  . . A14566TS            >   | TABLESPACE  . . A14566TS            >
DBNAME    . . . CPS0004A  >             | DBNAME    . . . CPS0004A  >

S   OBJ# TP NAME               CREATOR  | MAP# C TP NAME               CREATOR
_      1 T  ACCT_ACT_14566     authid   | ____   T  ACCT_ACT_14566     authid
_      2 A  ACCT_ACT_14566     authid1  | ____   A  ACCT_ACT_14566     authid1
_      3 A  ACCT_ACT_14566     authid2  | ____   A  ACCT_ACT_14566     authid2
_      4 I  A14566X1           authid   | ____   I  A14566X1           authid
_      5 I  A14566X2           authid   | ____   I  A14566X2           authid