Hi Eric!

There is no reason whatsoever not to move data i_n_t_o FROMSTGPOOL (which is 
YourTAPEPOOL).

For efficiency reasons, 
depending on your HW configuration and usage of your tape drives, 
following configuration may, (conditional!) , be of advantage:

- define device class RECLAIM as SEQuential, FILE
 with parameters ESTCAP and MOUNT set so that the resultion size of 
 (ESTCAP times MOUNTL)  is at least 10%, better 30%-100% the size of single 
tape.

- define disk storage pool e.g. DISKMGR2TAPE based on RECLAIM.

- for DISKMGR2TAPE 
  set "next storage pool" to YourTAPEPOOL.
  set LOWmig to zero and HIGHmig to some low value.

- use MOVE DATA or MOVE NODEDATA
        FROMSTG=YourTAPEPOOL TOSTG=DISKMGR2TAPE 

>>>>> This will save you both mount points in tape library and tape mount 
>>>>> requestst. *
On the negative side, this will cost you some temporary disk space, disk access 
time, disk bus usage.

btw, you can use the very same DISKMGR2TAPE pool for reclamation purposes of 
YourTAPEPOOL,
simply by setting:
 UPDate STG YourTAPEPOOL RECLAIMSTGpool=DISKMGR2TAPE 
with the very same effect (*)

hope it helps
regards
Juraj




> -----Ursprüngliche Nachricht-----
> Von: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] Im 
> Auftrag von Jones, Eric J
> Gesendet: Dienstag, 15. November 2005 02:05
> An: ADSM-L AT VM.MARIST DOT EDU
> Betreff: Re: Backup question - Full and Incremental
> 
> Thanks for the answers on the full/incremental backups.
> I did some research on the move node but it looks like you 
> move from one pool to different pool(could be very confused). 
>  I would like to move within the same pool but combine all 
> the backups from a node(20+ tapes)
> to 1 or 2 tapes within the same pool to help with restores.   Some of
> the machines have been backed up for years and the data is 
> spread across so many tapes.  Can the pools be the same 
> (FROMSTGPOOL and TOSTGPOOL)?
> Never used this command before and a little nervous.
> 
> Thanks for all the help,
> Eric
> 
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] 
> On Behalf Of John Black
> Sent: Monday, November 14, 2005 4:28 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] Backup question - Full and Incremental
> 
> Eric,
>  To organize your data, the following command should do the 
> trick: *move nodedata; *when you have a chance, please 
> research. Additionally, yes, full
> (selective) backups are seems as files. And as such, the 
> normal copy group retention periods apply. I hope this 
> information was beneficial  --MG
> 
> 
>  On 11/14/05, Jones, Eric J <eric.j.jones AT lmco DOT com> wrote:
> >
> > Good Afternoon.
> >
> > I have a question on backups and how if you mix full backups and 
> > incremental backups the data is stored.
> >
> > We are running TSM 5.2.2 on all our TSM clients(AIX, SUN, Windows
> 2000,
> > windows 2003), and the server is AIX 5.2 with TSM 5.2.2.
> >
> > We normally just run incremental for all our machines and over the
> years
> > the data gets scattered every where(number of tapes and in 
> some cases
> > 30+) so restores can be very slow. We keep all our data for 
> 90 days so
> > with the incremental backups the files expire after 90 days if the
> file
> > has been backed up(90 day policy/keep up to 90 backups). My question
> is
> > if I want to do a full backup every 120 days just to better organize
> my
> > data on less tapes(current data) does it effect the 
> incremental data 
> > that is on tape in any way? Does TSM see the backups 
> including a full 
> > backup as files and they expire after a given amount of time?
> >
> > From what I could find that is the case but I do not want 
> to mess up 
> > years of data and the users were asking lots of questions on how it 
> > might affect them. They would be happy with the possibility 
> of faster 
> > restores.
> >
> > Another question came up, is there any way to have TSM 
> organize data 
> > already on tape for a specific server so it's on a few tapes instead
> of
> > spread across many tapes? Just seeing if we could better manage our 
> > data.
> >
> >
> > Thanks
> >
> > Eric Jones
> >
>