When using Global Changes for an in-place migration, RC/Migrator generates DROP DDL for an object using the new creator.

Products

• RC Compare for DB2 for z/OS

Issue/Introduction

When using Global Changes for an in-place migration and specify Analysis Option, DROP OBJECTS = Y, DROP DDL is generated, however it is for the new creator of the object.

 

For example, using the following Global Change

-- ALCR CREATOR

-- FROM OLDCR TO NEWCR

 

RC/Migrator Analysis generates:

DROP ALIAS NEWCR.SAMPLE_TABLE;

 

Why does RC/Migrator not generate DROP DDL for OLDCR.SAMPLE_TABLE?

Environment

Release:
Component: RCM

Resolution

The Analysis uses option 'DROP OBJECTS ==> Y', which means that DROP DDL is generated for all the new objects on the target subsystem. 

RCM generates the DDL to DROP the new objects involved in the migration. However, no checks are made on the target SSID, to see whether the object exists before issuing the drop statement. So there is the potential for -204 SQL errors when the new object does not exist in the target subsystem. 

For example, when migrating a database (which has a tablespace, table and index) to a target subsystem, during the analysis, if the user selects the analysis option 'Drop Objects ===> Y', then RCM generates DROP DDL only for the database. Dropping the database will implicitly drop dependent objects. Now if the DATABASE does not exist on the target, then the DROP DATABASE will fail with SQLCODE -204 and the user has to manually remove the DROP DATABASE and RESTART the execution.

 

Additional Information

Further information on the Drop Objects Analysis Option can be found in the RC/Migrator documentation: 

RC/Migrator Analysis Options