Debbie et al,

I am sorry to hear that you had negative experiences with our ADSM
implementation. There are a number of variables that need to be in place for
it all to work. Did you call upon our support people to help you resolve the
issue?

The way our implementation works is to use the API client to port data from
BE (Backup Exec) to ADSM. BE sees the entire ADSM system as one virtual
Autoloader. The data stream is forked into user data and control data before
sending it to ADSM.  We always advise customers to keep the control data
(PI data) on a disk based pool. This way access, positioning etc of the
'virtual tape' is fast and there are no timing issues with BE. The user data
(VT data) can be written either directly to tape or overspill to tape from a
disk pool. (Personally I prefer the overspill config. since ADSM does not
need to mount a tape -locate, get, mount, position- and thus will eat all
data at that time like candy).

We did encounter unpredictable events/behaviour when PI data was written to
tape. This is the position data that would normally live at the beginning of
a tape (cat, header, mounts etc). Similarly one would also get unpredictable
behaviour if the header data was in any way shape or form incorrect on a
normal tape.


I hope this explains our implementation a bit.


Regards,

Freddy Sjauw-En-Wa, B.Sc., B.Eng.
-Homo Bonae Voluntatis-
VERITAS  support
VERITAS  support