HP OpenVMS Systems

Third-party MSCP hardware off-line?

» close window

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.

  

     

     
answer written or last revised on ( 18-APR-2000 )
     
» close window