Hi, Glenn,

This requires that the caller have already located the primary UCB.
Presumably, the caller driver will have created a UCB, then noticed that there's 
already one with the same device name.  (I'm trying to remember how DUDRIVER does 
this....)  So, if it's DUDRIVER, it will then check if DUDRIVER owns this (that 
is, is it another DUDRIVER-owned path to the same device) in which case DUDRIVER 
deals with the switching internally.  If not, then the SETUP_SWITCH routine is 
called, specifying the pre-exsisting UCB as primary, and the new one as secondary.

So, the caller has to determine if the existing UCB is a different enough path 
such that switching is required.  We probably discussed this the other day, but I 
don't remember:  is there a straightforward way to determine this, or is it 
specific to the driver or device type?

Another assumption, just to make sure I really understand things:  The switching 
driver is loaded by default, even if it's not needed.  When the first UCB is 
created, it's created in the normal way, with no switch interaction at all.  It's 
only when a second UCB is created that this has to be called.

John
----------------------------------------------------------------------------------
John -

What I'm proposing as the interface for setting up a secondary UCB to a
device is

status = IOC_STD$SETUP_SWITCH(primary-UCB,secondary-UCB)

where the args are just the UCB addresses.

The routine I have will look to see if the primary is connected to SW
and if not will clone a UCB and set it up, and set the primary up as
a path. Then it will add the secondary UCB as a path. If the primary
was already connected the secondary just gets added. Ultimately the
code to unlink the secondary from the device lists can get in there
too, but not during early tests...

The routine expects to be called from fork, holding io database mutex
(dkdriver has it and I believe dutusubs does where this is needed too.)

Sound ok?
glenn