avoiding ghost disk devices across cluster

[Jess Goodman]

Large VMS 7.3-2 cluster. Most systems have their own locally-attached system disk so I have MSCP_SERVE_ALL set so I can access them across the cluster (you can't use SET DEVICE/SERVED with system disks).

In this environment how can I prevent a temporary disk device on one system from being seen by the rest of the cluster?

I know I can stop the CONFIGURE process while I'm using the device, but when I restart CONFIGURE after the device is no longer online it still shows up thru out the rest of cluster.

I have tried SET DEVICE /NOAVAILABLE before restarting CONFIGURE, but that doesn't help. For some reason VMS has never supported SET DEVICE /NOSERVED. There isn't any way I know to "delete" an unused device from the VMS device tables.

Why I want this: We have an EVA SAN and I use snapclones for online backups. On occasion I need to temporarily present a set of snapclones to one VMS node (not cluster wide). I like to present them using device names that logically follow (i.e. if source volume is DGA101 then first backup will be presented as DGA201, next backup DGA301). But this means that if over the course of a few months without a reboot I might have created dozens of DGA units that are no longer online. It's ok that they still show up on that one node, but I really don't want dozens of ghost devices to show up on every node of the cluster.

Or can anyone tell me is there is any downside to not running CONFIGURE at all after boot completes? I noticed that even though CONFIGURE isn't running on node A that if node B reboots it still sees node A's system disk.

[Steven Schweda]

I have MSCP_SERVE_ALL = 4 ("serve the system
disk"), and then I have an explicit "SET
DEVICE /SERVED device" command in the
procedure where the other (normal) disks get
mounted. Thus, all the normal disks get
served, but exotic ones do not.

I did this to avoid having a CD-R/RW drive
get served, as I usually leave it powered
off, and endless errors get logged if a
served disk goes away.

I also have a SYS$MANAGER:SYCONFIG.COM, so
that I could configure an old Yamaha CD-R/RW
drive manually, to keep it from appearing
(spuriously) at multiple LUNs. Since the
last round of hardware upgrades, I see now
that this is probably no longer needed, but
while looking around for the info relevant to
this reply, I was reminded that when I first
activated SYS$MANAGER:SYCONFIG.COM, my
CONFIGURE process vanished, due to quirks in
SYS$STARTUP:VMS$DEVICE_STARTUP.COM. Before I
figured out (that is, "was told") what the
problem was, I got severely confused by disks
not being served as expected, dependent on
the boot order of the systems in the cluster.
So, I'd advise against whacking the CONFIGURE
process, unless you're sufficiently smarter
than I was.

[Ian Miller.]

I wonder if MSCP_SERVE_ALL = 9 would do what you want?

from the cluster manual
"All disks except those with allocation classes that differ from the system's allocation class (set by the ALLOCLASS parameter) are served."