Document revision date: 30 March 2001

Before you begin the upgrade procedure, use the following checklist to make sure you have completed all the necessary preupgrade tasks.

• Read the OpenVMS Version 7.3 New Features and Documentation Overview, the OpenVMS Version 7.3 Release Notes, and any cover letters that came with your kit.
• Read the cautions and restrictions described at the beginning of this chapter and in Chapter 1.
• Make sure you have enough free blocks for the upgrade. You need at least 48,950 free blocks for the required files to start the upgrade (described in Section 5.5). The entire upgrade requires about 163,000 blocks.
• Set up your system to record the upgrade procedure on either a hardcopy terminal or a printer attached to the console terminal. If you do not do this, the screen messages will be lost. You need a transcript in case there is a problem during the upgrade. For information on how to connect a hardcopy device to your console to record the procedure, refer to the upgrade and installation supplement for your VAX computer.
• Check your AUTOGEN feedback information to be sure it is valid before rebooting the system. (Described in Section 5.3)
• Make a backup copy of the system disk and, if applicable, of the console media. (Described in the upgrade and installation supplement for your computer)
• If, in previous versions, your distribution kit provided standalone BACKUP on one of the following media types, make sure you have created a standalone BACKUP kit on one of the following media types:

  RX33
  TU58
  RX50
  RX01
  RL02

  
  (Described in Section 5.4)
• Make sure SYSUAF.DAT is in the SYS$COMMON:[SYSEXE] and VMS$AUDIT_SERVER.DAT is in the SYS$COMMON:[SYSMGR] directory. (Described in Section 5.5)
• Make sure SWAPFILE.SYS (if it is located on the system disk) and PAGEFILE.SYS are in the SYS$SPECIFIC:[SYSEXE] directory. (Described in Section 5.5)
• Make sure the page file is at least 4600 blocks. (Described in Section 5.5)
• If you have a shared system dump file in SYS$COMMON:[SYSEXE], make sure the shared file is not named SYSDUMP.DMP. (Described in Section 5.5)
• If your system disk is part of a shadow set, create a nonshadowed system disk to upgrade. (Described in Volume Shadowing for OpenVMS)
• Make sure the SYSTEM account has sufficient quotas and limits. (Described in Section 5.5)
• Set the appropriate system parameters and make sure that STARTUP_P1 is set to MIN. (Described in Section 5.5)
• Define the system parameters SCSNODE and SCSSYSTEMID. (Described in Section 5.5)
• If your system has a KFQSA controller, make sure the VMS5 parameter is set to 0. (Described in Section 5.5)
• Check the location of your AGEN$INCLUDE files. (Described in Section 5.5.10)
• Set up the system to restart automatically. (Described in the upgrade and installation supplement for your VAX computer)
• Shut down and reboot the system from which you will perform the upgrade. If you are upgrading a VAXcluster, shut down all computers that boot from the system disk you are upgrading.
• Set interactive logins to 0.
• Shut down DECnet for OpenVMS software. (Described in Section 5.6)
• Migrate to phase II volume shadowing if you are currently using phase I. (Described in Section 5.6)
• Stop all batch and print queues on the node you are upgrading. (Described in Section 5.6)
• Make sure you have the following information (described in Section 5.7) available:
  • The device names of the drives that will hold the system disk and the distribution media
  • Passwords of at least 8 characters for the SYSTEM, SYSTEST, and FIELD accounts
  • A list of optional OpenVMS VAX components you want to install
  • A list of optional DECwindows components you want to install
  • The information listed on Product Authorization Keys (PAKs) for any new product licenses you will register
• Create a command procedure to be used when booting from [SYSF]. See Appendix C.

To upgrade a standalone system, go to Chapter 7.

To upgrade a VAXcluster environment, go to Chapter 6.

This chapter describes how to upgrade a VAXcluster environment. Refer to OpenVMS Cluster Systems for more detailed information on VAXcluster environments.

6.1 Mixed-Version Support

OpenVMS Alpha Version 7.3 and OpenVMS VAX Version 7.3 provide two levels of support for mixed-version and mixed-architecture OpenVMS Cluster systems. These two support types are warranted and migration.

Warranted support means that Compaq has fully qualified the two versions coexisting in an OpenVMS Cluster and will answer all problems identified by customers using these configurations.

Migration support is a superset of the Rolling Upgrade support provided in earlier releases of OpenVMS and is available for mixes that are not warranted. Migration support means that Compaq has qualified the versions for use together in configurations that are migrating in phases to a newer version of OpenVMS VAX or to OpenVMS Alpha. Problem reports submitted against these configurations will be answered by Compaq. However, in exceptional cases Compaq may request that you move to a warranted configuration as part of answering the problem.

Migration support will help you move to warranted OpenVMS Cluster version mixes with minimal impact on your cluster environment. Table 6-1 shows the level of support provided for all possible version pairings.

Table 6-1 VAX and Alpha OpenVMS Cluster Warranted and Migration Support

	V6.2-xxx	V7.0-xxx	V7.1-xxx	V7.2-xxx	V7.3
V6.2	WARRANTED	Migration	Migration	Migration	Migration
V7.0	Migration	WARRANTED	Migration	Migration	Migration
V7.1	Migration	Migration	WARRANTED	Migration	Migration
V7.2	Migration	Migration	Migration	WARRANTED	Migration
V7.3	Migration	Migration	Migration	Migration	WARRANTED

If your cluster environment has both VAX and Alpha systems, also refer to Migrating an Environment from OpenVMS VAX to OpenVMS Alpha¹.

6.2 Types of Upgrades

There are two types of cluster upgrades: concurrent and rolling. The type of upgrade you use depends on whether you want to maintain the availability of the cluster during the upgrade and whether you have more than one system disk. Review this chapter and then perform the preliminary tasks for the upgrade procedure (concurrent or rolling) that best suits your configuration.

6.2.1 Concurrent Upgrades

During a concurrent upgrade, you must shut down the entire cluster and upgrade each system disk. No one can use the cluster until you upgrade each system disk and reboot each VAX computer. If all systems in the VAXcluster environment are booted from one system disk, you must perform a concurrent upgrade.

To perform a concurrent upgrade, go to Section 6.3.

6.2.2 Rolling Upgrades

During a rolling upgrade, you can keep some of the VAX computers in the cluster running while you upgrade others (you must have more than one system disk). The cluster runs temporarily with different versions of the operating system.

To perform a rolling upgrade, go to Section 6.4.

6.3 Concurrent Upgrade

This section describes the following:

• How a concurrent upgrade works
• Tasks you need to perform to prepare your system for a concurrent upgrade

During a concurrent upgrade, you must shut down the entire cluster and upgrade each system disk and reboot each VAX computer in the cluster. When the cluster reboots, each VAX computer will be running the upgraded version of the OpenVMS VAX operating system.

6.3.2 Preparing for a Concurrent Upgrade

To prepare for a concurrent upgrade, use the following procedure:

1. Shut down the entire cluster by logging in to the SYSTEM account on each node locally, entering the following command, and choosing the CLUSTER_SHUTDOWN option:

   $ @SYS$SYSTEM:SHUTDOWN

2. If you have only one system disk for your cluster, go to step 3.
   If you have more than one system disk, select one to upgrade.

   Caution You cannot use the system disk that you usually use as the quorum disk to hold the save sets from the distribution kit.

3. Perform a conversational boot of a single VAX computer from the system disk you will be upgrading. For more information about the conversational boot procedure, refer to the upgrade and installation supplement for your VAX computer.
   At the SYSBOOT> prompt, use the SHOW VOTES and SHOW EXPECTED_VOTES command to display the current values of the parameters. Write these values down because you will need to restore them later. Set the VOTES and EXPECTED_VOTES values to 1 by entering the following commands:

   SYSBOOT> USE CURRENT SYSBOOT> SET VOTES 1 SYSBOOT> SET EXPECTED_VOTES 1 SYSBOOT> CONTINUE

4. Upgrade the system disk, using the procedure in Chapter 7.
5. If you have only one system disk, go to step 6.
   If you have more than one system disk, shut down the system that you just upgraded. Then repeat steps 2 through 4 to upgrade each system disk in the cluster. When you finish upgrading all of the system disks, go to step 6.
6. Reboot each computer in the VAXcluster environment.
7. Complete the postupgrade procedures described in Chapter 8.

This section describes the following:

• How a rolling upgrade works
• Notes and restrictions
• Tasks you need to perform to prepare your system for a rolling upgrade

During a rolling upgrade, you upgrade each system disk individually, allowing old and new versions of the operating system to run together in the same cluster, creating a mixed-version cluster. Because rolling upgrades allow mixed-version clusters, the systems that you are not upgrading remain available.

6.4.2 Notes and Restrictions

The following restrictions apply to rolling upgrades:

• Compaq recommends that all VAX computers in a cluster run the same version of the operating system. Mixed-version clusters are supported only for the purpose of upgrading the entire cluster incrementally. Compaq further recommends that all VAX systems in a VAXcluster run the latest version of the OpenVMS VAX operating system.
• A rolling upgrade does not apply when all systems boot from a single system disk. When all systems boot from a single system disk, perform a concurrent upgrade using the procedure described in Section 6.3.
• During the rolling upgrade, the queuing system is disabled on the nodes being upgraded. The queuing system on the other nodes should be unaffected by the upgrade as long as a START/QUEUE/MANAGER/ON=(upgrade
  node . . .) command is not executed. A START/QUEUE/MANAGER command could attempt to move the queue manager process to the node being upgraded if the /ON qualifier indicates that it is one of the preferred nodes. If the queue manager attempts to run on the node being upgraded, the queuing system will hang on the entire cluster.
  If your startup file contains a START/QUEUE/MANAGER/ON=(upgrade node1, node2 ... noden) command, do not boot in any nonupgrading nodes until you have removed that command from the startup file. Booting in a node causes the queuing system to hang on the cluster if the START/QUEUE/MANAGER/ON=(upgrade node, ... ) command is executed. When the upgrade has completed, you can add the command back to the startup file.
  If the cluster queuing system hangs during the upgrade, it is most likely caused by the queue manager attempting to run on the upgrading node. To clear the condition, move the queue manager to a node you are not upgrading by entering the following command:

  START/QUEUE/MANAGER/ON=(nonupgrading node1, - node2 . . . noden)

To prepare for a rolling upgrade, follow these steps:

1. Check the votes and make adjustments to maintain the proper quorum so the cluster can continue to operate throughout the upgrade. (OpenVMS Cluster Systems describes this procedure in detail.)
2. Select a system disk to upgrade.
3. Shut down all VAX computers booting from the system disk that you are upgrading, except for the computer that you will use to apply the upgrade. VAX computers that do not boot from the system disk that you are upgrading remain available to users.
   1. Log in to the SYSTEM account on the VAX computer you are shutting down.
   2. Enter the following command:

      $ @SYS$SYSTEM:SHUTDOWN.COM

   3. On one of the VAX computers that is still running, enter the following command:

      $ SET CLUSTER/EXPECTED_VOTES

   4. Repeat steps a to c for each VAX computer requiring a shutdown.
   
   This procedure lets one VAX computer continue running from the system disk (assuming computers running from different system disks supply enough votes to sustain cluster quorum).
4. If proper quorum is not maintained at any time during the upgrade procedure, the shutdown procedure will hang the cluster. If the cluster hangs during a shutdown, enter the following commands on the system console of a CPU that is still a cluster member:

   $ [Ctrl/P] >>> H >>> D/I 14 C >>> C IPC> Q IPC> [Ctrl/Z]

5. Upgrade the system disk using the procedure in Chapter 7.

   Caution The upgrade procedure requires exclusive access to the drive that holds the distribution media. Do not mount the distribution media on other nodes.

6. During phase 1 of the upgrade, the procedure asks if you are performing a rolling upgrade. If you enter Y, the procedure asks you several questions to determine if all system disks in the cluster (other than the one you are upgrading) are running at least OpenVMS VAX Version 6.2. For example:

   * Are the other system disks running OpenVMS V6.2 or higher?

   
   All systems in the cluster must be running at least OpenVMS VAX Version 6.2 to perform the rolling upgrade. Type Y and press Return.

7. When the upgrade has completed, reboot each VAX computer that boots from the system disk you have just upgraded.
8. Perform the postupgrade tasks described in Chapter 8.
9. Repeat steps 2 to 7 for each system disk you are upgrading. Once you have performed tasks a to d in step 3, you do not need to perform them again.

If you need to add a new CPU supported by OpenVMS VAX Version 7.3 to an existing Version 6.2 VAXcluster, Compaq supports two options, listed in the following preferred order:

1. Upgrade the entire cluster to OpenVMS VAX Version 7.3 and bring the new CPU in as a member.
2. If you need to keep some systems in the cluster at OpenVMS VAX Version 6.2, you must upgrade a system disk in the cluster to Version 7.3 using the rolling upgrade procedure and then boot the new CPU into the cluster using that system disk.

	privacy and legal statement
6630PRO_008.HTML