We present a UCB that looks exactly like a local UCB, except there's
a bit that indicates the device is remote and QIOserved.  On the
server side, there's another bit that indicates the device is servable.
We will have the ability to control what gets exported and to whom.
How it integrates with the switcher code is an open question, but if
your usermode process gets integrated with my usermode process, it may
be moot.

John

-------------------------------------------------------------------------------
There aren't really any dk hooks I'm doing for mount verify; I just
get a look at i/o status coming back looking for SS$_MEDOFL. Your
server should have no problems with that. MY guess is you will need to do
practically nothing, just so the switcher code can see packack coming
from MV, even if it gets junked early in your code. So long as
kclient presents a UCB that looks like a disk and gets a normal looking
interface, the switcher will be ok. I presume you'll have some way I can
use to tell that I'm seeing KCLIENT and not a local attached disk
for purposes of determining whether a local connection to a disk
exists...but that's about all I presume.

Sorry about the message...I doubt much that you'll need to be concerned
with this kind of issue, just remoting things as you are.

There really needs to be some way that your server will know it should
export a device access too, so that it can be turned off/on. I'll need
to do that, basically allowing serving of disks where a local path
exists (even if the path the rest of VMS sees is a served path
locally, which fact I hope to disguise) and not allowing serving if
there is no local path (even if the name used everywhere is in fact
one that would otherwise "look" local).
glenn