Online DB2 Z/OS Cloning
The main purpose of this video-tutorial is to show you how to clone a DB2 subsystem to other subsystem running in the same Z/OS LPAR. Each step is explained with a video (screen cast). Video is opened when you click to the link.
It is supossed that you have two DB2 subsystems, in this case DB8G (source) and DBF (target), both up & running:
The procedure is automated in three main steps contained in library SYSADM.ODBCLONE. First step is related with the physical COPY from SOURCE datasets to TARGET DB2 datasets. While the remaining, are related with making target DB2 BSDS & CATALOG consistent with the location of the DATASETS copied from source subsystem:
STEP 1: Copy Source DB2 DataSets to Target DB2
First of all, we execute REXX code to simulate DB workload. This workload consist in inserting on row per second in table sysadm.prv.
Second, we stop TARGET (/-DBF STOP DB2) and delete all its datasets except the TARGET SDSN libraries and installation jobs . Finally, we proceed to COPY SOURCE datasets to TARGET DB2, while renaming HLQ (High Level Qualifier). The JCL that implements this is called CPYREN and is executed while source DB is up and running.
STEP 2: Change Target BSDS & Catalog to make it consistent with new DataSets location
STEP 2.1 Change log inventory HLQ:
This is automated with job RBLDLOGI which prints DBF.BSDS01 log inventory, reads its output (SYSADM.TEMP.PRNTBSDS) and generates a JOB (SYSADM.TEMP.JU004) to:
1.-) Change BSDS HLQ
2.-) Delete LOGCOPIES with source HLQ
3.-) Create new LOGCOPIES with target HLQ and START/END RBAs taken from log inventory output.
Before proceding, ENSURE that TARGET SYSTEM CANNOT ACCESS TO SOURCE SYSTEM BY:
Changing DSNZPARM module with the DEFER ALL option before starting target.
Enforcing it with RACF RULES (In our shop, in UTES test LPAR, CCOP userid hasn't access to SOURCE HLQ: DBUN, DB2N, DSN )
When possible, physically disabling access to source subsystem volumes (In our show, we vary off DB2NXX, DB2SR1,DB2LB1,DB2R01 volumes on UTES TEST LPAR)
At this point we can start target system.Target DB2 subsystem is started in MAINTENACE MODE: /-DBF START DB2 ACCESS(MAINT)
STEP 2.2: Change Catalog STOGROUPs HLQ:
So, now we got both systems up and runing, but TARGET DB2 storage groups point to source HLQ. So we have to update TARGET DB2 catalog to point to new HLQ. To do this we use REXX code to select all storage groups and generate DDL to:
1.- Alter all depenent tablespaces and indexspaces to a temporal storage group -> SYSADM.TEMP.CHTSSGT
2.- Drop all storage groups -> SYSADM.TEMP.DROPSTO
3.- Create all storage groups with new HLQ (VCAT) -> SYSADM.TEMP.CREASTO
4.- Alter all depenent tablespaces and indexspaces to their original storages groups -> SYSADM.TEMP.CHTSSGO
The JCLs that automates all this stuff are RENSTOGC (generates DDL to change STOGROUP VCAT) and ALTSTOG (executes it)
Finally, we RESTART TARGET DB2 and it's stopped databases. Finally, we compare rows from the table that was been modified while source DB2 was clonned.
Additional STEPS:
Recreate DSNDB07 work database with TARGET HLQ
Change TABLESPACES HLQ with NO STORAGE GROUPS associated (For example those related with QMF)
Rebind all plans with option REPLACE and grant execution to them
Repair datasets unavailable due to incorrect level id.
Check that applications are runing; first batch, then web.
Bugs FOUND:
Some QMF VSAM are improperly cataloged. They should be recatalogued with IDCAMS (ALTER NEWNAME).
Josep Vidal - System Programmer. For more questions you can reach me at: josepvidalcanet@gmail.com .