How archive logs are recalled by DFSMShsm

DFSMShsm can automatically migrate and recall archive log data sets and image copy data sets. If Db2 needs an archive log data set or an image copy data set that DFSMShsm has migrated, a recall begins automatically and Db2 waits for the recall to complete before continuing.

For processes that read more than one archive log data set, such as the RECOVER utility, Db2 anticipates a DFSMShsm recall of migrated archive log data sets. When a Db2 process finishes reading one data set, it can continue with the next data set without delay, because the data set might already have been recalled by DFSMShsm.

If you accept the default value YES for the RECALL DATABASE parameter on the Operator Functions panel (DSNTIPO), Db2 also recalls migrated table spaces and index spaces. At data set open time, Db2 waits for DFSMShsm to perform the recall. You can specify the amount of time Db2 waits while the recall is being performed with the RECALL DELAY parameter, which is also on panel DSNTIPO. If RECALL DELAY is set to zero, Db2 does not wait, and the recall is performed asynchronously.

You can use System Managed Storage (SMS) to archive Db2 subsystem data sets, including the Db2 catalog, Db2 directory, active logs, and work file databases (DSNDB07 in a non-data-sharing environment). However, before starting Db2, you should recall these data sets by using DFSMShsm. Alternatively, you can avoid migrating these data sets by assigning them to a management class that prevents migration.

If a volume has a STOGROUP specified, you must recall that volume only to volumes of the same device type as others in the STOGROUP.

In addition, you must coordinate the DFSMShsm automatic purge period, the Db2 log retention period, and MODIFY utility usage. Otherwise, the image copies or logs that you might need during a recovery could already have been deleted.