Go to LeighWeb Home Page            

Back To LeighWeb Mainframe Utilities Page

View the module associated with this documentation

 COPYDB is a utility that will generate necessary JCL to copy ENTIRE DB2
 databases from a source database to a target database.  The use of Princeton's
 Move For DB2 in conjunction with BMC's Unload Plus can move referentially
 intact subsets of a given source database (live or from image copy) to a target
 database, but that solution presents problems when an entire database
 (especially a large one) needs to be moved from a source to a target.

 At that point the IBM-supplied program DSN1COPY works better (and much faster),
 but it is difficult to set up and requires that some follow-up "clean-up" steps
 be executed as well.  This is where COPYDB comes in.

 COPYDB allows you to specify a source database (on a source subsystem) and a
 target database (on a target subsystem) that you want to work with.  It then
 allows you to specify what set of image copies you want to deal with by
 allowing you to specify a timestamp range within which the source subsystem's
 SYSIBM.SYSCOPY table is searched for the source database local, full image
 copes.

 This becomes the set of image copies that COPYDB will use as a source.  Then
 COPYDB attempts to match up appropriate target database objects with the source
 database objects.  This indicates that COPYDB requires that the target database
 objects must exist.  COPYDB also makes no attempt to determine if the target
 database is sized appropriately to receive the source data.  If the database in
 question is a UNISTAR or ELM database, it is recommended that DBSETUP or
 ELMSETUP be used to create the target database environment to accomplish the
 appropriate sizing.

 COPYDB does it's matching based on DB2 Table name.  This makes the usually true
 assumption that a tablespace contains one table.  The DSN1COPY activity happens
 at a tablespace level but as long as there is a one-to-one relationship between
 tables and tablespaces, this will work well. If there are multiple tables in
 the tablespace, some manual JCL editing may be required.

 As an example (very real-world) of how COPYDB matches up source and target,
 consider the following:

 Source Subsystem: DSNP
 Source Database: UFMSTP00 (UNISTAR Denver Full-Service database)
 Source Tablespace: UFNTES01
 Source Table:  NTE01T_NOTE

 Target Subsystem: DSNT
 Target Database: P@UXXXDB
 Target Tablespace: XXNTES01
 Target Table:  NTE01T_NOTE

 In this case, COPYDB determines that NTE01T_NOTE in the source matches
 NTE01T_NOTE in the target.  From this it creates JCL to copy the image copy
 from the UFMSTP00.UFNTES01 tablespace into the dataset associated with
 P@UXXXDB.XXNTES01 target tablespace.

 The main COPYDB panel allows you to specify all the parameters necessary for it
 to create and submit JCL which actually creates another set of jobs (in a
 single output dataset) that does the actual copy of the data and the associated
 cleanup.

 The process of the actual data copy activity is as follows:
1
 1. STOP all target tablespaces
 2. Perform all the individual DSN1COPY steps
 3. START all the target tablespaces
 4. Image copy all the target tablespaces
 5. Recover all the indexes for all the tables in the target tablespaces
 6. Execute RUNSTATS on all the target tablespaces

 This process is broken in to several jobs since the number of steps will
 typically exceed JES limitations on steps per job.

 The first job is stored in: userid.TEMP.COPYDB.JCL

 The job to do the data copy is stored in: userid.TEMP.DSN1COPY.JCL