  Volume shadowing and upgrades? 
 The Question is:
 
Hello,
 
We have problems sometimes determining the actual boot device of an Alpha
 system.  Typically, our system disks are shadowed.  During an upgrade
 procedure, we dismount one of the shadow members, and reboot from the second
 shadow member as defined in the mo
unt_disks.dat file (*note: this disk corresponds to the second system disk
 shadow member as recognized within OpenVMS).  The problem is that on reboot,
 the boot disk defined in OpenVMS does NOT correspond to the actual boot device
 as known by the console.
  Is there a way to determine the actual boot device within VMS (aka without
 having to bring the system down to the console)???
 
*note:  we have set the userd2 setting to "2" within sysgen before rebooting
 the system... and I understand why there are differences in naming convention
 between VMS and the console after reading article, "OpenVMS and console device
 name differences."
 
 The Answer is:
 
  You have not specified details of the particular problem(s) you are
  encountering.
 
  If you simply seek the master volume, there are system services and DCL
  lexical functions to retrieve the current master volume of the shadowset.
  (Please see sys$getdvi and f$getdvi documentation for details.)
 
  When a system disk is configured as a shadowset, the console contains
  an environment variable with a list of the shadowset member volumes.
  When upgrading, you must disable shadowing for the duration of the
  upgrade.
 
  When upgrading OpenVMS, please see the section "Upgrading the OpenVMS
  Operating System on a System Disk Shadow Set", currently Chapter seven
  in the shadowing manual.  A section "Preparing to Upgrade in a Volume
  Shadowing Environment" is included in the Upgrade and Installation
  manual, as well.  Also see the section entitled "Using Copy Operations
  to Create a Backup", if that task is involved here.
 
  For details on performing a rolling upgrade within an OpenVMS Cluster,
  please see the Upgrade and Installation documentation -- the rolling
  upgrade will permit you to maintain cluster availability during the
  OpenVMS upgrade procedures and reboots.
 
