Article 159552 of comp.os.vms:

I put a virtual disk driver that journals writes to the disk onto the
V3 freeware CD, and it'll be on F96 sig tapes. This could be possibly a
useful thing for some folks...

Since the journalling is done from a user mode process, it'd be
pretty straightforward to make it a "remote shadowing" type disk
by treating the journal as a large circular buffer and writing it
to a remote copy of the data via a second process. that way, as long
as the average network speed were adequate, your remote shadow would
be current. (Catch-up would be done if a crash occurred from the local
circular disk buffer, so the thing would be pretty well risk-free.

The local disk access is done like vddriver, i.e., to contiguous file
or disk area, so that is fairly fast. (A faster general version may
be on the F96 sigtapes...probably will in fact.)

The idea for this is due to Larry Robertson of Bear Computer, who
implemented it. BEAR can be reached at
 bearcom@bearcomp.com

(818)341-0403 (Voice)
(818)341-1831 (FAX)

A few months after the product appeared, another outfit produced
a clone, by processes unknown. I have refrained in the past because
I think Larry deserves the benefit of his idea, and of his
implementation (still IMO the highest quality one around; Larry is a
VERY good systems guy...and does not take others' work). Still,
if you have interest in disk mirroring in software, this possibility
is one you might want to think about.

By the way, a generic WARNING. 

Any product that does virtual disk, mirroring, etc. by trying to steal
underlying start-io entries WILL corrupt SCSI disks handled by DKdriver
if the load gets heavy enough or anything causes the dkdriver underlying
code to have to declare itself busy. This cannot readily be worked around
in the current code base. (I'm fixing that but the fix isn't ready yet).

The problem is that dkdriver pulls IRPs off its queue without going thru
the standard entries, and you can't catch IRPs before they get onto
the queue reliably with current VMS (except by some really error prone
hot patching techniques in the bowels of VMS that are likely to break
with mods to the system!). 

Packages that leave pre-existing device names alone and have you continue
to use them as the devices, where you can start them with the devices
already in existence & use, are likely to be implemented like this. With
older drivers, or under non-extreme load, the problem might not show up,
but beware. If a vendor has something like this, DON'T BUY IT UNTIL THEY

EXPLAIN WHY THIS IS NOT A PROBLEM WITH THEIR IMPLEMENTATION. The
problem can be solved, but they need to be able to understand it and
give a response. (There is one way that is even likely to be somewhat
robust, but could hit i/o performance all over the system if extreme
caution in its use is not followed, or in a worse case cause crashes.)

Where the package gives a new device name (as e.g., vddriver does, or
the DEC shdriver does) this is not an issue.

Those needing further info may write me.
Glenn Everhart
Everhart@row.enet.dec.com