An interesting problem that exists at some sites is that there are
physical devices or similar resources which need to be scheduled.
Consider magtapes, for example. VMS has no logic to, say, referee
tape access so that the guy who needs 4 tape drives for his job
can allocate them sometime, while the guys who have jobs that
need one or two can also be in the jobstream somehow, so that
fairness can be achieved. Now, device ACLs could be used to prevent
random tape allocation so a scheduler process that did $grantid
would control who could use the drives at any one time (and sending
this process messages would be the analogue of allocating the drives)
but I don't know of anyone's process that tries to do such allocation.
There are examples of such computations in things like classroom
scheduling programs and the like, but I've never seen them used
for system resource management. Seems like a good thing to have in
some shops at least. It is particularly important for devices like tape
or diskette drives, and to a degree for CD drives; I've seen cases
where it can be important for printers just due to time needed to
print some complex files. (This was using Sun servers; their printers
are abysmally slow where they're printing complex graphics via
serial connected Postscript printers....)

	It would be useful to allow virtual disks to fail over
in clusters. To enable this, in principle one can turn a local
virtual disk into a "DSA" disk by MSCP serving it. Now, if we
do this with 2 virtual disks, pointing at the same storage,
and MSCP serving both, we get what appears to be TWO units to
the cluster. However, if we fill in some extra fields and get the
MSCP server to use the same ID for both units and make it forget
that one is local, we ought to be able to make one of the units look
like a second path to a disk. This would mean starting up one
disk and MSCP server, then getting the MSCP ID on a remote
system and arranging to fire up the MSCP server on a second
system making the MSCP server believe it was seeing a second
request for a remote MSCP disk and that this was just a dual
path. Somehow the MSCP server would have to believe that the
local driver was a second path to the same DSA disk. When
the original MSCP server failed, then, it would be necessary
for the MSCP server on the second site to come up with the SAME
device ID as the old one. If it came up with the same MSCP ID
quickly enough, and the secondary path were marked in all 
client processors already, it might be possible to get this
sort of disk to fail over also, in effect, by having the new
MSCP server handle the disks. If the same underlying storage were
used (e.g. in a striping or shadowing driver like my VWdriver or
VQdriver respectively, where the underlying storage might live
on an HSC to which there was still a path), this could make
much sense. DEC does something akin in results by having its
drivers talk MSCP directly, so it routes SCS packets around
with them, and SCS handles the reconfiguration. The idea here
is that my drivers don't have the info to talk SCS but look
like local disks. One uses the MSCP server to make a local disk
look like a cluster object, so once it serves a disk, access
goes via the server except on the local node. A remote node sees
the structures created by the MSCP server as the disk's identifier
and gets to it that way. If one changes those structures to have
whatever identifier is desired it ought to be possible to arrange
to have a hot backup sitting around LOOKING like a second path
on the processor running the 2nd copy of the virtual driver
(but not actually doing anything, nor getting any requests).
   With FDdriver and variants, a lock could be passed around to
determine the real master; with VQdriver/VWdriver/VDDriver,
a daemon or something like it would be needed. Ditto VRdriver,
but VRdriver's extensive FDT time operations mean that its'
activity will have to be remote handled differently somehow.
The MSCP server remotes I/O using start-io entry and more or
less assumes everyone has the same FDT routines. For VRdriver
to be served, a "remote" version that had the FDT logic would
be needed, so it could patch over the FDT table and put
the code in for other nodes. This kind of thing will be needed
for use of the code on "regular" cluster disks anyway.
   Probably a dualpath fakeout would need something to be run on
each cluster node.