No.

Reclaim is the process of recovering unused portions of tapes by copying the
good stuff to a new tape.

Colocation is an option reduces the number of tapes occupied by the backups
for a system.  This will make restores faster since it reduces the number of
tape mounts at the expense of additional tape mounts for backups and more
partially filled tapes.  Some sites use it for critcal servers.

I suggest reading the Getting Started redbook.  That's not its full name;
but if you search for that you should be able to find it.


On Wed, 20 Jun 2001, Taylor, Garry wrote:

> Hello to all,
> I have a very basic question ( I am new user ) is the Reclaims process the
> same as colocation??
>
> Garry
>
> -----Original Message-----
> From: Lindsay Morris [mailto:lmorris AT servergraph DOT com]
> Sent: Wednesday, June 20, 2001 5:16 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Reclaims Ques
>
>
> Thanks Richard, Eric, all---
>
> I've seen the reclaim-won't-let-go situation a lot, and sometimes tried to
> cancel the reclamation process ---
> and STILL, more often than not, it takes 40 minutes for cancel process to
> take effect!
>
> I didn't have NOPREEMPT set (unless it's a default value -- I think it's
> not);
> I didn't have huge files;
> I've seen this on DLT700 and on 3590 drives;
>
> For me it's more curiosity than critical; maybe it's a major annotance for
> some other people.
> I wonder if any developers can shed some light.
>
>
> > -----Original Message-----
> > From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf 
> > Of
> > Loon, E.J. van - SPLXM
> > Sent: Wednesday, June 20, 2001 5:25 AM
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Subject: Re: Reclaims Ques
> >
> >
> > Hi Lindsay and Richard!
> > I have seen the exact same thing here!
> > The day before yesterday a user called me about an Oracle database restore
> > that was taking quite some time. I did a q sess and saw that it was in a
> > MediaW state. I have two tape units and TSM was reclaiming a tape. I was
> > also expecting to see the preempting message, but the reclaim was not
> > canceled by TSM. As soon as I did a CANCEL PROC the reclaim stopped, the
> > tapes were dismounted, the clients tape was mounted and the client restore
> > continued.
> > Yesterday we did the exact same thing and the running reclaim WAS
> > cancel by
> > a preemption!
> > So prioritizing works.... Sometimes...
> > Kindest regards,
> > Eric van Loon
> > KLM Royal Dutch Airlines
> >
> > -----Original Message-----
> > From: Richard Sims [mailto:rbs AT BU DOT EDU]
> > Sent: Tuesday, June 19, 2001 21:48
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Subject: Re: Reclaims Ques
> >
> >
> > >How long does it usually take for the reclamation process to
> > actually stop,
> > >and release the tape drive(s) so the restore can use them?  I've
> > typically
> > >seen this be 40 minutes or more, but I'm not sure why,  or if something
> > >could be done to speed it up.
> >
> > Lindsay - The first thing I would check is whether you have NOPREEMPT in
> >           your server options file.  Reclamation of onsite volumes itself
> > takes a long time, but at least looks at the Reclamation Threshold between
> > volumes: offsite volume reclamation never looks back, just continuing to
> > process all the volumes it saw that it had to do when it started.
> >
> > If you don't have NOPREEMPT in force, there may be something else at play.
> > Do queries in a future situation and see if an explicit Cancel Process
> > will stop reclamation.
> >
> >   Richard Sims, BU
> >
> >
> > **********************************************************************
> > This e-mail and any attachment may contain confidential and
> > privileged material intended for the addressee only. If you are
> > not the addressee, you are notified that no part of the e-mail or
> > any attachment may be disclosed, copied or distributed, and that
> > any other action related to this e-mail or attachment is strictly
> > prohibited, and may be unlawful. If you have received this e-mail
> > by error, please notify the sender immediately by return e-mail,
> > and delete this message. Koninklijke Luchtvaart Maatschappij NV
> > (KLM), its subsidiaries and/or its employees shall not be liable
> > for the incorrect or incomplete transmission of this e-mail or
> > any attachments, nor responsible for any delay in receipt.
> > **********************************************************************
> >
>