Well I have looked at everyones responses.  And I would like to thank
everyone who has responded.  I know it takes time and effert to do so.
        Fundimentally I don't think I can use collocation by Filespace.
I would be using 6x as many tapes for the task if I put the COPYPOOL
tapes like that.  It would also cost me at least 50% more for the local
tapepool.  But I think it was a popular suggestion because I did not
include enough detail in this e-mail.  I did so on the first e-mail and
then made a bad assumption... .  Anyway the Large system I need to
restore is an ORACLE DB that we do FULL BACKUP (cold) once a week and
then save the logs during the week.  I do not believe that this is the
best way to do things but spending $$ seems to be a no no.  Anyway I
need the RESTORE to work for a full system, (like DR), to provide
recovery for a local or DR site RESTORE or to populate a test system.
The part that makes this different is that there are no daily
incremental updates on any of these Filesystems.  
        My solution:
        1) I do a     select node_name, volume_name, Filespace_name from
volume usage where node_name='MYNODE' and filespace_name like '/U0%' and
stgpool_name='TAPEPOOL'    this lists all tape volumes that have any of
the filespaces I need
        2) I use SAS to make a smaller file that contains the list of
UNIQUE tape volumes.  The program then creates the TSM commands to do
step 3.
        3)  select volume_name, last_write_date from volumes where
volume_name='thevolser'
        4)  here I do some sorting to merge all the data together,
through away all but the most recent tape used for every filespace and
then sort them again to have a list of tape volumes and every filespace
on them to do individual restores, knowing which file spaces to ask for
so all are listed on 1 tape.  (ps: the STK tape silo  tape system
allocates scratch tapes in a ascending volser order.  So a Filsystem on
2 tapes 'should' start on the tape with a numerically smaller volser
number)

I still think Tivoli/IBM should be able to do this internally.  This is
no more than a standard RESTORE NO QUERY that would ALLOW FOR A
WILDCARDED FILESPACE.

Thanks everyone.
Matt

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Andy Carlson
Sent: Wednesday, June 23, 2004 2:30 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: anyone have script for multi-session/multi-filespace
restore?

If you have enough scratch tapes, you could consider colocation by
filespace, then divide the filespaces roughly by size into 8 groups (or
however many tape drives you want to assign) and start 8 restores.  They
would be guaranteed to be on separate tapes becuase of the collocation.

On Wed, 23 Jun 2004, MC Matt Cooper (2838) wrote:

> Hello all,
>        I received no responses from my previous post    'Need your
> thoughts on best RESTORE approach'.  So with just my own research I 
> have found that TSM does NOT have anything to manage a 
> multi-filespace, multi-session restore that is not relying on the user

> to prevent 2 sessions asking for the same tape.  (please tell me I am
wrong)
>      ( reference the section in the (AIX) client book on LARGE 
> RESTORES, NO QUERY,  it is set up for a single filespace (NO 
> WILDCARDS) In my case I will have 60+ filesspaces on 6+ tapes with 8 
> tape drives available and have to start from the command line 
> (actually scripted) to start a session for each tape drive.  The real 
> problem is preventing more than 1 session from asking for the same 
> tape.  I believe I can find the necessary information to write the 
> script from quering the volumeusage  and volume tables and doing the
restore comands from there.
> I would guess I am not the first one to approach this problem and hate

> to spend my time trying to script this when someone else, (who is most

> likely much better at scripting than me) has already done it.
>
> Does anyone have a script that will arrange/control the submission of 
> multiple restore sessions to avoid having sessions having to wait for 
> other sessions to finish using a tape?
>
>
> Thanks in advance
> Matt
>
>