![]() |
![]() HP OpenVMS Systemsask the wizard |
![]() |
The Question is: Configuration: 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. Problem: 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. Questions: 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 ce? 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.
|