From: NORLMN::EVERHART 22-MAY-1996 14:34:57.01 To: STAR::COUGHLAN,STAR::ST_LAURENT CC: EVERHART Subj: mscp <-> dk failover When dudriver gets a message from a MSCP server and detects that there is a device being served, it sets up a UCB and a path to the MSCP server with it. However, one of the last steps it does is to check the local database to see if the same device exists. If it finds such a 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 found into the altucb field of the MSCP driver's UCB. It also marks the MSCP ucb offline (clears online) and clears the AVL bit in devchar2 so that the device does not appear available. This prevents assignment of channels and so forth and effectively hides this extra UCB. No special MSCP operations are carried out however...that's all it does, far as I can see. The two UCBs are placed in each other's ucb$l_2p_altucb fields and BOTH dev$m_2P bits are set, but the dev$m_cdp bit is set only in the MSCP UCB which is being disabled. ucb$l_2p_ddb entries are also filled in with each other's ucb$l_ddb entries. (The lookup code is in lookup_local_ucb in dutusubs.mar, by the way.) The VMS internal device search routine (used by practically everyone) checks the CDP bit and replaces the UCB with the altucb field in the ioc$testdev routine. Thus anything coming along will use the local path. If the MSCP path is set up before a local dkdriver path is known, of course, this processing can't occur, and the MSCP path will come up fully functional. It is to be expected the local dkdriver path is also fully functional, since it has no clue this is going on. (Incidentally, the system $assign service calls the common search routine.) Therefore the device that winds up getting used will be the one that is found first in ioc$search. This is likely to happen to be the MSCP path, since it was set up first. Clearly the guarantee that nothing will use both paths is somewhat a matter of luck in this case though. If in the general case someone has already started using the MSCP 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 that data at the device will always be sensible in such a case...the delays will in general differ. 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 leaves the direct path in place. This would mean the device would have to be unmounted, and unreferenced by any channels, and probably should mean an operation count of zero. At any event, the switching driver code I have could also be used to 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 I/O would wind up at the local path but being able to switch over whenever either side went into mount verify. It would have to use a different technique to ensure it found any such MSCP paths (again, not all that difficult...just do what ioc$search does except for the cdp bit processing) and it should (as it does) inhibit use of the alternate path. Such a thing would not however be effective until started, sometime after initial boot, and might require some additional operation for later-attached devices. Experimenting shows that show device is not wholly fixed by this 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.