OAM provides the following mechanisms to help you ensure that objects
are not deleted accidentally or prematurely:
- CBRHADUX exit
- The CBRHADUX auto-deletion user exit can optionally be used to
define a set of objects that are not to be deleted by OSMC expiration
processing, even though the objects’ expiration criteria had
been met. The CBRHADUX user exit is invoked only for OSMC expiration
processing. It is not invoked, and therefore offers no protection,
for OSREQ DELETE requests.
- CBRUXSAE exit
- The CBRUXSAE authorization user exit can optionally be used to
verify the caller has authority to perform an OSREQ DELETE request.
- Deletion-hold
- When an object is in deletion-hold mode, it cannot be deleted
from the OAM inventory (either by OSREQ DELETE or by OSMC expiration
processing). An object can be put into deletion-hold mode by a DELHOLD=HOLD
parameter on the OSREQ API. It can be released from deletion-hold
mode by a subsequent OSREQ API request with the DELHOLD=NOHOLD parameter
specified.
- Deletion-protection
- When deletion-protection is enabled (at a global or storage group
level) OAM will not allow an object to be deleted prior to its expiration
date. Deletion-protection differs from retention-protection in that
deletion-protection can be turned on and off by the installation,
and deletion-protection has no restrictions on the expiration date
changing.
- Event-based-retention
- When an object is in event-based-retention mode, its expiration
date is not calculated until OAM has received notification that an
external event has occurred. An object is placed into event-based-retention
mode with an RETPD=-2 (negative 2) parameter on the OSREQ API. At
that point its expiration date is set to the special value of 0002-02-02
and the object is waiting for notification of an external event before
calculating the expiration date. The external event notification
comes in the form of receipt of an OSREQ API request with the EVENTEXP=nnnn parameter.
- Retention-protection
- Retention-protection provides OAM’s most stringent protection
to ensure that an object has not been modified or deleted prior to
its expiration date. When retention-protection is enabled for a given
object, OAM will not allow that object to be deleted prior to its
expiration date. Additionally, OAM will not allow the expiration date
to be changed to an earlier date. It will however, allow the expiration
date to be changed to a later date. If an object is stored into an
object storage group that has retention-protection enabled, then that
object is considered retention-protected for the life of the object.
Installations cannot disable retention-protection for a retention-protected
object.
Note: OAM does not allow the modification of data
for an existing object, so the procedure to modify an object’s
data is to delete the original object and then store the modified
data with the original object name. Therefore, protecting an object
from being deleted will also prevent it from having its data modified.
See z/OS DFSMS OAM Application Programmer's Referencez/OS DFSMS OAM Application Programmer's Reference for
more information.