Craig S. Mullins
COPYTOCOPY: A New DB2 Utility for Version 7
By Craig S. Mullins
Version 7 introduces several new utilities and utility functions, one of which
is a new utility called COPYTOCOPY. The
purpose of the COPYTOCOPY utility is to make additional image copies of
currently existing image copy data sets.
primary benefit of COPYTOCOPY is to reduce the amount of time required to run
the COPY utility. Remember that the COPY utility can be used to take up to four
image copies with a single execution of the utility. But with COPYTOCOPY
available, instead of using COPY to make four image copy backups, the DBA can
use COPY to make a single image copy, and then run COPYTOCOPY to make additional
image copies. The COPY utility will take less time to create a single image copy
backup than it will to take multiple image copy backups. And the combination of
COPY plus COPYTOCOPY can be used to increase availability.
COPYTOCOPY is running the database object (table space or index space) being
copied is placed in utility restricted read/write state (UTRW). This prevents
other users from dropping the table space or index while COPYTOCOPY is running.
Individual data and index
partitions are treated as distinct target objects by the COPYTOCOPY utility. Any
other utilities operating on different partitions of the same table space or
index space can be run concurrently with COPYTOCOPY.
The following utilities can
not be run concurrently on the same database object as the COPYTOCOPY utility:
COPYTOCOPY is flexible enough to run against any DB2 image copy data set. This
includes inline copies made during the execution of the REORG and LOAD
utilities. COPYTOCOPY must start with a primary image copy backup either the
local primary or recovery site primary copy. From that image copy, the
COPYTOCOPY utility can make up to three copies of one or more of the following
created by COPYTOCOPY can be used by the RECOVER utility just like regular image
copies created using the COPY utility. Both table space and index space copies
can be made using the COPYTOCOPY utility. Any DB2 utility process that uses
image copy data sets can use the image copy data sets created by COPYTOCOPY.
This includes MERGECOPY, UNLOAD, and subsequent runs of COPYTOCOPY. However,
keep in mind that image copies created with the CONCURRENT option of the COPY
utility are not supported by the COPYTOCOPY utility.
like the COPY utility, the COPYTOCOPY utility records information about the
image copies that it creates in the SYSIBM.SYSCOPY system catalog table. The
COPYTOCOPY utility will insert the values in the DSNAME, GROUP_MEMBER, JOBNAME,
AUTHID, DSVOLSER and DEVTYPE columns as appropriate depending on the copies that
are being created.
cannot run COPYTOCOPY to create additional image copies for certain DB2 Catalog
(SYSCOPY in DSNDB06) and DB2 Directory (DSNDB01 and SYSUTILX both in DSNDB01)
COPYTOCOPY utility operates in these distinct phases:
To execute COPYTOCOPY, the process or user running the utility must have been granted one of the following privileges:
only exception to the above is for the DB2 Directory (DSNDB01) and the DB2
Catalog (DSNDB06). Any process or user having INSTALL SYSOPR authority can run
COPYTOCOPY for table spaces in the directory or catalog.
The use of the TERM command
to terminate a COPYTOCOPY step that has abended is not recommended. A current
restart should be done instead to allow COPYTOCOPY to pickup where it left off.
Terminating COPYTOCOPY in such a situation might cause inconsistencies between
the ICF catalog and DB2 catalog when GDGs are used.
cannot use RESTART(PHASE) for a COPYTOCOPY job. It is fine to use
RESTART(CURRENT) as long as you avoid using the -TERM UTILITY command to
terminate a COPYTOCOPY step. When you use RESTART(CURRENT), COPYTOCOPY will
restart from the last commit point with the same image copy data set, so be sure
to code a data set disposition of DISP=(MOD,CATLG,CATLG) on your JCL DD
using COPYTOCOPY to copy an inline image copy that was made by the REORG utility
with the part range option you will need to specify individual DSNUM for the
partitions to be copied. The COPYTOCOPY utility does not support part range.
COPYTOCOPY will copy only the specified partition data from the input inline
image copy data set into the output image copy data set.
run the COPYTOCOPY utility it is not necessary to provide the explicit data set
name of the image copy being copied. Instead, the input to the COPYTOCOPY
utility is the name of the table space, index space, or index for which the
original copy was made, and an indication of which image copy in the catalog
should be copied. To specify this information COPYTOCOPY provides three options:
Of course, you may choose
instead to specify the data set name for the image copy that is to be copied by
the COPYTOCOPY utility. This can be accomplished by using the FROMCOPY clause.
But keep in mind that when you are using COPYTOCOPY with a list of objects
defined using the LISTDEF statement, the FROMCOPY clause is not valid.
the FROMCOPY keyword is not used the COPYTOCOPY utility must determine which
specific image copy is to be copied. Before COPYTOCOPY can execute it may have
to choose between the local site primary copy, local site backup copy, recovery
site primary copy, and recovery site backup copy data sets. COPYTOCOPY will
search image copies in the following order to determine the input data set to be
If the input data set cannot be allocated or opened, the COPYTOCOPY utility will try to use the next image copy data with the same START_RBA value in SYSIBM.SYSCOPY column, in the search order as indicated previously. When the FROMCOPY keyword is used though, only the explicitly specified data set can be used as the input to COPYTOCOPY.
of the COPYTOCOPY Utility
Lets take a
quick look at a sample JCL job step to run the COPYTOCOPY utility. The following
code can be run to make a backup local image copy of the table space DSN8S71E in
the sample DB2 database DSN8D71A. This will be either a full or incremental
image copy, whichever was last run for this object: