Joe Faracchio wrote to me:

>Try using a disk-file area and one tape reclamation.
>
>... joe.f.
>
>Joseph A Faracchio,  Systems Programmer, UC Berkeley

Hello Joe,

Have you had good results with this technique to speed things up?

It would be nice if there was some documentation to explain the practical
differences in the behaviour of

(1) Reclaim (tape pool to itself)
(2) Move Data (tape pool to itself)
(3) Move Data (tape pool to disk pool) followed by Migrate (disk pool to
tape pool)

There has been discussion on this list, and some suggestions in Tivoli
documentation,
on differences between Reclaim and Move Data with respect to how much space
is
recovered - Reclaim removes empty space from within aggregates, Move Data
just
copies aggregates without reconstructing them.

What is important to me in the present context (relaiming tapes with Notes
Agent files
and large numbers of "collocation clusters") is the elapsed time taken by
the operation,
and also to some extent the resource consumption.

I find that (1) and (2) are similar and abysmally slow, but use very little
CPU or database
I/O (as I said in my original posting, most of the elapsed time is waiting
for input tape
positioning).

(3) on the other hand is MUCH faster (typically an hour or two for the Move
Data and
same again for the Migrate, although sometimes the Migrate bogs down a
bit).   CPU
consumption is quite significant.  It is noticeable that the Move Data to
disk does not
issue the ANR1142I messages (counting "clusters") which are issued both by
the
Reclaim and by Move Data to tape.

Why is the Move Data to disk so much faster than the Move Data to tape,
when the input
tape is the same?

I take it that performance using your suggestion (4), Reclaim to Disk File
then Migrate
back to tape pool, will be quite similar to my (3).

I haven't tried (4) because I am reluctant to invest more disk space for a
housekeeping
function, and my normal disk pool (uncached) is mostly free during the day.
Unfortunately
it is a bit manual, I initially hoped I could automate it by defining the
disk pool as the reclaim
pool, but found that this is not allowed to be a random access pool.  Your
method gets
around this.  On the other hand, I can overlap multiple Move Datas, but
only one tape will
Reclaim at a time.

Cheers,
Geoff