Output copy data sets

You can use DD statements in the JCL to allocate the data sets, or you can let BMC AMI Copy dynamically make the allocation. We recommend that you let BMC AMI Copy dynamically allocate the output copy data sets. For information about dynamic allocation refer to the following topics:

• Allocating output copy data sets dynamically

• Using GDGs and symbolic variables in data set names

• Stacking copies on tape

• OUTPUT syntax options reserved for tape data sets

If you choose to allocate the copy data sets in the JCL, you should be aware of the information in the following sections.

SYSCOPY data set in JCL allocations

When you are making copies using the COPY command and you allocate the output copy data sets in the JCL but do not specify COPYDDN, SYSCOPY is the default data set for the image copy. It is also the default for the first copy when COPYDDN is specified and the default is taken for the first copy. You can use COPYDDN to change the DDName and to add up to three additional copy data sets. For information about the COPYDDN and RECOVERYDDN options when used in a COPY command, see COPY object options.

When you are making copies using the COPY IMAGECOPY command and you allocate the output copy data sets in the JCL, there is no default copy data set. You can use COPYDDN to make only one or two copies. For information about the COPYDDN and RECOVERYDDN options when used in a COPY IMAGECOPY command, see COPY IMAGECOPY syntax options .

Each copy data set requires its own DD statement in the JCL. You can allocate each one to a different device type by specifying the UNIT parameter in the corresponding DD statement.

Specifying BLKSIZE and LRECL parameters for JCL allocations

BMC AMI Copy normally determines an optimal block size for each copy data set, depending on the device type where the copy data set is written.

Because of performance considerations, we recommend that you normally do not code BLKSIZE or LRECL for the output copies and let BMC AMI Copy select optimal values of these parameters for you. (See Summary of performance notes.) However, if you are using disk data sets for output copies, you can code BLKSIZE=0 so that unopened data sets can be migrated successfully when you start a job over after an unsuccessful run.

Otherwise, if you choose to specify block size, you can override the default values by allocating each copy data set in your JCL with a block size that is a nonzero even multiple of 4 KB but not greater than 28 KB unless you are using the large block interface. The output block size must be a multiple of 4 KB to be compatible with BMC AMI Recover or IBM Db2 RECOVER. The size needed for the copy data set depends on the number of pages required when the space is copied. Allocate the primary amount as the total amount needed and allow room for future growth. The size needed for the copy data set for a full image copy is:

dataSetSize(bytes) = (numberOfPages)*(pageSize)

where:

numberOfPages is obtained from the NACTIVE column of the SYSIBM.SYSTABLESPACE table after running the RUNSTATS utility.

pageSize equals the value from the PGSIZE column of SYSIBM.SYSTABLESPACE table multiplied by 1,024.

dataSetSize can also be found from the IDCAMS LISTC output of the high-used RBA for each data set.

Using BMC AMI Copy with the large block interface

For tape output, BMC AMI Copy provides large block interface (LBI) support when you are running BMC AMI Copy in the following environment:

• z/OS Version 1.7 or later

• Db2 Version 11 or later

The following table shows block sizes used by BMC AMI Copy for tape output for different environments.

Specifying copy data set disposition for JCL allocations

When you allocate the output copy data sets in the JCL, the disposition (DISP) of the data set depends on your intentions for cataloging the data set, your restart plans, and whether a restart is in progress.

We do not recommend using DELETE as the normal or abnormal disposition because it can cause the MVS and Db2 catalogs to lose synchronization. When multiple spaces are copied within the same job step, a DELETE abnormal disposition causes registered copies to be deleted if a COPY command other than the first COPY command abends. Even for job steps that make and register only one copy, an abend in the UTILTERM phase (after the copy is registered) causes the catalogs to lose synchronization. You must exercise caution when deleting image copy data sets. Review Restarting a failed BMC AMI Copy job before selecting the disposition.

Naming considerations for JCL allocations

You must use a copy data set name that does not match any image copy data set already registered in the SYSIBM.SYSCOPY table.

For cataloged data sets, the name alone constitutes a match. For uncataloged data sets, the name, volume serial number (volser), and file sequence number uniquely identify a data set and must not match any data set already registered.

Tape copy data set considerations for JCL allocations

Both copy and recovery considerations apply when you specify tape data sets. Also, for copy data sets, do not specify FREE=CLOSE.

If you specify tape data sets when making multiple copies using the COPYDDN option, you must specify a different tape volume for each copy data set. This is because BMC AMI Copy makes all copies concurrently for a COPY command.

Also, when stacking copies on tape, RETAIN should be coded in the VOL specification to prevent the tape from rewinding after each data set is closed. Moreover, if the number of output copy data sets written to tape exceeds the default number of volumes, a volume count must be coded in the VOL specification for each DD statement using the tape.

When stacking image copy data sets on tape, you must consider recovery requirements. Data sets on the same tape are accessed serially and, therefore, restored serially. This might lengthen recovery time.