John -
As we discussed, I'm putting code into SWdriver to allow it to act as a
template device so there'll be no problems with getting UCBs connected;
a simple $assign call will do that. I've also put in calls which will

* Tell whether a device is already intercepted and if so, return lots
	of information about what it's intercepting, what all the alternate
	paths are, which path is in use, whether it's busy, etc. (though
	the vital stuff is where the paths are.)
* Return statistics etc. about all paths
* Connect a new device to the set of paths
* Disconnect a device from the set of paths
* Inform the switching driver about the server process


I have also got some code in the switching driver that will attempt to
allow or disallow MSCP serving of its path, depending on whether it
is or is not connected to a directly connected path (as opposed to a
served one). However, you and Dave were talking about making some change,
defining a status bit or two perhaps, to control this. I'd prefer to
use the scheme you're using for this if it is defined. Got anything
further yet?

I'm building some test code to let me get the stuff debugged, but the
master setup routine I'm building will call these services and hopefully
will just slide into other code. I'm trying to avoid having to tell
anything about kernel switching structures except the switch driver
itself, apart from those routines that need to get info out of the
various UCBs directly for whatever reasons. They should be few.


The calling environment will however need to do the monkeying with
the system UCB lists; doesn't make sense to me to put that into
the switch driver itself.

BTW I'm keeping a copy of swdriver.c in scsi$work:[everhart] on evms::
if you want to look at it for any reason.
Glenn Everhart
3 April 1997