ARGGHH I found it.  

Its there even in 5.5

If you run 
Update stg primarypool 
And use the following option:
COPYSTGpools=copypool,copypool2,etc.

You'll get the Simultaneous writes.
Of course you'll want to set:
COPYContinue=yes
Or else your whole backup will stop on any error.

See Ya'
Howard


> -----Original Message-----
> From: Howard Coles
> Sent: Wednesday, October 01, 2008 2:46 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: RE: [ADSM-L] NBU user considering switch to TSM
> 
> See below.
> 
> See Ya'
> Howard
> 
> 
> > -----Original Message-----
> > From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On
Behalf
> > Of Paul Zarnowski
> > Sent: Wednesday, October 01, 2008 1:55 PM
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Subject: Re: [ADSM-L] NBU user considering switch to TSM
> >
> > See my responses below..
> >
> > At 02:04 PM 10/1/2008, Howard Coles wrote:
> > >See in line answers below
> > >
> > >See Ya'
> > >Howard
> > >
> > >
> > > > -----Original Message-----
> > > > From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On
> > Behalf
> > > > Of steve sorenson
> > > > Sent: Tuesday, September 30, 2008 11:44 PM
> > > > To: ADSM-L AT VM.MARIST DOT EDU
> > > > Subject: Re: [ADSM-L] NBU user considering switch to TSM
> > > >
> > > > Thanks so much for all the responses.  I'd like to reply to just
> a
> > few
> > > > responses for clarification.
> > >
> > >You're welcome.
> > >
> > > > Regarding simultaneous copies, Howard Coles said:
> > > > I'm not talking about migration and backups happening at the
same
> > time,
> > > > or even multiple migrations happening at the same time.
> > > >
> > > > First, let me verify what I was told TSM _could_ do.  I was told
> > that
> > > during
> > > > the initial backup (if you went straight to tape, such as with a
> > large
> > > > dataset), TSM could write to two tape drives simultaneously,
> making
> > two
> > > > copies in the time it takes to make one.  Is that part true?
> > >
> > >Yes.
> >
> > No, I do not think this is possible.  Howard, the Copy Group
> > DESTination
> > can only specify one storage pool.  Thus, it is not possible to send
> > incoming data simultaneously to two different tape drives.  This is
> by
> > design, and is not an oversight.  The normal way of doing things is
> to
> > receive the data on disk first, and then you can simultaneously
> migrate
> > the
> > data from disk to tape, and copy it to a copy storage pool.  Perhaps
> > Howard
> > missed your premise that you want to go straight to tape.
> 
> Sorry, but if you check your primary tape pools' properties you'll
find
> you are incorrect (unless the option doesn't even show up in a
straight
> up 5.5 environment).  This option is set at the Storage Pool level,
not
> the Policy Domain.
> 
> In a primary tape pool's definition you find the "Simultaneous Write"
> tab.  The description in that tab says:
> Simultaneous Write
> During client node or import operations, data can be written to the
> primary storage pool and any combination of copy storage pools and
> active-data pools. To protect inactive data, specify at least one copy
> storage pool.
> 
> However, it does appear that this feature isn't present in 5.5, or I'm
> overlooking it badly.  It was up until 5.4, which is why I see the
> option I suppose (I also have a 5.3.5 server).  And it does work for
> copying into active data pools even in 5.5, or so it appears.  Hmmm. .
> . gotta dig into this.  I never used it before, except in one occasion
> where the client's users were very paranoid.  :-D
> 
> Note:  I'm using TSM 5.5.1 & 5.3.5 & 5.2.8 (older hp-ux box about to
be
> replaced)
> 
> > > > Howard Coles said:
> > > > >You use the TSM GUI and/or command line to
> > > > >do all the restores whether it be a backup set, or a backup
from
> > the
> > > > >TSM server.
> > > >
> > > > But the contents of the backup set aren't in the TSM database,
> > right?
> > > > Isn't that the point of the backup set, to make an archive of a
> > bunch of
> > > > files that aren't tracked in the database, and that can be read
> > outside of
> > > > TSM?  So if the contents of the backup set aren't in the
> database,
> > how
> > > could
> > > > you do restores the same way as you do with regular backups?
> > >
> > >Well, partially.  The purpose of a backup set is to make a client's
> > >backups portable.  You are correct in that the contents of the
> Backup
> > >Set are not in the database (because they were intended to be
> removed
> > >from TSM and handed off to a client).  However, you will need the
> TSM
> > >client, preferably the version that did the backup or newer, to
> import
> > >the backup set at the client, and hardware to read the tape/media
> used
> > >to create the backup set.
> >
> > This is not the only reason to use backup sets.  You do not need
> > hardware
> > on the client to read the media, unless the point of the backupset
is
> > to
> > have portable media.  You can reference the backupset directly from
> the
> > server.  Some folks use backupsets to take snapshots of their
current
> > backups, without having to re-send the data from the client again.
> >
> 
> Sorry, I was thinking of the original purpose.  Yes, you can leave the
> backup set in the library and mount it up for the client at the server
> side.