I never used, but I think that might work for you...

If you use the command UPDATE LIBV, then you can change the owner of the
volumes...

>>-UPDate LIBVolume--library_name--volume_name------------------>

>--+------------------------+--+-----------------------+-------><
   '-STATus--=--+-PRIvate-+-'  '-OWNer--=--server_name-'
                '-SCRatch-'


OWNer
     Specifies which server owns a private volume in a shared library that
     is shared across a SAN. You can change the owner of a private volume in
     a shared library (SAN) when you issue the command from the library
     manager server. If you do not specify this parameter, the library
     manager server owns the private volume.
     Note:
          OWNER is invalid for all scratch volumes, but is valid when
          changing a scratch volume to private.


On Fri, Nov 21, 2008 at 8:00 AM, Henrik Ahlgren <pablo AT elma DOT net> wrote:

> thanks for comments so far.
>
> Yeah, but wouldn't that lead to an empty node in the target server? Of
> course I want to migrate the data, I just don't like the idea of
> copying ten tapes worth of data to a set of temporary tapes and then
> again to new storage pool tapes (I have not tried it yet, but I assume
> TSM doesn't just use the export tapes as stgpool tapes, right?), if I had
> the
> possibility to just move the DB entries and keep the data in the tapes
> it was in the first place. I mean, with reusedelay and all, I would
> have the same data in 30 tapes instead of 10 for some time (not counting
> copypools volumes). Multiply that for couple of nodes, and soon you
> run out of library space. Well, at least it would have the side effect
> of reclamation.
>
> I guess the next best thing to do would be to use FILEs on disk.
>
> Imoprting the whole DB to a new server is also a nice hack, but I
> would like to start from scratch, since I'm planning an upgrade from
> prettyy ancient TSM version with DB that have lived for about eight
> years.
>
> BTW, I haven't heard or noticed before that TSM might not adhere
> collocation in case of running out of scratch volumes. Is that
> behavior version dependend? I believe everyone runs out of scratch
> volumes every now and then...
>
> On Fri, Nov 21, 2008 at 06:51:23AM -0200, Leandro Mazur wrote:
> > I think you can use the command export node with the parameter
> > filedata=none. Example:
> >
> > export node test filed=none tos=server1
> >
> > Please, correct me if I'm wrong.
> >
> > On Thu, Nov 20, 2008 at 9:13 PM, Wanda Prather <wprather AT jasi DOT com>
> wrote:
> >
> > > You can't copy just some DB entries.
> > > Other people have reported success with restoring the TSM DB to the new
> > > server, then deleting the unwanted filespaces/nodes on the new server.
> > >
> > > But you need to review your tape inventory carefully.  The fact that
> your
> > > storage pool is collocated doesn't mean that tapes necessarily have
> data
> > > for
> > > only one client.  If there was ever a day where you ran short of
> scratch
> > > tapes, TSM would have started stacking multiple clients per tape.
> > >
> > >  I'd recommend checking each tape before moving it would be a good
> plan.
> > >  If
> > > there are multiple nodes on a tape, you can use MOVE DATA to force the
> data
> > > to other volumes in the storage pool; if scratch tapes are available,
> > > collocation will be honored on output.  I think that would be less
> trouble
> > > than cleaning up the mess after a move.
>
> --
> Terveisin
>
> Henrik Ahlgren
> Technical Manager
> Itella Information Oy
>
> Tietäjäntie 2
> FI-02130 Espoo
> GSM +358-50-3866200
>



-- 
__________________________________
Leandro Mazur