How to migrate objects from one environment to another environment where the product libraries are not shared with RC/Migrator
Article ID: 200629
Updated On:
Products
Issue/Introduction
How can we migrate objects from one environment to another environment, where the two environments do not share
RC/Migrator for Db2 for z/OS (RCM) product libraries. For example hlq.CDBALOAD and hlq.CDBAPARM.
As the two environments are not shared the source and target subsystems are not defined to both hlq.CDBAPARMs.
Resolution
For a RCM 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 hlq.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.
Enter the version of the target subsystem in the Target Version field.
The following formats are supported:
VvvR1Mmmm or vvR1Mmmm (DB2 12 and above. For example, V13R1M500 or
13R1M500 for DB2 13 with function level 500)
V11R1M0 or 11R1M0 (DB2 11 new function mode)
(V12R1M500 is the default)
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 DD card. For example:
TRGVERS V12R1M500
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.
.RESTART SYSTEM(UNLOADS)
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 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.
.RESTART SYSTEM(SQLDDL,SQLSTATS)
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
Feedback
