Restore skeletons

When a backup is originally registered through the file copy notification service, a five character product identifier is associated with the backup.

The product identifier is a concatenation of the three character backup_product and two character backup_type parameters that are specified when the service is called. For example, you can specify a product identifier of 'REPRO' when notifying CICS® VR of backups made using the IDCAMS REPRO utility.

Prior to selecting a registered backup for restore, a restore skeleton must be defined to CICS VR for the product identifier associated with the selected backup. The restore skeleton must either be added as a member to the SDWWSENU data set, using the characteristics of this PDS, or as a member of another PDS allocated to the DWWSLIB ddname. The restore skeleton member name must follow this naming convention:

DWWxxxxx (where xxxxx is the product identifier)

For example, a restore skeleton that was created for the backups registered with the 'REPRO' product identifier must be defined with the DWWREPRO member name.

The restore skeleton must contain the commands required to restore the associated backup type. For example, if the target data set already exists, the restore skeleton associated with backups created by IDCAMS REPRO might contain commands to call REPRO to copy records from the backup data set into the target data set.

To make a restore skeleton usable with all backups of the same type registered for various VSAM spheres, you can include variables within the skeleton. CICS VR supports a number of variables that can be used to retrieve information about the backup and VSAM data set that is stored in the RCDS, such as backup name and data set name, along with parameters specified during recovery creation through the CICS VR panel interface, such as new target data set name, volume, and unit. For example, in the REPRO skeleton, you might include the &CBUDSN variable name to retrieve the original backup data set name that is stored in the RCDS, along with other variables.

When a backup that was registered through the file copy notification service is selected for restore through the CICS VR panel interface, CICS VR adds the associated restore skeleton as a step in the produced recovery job. All variables specified in the restore skeleton are substituted with their associated values. For example, when a backup data set that is named 'EXAMPLE.REPRO' is selected for restore, the &CBUDSN variable name is substituted with the value EXAMPLE.REPRO.

This table lists all restore skeleton variables that are supported by CICS VR. When specifying a variable in a restore skeleton, be sure to precede the variable name with an ampersand (&).

Null variable value

CICS VR allows any of the variables described in the table Table 1 to be coded in a restore skeleton. However, CICS VR might not contain information about a specified variable in the RCDS. For example, control_interval_size is an optional input parameter of the file copy notification service. The CICS VR RCDS does not contain a value for the control interval size associated with a backup if it was not specified during notification. CICS VR substitutes a null string for all specified restore skeleton variables about which CICS VR does not contain information.

Restore skeleton logic

In most cases, restore skeleton variables can simply be placed within the commands and keywords required to restore the selected backup type. For example, a REPRO skeleton might contain the following statement to include the target data set name within the OUTDATASET keyword:

OUTDATASET(&CTODSN.)

However, some additional logic might be required within your skeleton to:

• Traverse through a table of similar items, such as volume names.
• Verify the existence of a variable before including it within a command or keyword.

Logic can be coded within your restore skeletons using the statements defined in the ISPF Dialog Developer's Guide and Reference. Below are a few examples of the most common logic that can be added to restore skeletons:

Table processing

CICS VR allows a few repeatable parameters, volume list, optional information, and ddname and APPLID list, to be specified to the file copy notification service. CICS VR stores these repeatable values in the RCDS and allows them to be retrieved from a table by a restore skeleton. To process a table within a restore skeleton, use the )DOT and )ENDDOT statements:

)DOT tablename
         additional statements
)ENDDOT

Any statements between the )DOT and )ENDDOT statements are processed for each row in the specified table. See Example using the CICS VR NOTIFY utility and restore skeletons for an example of using the )DOT and )ENDDOT statements.

Variable existence testing

As previously mentioned, information for some optional parameters of the file copy notification service might not have been specified during notification. Therefore, CICS VR might not contain values in the RCDS for all available restore skeleton variables.

To verify the existence or value of a variable before including it in your JCL or commands and keywords, you can use the )SEL and )ENDSEL statements, as shown:

)SEL &varname NE &Z
         additional statements
)ENDSEL

Note: &Z is the null string system variable.

The relational expression (&varname NE &Z) is evaluated for a true or false condition. If the condition is true, the skeleton input records between the )SEL and the corresponding )ENDSEL are processed. If the condition is false, these records are skipped. See Example using the CICS VR NOTIFY utility and restore skeletons for an example of using the )DOT and )ENDDOT statements.

Testing for new information

Code your restore skeletons so that they can process any new information, such as target data set name, volume, and unit, that might have been specified through the CICS VR panel interface during recovery construction. To help simplify the this logic, a few additional variables are provided by CICS VR. CNEWQ and CNEWVOLQ contain a value of 'YES' if a new value has been specified for either the target data set name or volume and unit respectively though the panel interface. Optionally, you can also use the CTODSN variable. CTODSN contains the new target data set name if it was specified through the panel interface, otherwise it contains the original data set name.

For example, you can code the following select statement to check if a new volume and unit was specified during recovery construction.

)SEL &CNEWVOLQ=YES
         volume and unit processing statements
)ENDSEL

In this example , the processing statements within the )SEL and )ENDSEL statements are only processed if a new volume and unit was specified through the CICS VR panel interface during recovery construction.

See the ISPF Dialog Developer's Guide and Reference for further details about coding statements within an ISPF skeleton.