Backing up and Restoring IAM Data Sets

Backup Overview

Frequently, IAM data sets are incorporated into normal DASD management procedures for backup, restore, and archival (or migration) purposes. Software products that provide such services can easily handle IAM data sets within the normal functionality that they provide. The major considerations are, first, that IAM data sets are treated as non-VSAM data sets by these products, and second, that the default DSORG of PS for IAM files is highly recommended to provide the most flexibility when managing IAM data sets with such products. The functionality and limitations that these products have with non-VSAM data sets, will apply for IAM data sets.

Many application job streams incorporate their own backup of their related data sets in scheduled time frames that are more relevant to the application, and provide for improved recoverability of application data. As an aid to those responsible for maintaining recoverability of application data contained in IAM data sets, this section will present some of the considerations with the various methods of backing up and restoring at the data set level, along with some examples. The examples are intended to demonstrate basic functionality of the various backup and restore methods that are applicable to IAM data sets.

Alternate Index Considerations

For IAM data sets in an associated Alternate Index sphere, as with VSAM, the most critical piece is the base cluster data set. After restoring a base cluster, the Alternate Indexes and paths can always be recreated if backups are not readily available. The major concern with IAM Alternate Indexes and their associated data sets is that DASD management utility programs will treat each data set as a separate entity. With VSAM, some of these utilities have developed processing to recognize the associations, and handle the base cluster and all associated Alternate Indexes and paths as one entity. Using data set naming conventions within a set of Alternate Index associated data sets, where the only name difference is in the last index level of the name, will help ease the data set management difficulties. By doing so, you can treat any set of associated data sets by a data set group name in the control cards for the utility. Information on how to do this will be provided in some of the subsequent examples.

Backup with IDCAMS

The most common method for backing up IAM base cluster and alternate index data sets by application job streams is with IDCAMS REPRO. This method copies the data at the record level into a sequential output data set. The main advantages of using such a backup are that, the application programs can directly read the data from the backup sequential data set, a restore will reorganize the data set, and when moved to a different device type, IAM will adjust the block size automatically to obtain the best possible device utilization. Performance of such a backup can be very fast through effective use of buffering. If the sequential copy of the data is only used for backup purposes, then the IAM Backup Compressed feature can be used if the data set was compressed with IAM software compression. This feature prevents the decompressing of the data during backup, and the compressing of data when it is used to reload the data set. Using the IAM Backup Compressed feature, saves CPU time, as well as I/O time transferring data to and from the backup media. There is unlikely to be any savings in terms of the number of tapes required to backup the IAM data set when the tape devices that also offer compression, because the data is already compressed. The main disadvantage of IDCAMS REPRO is that, the attributes used to define the data set are not retained with the output data set. While IDCAMS does offer a function for VSAM data sets to save the data set attributes, called EXPORT, and the corresponding restoration of data set and attributes with IMPORT, IAM does not provide support for the use of those functions.

Backup and Restore Utilities

An alternative to using IDCAMS is to use a software product that provides DASD data set management functions, including backing up and restoring data sets. Examples of such products include FDR, ABR, DFSMSdss, and DFSMShsm. These products offer the fastest possible data movement, along with various data set management capabilities. A major advantage of using one of these products is that the file attribute information is saved with the backup, along with an exact image of the data set. The disadvantages are that, the application programs can not directly access the data because of the format it is stored in, the software is not as easy to use as an IDCAMS REPRO, when restored the data set is not reorganized, and restoration to an unlike device can cause inefficient usage of DASD space. However, when fast backup times are required, and when the backup copy of the data is not being used by the application, then these DASD utilities will meet that requirement.

Other Backup Options

There are other utility software products that provide a data movement capability for VSAM data sets and can also be used for IAM data sets. Examples include, using the DFSORT, SYNCSORT, or DITTO. These and similar software products essentially work like an IDCAMS REPRO, where they process the data at the logical record level, using standard access method I/O requests. Software packages that use control interval (CI) access to process VSAM data sets or do their own I/O rather than using VSAM, such as FAVER or BMC VSAM-ASSIST, will not work with IAM data sets.

Using IDCAMS REPRO

The use of IDCAMS REPRO for backing up and restoring IAM data sets is straight forward. Jobs that have been set up to backup VSAM data sets with this method should not require any changes. One thing to be careful about is that, IDCAMS defaults sequential output files to RECFM=U, which forces each output record to become a physical block on the storage media. This can waste media and backup time. By assigning the output data set a RECFM=VB, and a block size of 27998 for 3390 DASD, or 32760 for tape, plus providing a large number of buffers, will speed up the REPRO process substantially. When an installation uses the IAM buffering defaults as shipped, then there should be no need for IAM overrides on an IDCAMS repro, unless you desire to use BACKUPCOMPRESSED.

Example A:IDCAMS Backup

In this example, a large multi-volume IAM data set is backed up by an IDCAMS REPRO. The output media is tape. Note that the DCB information that is provided including BUFNO. The LRECL for the output tape volume is the maximum record size defined for the IAM data set, and four for the RDW added for variable format records and an additional four for IAM compression data. Therefore, assuming the IAM file has a maximum record length of 1016, a value of minimum 1024 must be used for the LRECL on the output data set. The BACKUPCOMPRESSED override is specified because the sequential output file will not be used for any purpose other than to reload the data set should a restore be needed. A volume count of 20 is provided for the output tape data set to provide enough tape volumes to hold the data. A LISTCAT ALL is included so that information on what is needed to define the data set, if necessary, is readily available.

Example of IDCAMS Backup (EX1085A)

Example B:IDCAMS Restore

The following example demonstrates how to restore the data set that was backed up in the prior example. The IAM data set is not being deleted and redefined, so the REUSE parameter is required on the REPRO statement. A BUFNO is provided on the tape input to speed up reading the data. A CREATE override indicating BACKUPCOMPRESSED is required because the backup tape contains IAM compressed data. A LISTCAT ALL is done after the REPRO to verify the new file structure.

Example of an IDCAMS Restore with BACKUPCOMPRESSED (EX1085B)

Example C: Decompress the Backup Data Set

If ever needed, the IAMRECVR utility program can be used to create a sequential uncompressed file from the sequential file with records in an IAM data compressed format, as created by using the BACKUPCOMPRESSED override. The new file will contain uncompressed records from the original data set, ready to be used by application or other processing needs. To perform this function, you must know the key length and key offset (RKP) for the file being processed. These values can be obtained from a LISTCAT or an IAMINFO report from the original data set. In the example below, a new sequential backup with uncompressed records is created using the sequential data set created in Example EX1085A. The DISKIN DD specifies the original backup data set, and the TAPEOUT DD specifies the new uncompressed data set.

Example of decompressing a BACKUPCOMPRESSED Data Set (EX1085C).

Single Volume

For the DASD backup and restore utilities, the examples will be split into single volume data sets, and multi-volume data sets. Single volume IAM data sets are very easily dumped and restored with either FDR or DFSMSdss. While normally not necessary, it is recommended that the original data set be deleted prior to doing the restore if you are replacing the original data set. When the delete is complete, the restore will allocate the data set attempting to obtain all the required space in one extent, which may be beneficial because the file may be able to acquire more DASD space.

The single volume examples shown below are all set to handle either a single IAM data set, or all associated IAM data sets in an alternate index sphere, if they are all on the same volume. If the various associated data sets are on different volumes, then use the multi-volume procedures. For these examples, each associated data set in the Alternate Index sphere has an identical high level qualifiers, with only the last level being different. Assume the following names:

• Base Cluster DSN=my.iam.dataset.cluster
• Alternate Index DSN=my.iam.dataset.aix
• Path DSN=my.iam.dataset.path

If you are using different naming conventions, refer to the space for the product you use for further information on building a data set name mask.

Example D: FDR/DSF BACKUP

In this first example, FDR is being used to backup an IAM data set to tape. The JCL requirements are for a DISKx DD statement that specifies the volume of the data set being backed up. Then a corresponding TAPEx DD statement is required for the tape to contain the backup data.

Example of FDR/DSF Backup of Single Volume IAMData Set (EX1085D)

Example E: FDR/DSF Restore

The restore of the data set is just as easy. This example works whether or not the original data set had been deleted. The DISK1 DD specifies the receiving volume, which does not have to be the same as the data set originally resided on. The TAPE1 DD specifies the backup tape created in the prior backup example. The backup tape could also be from a full volume backup as well.

Example of an FDR/DSF restore of a Single Volume IAM Data Set (EX1085E)

Example F: DFSMSdss Backup

In this next example, DFSMSdss is being used to backup an IAM data set. The output tape is specified by the OUTDD parameter, and use of an input DD is optional, and not shown in this example.

Example of DFSMSdss Dump of a Single Volume IAM Data Set (EX1085F)

Example G: DFSMSdss Restore

This corresponding example demonstrates how to restore the IAM data set. The output volume could be the same as the original, or different.

Example of DFSMSdss Restore of a Single Volume IAM Data Set (EX1085G)

Multivolume Backup & Restore

Multivolume backup and restore operations require a little more effort. The best overall process for the combined backup and restore effort seems to be using the application backup capabilities of ABR. While this does require an additional job step on both the backup and restore jobs, the data set is restored across the same number of volumes as it had originally, along with the same amount of space on each volume. If the ABR product is not available, then the same results can still be achieved with FDR/DSF with a little more effort on the JCL. DFSMSdss can also be used for multivolume backup and restore, although it may be difficult to restore the data set spread across multiple volumes as it was originally.

The multivolume backup and restore process can also be used when backing up an IAM alternate index sphere, where the data sets reside on different volumes, or one or more of the data sets resides on multiple volumes. These set of examples will continue to assume use of the data set naming conventions from the single volume examples.

Example H: ABR Backup

In this example, a multi-volume IAM data set will be backed up using ABR application backup and recovery capability. While the example given here is a single data set, multiple data sets for the entire application can be backed up and restored as necessary with this technique. Basically, this process involves creating a temporary archive control file, which is used to store information about the data sets backed up, and is subsequently also backed up to the same tape as the data sets. If this type of backup job is being set up to run on a regular basis, then GDG data set names can be used for both the Archive control file, and the backup of the Archive control file.

The Archive control file can be deleted after this job runs. Full details on using this capability of ABR can be found in section 52 of the FDR space.

Example of FDR/ABR Backup of Multivolume IAM Data Set (EX1085H)

Example I: ABR Restore

The restore process is a two step process as well. The first step restores the copy of the archive control file that was backed up, and the next step restores the IAM data set. In this example, the data set is being restored to the original volumes, however, there are various options to change the volumes that it is being restored to, as well as to give the data set a new name. When restoring as the original data set, it is highly recommended that the data set be deleted first, so that ABR can allocate it as it existed previously.

Example of FDR/ABR Restore of Multivolume IAM Data Set (EX1085I)

Example J: FDR/DSF Multivolume Backup

FDR/DSF can also be used to backup and restore a multi-volume IAM data set, although the use of ABR Application backup is strongly recommended. A three volume IAM data set is being backed up in this example. Each volume is effectively a separate backup, but can and should be done in one job step. For each DASD volume, there will be a DISKx and corresponding TAPEx DD card. As long as you make sure that you get all the pieces on both the backup and restore, this process will work fine.

Example of using FDR/DSF to Backup a Multivolume IAM Data Set (EX1085J)

Example K: FDR/DSF Multivolume Restore

To restore the data set, the procedure is almost identical. In this example, the data set is being restored to the same three volumes, however, different volumes could be used, and the data set could be given a new name. If the data set is being restored to replace the existing version, it is required that the data set be deleted prior to performing the restore. To make sure that the data set does not exist, the restore is preceded by an IDCAMS step to delete the data set.

Example of Using FDR/DSF to Restore a Multivolume IAM Data Set (EX1085K)

Example L: DFSMSdss Multivolume Backup

In this last pair of examples, DFSMSdss is being used to backup and subsequently restore a multi-volume IAM data set. As can be seen, the backup portion of this example is essentially identical to the backup of a single volume IAM data set.

Example of DFSMSdss Backup of a Multivolume IAM Data Set (EX1085L)

Example M: DFSMSdss Multivolume Restore

Now in this example, DFSMSdss will be used to restore the data set backed up in the prior example. Unless you can be certain that the IAM data set was not deleted and defined or reorganized since the backup was done, the data set must be deleted prior to attempting the restore. This is to prevent a possible restore failure. To force the data set to be split across the three volumes, temporary data sets are allocated on all of the DASD volumes so that DFSMSdss will not find enough space to restore the whole data set on any particular volume. The manual part of this process involves checking each volume for how much space it has available, and determining how much space is needed by the data set being restored, and how much space should be used on each volume for the data set being restored. Then, set up the JCL to allocate a temporary data set on each volume with the remaining free space.

Example of DFSMSdss Restore of a Multivolume IAM Data Set (EX1085M)