Right,

But that only goes for primary storage pools!!!!!


Frans Bijma ADSM certified professional
Solution 6000 BV

> -----Original Message-----
> From: Leo Humar [mailto:lhumar AT BIGPOND.NET DOT AU]
> Sent: Thursday, July 29, 1999 1:22 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Reclaimed to a different pool?!
>
>
> Hi Richard,
>
> There is a setting in stgpools that let you specify another
> storagepool as
> your reclaim pool.
> For the reclaim to work the way you wan't it to is to leave this field
> blank.
>
> from the admin reference manual:
>
> RECLAIMSTGpool=poolname
>
>      Specifies another storage pool as a target for reclaimed
> data. This
> parameter is primarily for use with
>      storage pools that have only one drive in its library.
> This parameter
> allows the volume to be reclaimed to
>      be mounted in its library and the data is then moved to
> the specified
> reclaim storage pool.
>
>      This parameter must be an existing primary sequential
> storage pool.
> This parameter is optional, however,
>      if this parameter is used all data will be reclaimed to
> that storage
> pool regardless of the number of drives
>      in that library.
>
>      The reclaim storage pool itself must be defined as a
> primary storage
> pool.  There are no restrictions on
>      this storage pool's definition, but it should be defined with a
> NEXTSTGPOOL= value that will migrate its
>      data back into the data storage hierarchy. Because its
> primary function
> is to collect reclaimed data, its
>      NEXTSTGPOOL= value should be the same storage pool from
> which the data
> was reclaimed.
>
>
> Leo Humar
> LCS Pty Ltd
> lhumar AT bigpond.net DOT au
>
> No trees were killed in the sending of this message. However a large
> number of electrons were terribly inconvenienced.
>
> -----Original Message-----
> From: Adam Slesinger <aslesinger AT US.BNSMC DOT COM>
> To: ADSM-L AT VM.MARIST DOT EDU <ADSM-L AT VM.MARIST DOT EDU>
> Date: 28 July 1999 21:55
> Subject: Re: Reclaimed to a different pool?!
>
>
> >Sorry if I wasn't clear enough.  During reclamation of the
> offsite tape
> copy pool, TAPECOPYPOOL, a volume from our primary onsite
> >tape pool, TAPEPOOL, was grabbed and used as the output
> volume for the
> reclamation process.  Can anyone tell me why on earth ADSM
> >would do this?  It should have created a new tape in
> TAPECOPYPOOL and have
> written the data to that volume to be taken offsite,
> >right?  My concern is that TAPECOPYPOOL is now not an exact
> duplicate of
> TAPEPOOL because the reclamation removed the data from
> >the four offsite tapes in TAPECOPYPOOL and consolidated it
> onto a tape in
> TAPEPOOL .  Does anybody have any ideas?  Thank you!
> >
> >adam
> >__________________
> >Adam Slesinger
> >Corporate Information Systems
> >Brown & Sharpe, RI
> >Phone: (401) 886-2236
> >Pager: (800) 913-5395
> >Email: aslesinger AT us.bnsmc DOT com
> >
> >
> >
> >Richard Cowen wrote:
> >
> >> >We have a primary tape pool (TAPEPOOL) and a copy pool
> (TAPECOPYPOOL)
> >> >both made up of DLT tapes.  We're in the process of
> creating processes
> >> >to send and retrieve the copy pool tapes to our offsite
> location without
> >> >the help DRM.  We created a schedule to kick off
> reclamation of the copy
> >> >pool tapes on Sunday, so there would be tapes to return
> on Monday.  When
> >> >I checked the activity log for the reclamation, it had
> identified 4
> >> >offsite tapes in TAPECOPYPOOL that were eligible to be
> reclaimed.  The
> >> >weird thing is that it grabbed and wrote the data to a
> private volume in
> >> >TAPEPOOL!  I was under the impression that a new tape
> volume would be
> >> >defined in TAPECOPYPOOL, the data would be written to
> that tape, we'd
> >> >send that tape offsite, and bring the other 4, now empty,
> tapes back.
> >> >Could someone tell what a possible reason exists for it
> to have grabbed
> >> >a tape from a different pool as the output of the reclamation??
> >>
> >> What pool did it go to?
> >> Sample of one of mine:
> >>
> >> 07/23/99   11:39:20      ANR2202I Storage pool BACKUP3590_OFFSITE
> updated.
> >> 07/23/99   11:39:20      ANR0984I Process 467 for SPACE RECLAMATION
> started
> >>                           in the BACKGROUND at 11:39:20.
> >> 07/23/99   11:39:20      ANR1040I Space reclamation
> started for volume
> M00386,
> >>                           storage pool BACKUP3590_OFFSITE
> (process number
> 467).
> >>
> >> ...
> >> 07/23/99   11:41:53      ANR1044I Removable volume M00582
> is required for
> space    <== source of files to copy
> >>                           reclamation.
> >> 07/23/99   11:41:53      ANR8324I 3590 volume M00582 is
> expected to be
> mounted
> >>                           (R/O).
> >> 07/23/99   11:43:01      ANR8337I 3590 volume M00368
> mounted in drive
> DRIVE02
> >>                           (/dev/rmt1).
> >> 07/23/99   11:43:02      ANR8337I 3590 volume M00582
> mounted in drive
> DRIVE01
> >>                           (/dev/rmt0).
> >> ....
> >> 07/23/99   11:55:47      ANR8341I End-of-volume reached
> for 3590 volume
> M00368.     <== existing volume in BACKUP3590_OFFSITE
> >> 07/23/99   11:55:51      ANR8336I Verifying label of 3590
> volume M00368
> in drive
> >>                           DRIVE02 (/dev/rmt1).
> >> 07/23/99   11:56:17      ANR8468I 3590 volume M00368
> dismounted from
> drive DRIVE02
> >>                           (/dev/rmt1) in library MAGSTAR3494.
> >> 07/23/99   11:59:35      ANR8337I 3590 volume M00655
> mounted in drive
> DRIVE02
> >>                           (/dev/rmt1).
> >> 07/23/99   11:59:37      ANR1340I Scratch volume M00655 is
> now defined in
> storage
> >>                           pool BACKUP3590_OFFSITE.
> <== new volume in BACKUP3590_OFFSITE
> >>
> >> Richard
> >
> >--
>