I've already seen one reply to check the NIC settings - those will get you
every time.  An easy check that can really pay off.

Another thing to check is to see if the client is CPU or I/O bound.  If
your CPU utilization is at 100% (or near it), client side compression can
slow you down.  If the DASD is I/O bound, you'll need to address that area
to improve performance.

To answer the questions:

1.  The source storagepool is examined at the beginning of the "backup
stgpool" process, so any data that comes in after the process starts is not
going to be copied.  That is as dangerous as it sounds - you may not have
all the data you need offsite.
1a.  Yes, it will finish, since it doesn't "know" about the data the client
has been sending.
2.  Sort of the same as question 1 above, but the database backup will pick
up changes as it goes (after the end of the backup process).  However, if
you have a process running that doesn't complete/commit it's changes, they
may not get backed up.  It's a crapshoot, and can be dangerous, so I'd
recommend you avoid it if you can.
2a.  The backup will have the image as it was when the backup was taken.
If there is data being copied from tape to tape, and the old, now scratch,
tape is reused between the TSM database backup and the restore, the data
can be overwritten.  See "reuse delay" for ways to close this exposure.
3.  Expire Inventory can run parallel to anything else.  With
reclamation/migration, you may expire a file you just spent time
reclaiming, so if you can avoid it, you should, but then there are only 24
hours in the day...
4.  No, you can run migration and reclamation at the same time, and you're
right - you may fight for tapes/drives.  With the message you are getting -
does the tape get mounted?  I think that message just means that TSM wants
the tape - it's just an FYI.
5.  Yes, that is VERY slow.  Your actual performance may vary depending on
a lot of factors, but that is definitely slow.

Nick Cassimatis
nickpc AT us.ibm DOT com

Today is the tomorrow of yesterday.