Author's note: I was fortunate to attend a very brief and informal OAM Tuning presentation by Sherrie Niederbrach from OAM development.
These are the notes from that presentation.
If you have any specific questions, I suggest you contact OAM support.
OAM provides the following controls for tuning:
In the CBROAMxx parmlib member:
- TAPEDRIVESTARTUP threshold optional subparameter of the STORAGEGROUP parameter on the SETOAM statement, determines when OAM is to start additional tape drives for writing object data to tape volumes that belong to the Object and Object Backup storage groups.
- MAXTAPESTORETASKS keyword (for the OAM global level) and SGMAXTAPESTORETASKS keyword ( for the storage group level)
- MAXTAPERETRIEVETASKS keyword (for the OAM global level) and SGMAXTAPERETRIEVETASKS keyword ( for the storage group level)
- DEMOUNTWAITTIME keyword (how long in a non-busy environment to keep a volume mounted if not being read/written). In a busy environment this keyword is ignored.
- TAPEDISPATCHERDELAY an optional parameter that specifies a numeric value of 1 through 60 and can be used at the global level only. This specifies that OAM wait a specified number of seconds before demounting a tape volume, even if other work is available for this drive. This delay allows time for a new read request to come into OAM that requires the currently mounted tape volume. This delay can greatly reduce the number of mounts and demounts of volumes for certain applications.
Restriction: Do not specify a number greater than the number of tape drives available to OAM for the combined MAXTAPESTORETASKS, MAXTAPERETRIEVETASKS, SGMAXTAPESTORETASKS, and SGMAXTAPERETRIEVETASKS subparameters. This specification can cause a system to go into allocation recovery and attempt to allocate tape drives after all tape drives are in use causing system problems.
In ISMF:
- The CYCLE START TIME and CYCLE END TIME attributes of each Object or Object Backup storage group control the window in which the storage management cycle begins processing and (optionally, stops processing) the storage group.
- In an OAMplex, the OSMC processing system name for each Object or Object Backup storage group controls where OSMC processing is done for that storage group. Using this parameter and separating hardware between storage groups can balance workload across systems for OSMC processing. Localize hardware and highest usage to reduce XCF overhead.
In SYS1.PROCLIB(OAM)
- The MAXS parameter of the OAM cataloged procedure controls the number of storage groups that the storage management cycle processes concurrently.
- The REST parameter of the OAM Cataloged procedure controls whether or not OAM should automatically restart when it receives notification that a new SCDS is activated.
In IEFSSNxx PARMLIB member
- The UPD=N option on the OAM1 statement in IEFSSNxx member of PARMLIB reduces unnecessary retrieval and update of objects' directory entries during the OSMC cycle if your installation's management classes do not use the TIME SINCE LAST USE or EXPIRE AFTER DAYS USAGE parameters.
- The QB=N option on the OAM1 statement in IEFSSNxx member of PARMLIB reduces unnecessary calls into the OAM address space for each backup copy on an OSREQ query request. Many applications issue an OSREQ query prior to an OSREQ retrieve and do not want or need the queried information on the backups and gathering the backup information can extend the overall retrieval response for the application.
Remember that OSMC functions other than the storage management cycle you start (for example, Volume Recovery utility, Move Volume utility, and others) are consumers of resources as well and need to be considered in your usage of the MAXS and DRIVE STARTUP threshold controls.
Attention: If you plan on using the CBRHADUX installation exit that is shipped with the SAMPLIB or plan on editing or creating your own CBRHADUX installation exit that does not allow expiration of objects, using this exit can cause OSMC performance problems if you have not properly established your expiration criteria in your SMS management classes.
If you do not plan on expiring objects and have established your CBRHADUX installation exit to return with an indication that no expiration is allowed, you must make sure that your SMS management class has expiration criteria that does not cause OSMC to continually pick objects to be expired. Always be sure that your management class sets the expiration criteria to NEVER expire if you do not plan to expire OAM objects.
