The backup and archival functions make saved data available as possible replacements for a certain period of time. The length of this period can be specified:
The retention period is the period of time during which a volume is protected against overwriting and thus the data stored on that volume is protected against deletion.
The operand RETENTION-PERIOD refers to the save files of an archive and serves to define the number of days after the completion of a save file during which the volume containing the save file is to be protected against overwriting.
In the migration and version backup functions, the retention period is determined only via the archive definition; in the other basic functions, it can also be specified in the corresponding HSMS statement.
The expiration date derives from the retention period. It is reached once the retention period has expired:
expiration date = creation date + retention period (in days)
(Expiration date = Creation date + Retention period)
In the case of a standard save file with NEW-STD-SAVE-FILE=*IN-PERIODS the continuation period must also be taken into account (see the section "Updating ("continuing") save files").
The expiration date is indicated on the volume, in the archive directory and, if applicable, in the MAREN catalog. The expiration date can be increased later in the HSMS archive directory; by doing so the expiration date of the volume in the MAREN catalogue is automatically increased as well. However, these changes cannot be carried out on the volume itself. Therefore, the volume is only protected after the original expiration date when MAREN is loaded and the volume is not moved to another system.
If the retention period of a save file on disk is increased, this protects the save file from deletion and the expiration date of its catalog entry is changed.
From HSMS V8.0A the retention period of a save file cannot just be increased but also reduced (SAVE-FILE-RETPD-UPD operand, also with a negative value). When the retention period of a save file is changed later, you must ensure that in backup archives the Cataloged-Not-Saved entries of files from incremental backups which have not been modified also require the reference to the last full backup, possibly in another save file, for restoration purposes. It does not make sense to release the save file with the full backups earlier, before the save file with the incremental backup.
In addition to the volume expiration date derived from the physical retention period, HSMS permits the definition of a file expiration date in connection with long-term archives. The file expiration date can be defined for a particular save version (and its files), independently of the retention period defined for the volume. A file expiration date may be useful, for instance, when reshuffling the save tapes: when reshuffling the cartridges, the archive owner may retain only those save versions whose logical expiration date has not yet been reached.
If, for instance, cartridge reshuffling takes place every 2 years and a retention period of 2 years has been defined, the cartridges can be released and used again for saving, without reinitialization, after copying the files whose logical expiration date has not yet been reached (for more information, refer to section "Copying within long-term archives").
The HSMS administrator can use the operand FILE-EXPIRATION-DATE to define for long-term archives whether the user-specified file expiration date may exceed the volume expiration date (FILE-EXPIRATION-DATE=*UNRESTRICTED).
Since a volume is no longer protected once the retention period has expired, the archive owner must take appropriate administrative measures to protect the volume, e.g. by using the SAVE-FILE-RETPD-UPD operand. This operand, which is recommended for archives with several save versions, allows the retention period of the volume to be automatically increased. The new retention period of the volume depends on the file expiration date of the newly created save version. This change also affects the MAREN catalog.
Note
Specifying the value 0 for a file’s retention period can have undesirable consequences since this value indicates that the expiration date and creation date are the same. As a result, the save file has no retention period and can be deleted immediately after creation.
This status can lead to unexpected deletion and inconsistencies in the directory file: If the deletion of an archive whose retention period has the value 0 is initiated while an action statement is simultaneously issued for this archive (e.g. BACKUP-FILES), then the save file is deleted. However, since the action statement continues to run, a number of dependent records will be locked in the directory file and can therefore not be deleted. HSMS will be able to identify the inconsistencies later since the records remain in the directory file.
You should therefore be very careful when assigning a retention period of 0.
Retention period and expiration
When the retention period has elapsed (expiration date today or earlier) and all backup versions of a save file have reached their expiration date a save file is regarded as “obsolete” and can therefore be deleted using the MODIFY-ARCHIVE statement with a MAREN release of the volume in the event of tape backups.
As of HSMS V8.0A the option of automatically deleting obsolete save files is also provided implicitly for backups or copy operations in backup or long-term archives. This function is not available for migration and version backups. As of V11.0 MAREN also normally dispenses with a separate release run so that the release can take place immediately when the tape is deleted and it can be used again straight away for the subsequent backup or copy. Automatic deletion of obsolete save files is enabled with the archive attribute AUTOMATIC-DELETION = *OBSOLETE-SAVE-FILES.
When Several-SVID format and large cartridges are used it can be practical to update a backup file with a very large number of save versions. In this case at some point so many save versions starting at the start beginning of the save tape will be obsolete that it will be possible to release the first tape volume of the save file and reuse it. A finer function based on save versions is available for backup and long-term archives with the archive attribute AUTOMATIC-DELETION = *OBSOLETE-SAVE-VERSIONS: implicit deletion of obsolete save versions from the beginning of the save file in the archive directory in conjunction with the release of the tapes in the save file which are now no longer required.
With both variants implicit deletion takes place only when the save or copy operation is performed by the archive owner.
Sketch of a save file on tape in Several-SVID format in the case of implicit deletion in accordance with the variant AUTOMATIC-DELETION = *OBSOLETE-SAVE-VERSIONS
Assuming that SVIDs A to D each have an elapsed expiration date, SVIDs A to H are distributed to the backup tapes as follows:
Tape-1: | SVID-A | SVID-B | SVID-C | |
Tape-2: | SVID-C remainder | SVID-D | SVID-E | SVID-F |
Tape-3: | SVID-F remainder | SVID-G | SVID-H | Continue position |
These obsolete save versions are deleted in the archive directory and Tape-1 is released. Tape-2 and Tape-3 are not released because these tapes do not yet contain elapsed SVIDs. Tape-3 is also needed for the next save run.