The Question is:
Mixed cluster containing two Alpha 2100's with DSSI connection to an MTI
Stingray. Two Vax nodes connect to the cluster via FDDI. The Alpha nodes MSCP
serve the MTI disks to the Vax nodes. All nodes on 6.2.
The MTI array had some hardware problems that made some disks temporarily
unavailable (offline). Now the MSCP database sems confused.
One (MTI served) device ($1$DIA27) can be mounted directly from either Alpha
node without problem. Any attempt to mount this device from a Vax (MSCP
served) node results in a "device offline" message.
$1$dia27 is "online" from the perspective of the Alpha nodes ("sho dev/full").
However, a "sho dev/served" gives mixed results - one Alpha reports the disk
as "offline", the other reports it as "online".
A "sho dev/full" issued on each Vax shows a path through the Alpha node that
considers the disk (from the mscp perspective "sho dev/served") to be "online".
Nonetheless a mount fails as described above.
Why does one Alpha report the device as "offline" from the mscp perspective
even though the disk shows "online" with a "show dev/full" and mounts
successfully from this node?
Why do the Vax mounts fail with a "device offline" message even though the
device shows "online" to a "sho dev/full" issued on the Vax, and the Vax paths
the device through a node that shows the device online ("sho dev/serv") and
can itself mount the devi
Is there a graceful way to correct the MSCP state (short of a reboot?)
Are there any troubleshooting tips for this kind of problem?
The Answer is :
Please contact your hardware support organization or MTI for assistance
with this storage configuration -- in the experience of the OpenVMS
Wizard, MSCP typically only becomes "confused" when something is rather
seriously wrong with the hardware, the firmware, or the associated (and
low-level) OpenVMS software. None of these problems are likely to be
particularly feasible to resolve without a direct look at the OpenVMS
Cluster configuration and the settings, and this may well require the
assistance of both MTI and Compaq OpenVMS Engineering to resolve. (And
this activity may/will also likely end up requiring a reboot, of course.)
Please also see the other discussions of third-party hardware support
here in Ask The Wizard.