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


4 Modifying the installation exit to manage deleted objects

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

For a new installation, evaluate and implement the auto-delete installation exit. If you are migrating to a new release, you can reuse the auto-delete installation exit.

Perform this step only if you are running OSMC for expiration processing.

One of the rules defined in the management class is the end of an object’s life. OSMC can delete an object when its lifetime expires. An object can also expire through an explicit expiration date. If an object has an explicit expiration date, the explicit expiration date takes precedence over the management-class-defined lifetime. OSMC calls the auto-delete installation exit before it deletes any object. The auto-delete installation exit indicates by return code whether the object should be deleted. Also, the installation exit can record the deletion of an object so applications can be kept synchronized with the OAM object directory table. In an OAMplex, you should synchronize the instances of CBRHADUX across the OAMs to avoid one OAM deleting an object with the approval of the exit when there is another exit on another OAM that is set to deny the delete request.

Requirement: The sample auto-delete installation exit prevents objects from being deleted. If your previous installation of OAM relied on the sample auto-delete installation exit to allow objects to be automatically deleted, you must modify the code in this exit to continue automatic deletion. You also must modify the code in this exit to define or change your installation handling of deleted objects. For more information about the installation exit, see Auto-delete installation exit (CBRHADUX).

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014