I'm somewhat inclined to change my mind on this.
Code in dkdriver or dutusubs has both UCBs and has a preference as to 
which should be primary. The scheme I suggested is fine for those
drivers. DUdriver (well, dutusubs) checks if a local path exists when
creating a served path. DKdriver checks for a served path creating a
local one.

If however I put the call here into load driver, having load driver look
for a device of the same name, then the first unit loaded would get
to be primary, regardless. But in dkdriver or dutusubs, I could
call the routine to switch to the correct preferred path (which
would be known as before) if the driver were idle. That can be done
OK from high IPL and would replicate the behavior. It also would mean
that any duplicate paths would get condensed together, detected by
name being the same. As long as load driver gets the same name the
paths get collected. Doesn't matter what the driver is, and is
concerned with what the rest of VMS cares about.

The first UCB would indeed need no special action; only when a second
one is found would one bother with this. Or the third, fourth, etc.

The other consideration with putting calls into load driver directly
is whether mscp calls loaddriver to create new UCBs which get torn
down. Seems to me it does, and I don't want to do this linking until
the UCB is going to stick around if that can be arranged. Also later
on we may want to rename a driver after driver load.

That means that do operate most cleanly and not create SWdriver units
until a second path really exists, I want to wait till AFTER driver
load hooks up a disk, then search for a like named disk & call
setup_switch if one is found. 

I'm gonna go stare at some code to check all this tho...want to see
how mscp calls driver load.
glenn