|
HP OpenVMS Systemsask the wizard |
|
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.
|