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


Recalling objects to disk

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

When objects residing on optical or tape media are retrieved, they can be recalled to the DB2 sublevel or file system sublevel for up to 255 days beyond the day of retrieval, thereby providing improved performance for subsequent retrieves of those objects. If you anticipate increased demand for an object, you can specify, through OSREQ or SETOSMC keywords, how long to keep it on the DB2 sublevel or file system sublevel when retrieving it. After the specified number of days have elapsed the objects are restored back to their original location as part of the OSMC storage management cycle.

For each OSREQ RETRIEVE request for an object residing on optical or tape media, OAM determines whether or not a recall to the DB2 sublevel or file system sublevel is required, either explicitly through the RECALL keyword on the OSREQ RETRIEVE, or implicitly through SETOSMC keywords in the CBROAMxx PARMLIB member. If a recall is specified, OAM initiates a recall request to the OSMC component to write a full copy of the object to the DB2 sublevel or file system sublevel at the same time the OSR component of OAM services the object retrieval. The location field for an object will be updated to "R" (if recalled to the DB2 sublevel ) or to "2" (if recalled to the file system sublevel). The objects pending action date will be set to the current date + the number of days the object is to be recalled. Because these OSMC recall tasks can consume considerable resources, you may wish to use the MAXRECALLTASKS keyword on the SETOSMC statement to limit the number of recalls that can run simultaneously.

Automatic class selection (ACS) routines are not invoked when the recalled object is copied to the DB2 sublevel or file system sublevel. ACS may, however, be invoked when the object is restored to its original location and the DB2 or file system copy is deleted after the specified number of days. After the specified number of days, the recalled object is subsequently processed by OSMC, which deletes the disk copy of the object and updates the object's location and pending action date based on the object's current management class. If the calculated pending action date is the current date or earlier, object processing will occur at this time for that object, including object expiration, the invocation of the ACS routines for transitioning the object, or both.

Recalls are processed asynchronously with the actual RETRIEVE request so that the RETRIEVE is not delayed while recall processing takes place. For each object that is recalled, an OSMC task is started in the background. This can result in subsequent RETRIEVES for an object with recall processing still pending. In most cases the cartridge will still be mounted on the drive, reducing any delays on subsequent retrievals. To increase the chances of the volume still being mounted, use the TAPEDISPATCHERDELAY function described in SETOAM keyword definitions for global level and the and OPTICALDISPATCHERDELAY function described in SETOPT keyword definitions.

See Updating SETOSMC values and Updating SETOAM values for information on specifying recall to the DB2 sublevel or file system sublevel.

Refer to z/OS DFSMS OAM Application Programmer's Reference for information on using the optional RECALL keyword on an OSREQ RETRIEVE request to initiate an explicit recall.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014