DSN1COPY

You can use the DSN1COPY stand-alone utility to copy Db2 VSAM data sets.

With the DSN1COPY stand-alone utility, you can copy:

  • Db2 VSAM data sets to sequential data sets
  • DSN1COPY sequential data sets to Db2 VSAM data sets
  • Db2 image copy data sets to Db2 VSAM data sets
  • Db2 VSAM data sets to other Db2 VSAM data sets
  • DSN1COPY sequential data sets to other sequential data sets
A Db2 VSAM data set is one of the following items:
  • A single piece of a nonpartitioned table space or index
  • a single partition of a partitioned table space or index
  • A FlashCopy® image copy data set
The input must be a single z/OS® sequential or VSAM data set. Concatenation of input data sets is not supported.
You can also use DSN1COPY to perform the following actions:
  • Print hexadecimal dumps of Db2 data sets and databases
  • Check the validity of data or index pages (including dictionary pages for compressed data)
  • Translate database object identifiers (OBIDs) to enable moving data sets between different systems
  • Reset to 0 the log RBA that is recorded in each index page or data page.

You cannot run DSN1COPY on concurrent copies.

DSN1COPY can operate on both base and clone objects.

In most cases, specify a VSAM cluster rather than a specific data component. The only exception is when you use DSN1COPY for a specific data component. (For example, specify the data component when printing or copying that specific component and not the entire cluster.) In the following data set name format, the bold "C" indicates a cluster. A "D" in that place of the data set name indicates a data component.
catname.DSNDBC.dbname.psname.y001.z001

You can use the DSN1COPY utility on LOB table spaces by specifying the LOB keyword and omitting the SEGMENT and INLCOPY keywords.

Db2-managed data sets can be moved from hard disk drives to solid state drives by using DSN1COPY.

Output

The first time that the CHECK INDEX, CHECK DATA, COPY, REBUILD INDEX, REORG TABLESPACE, RUNSTATS, or UNLOAD utility physically opens a data set after DSN1COPY populates the data set, Db2 checks for any data and catalog inconsistencies. Those checks are the same ones that REPAIR CATALOG performs.

The first time that an SQL data manipulation statement or query physically opens a data set after DSN1COPY populates the data set, Db2 checks for any data and catalog inconsistencies for the following items:

  • DBID, PSID, and OBID
  • Attributes that are defined by SEGSIZE, BUFFERPOOL (page size), and PAGENUM options
  • Table space type
  • Table schema

    Db2 checks this item only if the table space contains a system page for the table.

Db2 reports any inconsistencies with a -904 SQL code, and you cannot access the data.

Db2 does not check these items for LOB or XML table spaces or for index spaces. Db2 also does not validate record row format or RBA format.

Db2 does not check for data and catalog inconsistencies during the following situations:

  • Db2 is restarting.
  • The header page is not formatted yet.
  • The REPAIR utility is operating on the header page. (The REPAIR utility closes the page set when it is finished. Therefore, validation can be done the next time that the data set is physically opened.)
  • The LOGAPPLY phase of the RECOVER utility is running.
  • The LOAD utility is running.

By not checking for inconsistencies during these situations, Db2 limits any performance impact.

You can correct some of the reported inconsistencies by using the REPAIR utility with the CATALOG option. The REPAIR CATALOG output indicates which inconsistencies it can fix.

Environment

Run DSN1COPY as a z/OS job when the Db2 subsystem is either active or not active.

If you run DSN1COPY when Db2 is active, use the following procedure:

  1. Start the source table space in read-only mode by issuing the -START DATABASE command for the table space.
  2. Run the QUIESCE utility with the WRITE (YES) option on the source table space to externalize all data pages and index pages.
  3. Run DSN1COPY.
  4. Start the source table space in read/write mode by issuing the -START DATABASE command.

Authorization required

DSN1COPY does not require authorization. However, if any of the data sets is protected by RACF®, the authorization ID of the job must have RACF authority.

If any of the data sets is encrypted using ICSF key label, the authorization ID of the job must have access to the key label.

Restrictions

DSN1COPY does not alter data set structure. For example, DSN1COPY does not convert a partitioned or segmented (non-UTS) table space to a simple table space if you copy the contents of a partitioned or segmented (non-UTS) table space to a simple table space. The output data set is a page-for-page copy of the input data set. If the intended use of DSN1COPY is to move or restore data, ensure that definitions for the source and target table spaces, tables, and indexes are identical. Otherwise, unpredictable results can occur.

DSN1COPY cannot copy Db2 recovery log data sets. The format of a Db2 log page is different from the format of a table or index page. If you try to use DSN1COPY to recover log data sets, DSN1COPY abnormally terminates.

All the target data sets must exist. You can use Access Method Services to define them.

For a compressed table space, DSN1COPY does not reset the dictionary version for the following items:
  • An inline image copy
  • An incremental image copy that was created with the SYSTEMPAGES=YES COPY utility option
To reset the dictionary version for an inline image copy, use the inline image copy as input to DSN1COPY with a VSAM intermediate data set as output. This intermediate data set can then be used as input to DSN1COPY RESET to copy the intermediate data set to the real target data set.
DSN1COPY issues an error and terminates in the following situations:
  • DSN1COPY can verify that the LOB option is specified, but the data set is not a LOB data set.
  • The LOB option is omitted for a data set that is a LOB data set.
To avoid problems, always specify the LOB option if the input data set SYSUT1 is a LOB table space, and make sure that the LOB option is not specified for non LOB table spaces.

If compressed LOB data is copied to a target subsystem that does not have the zEnterprise® data compression (zEDC) hardware, SQLCODE -904 will be issued when the LOB table space is accessed.

DSN1COPY cannot copy a source object of 4 GB or greater in size when it is full unless the target object is EA-enabled. For example, the source is full when it is not the last piece of a multi-piece non-partitioned object with a DSSIZE of 4 GB or greater. To avoid VSAM errors and limit each piece to 2 GB so that the target object has more pieces than the original source:

  • Define the target data set as EA-enabled and use DSN1COPY to copy the data, one piece at a time, from the source that is not EA-enabled to the target.
  • If it is not possible to define the target data set as EA-enabled:
    1. Take a full image copy of the entire source object by running the COPY utility and specifying DSNUM ALL.
    2. Create the target object by specifying DSSIZE 2GB for table spaces and PIECESIZE 2GB for indexes. See Copying tables from one subsystem to another.
    3. Define the partition number data sets (2 GB each) with the IDCAMS command. Define enough pieces to hold the entire source.
    4. Run the DSN1COPY utility with the image copy as the source (SYSUT1), the target object as SYSUT2, and specify DSSIZE 2G.

DSN1COPY cannot be used to restore data to a point in time before materialization of pending definition changes.

For partition-by-growth table spaces, DSN1COPY can be used only if the number of active partitions of the source and the target table space are the same. If the number of partitions in the source table space and the target table space are not the same, take one of the following actions:

  • If the number of partitions in the source table space is greater than the number of partitions in the target table space, issue SQL statement ALTER TABLE with the ADD PARTITION option on the table in the target table space to make the number of partitions the same in the source and target table spaces. Then use DSN1COPY to copy the contents of the source table space to the target table space.
  • Use the UNLOAD utility to unload the data from the source table space, and use the LOAD utility to reload the data into the target table space.