2 From:	NORLMN::EVERHART     22-MAY-1996 14:34:57.01# To:	STAR::COUGHLAN,STAR::ST_LAURENT  CC:	EVERHART Subj:	mscp <-> dk failover  F When dudriver gets a message from a MSCP server and detects that thereA is a device being served, it sets up a UCB and a path to the MSCP F server with it. However, one of the last steps it does is to check theC local database to see if the same device exists. If it finds such a B device, it then, at that time, marks the MSCP path with the 2P and@ the CDP flags, and stores the address of the local path it foundA into the altucb field of the MSCP driver's UCB. It also marks the C MSCP ucb offline (clears online) and clears the AVL bit in devchar2 F so that the device does not appear available. This prevents assignmentA of channels and so forth and effectively hides this extra UCB. No E special MSCP operations are carried out however...that's all it does, I far as I can see. The two UCBs are placed in each other's ucb$l_2p_altucb C fields and BOTH dev$m_2P bits are set, but the dev$m_cdp bit is set F only in the MSCP UCB which is being disabled. ucb$l_2p_ddb entries areG also filled in with each other's ucb$l_ddb entries. (The lookup code is 1 in lookup_local_ucb in dutusubs.mar, by the way.)   E The VMS internal device search routine (used by practically everyone) D checks the CDP bit and replaces the UCB with the altucb field in theB ioc$testdev routine. Thus anything coming along will use the local path.   L If the MSCP path is set up before a local dkdriver path is known, of course,A this processing can't occur, and the MSCP path will come up fully @ functional. It is to be expected the local dkdriver path is alsoG fully functional, since it has no clue this is going on. (Incidentally, < the system $assign service calls the common search routine.)  D Therefore the device that winds up getting used will be the one thatE is found first in ioc$search. This is likely to happen to be the MSCP C path, since it was set up first. Clearly the guarantee that nothing E will use both paths is somewhat a matter of luck in this case though.   A If in the general case someone has already started using the MSCP C path, we don't in general want to try to undo it, nor do we want to ? allow the paths to be shared, since we have no way to guarantee D that data at the device will always be sensible in such a case...the delays will in general differ.  D It is conceivable that if neither path is active, we might just have? some dkdriver code that would pull the same trick that the MSCP = server does...the operations described are pretty short...and A leaves the direct path in place. This would mean the device would D have to be unmounted, and unreferenced by any channels, and probably( should mean an operation count of zero.   D At any event, the switching driver code I have could also be used toD do a main force & awkwardness swap when started up by setting online= again for the MSCP path (to allow failover to use it) and by  ? routing everything there as the primary, then switching so that A I/O would wind up at the local path but being able to switch over C whenever either side went into mount verify. It would have to use a F different technique to ensure it found any such MSCP paths (again, not@ all that difficult...just do what ioc$search does except for theA cdp bit processing) and it should (as it does) inhibit use of the A alternate path. Such a thing would not however be effective until < started, sometime after initial boot, and might require some0 additional operation for later-attached devices.  @ Experimenting shows that show device is not wholly fixed by thisA sort of manipulation; setting the CDP and 2P bits and setting the @ ucb$l_2p_altucb to a UCB of a previously found device causes the@ pointed-to device to show up twice. However I was not filling in: both UCBs as dutusubs do and it appears that was required.  