z/OS DFSMS OAM Planning, Installation, and Storage Administration Guide for Object Support
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Processing object expiration

z/OS DFSMS OAM Planning, Installation, and Storage Administration Guide for Object Support
SC23-6866-00

Each object stored by OAM is assigned an expiration date. This expiration date is derived using the retention period (RETPD) keyword on the OSREQ STORE macro when the object was stored, the expiration rules in the SMS management class assigned to the object, or both.

When a class transition occurs, the SMS storage class and management class ACS routines are invoked. The SMS storage class ACS routine can assign a new management class to the object. Input to the SMS storage class and management class ACS routine indicates that the reason the routine is invoked is for an OAM object class transition. As a result of a new SMS storage class being assigned to the object, the physical location of the object in the OAM storage hierarchy might change. As a result of a new SMS management class assignment to the object, the expiration date of the object might change as well as its backup requirements.

If an OSREQ CHANGE request is performed and a new retention period is specified with the RETPD keyword on the OSREQ CHANGE macro, then the expiration date of the object is recalculated based on the period specified with the RETPD keyword on the OSREQ CHANGE macro. This is true regardless of the media type of the primary or backup copy.

Note: If the requested expiration date is earlier than the retention date for a retention-protected object, the expiration date is set to object's retention date.

When the OSMC storage management cycle determines that an object has reached or passed its expiration date and is not in deletion-hold status, it invokes the Auto-Delete Installation Exit to approve the deletion of the object. If the exit approves the deletion of the object, the object is expired. When an object expires, all copies of the object are deleted, the row for the object in the Object Directory Table is deleted and any reusable resources are reclaimed. For objects residing on tape volumes, the number of logical KB deleted from the tape volume is incremented for each object deleted.

If at any time an object’s management class results in the object’s expiration date being set to 9999/12/31 while that object is on removable media, that volume’s expiration date is set to 9999/12/31. The volume never expires, even if the object’s management class changes at a later date allowing the object to expire. Be aware of the affects of expiration dates that can be set by a management class, even if it is being used as an interim management class for an object.

For primary copies in the DB2 sublevel, OSMC deletes the copy from the DB2 sublevel. For primary copies in the file system or on optical or tape, OSMC makes a delete request to LCS to delete the copy from the file system, optical, or tape.

For backup copies on optical or tape, OSMC makes a delete request to delete all the copies from optical or tape.

For both optical and object tape volumes, the number of logical KB of data that is deleted from an OAM optical or tape volume containing objects is calculated and stored in the VOLUME or TAPEVOL table. Each time LCS receives a request to delete an object from an optical or tape volume, LCS updates the number of logical KB deleted for that volume. Because an application could choose to do a DB2 ROLLBACK after requesting a delete, the count of the logical KB deleted in the VOLUME or TAPEVOL table is an approximation.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014