Geoff,

You ask if you are letting it run long enough.  Do you actually cancel
the reclaim process?  Just raising the reclaim threshhold at 7 pm should
not stop the process.

If you are cancelling the process, then you are running offsite reclaim
like the old Greek math/philosophy question -- if a grasshopper jumps
half the distance to a wall will it ever reach the wall? (I don't know the
answer either).

The way offsite reclaims work is that all the eligible volumes are identified,
then the good files on all those volumes are sorted together in order
of the primary pool volumes that the unexpired files are on.  Then
the process starts mounting the primary pool volumes and rebacking up the
unexpired files.  If you don't let the process finish it is possible
for none of the offsite volumes to reach empty; they may all have just one
file on them that would have been recopied from the last primary volume
that didn't get mounted because of the cancel.
When you restart offsite reclaim, a new volume may enter the
process and possibly every primary volume needs to be mounted again.

Try running a reclaim=99 process and let if finish.  That should be short
and should put the 0.0% and full volumes into empty status.


--
--------------------------
--------------------------
Bill Colwell
Bill Colwell
C. S. Draper Lab
Cambridge, Ma.
bcolwell AT draper DOT com
--------------------------
In <C6ABD2B1D4F9D4119D3B0002A52C0FEC41B4F5 AT cp-its-exs04.mail.saic DOT com>, 
on 05/10/01
In <C6ABD2B1D4F9D4119D3B0002A52C0FEC41B4F5 AT cp-its-exs04.mail.saic DOT com>, 
on 05/10/01
   at 10:01 AM, "Gill, Geoffrey L." <GEOFFREY.L.GILL AT SAIC DOT COM> said:

>>-----Original Message-----
>>From: Robin Sharpe [mailto:Robin_Sharpe AT BERLEX DOT COM]
>>Sent: Wednesday, May 09, 2001 1:57 PM
>>To: ADSM-L AT VM.MARIST DOT EDU
>>Subject: Re: reclaim spoy stgpool volumes
>>Geoff...
>>
>>You should be removing ALL copy pool volumes every day, even
>>if they are
>>only 1% used (that's what DRM does).  True, they will immediately be
>>reclaimed when you do the next reclaim for copy pools, but at
>>least you're
>>covered in case of disaster.

>Robin,

>I do eject "all" tapes every day. I have been keeping an eye on this and
>from what I can tell this is not a true statement, as it relates to my
>environment anyway.

>Here is output from the following command; q vol * access=offsite f=d (I
>took only one tape as an example)

>                   Volume Name: U00531
>             Storage Pool Name: OFFSITE_POOL
>             Device Class Name: 3590CLASS
>       Estimated Capacity (MB): 20,000.0
>                      Pct Util: 0.0
>                 Volume Status: Filling
>                        Access: Offsite
>        Pct. Reclaimable Space: 100.0
>               Scratch Volume?: Yes
>               In Error State?: No
>      Number of Writable Sides: 1
>       Number of Times Mounted: 1
>             Write Pass Number: 1
>     Approx. Date Last Written: 10/02/00 07:06:32
>        Approx. Date Last Read: 10/02/00 07:03:19
>           Date Became Pending:
>        Number of Write Errors: 0
>         Number of Read Errors: 0
>               Volume Location: Arcus
>Last Update by (administrator): GEOFF
>         Last Update Date/Time: 10/02/00 14:11:57

>Q volhist goes all the way back to February and does not show this tape
>number. Unless I'm wrong it looks as though this tape has been in the
>offsite pool since October of last year. Notice the percent util is 0.0. I
>run a schedule that drops the threshhold "upd stg offsite_pool reclaim=60"
>at 3:30PM  and back "upd stg offsite_pool reclaim=100" at 7:00PM, every day
>of the week. Why has it taken so long for this volume to be reclaimed. At
>the moment I have 76 filling volumes offsite that I wish would consolidate
>to fewer.

>Does anyone else have a similar situation going on? Is my reclamation not
>running long enough?

>Thanks,

>Geoff Gill
>TSM Administrator
>NT Systems Support Engineer
>SAIC
>E-Mail:   gillg AT saic DOT com
>Phone:  (858) 826-4062
>Pager:   (888) 997-9614