FATSCOPY special considerations

CHECKPT/RESTART

FATSCOPY includes an option to create a checkpoint data set during a simulation run that can be used as input to a subsequent FATSCOPY job to copy the data sets selected during the simulation. FATSCOPY also has an Operator Communications function that allows you to display the STATUS of a FATSCOPY copy job or to stop the copy job (with an operator STOP or CANCEL command) and restart it at a later time. Both the CHECKPT and RESTART keywords and the Operator Communication require a DSNTABLE DD in the JCL.

If the DSNTABLE DD is present in the JCL, and both SIM and CHECKPT are specified (or the job is interrupted with a STOP or CANCEL command), FATSCOPY will create a data set containing an entry for each data set selected for copying. This data set is used as input to a subsequent FATSCOPY job that will copy all of the data sets selected during the simulation. When RESTART is specified, FATSCOPY uses the DSNTABLE data set to copy any data sets that weren't copied in the previous job using that DSNTABLE data set. When RESTART is specified, any SELECT statements will be ignored.

Operator commands

You can display the total number of files selected for copying and the current file being copied by issuing a MODIFY (F) command through an operator console. The format of the command is:

F jobname,STATUS

You can also stop a FATSCOPY copy job when it finishes copying the current file by issuing a MODIFY (F) command through an operator console. The format of the command is:

F jobname,STOP

If a DSNTABLE DD statement has been used, FATSCOPY will create a data set to be used to restart the job. If no DSNTABLE DD is present in the JCL, a FATSW15 message will be issued to the operator console asking whether to end the job. If the operator replies 'YES', FATSCOPY will end when it finishes copying the current data set, but will be unable to create the data set needed to restart the job.

Stacking limitations

If an application program attempts to OPEN two tape files concurrently, and you have used FATSCOPY to place both of those files on the same tape, the program will be unable to execute. If this should occur, the first OPEN will be successful but any subsequent OPEN for another file on the same tape will ABEND.

If two separate programs require tape files that you have placed on the same tape with FATSCOPY, and they happen to execute at the same time, one will work but the other will fail or wait.

Unfortunately, there is no simple way to determine which tape files may have this problem, so FATSCOPY is not able to automatically avoid placing such files on the same tape.

Therefore, it is the responsibility of the FATSCOPY user, through appropriate SELECT and EXCLUDE statements, to insure that tape files that may be needed by a single program or by programs executing concurrently are not placed on the same tape.

FDR tapes

You can use FATSCOPY to copy backup tapes created by FDR, backup software.

If some of the files that meet the data set selection criteria are FDRABR Archive or FDRAPPL Application Backup files, the Archive Control File or Application Control File maintained by FDRABR is updated by FATSCOPY when those files have been copied. If you wish to allow Archive and Application Backup files to be selected for copying, specify ABRARC=YES.

The copying of FDRABR Volume Backup tapes (full and incremental volume backups) is not restricted by the ABRARC parameter, because these tapes are simply cataloged in the ABR catalog, a standard z/OS system catalog. When FATSCOPYcopies these tapes and updates the ABR catalog, the copied tapes can be used by FDRABR. See the FDR space for the naming conventions used for FDRABR Volume Backups.

Special tapes

It is recommended to not use FATSCOPY to copy data sets created by proprietary products that record information about the locations of those files in their own databases because FATSCOPY isn't designed to update the data bases. Data sets created by some of these programs are automatically excluded from selection by FATSCOPY. However, some of these databases rely primarily on the recorded VOLSER of the data sets. In these cases, FATSCOPY image copy can be used to copy the data sets. Some of FATSCOPY products are noted below.

Consult IBM DFSMShsm documentation for the format of HSM data set names. If you select files with CATDSN=, FATSCOPY will by default exclude HSM backup and migration data sets based on the default names created by IBM; see the HSMMIGMASK= and HSMBAKMASK= operands for details.

FATSCOPYcan be used to copy HSM Migration Level 2 tapes by using the HSMML2 keyword. It can also be used to copy tapes that are not recorded in external databases, such as CA-Endevor and ESP/JSS backup tapes.

FATSCOPY can be used to copy OAM data sets only if you are doing an image copy. (Otherwise, OAM data sets will automatically be excluded from selection by FATSCOPY .) This image copy must be done to a device with the same Media Type as that of the input tapes.

After a volume is copied, an OAM UPDATE VOLUME operator command should be done to mark the volume as not writable. In a non-MTL environment, you should also either update the unit esoteric for the volume to reflect the new device for the volume, or use DB2 SPUFI to update the UNITNAME value with the new esoteric in OEM's DB2 TAPEVOL table entry for that volume. Contact BMC support for further details.

FATSCOPY can be used to copy CA View and ExHPDM data sets only if you are doing an image copy. (Otherwise, these data sets will automatically be excluded from selection by FATSCOPY.)

FATSCOPY can also be used to copy Mobius ViewDirect data sets if you catalog the output data sets. ViewDirect for MVS can track the files if they are cataloged.

Some special tapes can be copied by FATSCOPY using an image copy, as described below.

Image copies

In most cases, an image copy can be used to copy volumes that are used by products that record file locations in their own databases (such as OAM and UPSTREAM). This can be useful if you are migrating tapes from one tape system to another, and you want to avoid the extra processing needed to update the databases recording the files on those tapes. If the product only records information such as volume serial number, file sequence number, and block location on the tape, then you can do a FATSCOPY image copy for tapes created by that product. However, if it also records and uses device type information for the volume, you should do a FATSCOPY image copy for tapes created by that product only if you are copying to the same device type.

Products that record device type information for their files and whose files are thus not suitable for copying with an image copy (unless you are copying to the same device type) include HSM backups, CA-Disk, CA-Dispatch, Tivoli Space Manager archive tapes, SAS data sets, and DB2 image copies.

Mobius ViewDirect files should not be copied with an image copy if you are copying from one tape model to another with differing physical characteristics; positioning errors reading reports may result. Instead, you should copy and catalog the files with a non-image copy.

When doing an image copy of volume vvvvvv, you must ensure that a volume with serial vvvvvv does not already exist on the target tape device in the storage group to which you are copying. For example, if you are migrating volumes 100000 through 199999 using image copy, you should define a DIFFERENT range of VOLSERs (such as 500000 through 599999) on the output device as the scratch volumes to which the image copies will be done.

When an image copy of volume vvvvvv is done to scratch volume ssssss, the volume label of the output volume is replaced with vvvvvv. Volume ssssss no longer exists, but that VOLSER is not deleted from tape management. If you do not want to retain the tape management information for the output volume, you should delete it from your tape management system.

The volser of the scratch tape that was overwritten can be determined from the “O/P VOL” column in the Copy Report.

FATSCOPY can be used to write image copies to the following output devices:

• EMC DLm
• EMC MDL
• Stand-alone tape, including all Sun/STK devices and IBM tapes. (Note that the external label for any tape copied to a stand-alone drive needs to be changed after the image copy to make it match the VOLSER of the input tape.)

FATSCOPY cannot be used to write image copies to the following output devices:

• Any IBM TS77xx device
• CopyCross device
• IBM VTF device
• Any Sun/STK VSMx devices.

FATSCOPY will automatically detect any of these devices and not allow them to be used as output for image copies. Support for some of these devices is planned for a future release.

For the following output devices, FATSCOPY can be used to write image copies, but additional steps are required for the copied tapes to be used after the image copy completes:

• Sun/STK 9740
• Any tape library where tapes are mounted by a robot based on the external VOLSER of the tape.

For those devices, the following procedure must be used:

1. Run a FATSCOPY image copy calling for a scratch tape as output.
2. Use the FATSCOPY Copy Report to find the VOLSERs of the input and output volumes.
3. Eject both tapes from the library.
4. Replace the external label of the output tape with an external label that matches the VOLSER of the input tape.
5. Put the output tape back into the tape library.
6. Put a new external label on the input tape, put it back into the library, and run a FATS LABEL job to replace the internal label on the volume so that it matches the new external label.

If you have any questions about whether a device type not listed above is supported for FATSCOPY image copy, contact BMC support for assistance.

If you are doing an image copy with SMS-managed volumes, you may need to update your ACS routines after the copy. FATSCOPY will update the Storage Group in the Tape Configuration Database (TCDB) for the volume to be the storage group value for the output device. If your ACS routines use criteria other than the Storage Group to assign the device used to satisfy a tape mount, your ACS routines will need to be updated so that a subsequent job’s mount request for the copied volume will be directed to the correct device.

CA 1 considerations

If your tape management system is CA Technologies' CA 1 (also called TMS), the FATSCOPY support for selecting based on tape management criteria, scratching copied tapes, and updating tape management information is supported when you install the FATSCOPY CA 1 interface using the FATZAPOP program as described Activating the Tape Management Interface. FATSCOPY supports level 5.4 and higher.

If TMSDATA=COPY is specified or defaulted, these fields will be copied from the CA 1 records of the input tape file to the output file:

• creation date and time
• creating job name, step name, and program name
• last used date and time
• last using job name and program name
• expiration date, unless EXPDT= or RETPD= is specified on the TAPEOUT DD statement
• accounting information

If TMSINPUT=SCRATCH is specified, then FATSCOPY will update the expiration date of every successfully copied tape file to the current date + 4. The expiration date of the FIRST data set on the input tape will be set to the highest expiration date of any data set on the tape (or multi- volume tape set). If all data sets on the tape or tape set have been copied by FATSCOPY, FATSCOPY will set the expiration date for the volume to the current date + 4, unless you specified a value other than 4 using the ADDXDAYS keyword.

If you are converting tapes from RMM control to CA 1 control, contact BMC support for information on correctly migrating tape management information between the two systems.

RMM considerations

It is suggested applying the latest maintenance available for your level of RMM. FATSCOPY supports all levels of RMM. You must also install the FATSCOPY RMM interface using the FATZAPOP program as described Activating the Tape Management Interface.

If TMSDATA=COPY is specified or defaulted, these fields will be copied from the RMM records of the input tape file to the output file:

• creation date and time
• creating job name and program name
• last using job name, step name, and program name
• last read date and time
• last write date and time
• expiration date (of the associated tape volume) unless EXPDT= or RETPD= is specified on the TAPEOUT DD statement
• creating step and DD names
• accounting information

The creation date and creation time of the first data set copied will be assigned as the RMM volume-level assigned date and assigned time for all output data sets created by FATSCOPY.

If TMSINPUT=SCRATCH is specified, FATSCOPYwill change the expiration date for each input data set after it is copied. FATSCOPY will scratch the input tape only if all files on an input tape are being copied in this FATSCOPY execution and are eligible to be scratched.

TLMS considerations

If your tape management system is CA Technologies’ TLMS, you must install the FATSCOPY TLMS interface using the FATZAPOP program, as described Activating the Tape Management Interface. TLMS version 11 and above is supported.

On the TAPEOUT DD statement, you must use DISP=(NEW,KEEP) (or DISP=(OLD,KEEP) when appending to a volume). If KEEP is omitted, FATSCOPY will terminate with an error message.

If TMSDATA=COPY is specified or defaulted, these fields will be copied from the TLMS records of the input tape file to the output file:

• creation date and time
• creating job name, step name, DD name, and program name
• last used date and time
• last using job name
• expiration and keep dates, unless EXPDT= or RETPD= is specified on the TAPEOUT DD statement
• accounting information

When an output volume is created, its control data set number is the default (0, which acts as “1”), even when doing an ALLDSN copy of a volume with a different control data set number. This may result in the retention of the output volume being different from the retention of the input volume. If you want to set the control data set number of an output volume to a non- default value, you must use the TLMS UPV command to reset it.

When TMSINPUT=SCRATCH is specified and the control data set is copied, that input file’s keep date is set to the highest keep date (or special expiration date, that always count as “higher” than specific Julian keep dates) of all the data sets on the input volume (or multivolume set), rather than the usual scratch date (current date + ADDXDAYS). This is to prevent other data sets from being scratched prematurely. This may have unexpected results, such as causing the control data set and volume to be retained longer than if TMSINPUT=SCRATCH had not been specified. However, if FATSCOPY successfully copies all the data sets on the volume (or multivolume set) in this FATSCOPY execution, then the keep date of the control data set is set to the usual scratch date.

When a data set with keyword expiration “MSG/nnn” is copied, the output data set will have the same expiration. However, the keep date for the output data set may be different from the input’s keep date. The keep date will be calculated by your installation’s TLMS rules. “MSG/nnn” is an exception to the normal TLMS rule that a keyword expiration overrides the keep date when determining volume retention.

A data set with keyword expiration “STATS/nnn” not be selected for copying when SELECT CATDSN is used.

Data sets with keyword expiration “FOREIGN” will not be selected for copying.

ZARA considerations

If TMSDATA=COPY is specified or defaulted, these fields will be copied from the Zara records of the input tape file to the output file:

• accounting data
• creating job name, step name, program name, DD name, date, time, and unit
• last used job name, step name, DD name, date, and time
• expiration date, unless EXPDT= or RETPD= is specified on the TAPEOUT DD statement

Certain special retentions are not directly copied by FATSCOPY , such as

• catalog control or number of days, whichever is later (CDddd)
• catalog control plus number of days after being uncatalogued (CTddd)
• first cycle control (CYccc+ddd)

The correct expiration dates for these data sets will be set by Zara if the data set and job names match the values in the Expiration Candidate Table.

The use of TMSINPUT=ZARASCR to expire each input file should be done with care. If your installation has the Zara “Scratch by 1st” option set to “Y”, it is advised against the use of TMSINPUT=ZARASCR. Using this option may result in unintended loss of data. If FATSCOPY expires the first data set on a tape, the volume will be scratched when “Scratch by 1st” is set to “Y”, even if other non-expired data sets remain on the volume.

CONTROL-M/TAPE considerations

If your tape management system is BMC's Control-M/Tape, you must install the FATSCOPY Control-M/Tape interface using the FATZAPOP program, as described in Activating the Tape Management Interface. When doing the installation, you must specify several data sets and libraries from your Control-M/Tape system configuration using these FATZAPOP keywords on ZAP statements:

• CTTIOAPARM - Control-M/Tape IOA.PARM library name
• CTTIOAENV - Control-M/Tape IOA.IOAENV library name
• CTTMDB - Control-M/Tape Media Database Data File name
• CTTMDI - Control-M/Tape Media Database Index File name
• CTTSTKD - Control-M/Tape Stacking Statistics Data File name
• CTTSTKI - Control-M/Tape Stacking Statistics Index File name
• CTTTRC - Control-M/Tape Trace File name

If TMSDATA=COPY is specified or defaulted, these fields will be copied from the Control-M/Tape media database records of the input tape file to the output file:

• creation date and time
• creating job name, step name, DD name, unit address, and program name
• data set use count
• last-used date, time, job name, job step, program name, DD name, CPU
• last-write date, time, job name, job step, program name, DD name, CPU
• expiration and keep dates, unless EXPDT= or RETPD= is specified on the TAPEOUT DD statement
• accounting information

FATSCOPY uses the CTTMUP utility to update the metadata for copied data sets. This utility can generate a large amount of Control-M/Tape configuration information in SYSPRINT. If you want to suppress the display of this information in your Copy jobs, add the following DD statement to each job:

//DAPRENV DD DUMMY Suppress Control-T configuration display

FATSCOPY stacks output data sets based on input volume grouping or by expiration date grouping, depending on which FATSCOPY keywords you choose. A Simulation job displays how the data sets would be grouped by FATSCOPY if the same control statements were used by a Copy job. If Control-M/Tape Dynamic Data Set Stacking is active, that may supersede the grouping done by FATSCOPY, and the output data sets may be grouped differently than expected by FATSCOPY. If you want to override Dynamic Data Set Stacking to ensure that the output data sets are stacked in the way that they are grouped by FATSCOPY, add the following DD statement to your FATSCOPY Copy jobs:

SMS-managed tapes

If you want your output tape to be SMS-managed, you can specify STORCLAS= on the TAPEOUT DD statement, or you can specify a data set name on the TAPEOUT DD that is assigned to a SMS-managed tape by your SMS ACS routines. This will cause an SMS- managed tape to be mounted for output. The SMS classes specified or assigned will be used for all data sets copied. However, FATSCOPY does not copy any SMS class information from the input data sets to the output data sets.

If you are doing an image copy with SMS-managed volumes, you may need to update your ACS routines after the copy. FATSCOPY will update the Storage Group of the copied volume to the Storage Group value for the output device. If your ACS routines rely on criteria other than the Storage Group to assign the device for a tape mount, you will need to update those routines so that volumes which were mounted on the input device before the image copy will be mounted on the output device by subsequent jobs after the image copy.

Special note for DFSMSrmm users: if you are running z/OS level 1.13 or above, FATSCOPY will by default use an RMM update facility that copies the SMS information from the input data set to the output data set. If you do not want the management class to be copied from the input to the output, contact BMC support to receive a custom zap that will bypass this facility.

Concurrent copy jobs

The only limit to the number of FATSCOPY jobs that you can run at the same time is the number of tape units you have available. To run concurrent jobs, take the following into account:

• Due to z/OS restrictions, each concurrent job’s TAPEOUT DD statement must use a different dummy name as its DSN= parameter.
• If you are using an AUDIT DD statement to create audit records, concurrent jobs must use separate audit data sets. (The FATAUDIT utility can produce a single report using separate audit data sets.)
• Concurrent copy jobs can’t read from the same volume at the same time.
• It is recommended that concurrent jobs use different data set names in their DSNTABLE DD statements.

Writing audit records

FATSCOPY can write an audit record for each data set copied. The information recorded includes the volumes copied, whether the input data set was cataloged, the expiration date of the input data set, the output data sets and volumes created, the expiration date assigned to the output, the number of bytes read and written, and the return code for the copy.

A FATSCOPY job can use one of these two methods for recording audit records:

1. In a sequential data set specified by the AUDIT DD statement. The audit data set can be a disk or tape data set with a disposition of MOD, NEW, SHR, or OLD. We recommend a disposition of MOD to create a single repository for all the audit records.
   If you want to run multiple FATSCOPY jobs simultaneously, you can use a disposition of NEW to create a separate audit file (each with a different DSN) in each job. You can then concatenate the output data sets as input to a FATAUDIT job to produce a single report.
   While you can code DISP=SHR or DISP=OLD on the AUDIT DD when using an existing audit data set, it is recommended using MOD or NEW. Using SHR or OLD will wipe out any records that exist in the data set.
2. In a system logger log stream. This allows you to run concurrent FATSCOPY jobs that write to a single log stream. The z/OS system logger is a component of z/OS that must be activated and configured. You may use either a DASD-only log stream (which is not shared between LPARs) or the duplex coupling facility (to share the log stream between LPARs). For more information on the z/OS system logger see the following IBM publications:

–z/OS MVS Setting Up A Sysplex

–z/OS MVS Initialization and Tuning Reference

Using the system logger is not recommended unless your installation has experience with using the system logger for other purposes, and is familiar with how to use it.

You must first perform the following tasks in order to set up the FATSCOPY System Logger environment. Your z/OS systems programmer must do some of these tasks.

1. Make sure you have authorization to the z/OS system logger address space and that the z/OS system logger (IXGLOGR) is running before you define and use a FATSCOPY log stream. The section " Define authorization to system logger address space" in IBM’s z/OS MVS Setting Up a Sysplex space provides more information about this.
2. You must also have authorization to the MVS IXCMIAPU utility. This utility is used to define, update, and delete entries in the LOGR couple data set. IXCMIAPU is documented in Appendix B of z/OS MVS Setting Up a Sysplex.
3. Use the IXCL1DSU utility to define and format the LOGR couple data set. Your installation may have already done this if you are using the z/OS system logger for other products. This utility is documented in z/OS MVS Setting Up a Sysplex.
4. Define the FATSCOPY log stream in the LOGR couple data set using the z/OS utility IXCMIAPU. See the section Add Information about Log Streams and Coupling Facility Structures to the LOGR Policy in z/OS MVS Setting Up a Sysplex. The following JCL is an example of how to set the values required for a DASD-only FATSCOPY log stream (not shared between LPARs) using the IXCMIAPU utility:

For FATSCOPY to use this log stream to write records, use AUDITLOG=logstreamname on the COPY statement of each job. Alternatively, if you use the FATZAPOP program to set this value in the FATSCOPY Global Options Table on your system (see Displaying and Modifying FATSCOPY Defaults), then by default all copy jobs will use this log stream to write audit records without the need to specify AUDITLOG= in each job.

If you use both an AUDIT DD statement and the AUDITLOG= keyword in the same job, the AUDITLOG= is ignored; audit records will be written to the data set specified in the AUDIT DD statement.

The recorded audit information (sequential data set or log stream) is used as input to the FATAUDIT program. FATAUDIT produces a Detail Report showing all of the data sets copied and a Summary Report showing the total number of files copied, jobs run, etc. See FATAUDIT Functional Description for information on using FATAUDIT to produce audit reports.

Although the use of an AUDIT DD or AUDITLOG= is optional, it is recommended recording audit information in every FATSCOPY job. It is recommendedware recommends that customers use sequential data sets for recording audit records, unless they have experience using the z/OS System Logger facilities. Using the System Logger in conjunction with setting an AUDITLOG= in your FATSCOPY Options Table (using the FATZAPOP utility) has the advantage that all copy jobs in your shop will have audit information recorded even if your application programmers do not remember to specify audit recording parameters.

EMC DLm/MDL considerations

FATSCOPY can write image copies to EMC DLm or MDL virtual tape systems. An image copy replaces the output scratch volume’s VOLSER with the input volume’s VOLSER. These systems can recognize that the output VOLSER has been changed so that the new VOLSER can be recognized for subsequent tape mounts. See IMAGE for more information.

When an input volume is scratched on a DLm, the volume is scratched in tape management records but still occupies disk space on the DLm. EMC provides a utility to reclaim this disk space. FDREPORT, can scan through the tape management data base, select the volumes which have been scratched in tape management, and build a job which you can run to scratch the backing disk space in the DLm. FDREPORT can filter the scratch volumes to select only those meeting criteria that you specify expiration date, VOLSER mask or range, etc.

Here is an example of an FDREPORT job to generate the DLm scratch job with RMM:

Here is an example of an FDREPORT job to generate the DLm scratch job with CA 1. With CA 1, you need to provide the name of the CA 1 TMC. In this example, we are going to generate scratch statements only for volumes that reside on the DLm units 03BA and 03BB.

This is an excerpt of the output from the FDREPORT job that can be used as input to the DLm scratch processing job. (Note that the "RMM" here a DLm command that is used no matter which tape management system you are using.)