In the first part of this article, we have introduced what the new approach is and how to prepare the artifacts needed by the new approach. In the second part of this article, we will introduce how to perform DB2 migration with z/OSMF.
Automating DB2 migration in z/OSMF
Creating the workflow instance
For every DB2 subsystem to be migrated, a workflow instance must be created. The path of the workflow definition file must be provided for instantiating a workflow instance. The path of the workflow input variable file is optional. However, it is always best to save the variable values for a specific subsystem into the workflow input variable file and provide it when creating the instance. Otherwise, z/OSMF prompts you to provide the value during execution, preventing a fully automated migration.
z/OSMF prompts you to input the name of the workflow instance. It is best to name it with the workflow purpose and the target system. For example, "V10 to V11 CM Non-data-sharing - DB2A". "V10 to V11 CM Non-data-sharing" indicates the migration is from Version 10 to Version 11 conversion mode. DB2A is the name subsystem to be migrated.
All the steps in the workflow are assigned to the same person to fully automate the migration process. Dependencies have been set to these steps by the installation CLIST. Only the steps in the "Ready" state can be performed.
Validating JCL with symbolic substitution
It is best to validate the JCLs with variable substitution before executing them. The JCLs with variables substituted can be found on the "Perform" tab of a step. First review the values of the input variables.
By default, the values are loaded from the workflow input variable file, they don’t need to be changed here. However, if changes are required, click the exclamation mark next to the variable name, and check "Mark value editable." Then the input variable textbox becomes editable. The changed value applies to this workflow instance only.
In the step "Create JOB statement", you are prompted to review and update "JOB statement JCL". Update the job statement with a job name, a proper CLASS or MSGCLASS. For the migration steps that require INSTALL SYSADM authorization, you can also add one line to specify USERNAME and PASSWORD.
Then review the content of the JCL including the job statement. For anything to be updated, click the "Edit JCL" button then the JCL textbox becomes editable. The change on the JCL only applies to the particular workflow instance. If there is any change applying to all the workflow instances, it's best to change on the JCL template before creating workflow instances.
Because migration is a critical activity in an enterprise, every JCL must be verified after the substitution, for every workflow instance.
Executing the workflow
After all workflow instances are tested, execute them. Some DB2 steps can repeatedly run, such as DSNTIJPM. For DSNTIJPM, select the option "Manually perform the selected step only".
Open the "Status" tab, the job status can be found, including job name, job ID, return code, and job outputs. However, return code 0 of DSNTIJPM does not mean no action should be taken. Follow the instructions on DB2 manual and check the output of each pre-migration reports to determine the actions to be taken.
After the first successful execution of a step, its status is marked "Complete". However, you can still re-execute the step. That is, if actions must be taken after the first execution of DSNTIJPM, take the actions and then return to z/OSMF and rerun the step. Check the reports until all pre-migration tasks are done.
Except the first step, all other steps in migration can be done automatically at the migration window. Select the first option in the "Perform Automated Step" panel. With that option, z/OSMF executes the selected steps and all the subsequent steps in the workflow, until all steps are executed successfully or an error occurs. An error in a step execution is not necessarily a nonzero return code. The maximum return code that a step can tolerate is defined in the workflow definition file. It can be 0, 4, 8 or any number. In the DB2 sample installation and migration workflows, most steps have 0 or 4 as the maximum return code.
If any error occurs, check the job output on z/OSMF "Status" tab. Problem diagnosis and resolution remains is business as usual.
If everything goes smoothly, all the steps are marked as "Completed."
Migrating multiple DB2 subsystems
The biggest benefit of using z/OSMF is for migrating multiple DB2 subsystems. In particular, when the migration steps and the migration jobs used in the migration of these subsystems are the same, and only the parameters used for these migrations, such as subsystem name and buffer pool sizes, are different. With z/OSMF, the rule "define once, execute multiple times" applies.
DB2 installation CLIST can help generate one workflow input variable file that fits for one DB2 system. To create the workflow input variable files working for other systems, the original workflow input variable file should be duplicated for each subsystem. Then you can edit the workflow input variable file with the proper parameters for that subsystem.
DB2 installation CLIST also provides an UPDATE function to generate a z/OSMF workflow input variable file based on an existing workflow input variable file and an input member such as DSNTIDxx.
For example, if the workflow artifacts were generated for an OLTP member, but the DBA wants to customize the workflow input variable file, the DBA can use the UPDATE mode and provide the input member DSNTIDAP from the existing OLAP member.
Enter the source and the target workflow input variable files.
Then DSNTIVAP is generated which will use the same workflow variable definition in DSNTIVTP but use the value in the input member from DSNTIDAP.
As a comparison, the value of the variable "ACCEL" in the source workflow input variable file DSNTIVTP is NO.
In the target workflow input variable file DSNTIVDP is AUTO.
The DBA can use the same workflow definition file, the file templates and the new workflow input variable file to create a new workflow instance to migrate the OLAP member.
Migrating a data sharing group
To migrate a data-sharing group, at least 2 sets of workflow artifacts need to be generated. The first set is for the first member to be migrated in that data sharing group. The workflow definition of the first member in a data sharing group is the same as a non-data-sharing DB2 subsystem. It is also named DSNTIWMS. The second set, for the subsequent members, is named DSNTIWMD.
The process to generate the set of workflow artifacts for the first member is the same as the process for a non-data-sharing DB2 subsystem except YES should be specified for DATA SHRING and first member should be specified.
It is best to generate the second set for the subsequent in a different data set because the JCL jobs used by the first set and the second set might have the same name but different content.
Moving workflow artifacts
If the generated workflow artifacts need to be moved or copied to another location, the workflow variable input file must be modified to update with the name of data set containing the JCL templates.
In the workflow definition file, the references of the JCL templates contain the variable NEWSAMP2 whose input is defined in the workflow input variable file.
After the JCL templates are moved to a new location, change the value of NEWSAMP2 in the new
workflow variable file.
DB2 11 for z/OS Installation and Migration Guide (GC19-4056)
IBM z/OS Management Facility Programming Guide (SA32-1066-04)
IBM DB2 for z/OS in the age of cloud computing
Special thanks to Maryela Weihrauch who provided much inspiration and good advice during the writing of this article.
Kewei Wei (魏可伟) is a senior software engineer in DB2 for z/OS development.
Paul A. McWilliams is a content developer in DB2 for z/OS development
If you have any questions about the solution, please feel free to contact Kewei (email@example.com).