Bharath's Tech Blog

Checklist for data migration using Redirected Recovery

In many of my previous blogs I mentioned that we (DBA team) use Redirected Recovery of Recovery Expert for z/OS v3.2 for data migrations from one DB2 sub-system to another DB2 sub-system. The data migration (using Redirected Recovery) is done in 3 phases.

      Phase 1: Create Profiles and update Recovery options in Recovery Expert

This is pretty straight-forward process. We add all the Tablespaces in a database needed for data migration to an Application profile. Usually, nothing can go wrong in this phase.

      Phase 2: Execute Build JCL (that builds/generates the data migration JCLs)

In the Build JCL, we provide the following details to build/generate the data migration JCLs.

       a)      Application profile name (having the objects to be migrated)

       b)     Timestamp for PIT recovery 

             (Redirected Recovery can do only PIT recovery to another sub-system)

       c)      PDS name (data migration JCLs will be created in this PDS)

       d)     Plan number for the Recovery (its 29 for Redirected Recovery)

This job can fail for many reasons and the frustrating part is that it’s not easy to find out the reason for job failure. Most of the time we see just the ARYZ018E error message, with list of Objects that can’t be recovered. And, reason why the Objects are recoverable will be not be provided in the job output.

After discussions with Rocket Software tool support team, got the checklist to go through for Build job to be successful. The checklist provides the details of Objects that can lead to failure of Build job. So, these Objects will be excluded from data migration process. With the help of JCL and REXX, I automated the checklist. The JCL will have multiple steps to verify the below.

1. Check whether all TS’ in the Source database has ICTYPE=’F’ entries in SYSCOPY for a given ICDATE. I use this SQL query for verification.

SELECT

   DBNAME

  ,NAME

FROM SYSIBM.SYSTABLESPACE

WHERE

   DBNAME=<dbname> AND

   NAME NOT IN

              (SELECT

                 TSNAME

               FROM SYSIBM.SYSCOPY

               WHERE

                  DBNAME=<dbname> AND

                  ICDATE=<date>)

WITH UR;

2. Check whether all Image copy datasets (of the TS’ got from the above SQL query) are present in ICF catalog. I coded the below REXX routine for this verification.

LIST_PARA:                                                                     

 SAY '*****SYSCOPY ENTRIES NOT IN ICF CATALOG*****'                            

 DO I = 1 TO INP.0                                                              

   IC_DSN = STRIP(INP.I,"B")                                                   

   X = OUTTRAP(LSTC.)                                                          

    ADDRESS TSO "LISTCAT ENT('"IC_DSN"') "                                     

   X=OUTTRAP('OFF')                                                            

   Y = STRIP(WORD(LSTC.1,1),"B")                                               

   IF Y <> 'NONVSAM'                                                            

     THEN SAY IC_DSN NOT FOUND IN ICF CATALOG                                  

 END                                                                           

 SAY '********************************************'                             

RETURN;

3. Check whether any Objects (of TS’ included in the Application profile) are altered.

The CURRENT_VERSION of the TS can change for many reasons. Redirected Recovery can’t migrate data from versioned TS to non-versioned TS. I coded Objects’ structures comparison process to verify this.
Versioning can also be found using the below query.

SELECT

   TS.DBNAME

  ,TS.NAME

  ,TB.NAME

  ,TS.OLDEST_VERSION

  ,TS.CURRENT_VERSION

  ,TB.VERSION

FROM SYSIBM.SYSTABLESPACE TS

     INNER JOIN

SYSIBM.SYSTABLES TB ON

   TS.DBNAME = TB.CREATOR AND

   TS.DBNAME = TB.DBNAME  AND

   TS.NAME = TB.TSNAME

WHERE

   TS.DBNAME='dbname'  AND

   TB.TYPE = 'T'       AND

   TS.CURRENT_VERSION <> TB.VERSION;

4. PIT timestamp used in Build job must be greater than the highest START_RBA for a given DBNAME and ICDATE. I use this SQL query to get the value.

SELECT TIMESTAMP((MAX(START_RBA))||X'0001') + CURRENT TIMEZONE

FROM SYSIBM.SYSCOPY

WHERE

   DBNAME=<DBNAME> AND

   ICDATE=<DATE>

WITH UR;

         Phase 3: Execution of the data migration JCLs

This phase can go smooth if we follow the checklist.