Delete-expired considerations
Determining expiration date for archived data sets
For all data sets, life cycle management first explores the following data set attributes:
- Expiration date in the data set’s VTOC entry at time of archive
- Expiration date in the data set’s catalog entry at time of archive
For VSAM data sets, the catalog entry of the cluster is searched for a valid expiration date. For non-VSAM data sets, both the VTOC entry and the catalog entry are searched for a valid expiration date. The farthest date of both is considered to be the determinative expiration date. If a valid expiration date is found and it is earlier than the current date, the data set and its catalog entries are deleted. If no valid expiration date is found, the data set is not deleted. If the expiration date is later than the current date, the data set expiration date is updated.
Determining expiration date for SMS-managed archived data sets
For SMS-managed data sets, the process continues and searches the data set’s Management Class expiration attributes.
The data set’s Management Class is determined according to SMS rules:
- The data set’s Management Class, if one is assigned
- If not, the SMS base configuration default Management Class, if one is assigned
- If not, the Management Class default values
The Management Class expiration attributes are compared to the data set’s VTOC attributes:
- The data set’s creation date is compared to EXPIRE AFTER DATE/DAYS
- The data set’s last reference date is compared to PRIMARY DAYS NON-USAGE
If both Management Class attributes have values and can be calculated to a valid expiration date, the farthest of both is considered to be the determinative expiration date. If a valid expiration date is determined and it is earlier than the current date, the data set and its catalog entry are deleted. If no valid expiration date was found, the data set is not deleted and is kept until you manually delete it. If the date has not passed yet, the data set is not deleted and its expiration date is updated to the new date.
If the data set has an assigned Management Class that does not exist, an error message is displayed. In this case, you can delete it by using the DELARC command, or to redefine it the Management Class.
Archived generation data sets
The decision to check whether the archived generation data set is eligible for delete is determined by parameters in the agent configuration file. A generation data set is deleted according to expiration date and catalog entries, in the following manner:
- An archived generation data set with an explicit expiration date is deleted according to the expiration date, regardless of whether it is active or rolled off.
- An archived generation data set without an explicit expiration date is deleted once it is rolled off. Life cycle management treats generation data sets without a catalog entry as rolled off.
- An archived generation data set that has no expiration date, no catalog entry, and no generation data group (GDG) base catalog entry is not deleted at all, to avoid accidental deletes due to problems in the z/OS catalog.
- An archived generation data set with a GDG base catalog entry defined with the PURGE parameter is deleted when rolled off, even if its expiration date has not been reached yet.
- Changing the SCRATCH attribute of an existing GDG base catalog entry from SCRATCH to NOSCRATCH does not affect already archived generation data sets. Archived generation data sets are treated according to the GDG base catalog entry on time of archive. New generation data sets of the same GDG base catalog entry are not archived.
Archived permanent data sets
Data sets with the following expiration dates are considered permanent and are not deleted by life cycle management if archived:
Expiration parameter | Value |
|---|---|
Catalog PERM dates | 9999.999 1999.999 1999.365 1999.366 |
Catalog EMPTY dates | 0000.000 No expiration date |
VTOC PERM dates | 1999.999 1999.365 1999.366 |
VTOC EMPTY dates | 0000.000 No expiration date |
Deleting archives manually vs an automated process
The Management Class default expiration attributes value is NO LIMIT, meaning that by default, an archived data set is not deleted by automatic processes, but can be deleted by a manual action such as the DELARC CLI command.
HSM SETSYS EXPIREDATASETS for archived data sets compatibility
The HSM default for EXPIREDATASETS parameter is NO, meaning that data sets that are created with an explicit expiration date in the catalog or VTOC are not deleted by an automatic process. When setting the HSM EXPIREDATASETS parameter to SCRATCH, HSM deletes the expired data sets during space management. BMC AMI Cloud life cycle management is compatible to EXPIREDATASETS(SCRATCH) only.
Cloud Data Sets special dates support
Cloud data sets (CDS) supports the usage of special dates for expiration.
The following table lists all special expiration dates and their life behavior:
Expiration date | Expected behavior |
|---|---|
EXPDT=99000 | Cloud Data Set expiration is catalog controlled An expiration validation check is performed every week by default. |
EXPDT=90nnn | Same behavior as 99000 |
EXPDT=98nnn | Considered permanent |
No specific date specified | EXPDT=date |
Life cycle will expire the CDS on the requested date run. | EXPDT=99nnn |
Considered permanent | EXPDT=99366 or EXPDT=99365 |
Considered permanent | EXPDT=88nnn |
Considered permanent | Considered expendable and can be removed manually at anytime with DELCDS |
Determining expiration date for archive resource versions
Archive resource versions expire as part of the BMC AMI Cloud life cycle process.
Determining expiration date for backup resource versions
Backup resource versions that you create as part of a policy with generation settings, expire during the upcoming runs of a policy.
Another option is to define a backup policy by using a retention period. When you define a retention period, backup resource versions expire only after their expiration date.