Working with Model9 Life-Cycle

Managing the life cycle of resources in object storage

Life cycle management is a batch process that runs on z/OS and performs life cycle operations on resources. Expired data set backups and full volume dumps are deleted during the policy run according to the number of generations specified by the policy or SMS. Expired archived data sets and their catalog entries, and expired exported data sets are deleted by the life cycle management process.

Running life cycle management

Before running for the first time

  • Associate the same user-id to the Model9 z/OS agent and for the life cycle management process. Running life cycle management requires the userid to have READ access to: M9.LIFECYCLE.CLOUD.DELETEEXPIRED.

  • A life cycle management process can be associated with one resource complex only. Define a life cycle management process per each resource complex.

  • Only one life cycle management process can run simultaneously for the same resource process.

  • By default, all LPARS in a SYSPLEX are associated with the same resource complex, named “group-<sysplex-name>”. Running life cycle management in any lpar will delete the expired archived data sets in the whole sysplex.

Running for the first time

  • The life cycle management process can be activated in simulate mode, meaning it will report the data sets that would have been deleted without actually deleting them.

  • On the first run, the life cycle management process will scan all the archived data sets with an expiration date.

Running regularly

  • The next time the life cycle management process will run, it will pick up where the previous process ended.

  • It is recommended to run a life cycle management process every day.

Lifecycle action delete-expired

Parameters description

The sample JCL M9LIFECY can be found at the Model9 SAMPLIB PDS, see the installation guide for more details. The PWD parameter should point to the agent installation directory.

Parameter

Format

Description

Default

--simulate

yes/no

Life cycle runs in simulation mode, meaning no actual deletes occur

yes

--target

cloud

The target storage to be scanned (only cloud is supported)

cloud

--action

delete-expired

The life cycle action to be performed

delete-expired

--scan-start-date

yyyy-MM-dd

The projection start date to start scanning from. Accepted values are past dates only.

Previous successful run date

Additional Parameters

There are additional life cycle parameters which can be controlled from the agent.yml configuration file.

Parameter

Default value

Description

lifecycle.deleteExpired.gdg.minimumDays

7

The minimum number of days that a data set will be kept after being archived. After the number of minimum days has passed, the data set will be checked whether it is eligible for deletion.

lifecycle.deleteExpired.gdg.intervalDays

4

After the minimum number of days has passed, the data set will be checked whether it is eligible for deletion. The data set will be checked every X days.

deleteexpired.cds.catalogexpiration.minimumdays

7

The minimum number of days that a cloud data set with catalog controlled expiration (EXPDT=99000). After the number of minimum days has passed, life cycle will check if the data set is still cataloged, if it's not then the content will be removed and if it's not it will be postponed by the internalDays value.

Deleting cloud data sets

Cloud data sets are data sets that were migrated from another media, and are a copy of the original data set. The expiration date of a cloud data sets can be set in the import policy. See Importing data sets from tapes for more details.

Deleting data sets backup

Data sets with retention periods create either using a Model9 policy or using the Model9 CLI BACKDSN command, would be deleted by the life cycle when the expiration date is met.

Deleting archived data sets

The recorded expiration date of an archived data set is established upon archive. On the due day, life cycle management verifies that the expiration date has not changed.

Determining expiration date for archived data sets

For all data sets, life cycle management first explores the following data set attributes: 1. Expiration date in the data set’s VTOC entry at time of archive 2. 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 was 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: 1. The data set’s Management Class, if one is assigned. 2. If not, the SMS base configuration default Management Class, if one is assigned 3. 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 will be kept until manually deleted. 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 it is possible to delete it using the DELARC command, or to redefine the Management Class.

Archived Generation Data Sets

The decision to check whether the archived GDS is eligible for delete is determined by parameters in the agent’s configuration file. See the installation guide for more details. A GDS will be deleted according to expiration date and catalog entries, in the following manner:

  • An archived GDS with an explicit expiration date will be deleted according to the expiration date, regardless of whether it is active or rolled off.

  • An archived GDS without an explicit expiration date will be deleted once it is rolled off. Life cycle management treats GDS without a catalog entry as rolled off.

  • An archived GDS that has no expiration date, no catalog entry and no GDG base catalog entry will not be deleted at all, to avoid accidental deletes due to problems in the z/OS catalog.

  • An archived GDS with a GDG base catalog entry defined with the PURGE parameter, will be 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 will not affect already archived GDS - archived GDS will be treated according to the GDG base catalog entry on time of archive. New GDSs of the same GDG base catalog entry will not be archived.

Archived permanent data sets

Data sets with the following expiration dates are considered permanent and will not be 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 will not be 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

HSM default for EXPIREDATASETS parameter is NO, meaning that data sets that were created with an explicit expiration date in the catalog or VTOC, will not be deleted by an automatic process. When setting the HSM EXPIREDATASETS parameter to SCRATCH, HSM will delete the expired data sets during space management. Model9 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, see the table below for all special expiration dates and the life behavior:

Expiration Date

Expected Behavior

EXPDT=99000

Cloud data set expiration is catalog controlled. Expiration validation check will be performed every week by default.

EXPDT=90nnn

Same behavior as 99000

EXPDT=98nnn

Considered permanent

EXPDT=88nnn

Considered permanent

EXPDT=99366 or EXPDT=99365

Considered permanent

EXPDT=99nnn

Considered permanent

EXPDT=An actual date

Life cycle will expire the CDS on the requested date run.

No specific date specified

Considered expendable and can be removed manually at anytime with DELCDS

Last updated