Template Programming Interface Guide › Backup Job Template Files › OPTIONS Record

OPTIONS Record

OPTIONAL

Use OPTIONS records to specify processing options for the job to apply to the domains it backs up, unless an exception file specifies different options for a particular domain.

A file can include multiple OPTIONS records. An OPTIONS record can specify more than one parameter; however, the record can specify each parameter only once.

OPTIONS {“Parms”}...

Parms:

  BKPFILE {STANDARD | EXPANDED}
| BKPDETAIL {DOMAIN | FILE}
| BKPTYPE {ARCHIVE | LOGICAL | CMS | PHYSICAL | CMSALLOC | SFS}
| CATDETAIL {DOMAIN | FILE}
| CMSCHANGE {DATE | HASH}
| CMSSWITCH {YES | NO}
| CMSTRIES number
| DIRSCAN {YES | NO}
| PACKDATA {YES | NO}
| PHYSCHANGE {HASH | NONE}
| SFSTRIES number

Definitions

BKPFILE {STANDARD | EXPANDED}

Specifies whether CA VM:Backup is to store additional file information with the file. STANDARD indicates that CA VM:Backup is not to store the additional file information; EXPANDED indicates that CA VM:Backup is to store the additional file information on the tape.

Note: The BKPFILE parameter is only available through TPI. However, using BKPFILE STANDARD will not prevent you from managing the job template file through CA VM:Backup screens.

The BKPFILE EXPANDED parameter can only be used by an authorized client.

BKPDETAIL {DOMAIN | FILE}

For an incremental backup job, specifies whether the job is to back up the entire domain or just the portion that has changed since the previous backup. DOMAIN specifies that CA VM:Backup perform a full backup of the domain if it has changed since the last backup. FILE specifies that CA VM:Backup back up just those files that have changed.

BKPTYPE {ARCHIVE | LOGICAL | CMS | PHYSICAL | CMSALLOC | SFS}

Specifies the type of backup format the job is to use. For explanations of the backup formats, see the Systems Programmer Reference Guide.

Note: CA VM:Backup always exports the BKPTYPE SFS parameter as BKPTYPE LOGICAL. If an INCLUDE record specifies SFS data, CA VM:Backup backs up the data in SFS format, regardless of backup format specifications

BKPTYPE SFS is available only through TPI; using this parameter will not prevent you from managing the job template file through CA VM:Backup screens. BKPTYPE ARCHIVE is available only through TPI and can be used only by an authorized client.

CA VM:Backup uses the SFS backup type for BFS data as well.

CATDETAIL {DOMAIN | FILE}

Specifies the level of detail the job is to include in the catalog it creates. DOMAIN specifies detail at the domain level. FILE specifies detail at the file level.

CMSCHANGE {DATE | HASH}

Specifies change detection information for data backed up in CMS format. For a full backup, CMSCHANGE specifies what to save in the catalog to use for comparison during an incremental backup to detect whether data has changed. For an incremental backup, it specifies what values should be compared with the values stored in the catalog to determine whether data has changed. For more information, see the change detection information in the Administration Guide.

CMSSWITCH {YES | NO}

Indicates how the job is to handle a CMS minidisk that is still changing after trying to back it up the number of times specified by the CMSTRIES parameter. NO tells the job to skip the minidisk. YES tells the job to switch to a physical backup of this minidisk.

CMSTRIES number

Specifies the number of times the job is to try to back up a CMS minidisk that changes during the backup. Specify an integer from 1 through 9 for number. After number tries, the job either skips the minidisk or switches to a physical backup of the minidisk, as specified by the CMSSWITCH parameter. The default is 3.

DIRSCAN {YES | NO}

Specifies whether the job is to scan the CP online directory and SFS file pools for domain information.

DIRSCAN NO does not mean that the job will never read the CP online directory or the SFS catalog. The job may scan the directory for information that will enable CA VM:Backup to link to the minidisks and obtain information about the domains to be backed up. The job may scan the SFS catalog for information that will enable CA VM:Backup to link to storage group minidisks and obtain information about the domains to be backed up.

When a backup job template file specifies DIRSCAN NO:

• The job considers the minidisk information indicated in the job template file and any associated exception file valid and uses it.
• You must identify the file pool to CA VM:Backup on the FILEPOOL configuration file record, and CA VM:Backup must be an administrator of that file pool.
• The INCLUDE records in the job template file must explicitly specify the domains the job is to back up; the records cannot use pattern matching.

Note: This parameter is available only through TPI. Using the DIRSCAN NO parameter will prevent you from managing the job template file through the CA VM:Backup screens.

PACKDATA {YES | NO}

Specifies whether the job is to pack data.

PHYSCHANGE {HASH | NONE}

Specifies change detection information for data backed up in physical format. For a full backup, PHYSCHANGE specifies what to save in the catalog to use for comparison during an incremental backup to detect whether data has changed. For an incremental backup, it specifies what values should be compared with the values stored in the catalog to determine whether data has changed. For more information, see the change detection information in the Administration Guide.

SFSTRIES number

Specifies the maximum number of times the job is to check for changes in a file space during a backup. If after number checks CA VM:Backup still detects changes, the job backs up the file space, but writes a message in the job output report indicating that it could not obtain a consistent point-in-time view of the file space. Enter an integer from 0 through 9. The default is 0, which means that CA VM:Backup does not perform a consistency check. This default is suitable for most sites because SFS guarantees a consistent view of individual files. However, if you run applications that require files to be maintained at the same commit level, that is, in sync with each other, have CA VM:Backup perform one or more consistency checks, or quiesce the file space.

Note: This option has no effect on BFS file spaces. BFS files are update-in-place files; CA VM:Backup cannot detect changes in these files. To ensure a consistent point-in-time view of a BFS file space, you must quiesce the file space during backups.