---------------------------- Top of message ----------------------------
>>--> 03-28-96  20:53  S.SHEPPARD     (SHS)    Re: Offsite Reclaim
>>--> 03-28-96  20:53  S.SHEPPARD     (SHS)    Re: Offsite Reclaim
Charles:
To answer your last questions first;  the local storage pool does have
collocation on and the 'offsite' copy pool does not.  The first has
about 2000 volumes and the latter about 1200.

Your supposition about multiple relaimable volumes needing the same
volume from the local pool could definitely be correct given the colloc-
ation differences. I have redriven the reclaim process a couple of times
and each time some volumes do get reclaimed.  If this is the problem, it
seems there should be some indication, however.  I'll pass this info on
to ADSM support and see what their take is. I also thought of the MOVE
DATA approach, but haven't gotten to it as yet.
Thanks
Sam Sheppard
---------------------------- Top of message ----------------------------
>>--> 03-28-96  09:36  ..NETMAIL     (001)          Re: Offsite Reclaim
>>--> 03-28-96  09:36  ..NETMAIL     (001)          Re: Offsite Reclaim
>Sam Sheppard Writes:
>I have opened an ETR with ADSM support on this question, but thought
>that I would post it here too, in case anyone else might have run into
>this problem.
>
>Running MVS version 2 server at level .3, I am finding that the reclaim
>of my offsite copy pool is not working correctly.  Scenario is as follows:
>
>  1. Reset reclaim % on the offsite copy pool from 100 to 80.
>  2. Some 300+ volumes start reclaim processing.
>  3. Tapes from the local pool get called in for the reclaim process.
>  4. Some small percentage (around 10) of the offsite tapes get the
>     message that they are now SCRATCH volumes and are PENDING (based on
>     REUSEDELAY).
>  5. All 300+ tapes get message that reclaim processing is complete yet
>     only a small percent (see #4) are actually empty. The rest still
>     contain varying amounts of valid data as shown by QUERY VOLUME and
>     QUERY CONTENT commands.
>
>Any insight into this would be greatly appreciated as we seem to be
>chewing up a lot of tape unnecessarily.
>
>Sam Sheppard
>San Diego Data Processing Corp.
>SHS AT SDDPC.SANNET DOT GOV
>(619)-581-9668

I am running at the same server level as you.  I haven't tried this function
yet -- thanks for shaking out the bugs first!

My gut feeling is that you are running into serialization problems when
multiple reclaims want to read from the same primary storagepool cartridge.
Have you tried running another reclaim immediately after the first, by
setting the percent to 100 then back down to 80?  This should redrive reclaim
immediately.  I think it should; I don't know of any frequency check to limit
reclaim.  If this works it might be a solution so you can get you tapes
back -- using an automation tool, redrive reclaim until a message says there
are no eligible volumes.

You might try a 'move data' on one of the volumes which had data left as
a check that your database is ok.  This might be another bypass -- capture
the volsers of the volumes with residual data and issue move data commands
on them.  (A developer told me that reclaim is just a volume selector and
driver for the move data function.)

Some questions - are you using collocation on the primary or copy pool?
How many reclaim processes were you running?  How many volumes are in
use in the primary and copy pools?

Bill Colwell
C. S. Draper Lab
Email: BColwell AT draper DOT com
Voice: 617-258-1550
-----------------------------------------------------------------------`
=========================================================================