move data and reclamation

PREDATAR Control23

Ok as long as you ran pct_reclaim>85 in the query we should be good. That's looking at tapes that are 15% utilized, or has 85% 'free space' so to speak after expiration and what not has ran.
With the 5 scratch tapes to work with and 14 tapes with pct_reclaim higher than 85, we should be able to get those to come back as scratch once your reuse delay is taken into consideration.
I'd recommend updating the copy pool from what marclant said here:
Starting off, I think you should be able to update the Reclamation Threshold to well...85 and then run a protect storagepool with the reclaim=only. That should return those 14 tapes to scratch after using one or more tapes (depending on number of protect processes you have defined). You should see a summary and worker threads start. It is generally advisable not to cancel that process. So, if you don't want to dedicate time (no idea how fast you are able to write to tape) to run at 85%, set it higher to say 95, then 90, then 85. Just slowly step it down to free up tapes. And after each step, run a new protect process with reclaim=only

Now, if for some reason those tapes won't reclaim, I highly suggest starting a case with IBM. I have had some issues with directory copy container pools on tape, but the thoughts are around the fact that I was on 7.1.x code at the time.

I'm out traveling for a few days so likely won't be able to respond right away.
Take care!
 
Top