Nick -
  I saw a brief mention of the ASCI SHADOW product in the storage woods
slides & need to warn you it corrupts disks.

  I've been designing and testing a multipath extension for VMS, which
will cooperate with multipath SCSC controllers, MSCP server, and QIO
server and is implemented as an I/O intercept. In doing so, I have
found that the current (up to and including OVMS 7.1) I/O subsystem
does not have a clean way to intercept beneath an existing driver
for all drivers. (I have a tiny mod which will get checked into Raven
(7.2) later after I test it on multiprocessors and large clusters;works
wonderfully in all tests and looks proper theoretically as well. It will
provide a way, which I and others will use. Hopefully it can be done
in such a way that we can publish an interception standard using the
facilities.)

  SHADOW attempts to operate by stealing some I/O vectors...it would have
to, to do what it claims and has been reported to do. Doing this, one
can ALMOST do shadowing, but under heavy load, error conditions, cluster
transitions, or a number of other situations, the scheme will fail and
cannot (save at fairly high cost to all system I/O, and substantial risk
unless the programmer is VERY good and very cautious, if what I think
could be used as a kludge is even possible; it may in fact not be,
depending on where an entry is called from thru all of VMS) be made
to work. SHADOW in other words will not work and will corrupt disks.
I have a DECUSERVE thread describing this, though they don't realize
how pervasive the problem is. In fact it happens with dkdriver because
dkdriver pulls IRPs off its input queue without going thru any
standard entry (after the first one). VMS 7.1 and earlier have
no way sensibly to trap insertions into a device's queue, and if
dkdriver gets busy enough (or single streams due to a slightly
unusual condition...io$m_datacheck will do...), any IRPs coming in
can get queued and may never see start-io or any other standard
driver entry. A shadow package would miss them, thus getting
one side corrupt. Depending what else it was doing it could
corrupt both disks (and ASCI's customers do report this). I have
a mod, to go into Raven I hope, that calls exe_std$insert_irp
via the driver pending_io entry (which by default points to that
routine). It works fine on my system but it's way late in Gryphon
for anything as far reaching as that to go in since it affects the
basic I/O model. I don't see anywhere that the mod can in fact
cause any problems, and see no problems in tests, but the point is
that the potential impact of an error could echo through the whole
I/O subsystem; you don't do that at SSB time.)

  Products which use a different device name, like those from Bear
Software (where the remote shadowing idea originated; I have
their address if you or anyone else wants it; bearcom@bearcomp.com
will get you email access; phone is (818)341-0403 (Voice).) or like
the Digital shadowing driver do NOT have this problem. Therefore
if you want a commercial remote shadowing system that uses buffering
to have the shadow volume across a net, the Bear product will not
corrupt disks but the ASCI product will.

  I should add that I refrained from writing such a thing because it
was not my idea and I have used Bear's drivers before (while at RCA
technology staff) and found them good. (They added a cryptodisk, in
fact, at my suggestion.) However, I just put a journalling virtual
disk package onto the freeware CD (I wrote it back in 1991, well
before getting here in '95). That package can with some quite trivial
modifications be turned into a remote shadow disk in the same fashion.
I'd be happy to give details if anyone cares to do it and prefers not
to use one or the other of the shadow drivers I've given away since
the late 80s as information. In short, DEC can have a remote shadowing
package free with a fairly minor amount of work, on both architectures.

   There is another matter you need to be aware of, not directly related.
Has to do with some possible ethical issues. An acquaintance from DECUS
used to work at ASCI, and a lawsuit has ensued. In that suit, the head
of ASCI alleged that this guy put some DEC code (specifically TMSCP
server code) into an ASCI product. To check this out after some folks
from DEC legal asked, I used contacts within DECUS to get hold of
one of the 6 or 8 .EXE files from a vax version of the ASCI product
dating from before the guy's employment at ASCI, ran a disassembly
myself with DISM32 (a disassembler from the sigtapes written originally
by Andy Pavlin of GE). I compared the disassembly with the VAX TMSCP
server code of the period off the resd$ here and found many long
stretches of identical code. I didn't bother going over the entire
module...what I found establishes rather clearly that ASCI had stolen
or used the code (I don't know if anyone gage them dispensation to
use it, after all, but it's not the normal policy) before this ex
employee arrived there. (I still have copies of the disassembly
someplace if they turn out to be needed, though I did not want to
do anything but check if Digital's property was embedded.)

  To my mind this means that they are lying at least about the former
employee, and that they may be stealing Digital code and selling it
as their own. I have not checked other code of theirs to see if it
is derivative of other sources' code.) This is in a package that
competes against DEC DFS btw.

  I consider that kind of information to indicate caution is needed
in dealing with the guy. 

  (Note, I didn't seek to get involved with this, but as OVMS SIG librarian
I am somewhat well known in DECUS circles, and do try to help people
when I can. Also I knew of this person somewhat via his software
contributions; he's done some very good and original work in VMS
systems programming.)

Glenn Everhart