ALERT: Some images may not load properly within the Knowledge Base Article. If you see a broken image, please right-click and select 'Open image in a new tab'. We apologize for this inconvenience.

How to migrate objects from one environment to another environment where the product libraries are not shared.


Article ID: 200629


Updated On:


RC/Migrator for DB2 for z/OS


How can we migrate objects from one environment to another environment, where the two environments do not share CA product libraries, for example CDBALOAD and CDBAPARM? As the two environments are not shared the source and target subsystems are not defined to both CDBAPARMS.


For a migration strategy, it is a requirement that RC/Migrator is provided with the DB2 version of the target subsystem, so that it can generate version specific DDL for that subsystem. Ordinarily RC/Migrator would obtain this information from the SETUPxx Parmlib member in CDBAPARM. In a non-shared DASD environment, where this is not possible, then the following process can be used to provide RC/Migrator with the DB2 version of the target subsystem.

1. Creating the migrate strategy should be a normal process, as the target information is not needed at this stage.

2. Generating the analysis through the panels will require target information that is not available in the source CDBAPARM.

On the 'RC/M Migration Strategy Analysis' panel, when you enter the target subsystem SSID and hit ENTER

RC/Migrator will display a pop-up panel as the target SSID is not defined in the CDBAPARM that is being used.

You will need to enter the version of the target subsystem in the Target Version field. Valid values for v12 are:


Returning to the 'RC/M Migration Strategy Analysis' panel, you can complete the remaining fields before generating the batch JCL.

In the generated job you will see the TRGVERS parameter in the PARMFILE card. For example:


RC/Migrator will use this to generate the DDL appropriate for the DB2 version of the target subsystem.

The next steps document the migration of data as well as DDL.

If you are migrating DDL only and no data, then step 3. should be skipped.

3. On the 'RC/M Strategy Services' panel, place an 's' next to the DDLFILE that I want to execute and hit ENTER.

On the 'Batch Processor Interface' panel, specify 'u' for Unload Mode and hit ENTER.

This will tell the strategy execution to only execute the Unload section of the strategy.

Continue to generate the JCL. You will note in the JCL that the following card has been added.


Run the JCL to execute the unload section on the source environment.

4. Next we need to execute the remainder of the DDLFILE on the target subsystem.

To do this access the CA DB2 Tools in the production environment and specify the target subsystem SSID on the main menu.

Enter 'b' to access the Batch Processor Interface.

Under the 'BATCH PROCESSOR INPUT DATA SET:' section enter the dataset name of the DDLFILE that is to be executed.

Specify an Unload Mode of 'n'. This tells the strategy execution to skip unload processing, but perform the object creation and LOAD steps.

Continue to generate the JCL. You will note in the JCL that the following card has been added.


Run the JCL to execute the create and load sections on the target environment.

Additional Information

With regards to the setup for these two environments using separate product libraries, this is similar to the following scenario documented in the installation guide

Sample Setup for Multiple LPARs with Non Shared DASD