I have found that single drive reclamation can get into a loop when a file
is encountered that is larger than the interim storage pool. For example,
tape reclamation writes the contents of reclaimable tapes to a sequential
volume on disk. If the contents of the tape is a fragment of a file that is
continued on additional tapes, a sequential storage pool shortage occurs.
When *SM finishes reclamation for this tape (and the volumes needed for this
file) it pauses and once again has a look at what volume should be next to
reclaim. Then, starts the process again at the same tape/file. And again.
And again.

Maxfilesize in the storage pool is not an option. So, I have bypassed single
file reclamation (ie: gone back to tape to tape) for the time being to get
around this nasty file. I intend to revert back to single file reclamation
in the near future. However, you can be sure this nasty file will come
around again. Or, a similar sized file will do the same.

I want to find out what these large files are and where they came from.
Then, I can do some analysis as to what should really be done about this
situation. I am hesitant to launch an SQL select against the contents
database table. Has anyone found a way to determine the largest file(s) in
*SM's inventory?

John G. Talafous                         Sr. Tech. Prog/Anal
The Timken Company                 Phone: (330)-471-3390
P.O. Box 6927                           Fax  : (330)-471-4034
1835 Dueber Ave. S.W.
Canton, Ohio USA  44706-0927
talafous AT timken DOT com                  http://www.timken.com/