To:     TAPE::SENEKER
Subj:   RE: RE-2: WORM support in OVMS via OSMS
Enter your message below. Press CTRL/Z when complete, or CTRL/C to quit:
I'm around pretty much in my office. Don't leave voicemail...I use
email a lot, phone seldom and voicemail is lousy for me.

dtn 381 1497

I wonder...if the old worm-11 acp got made available as is, if it might
not be better to try a few hacks to use standard filesystems, using the
read/write logical trick I mentioned and some tests that can be inserted
ahead of the acp/xqp calls, and behind them, so that the customer gets
approximately a normal looking disk, but open for write might disallow
overwrite (filter write virtual), delete would be turned into rename and
faked (easy to do at io$_delete...my undelete product does it now!),
and some normal disk space (for indexf and dirs) would get taken up
till the user was done with the disk. It'd require a "freeze" operation
when the disk filled (writing the cached stuff back in place to the worm,
where those blocks would not in fact have been touched till then), or
possibly once in a while for cases where the disks could revector blocks
and had lots of them around. You'd of course need to fake dse out (trivial)
and the index info would hang around. The great benefit would be that if
you had a jukebox, the scheme automatically means that directories and
most of the preliminaries of file access would come from a mounted cache
disk, not needing robot motion till the actual data had to be grabbed.

The $64000 question is whether customers would be happy with this. I should
think they'd be bloody ecstatic, so long as their read access to old
WORMs was maintained. Maybe we need to talk to someone in management
about all this stuff though. (There are of course some ownership issues
with my cache design too; while I've disclosed some of my trade secrets
in it, I've not told all, and some of the tricks described live in code
that is being evaluated commercially. An undelete could be quite profitable...
I hope...)

glenn