At 07:56 AM 6/10/2004, you wrote:
>I already performed the move data from the primary pool to another primary
>pool. I guess TSM cant figure out that the primary copies are in a
>different primary storage pool than where they were origianlly backed up
>from.
>
>A   "DELETE FILES node filespace STG=stgpool"  sure would be nice....or a
>"DELETE NODEDATA STG=stgpool".....   (sigh)

No!  It would not be nice - unless you like shooting yourself in the foot.
Anything that lets you alter a backup destroys the integrity of the backup.
Think of your auditors - if they understood how good tsm is, this command
would destroy all their confidence.

If you have gone to the trouble of collocating the primary pool with move 
nodedata
commands, you can collocate the offsite pool by defining a new copypool and 
backing up to
it.  After the new pool is all offsite, delete the volumes in the old copypool 
with 'discarddata=yes'.

I really hope this helps,

Bill Colwell




>Dave Nicholson
>Whirlpool Corporation
>
>
>
>
>
>"Stapleton, Mark" <mark.stapleton AT BERBEE DOT COM>
>Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>06/09/2004 10:44 PM
>Please respond to "ADSM: Dist Stor Manager"
>
>
>        To:     ADSM-L AT VM.MARIST DOT EDU
>        cc:
>        Subject:        Re: Hey Big Blue....Why not MOVE DATA across copy 
> pools?!?
>
>
>From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On
>Behalf Of David Nicholson
>>        I tried a MOVE DATA for offsite data...it did not go after the
>>data in the primary pool...it wanted to mount the volume in the copy
>>pool...which was offsite.
>>        Am I missing something?
>
>Something is wrong. MOVE DATA will only call for offsite volumes if the
>required files are not available in the primary pool. Do you have
>volumes in unavailable status?
>
>--
>Mark Stapleton

----------
Bill Colwell
C. S. Draper Lab
Cambridge Ma.