Sorry, my previous answer assumed you where speaking of offsite pool

A quick fix to this (maybe long term in a perl script watcher too) is to
make maxscratch zero until it uses up one of the Filling tapes and moves
on to the other.

I use maxscr=0/max+1 , reclaim to disk-file and a perl program to
manage my collocated onsite pool so that tapes that are reclaimed
are given a new scratch as replacement on a strict one-for-one basis.

... joe.f


Joseph A Faracchio,  Systems Programmer, UC Berkeley


On Tue, 3 Apr 2001, Walker, Lesley R wrote:

> I'm scratching my head trying to figure out why this is happening:
>
> I have a reclaim running, no other processes, no client sessions.
> Collocation is off.
> The reclaim is moving data from volume A to volume B,
> there is another volume C in the same stgpool with FILLING status,
> and volume D is scratch, unassigned.
>
> When B reaches end-of-volume, I would expect it continue by mounting C - but
> no, it takes the scratch tape, defines it in that stgpool and uses it - even
> though there would have been more than enough space on C to have taken all
> the data.
>
> Is there some reason why it does this?  I would prefer it to leave the
> scratch volume alone so that it would be available to whatever stgpool might
> need it in the next 24 hours.
>
> Server is 3.7.4 on Solaris
> Library is an Exabyte 8mm thing defined as SCSI (2 drives, 10 slots)
>
>
> --
> Lesley Walker
> Unix Engineering, EDS New Zealand
> Lesley.Walker AT eds DOT com
> "I feel that there is a world market for as many as five computers"
>     Thomas Watson, IBM corp. - 1943
>