Why are you putting a 28GB database backup to a VTS? This is not a good use
of the VTS. I can see the length of the backup just knowing how the VTS
works internally. Your data is going to a 'cache' area in the VTS which is
DISK. When you hit the end-of-voloume on a 3490 tape (logically as there is
no real tape), the VTS assigns more are of the cache for the volume. If
there isn't room and the cache is full, then through a LRU algorithm old
data is purged off the cache. If that data hasn't been staged to 'real' 3590
tape volumes, you wait for that to happen. Depending on how large this cache
disk area in in your VTS, you're probably filling a large portion of that
just with your DB backup. Plus the data you send into the VTS needs to be
staged to real 3590 volumes.

The VTS is good for smaller amounts of data, just a couple volumes worth of
3490 size that is mostly written once and then read. Appending to a virtual
tape volume is not very effecient as the data needs to be re-staged back to
cache (if it's not there already), data appended and then staged back to
real tape, but in a different place. The original location of the data on
the real 3590 is now invalid. You can see that you have both a performance
hit while your data is staged back to cache, plus if you do a lot of
appending, you're fragmenting the real 3590 volumes.

The internal operation of the VTS is actually a form of TSM to handle the
data migration from cache to tape, recalls and reclamation of the tape
volumes when a threshold is reached.

TSM, HSM and applications that like to completely fill a tape volume are not
good candidates for a VTS.

There's also the offsite vaulting out of a VTS to deal with...

Bill Boyer
DSS, Inc.