 |
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.
|
|
|
|
|
