Mark Stapleton wrote, in part, a week or two ago: > You've got half of the problem solved. You should be running two commands > per storage pool to be reclaimed: > > upd stgpool <stgpool_name> reclaim=60 > > when you want reclamation to start, followed by > > upd stgpool <stgpool_name> reclaim=100 > > when you want it to stop. (It will stop sooner than the scheduled time if it > finishes first.)
A few remarks ... 1. The low value that you use (60% in the above example) is completely up to you. Lower values tend to decrease restore times, wear out read/write heads, and potentially to decrease the number of tapes required. Higher values tend to leave more tape drive time to do other *SM actions. My hardware and rate of data change cause my low reclamation value to be more like 75-85 for my collated and copy pools. 2. The current tape's reclamation won't stop when you set recl=100, but will complete (unless you cancel the process). A tape reclamation might be quick, but might be fairly long depending on several data and hardware variables. My reclamations can run over an hour, but are generally somewhat less slow. 3. Although it may have changed in current *SM versions (mine is V3), reclamations of offsite volumes (in a copypool) are selected somewhat differently than others. Tivoli ADSM determines the volumes eligible for reclamation of copypools (just offsite tapes?) when you lower the reclamation value. The reclamation process will continue until all of those volumes are reclaimed ... even if you change to recl=100. 4. Reclamation (in tandem with some other operations such as backups) is one of the activities that can cause your recovery log to become pinned (I don't use roll forward). So, it might pay to keep an eye on the max utilization of your recovery log ... well, it probably will pay to keep an eye on it anyway ;-) Hope this helps, wayne Wayne T. Smith -- [EMAIL PROTECTED] -- University of Maine System -- UNET
