16f Define management classes.
You must perform this step at initial installation. During migration,
you might optionally perform this step if you are adding management
classes.
Pages 1 through 3 of the Management Class Define panel are primarily
for DFSMShsm’s management of data sets. OAM uses the following subset
of those parameters to manage objects in the same manner that DFSMShsm
manages data sets.
Related reading: See “Defining Management Classes” in
z/OS DFSMSdfp Storage Administration more information.
- EXPIRATION ATTRIBUTES
- Specify when an object can be deleted automatically by OAM, assuming
deletion-hold is not enabled for the object and assuming the deletion
is approved by the auto-delete installation exit.
Note: A value of
NOLIMIT for the EXPIRATION ATTRIBUTES means OAM will not automatically
delete the objects that are associated with this management class.
Those objects must be explicitly deleted by the application, using
the application interface to OAM.
Note: If an object is in event-based-retention mode (ODEXPDT
= '0002–02–02') then object expiration is dependent on receipt of
an external event trigger by the EVENTEXP keyword on the OSREQ API,
and therefore the following management class parameters are ignored.
- EXPIRE AFTER DAYS NONUSAGE
- Specify when the object is to be automatically deleted by OAM
relative to the elapsed time since it was last referenced. (If the
object has not been referenced since it was stored, the create date
is treated as the last reference.)
Note: Do not use UPD=N on the OAM1 statement in the IEFSSNxx member of PARMLIB if this option is used in your management
class.
- EXPIRE AFTER DATE/DAYS
- Specify when the object is to be automatically deleted by OAM,
relative to the elapsed time since it was created or on an explicit
date.
- RETENTION LIMIT
- Specify the retention limit allowed on explicit parameters on
the application interface to OAM.
- AUTO BACKUP
- Specify whether you want to back up the object by writing one
or two copies of the object. The backup copies are made during the
OSMC storage management cycle. If you set AUTO BACKUP=Y and the number of backup copies specified in NUMBER
OF BACKUP VERSIONS (DATA SET EXISTS) is 0 or 1, and you have not specified
a SECONDBACKUPGROUP keyword on any SETOSMC statement in the CBROAMxx member of PARMLIB, then OSMC schedules a single
backup copy of the object to be written. If you set AUTO BACKUP=Y and the number of backup copies that is specified
in NUMBER OF BACKUP VERSIONS (DATA SET EXISTS) is 2 or above, and
you have specified a SECONDBACKUPGROUP keyword on any SETOSMC statement
in the CBROAMxx member of PARMLIB, then
OSMC schedules two backup copies of the object to be written.
- BACKUP FREQUENCY
- Specify when you want the first backup copy to the object be written.
If you set AUTO BACKUP=Y and BACKUP FREQUENCY = 0, OAM schedules the
first backup copy to be written immediately after the primary copy
of the object is successfully stored. Otherwise, any backup copies
are made during the first storage management cycle after the object
is stored, or during the first storage management cycle after a new
management class is assigned for the object.
OAM suggests you use
the immediate object backup cautiously as it might impact the performance
of storing and retrieving primary copies of objects.
- NUMBER OF BACKUP VERSIONS (DATA SET EXISTS)
- Specify the number of backup versions to be made for an object
when OSMC processing is done for an Object storage group.
Valid values for
the NUMBER OF BACKUP VERSIONS (DATA SET EXISTS) field are as follows:
Page 4 of the Management Class Define panel is not used for data
sets; it is used for objects to define an event that causes OAM to
invoke ACS for the purpose of selecting a new storage class or management
class. These class transition events are:
- TIME SINCE CREATION
- Specify the time (YEARS, MONTHS, and DAYS) that must elapse relative
to the date the object was created. The YEARS, MONTHS, and DAYS attributes
can be used separately or in combination. A maximum date of 9999/12/31
will be used if TIME SINCE CREATION results in a date exceeding the
maximum.
- TIME SINCE LAST USE
- Specify the time (YEARS, MONTHS, and DAYS) that must elapse relative
to the date the object was last referenced. If the object has not
been referenced since it was stored, the create date is treated as
the last reference. The YEARS, MONTHS, and DAYS attributes can be
used separately or in combination. A maximum date of 9999/12/31 will
be used if TIME SINCE LAST USE results in a date exceeding the maximum.
Restriction: Do not use UPD=N on the OAM1 statement in the
IEFSSNxx member of PARMLIB if this option
is used in your management class.
- PERIODIC
- Specify that a class transition will occur at a regular period,
based on the calendar (regardless of when the object was created or
referenced). This parameter has five attributes, which can be used
either separately or in combination:
- MONTHLY ON DAY
- Specify FIRST, LAST, or a number from 1 to 31 indicating the day
of the month on which class transition should occur; leave blank if
unused.
- QUARTERLY ON DAY
- Specify FIRST, LAST, or a number from 1 to 92 indicating the day
of the quarter on which class transition should occur; leave blank
if unused.
- QUARTERLY IN MONTH
- Specify a number from 1 to 3 indicating the month in each quarter
on which class transition should occur; leave blank if unused.
- YEARLY ON DAY
- Specify FIRST, LAST, or a number from 1 to 366 indicating the
day of the year on which class transition should occur; leave blank
if unused. For example, choosing the number 366 allows the transition
to occur on 1/1 of the next year. In the event of a leap year, OSMC
causes the transition to occur on 12/31 of the current year.
- YEARLY IN MONTH
- Specify a number from 1 to 12 indicating the month of the year
on which class transition should occur; leave blank if unused.
Restriction: You cannot specify the TIME SINCE CREATION,
TIME SINCE LAST USE, and PERIODIC attributes together.
An object’s management class association can change as a result
of an application request or a class transition. Should a change occur,
OAM applies the new management criteria. This might result in a variety
of actions, such as:
- Up to two backup copies might be made where one did not exist
before.
- An object’s lifetime might be decreased or increased.
- A new class transition event can cause the invocation of ACS routines
in the future.
As you define management classes and prepare and review your implementation
of class transition using the Automated Class Selection routines,
it is critical to analyze the end result of your class transitions
to avoid processing inefficiencies, unexpected results, or both.
The usage of TIME SINCE CREATION and TIME SINCE LAST USE attributes
must be carefully studied to ensure that one of the class transitions
in a series of class transitions assigns a management class, which
causes the next class transition to occur in the future or
the object to expire. Ensuring a management class is assigned to cause
the next class transition to occur in the future is accomplished through
your extensions to the operating system in the Management Class Automatic
Class Selection routine.
Restriction: Do not use the TIME SINCE LAST USE or the TIME
SINCE LAST REFERENCE attributes if you are using the new parameter
(UPD=N) on the CBRINIT line in the IEFSSNxx PARMLIB member with no pending action date. See Updating the IEFSSNxx PARMLIB member for more information.
If your implementation allows for a series of class transitions
that do not result in a class transition scheduled in the future,
or do not result in an object expiring and being deleted, the results
of the storage management cycle might be affected. Depending on the
number of objects processed, operational conditions, or possible processing
interruptions due to contention, it is likely that processing will
be seriously degraded. This could potentially force the storage management
process into a loop that attempts to identify a future date for class
transition processing or expiration for one or more objects.
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 will be set to 9999/12/31. This
will cause the volume to never expire, 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. This expiration date can be modified using the MODIFY OAM,UPDATE
command.
z/OS DFSMS OAM Planning, Installation, and Storage Administration Guide for Object Support
Copyright IBM Corporation 1990, 2014