OpenVMS Alpha Version 7.1
Upgrade and Installation Manual

4.14 Postinstallation Checklist

• Register your licenses if you did not do so during the installation procedure.
• Create accounts.
• Back up the system disk as a safeguard before customizing the system.
• Customize the system.
• Configure and start the DECnet for OpenVMS Alpha software.
• Run the User Environment Test Package (UETP) to test the system.
• Decompress the system libraries using LIBDECOMP.COM.
• Add and remove files.
• Prepare your OpenVMS Alpha system and your PC to run OpenVMS Management Station by following the procedures described in Appendix E.
• Install layered products.
• Back up the system disk after you have customized it and installed layered products.
• Configure your multihead system (if applicable).
• After the system has been running for at least 24 hours, run AUTOGEN to collect feedback information and modify the MODPARAMS.DAT file (if necessary).

This chapter describes which tasks you should perform prior to beginning an upgrade. Tasks described in this chapter include:

• Reviewing notes, cautions, and restrictions
• Preparing to upgrade in a volume shadowing environment
• Backing up the current system disk
• Preparing the system disk for the upgrade
• Shutting down the system
• Using the preupgrade checklist

In addition to reviewing the information in this chapter, you might need to refer to the following sources of information as well:

• OpenVMS Version 7.1 Release Notes
• OpenVMS System Manager's Manual, for information about using AUTOGEN, modifying the system parameters file (MODPARAMS.DAT), and related operations
• OpenVMS System Management Utilities Reference Manual, for information about using system management utilities such as SYSMAN and ANALYZE/DISK_STRUCTURE
• OpenVMS Guide to System Security, for information about reestablishing your security environment after the upgrade

5.1 Notes, Cautions, and Restrictions

• Before upgrading from OpenVMS Alpha Version 7.0, deinstall Spiralog. Once OpenVMS Alpha Version 7.1 has been installed, you can install Spiralog Version 1.2.
• If you upgrade your OpenVMS Alpha Version 7.0 system to OpenVMS Alpha Version 7.1 when Spiralog is installed, and later remove Spiralog or install any version of Spiralog, this action will cause a failure in the Backup utility, the batch and print queuing system, and DECdtm services.
• If you accidentally upgrade your OpenVMS Alpha system to Version 7.1 while Spiralog is installed, you must do the following to recover from this error:
  1. Deinstall Spiralog.
  2. Reinstall OpenVMS Alpha Version 7.1 using the PRESERVE option from the menu system.
  3. Install Spiralog Version 1.2.
  4. Reboot your system.
• See the release notes and Software Product Description (SPD) for additional information about Spiralog support, including ordering information.

  5.1.2 Required Operating System Version

  To upgrade to Version 7.1 of the OpenVMS Alpha operating system, you must be running at least Version 6.1, 6.2, or 7.0.

  If you are upgrading in a cluster environment, also see Chapter 6 for information about required versions of the OpenVMS Alpha and OpenVMS VAX operating systems.

  5.1.3 Upgrade Paths

  Note the following:

  • Upgrades are supported from Version 6.1, 6.2, and 7.0 of the OpenVMS Alpha operating system.
  • Rolling upgrades are supported from Version 6.2 and 7.0 of the OpenVMS Alpha operating system (see Chapter 6 for more information).

  5.1.4 Update License

  To upgrade to OpenVMS Version 7.1, you must have an appropriate license. Digital's software licenses grant the right to use the current version of a product or any previous version of the product at the time of purchase. If you have an OpenVMS license prior to Version 7.1 and are not covered by a Software Product Services agreement, which includes the right to use new versions (RTNV), you must purchase an Update License before upgrading to OpenVMS Version 7.1.

  If you do not have an Update License, please contact your Digital support representative who will assist you in obtaining the correct Product Authorization Key (PAK) needed to access the OpenVMS operating system.

  5.1.5 Files and Directories

  Note the following:

  • If you choose not to install optional OpenVMS Alpha software during the upgrade, the upgrade procedure removes existing files for those components from the system disk.
  • If you have changed directory structure on your system disk, the upgrade procedure will not work correctly. Restore your system disk to a standard directory structure before you attempt an upgrade.
  • The OpenVMS Alpha Version 7.1 upgrade procedure provides new files and directories in the directory [VMS$COMMON...]. If you had any special protections and access control lists (ACLs) before the upgrade, you need to reapply them to reestablish the security environment you had previously set up. For more information about creating and maintaining a secure environment, see the OpenVMS Guide to System Security.

  5.1.6 Licenses and Layered Products

  Note the following:

  • The upgrade procedure is designed so that you should not have to reinstall most layered products after the upgrade. However, you might need to reinstall certain layered products because of product-specific installation procedures.
  • The upgrade procedure leaves your OpenVMS Alpha license and layered product licenses intact. You do not need to reinstall these licenses after you upgrade.

  5.2 Preparing to Upgrade in a Volume Shadowing Environment

  Because you cannot upgrade the operating system on a shadowed system disk (the upgrade will fail), you need to disable shadowing on that disk and perform other operations before you can upgrade the operating system.

  There are several methods for creating a nonshadowed target disk. This chapter describes how to change one of your existing shadowed system disks in a multimember shadow set to a nonshadowed disk that you can use as your target disk for the upgrade.

  If you have a larger configuration with disks that you can physically access, you may want to use a copy of the system disk as your target disk. Volume Shadowing for OpenVMS describes two methods you can use to create this copy (using volume shadowing commands or BACKUP commands) and how to disable volume shadowing.

  5.2.1 Creating a Nonshadowed Target Disk

  Change one of your existing shadowed system disks to a nonshadowed disk as follows:

  1. Shut down all systems booted from the shadowed system disk.
  2. Perform a conversational boot (see Appendix A if necessary) on the system disk you have chosen for your target disk. For example:

     >>> BOOT -FL 0,1 DKA100
     

  3. At the SYSBOOT> prompt, enter the following command to disable volume shadowing on the disk:

     SYSBOOT> SET SHADOW_SYS_DISK 0
     

  4. Enter the CONTINUE command to resume the boot procedure. For example:

     SYSBOOT> CONTINUE
     

  5. After the boot completes, log in to the system.

  5.2.2 Changing the Label

  If you want to change the label on the upgrade disk, use the DCL command SET VOLUME/LABEL=volume-label device-spec[:] to perform this optional task. (The SET VOLUME/LABEL command requires write access [W] to the index file on the volume. If you are not the volume owner, you must have either a system UIC or the SYSPRV privilege.)

  For OpenVMS Cluster systems, be sure that the volume label is a unique name across the cluster.

  Note: If you need to change the volume label of a disk that is mounted across the cluster, be sure you change the label on all nodes in the OpenVMS Cluster system. The following example shows how you can use the SYSMAN utility to define the environment as a cluster and propagate the volume label change to all nodes in that cluster:

  SYSMAN> SET ENVIRONMENT/CLUSTER
  SYSMAN> DO SET VOLUME/LABEL=new-label disk-device-name:
  

  5.2.3 Setting the Boot Device

  Be sure your system is set to boot from the upgrade disk by default. Use the SHOW BOOTDEF_DEV and SET BOOTDEF_DEV console commands to accomplish this task. (See Appendix A for more information.)

  5.2.4 What to Do Next

  After you have created a nonshadowed system disk that you can use for the upgrade, perform the additional preupgrade procedures described in the balance of this chapter.

  5.3 Backing Up the System Disk

  Digital strongly recommends that you make a backup copy of the system disk and, if your configuration allows it, upgrade the backup copy. (If there are problems, you will still have a working system disk.)

  5.3.1 How to Back Up the System Disk

  To back up the system disk, do the following:

  1. Shut down the system (described in Appendix A).
  2. Boot the operating system CD--ROM (locally or from the InfoServer).
  3. Use the menu system to enter the DCL environment (option 7).
  4. Mount the system disk and the target device on which you will make the backup copy.
  5. Enter backup commands to back up the system disk to the target device.
  6. Log out from the DCL environment.
  7. Shut down the system by selecting option 8 from the menu.
  8. Boot from the system disk.

  5.3.2 For More Information

  For complete information about backup operations, including a description of an alternate method that does not require booting from the operating system CD--ROM, see Appendix B.

  5.4 Preparing the System Disk

  The following sections describe how to prepare the system disk for the upgrade. The operations include the following:

  • Examining the system disk
  • Checking the size of the system disk
  • Verifying system parameters

  5.4.1 Examining the System Disk

  Examine and repair (if necessary) the system disk using the ANALYZE/DISK_STRUCTURE command. (See the OpenVMS System Management Utilities Reference Manual for more information about this command.) Use the following procedure:

  1. Analyze the system disk for inconsistencies and errors in the file structure by entering the following command:

     $ ANALYZE/DISK_STRUCTURE SYS$SYSDEVICE
     

     
     Ignore the following message:

     %ANALDISK-I-OPENQUOTA, error opening QUOTA.SYS 
     

  2. If you find any other errors on the system disk, repair the errors by entering the following command:

     $ ANALYZE/DISK_STRUCTURE/REPAIR SYS$SYSDEVICE
     

  5.4.2 Checking the Size of the System Disk

  It is difficult to determine in advance how many blocks of disk space you will need for the upgrade. It depends on how many files you have on the target disk already and on how many components you select during the upgrade procedure. However, the following information will help:

  • The maximum amount of disk space you will need is approximately 360,000 blocks, but your system might use substantially less.
  • After you select the components you want installed on the system for the upgrade, the upgrade procedure calculates whether you have enough disk space, displaying the number of available blocks and the number required for the upgrade. If the procedure determines that your disk does not have enough space to perform the upgrade, it displays a message to alert you and allows you to terminate the upgrade so you can create more disk space and try the upgrade again.

  To see how much space you have on the system disk, enter the following command:

  $ SHOW DEVICE SYS$SYSDEVICE
  

  5.4.3 Verifying System Parameters

  Verify (and modify if necessary) system parameters, described as follows. (If necessary, see the OpenVMS System Manager's Manual for more information about modifying system parameters.) Any system parameters that you modified and did not enter in SYS$SYSTEM:MODPARAMS.DAT are lost during the upgrade. To retain these parameters, enter their names in SYS$SYSTEM:MODPARAMS.DAT and the value that AUTOGEN needs to add to the default minimum value. (When AUTOGEN runs after the upgrade, it uses the values in SYS$SYSTEM:MODPARAMS.DAT.)

  For example, if you modified GBLPAGES by 128 pages above the default, add the following line to SYS$SYSTEM:MODPARAMS.DAT:

  ADD_GBLPAGES=128 
  

  5.4.4 What to Do Next

  Continue the preupgrade tasks as follows, depending on whether you are upgrading in a standalone or OpenVMS Cluster environment:

  IF ...	THEN ...
  you are upgrading a standalone system,	do the following: Log in to the SYSTEM account. Enter the following command and then press the Return key: $ @SYS$SYSTEM:SHUTDOWN When the procedure asks if an automatic system reboot should be performed, enter N (No) and press the Return key. Go to the checklist at the end of this chapter to verify that you have performed the necessary tasks; then go to Chapter 7 to begin the upgrade procedure.
  you are upgrading an OpenVMS Cluster system,	do the following: Review the checklist at the end of this chapter. Go to Chapter 6.

  5.5 Preupgrade Checklist

  Use the following checklist to make sure you have performed all the tasks before beginning the upgrade:

  • Review all cover letters and the release notes.
  • Review all cautions and notes.
  • If your system disk is part of a shadow set, create a nonshadowed system disk to upgrade.
  • 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 will need a transcript in case there is a problem during the upgrade. For information on how to record the procedure, see the hardware manuals that came with your Alpha computer.
  • Make a backup copy of the system disk.
  • Examine and repair (if necessary) the system disk using the ANALYZE/DISK_STRUCTURE command.
  • Check the size of the system disk.
  • Verify system parameters.
  • Shut down the system (if you are upgrading in a standalone environment).
  • If you are upgrading an OpenVMS Cluster system, go to Chapter 6. If you are not upgrading an OpenVMS Cluster system, go to Chapter 7 to begin the upgrade procedure.

  ---

  Chapter 6
  Preparing to Upgrade in an OpenVMS Cluster Environment

  6.1 Overview

  This chapter describes how to prepare to upgrade in an OpenVMS Cluster environment, depending on the type of upgrade you perform and whether you need to add any new computers to the cluster.

  Note: Be sure you have performed the preupgrade tasks described in Chapter 5 before you upgrade your OpenVMS Cluster system.

  6.1.1 Mixed-Version Support

  OpenVMS Alpha Version 7.1 and OpenVMS VAX Version 7.1 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 Digital 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 Digital has qualified the versions for use together in configurations that are migrating in a staged fashion to a newer version of OpenVMS VAX or to OpenVMS Alpha. Problem reports submitted against these configurations will be answered by Digital. However, in exceptional cases Digital 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 OpenVMS Cluster Warranted and Migration Support

  	Alpha V6.2--xxx	Alpha V7.0	Alpha V7.1
  VAX V6.2-- xxx	WARRANTED	Migration	Migration
  VAX V7.0	Migration	WARRANTED	Migration
  VAX V7.1	Migration	Migration	WARRANTED

  ---

  Note

  Digital does not support the use of Version 7.1 with Version 6.1 (or earlier versions) in an OpenVMS Cluster environment. In many cases, mixing Version 7.1 with versions prior to Version 6.2 will successfully operate, but Digital cannot commit to resolving problems experienced with such configurations.

  ---

  6.1.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.1.3 Adding a New System to the Cluster

  If you need to add a new computer supported by OpenVMS Alpha Version 7.1 to an existing OpenVMS Cluster configuration, Digital supports two options, listed in the following preferred order:

  1. Upgrade the entire cluster to Version 7.1 of the OpenVMS Alpha operating system and add the new computer as a member.
  2. If you need to keep some systems in the cluster running the current version of OpenVMS Alpha, you must upgrade a system disk in the cluster to OpenVMS Alpha Version 7.1 using the rolling upgrade procedure. Then boot the new computer into the cluster using that upgraded system disk.

  6.1.4 For More Information

  When you upgrade the operating system in an OpenVMS Cluster environment, be sure the following information is available to review:

  • The cover letters and the software product descriptions included with your distribution kit
  • OpenVMS Version 7.1 Release Notes
  • OpenVMS Cluster Systems
  • Guidelines for OpenVMS Cluster Configurations
  • OpenVMS Version 7.1 New Features Manual

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

  6.2.1 How a Concurrent Upgrade Works

  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 Alpha computer. When the cluster reboots, each Alpha computer will be running the upgraded version of the OpenVMS Alpha operating system.

  If all Alpha systems in the OpenVMS Cluster environment are booted from one system disk, you must perform a concurrent upgrade.

  6.2.2 Preparing for a Concurrent Upgrade

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

  1. Log in locally to the SYSTEM account.
  2. Shut down all systems by entering the following command on each system (satellites first, then the boot nodes):

     $ @SYS$SYSTEM:SHUTDOWN
     

  3. When the procedure asks if an automatic system reboot should be performed, enter N (No) and press the Return key.
  4. Choose the CLUSTER_SHUTDOWN option.
  5. When the shutdown procedure is finished on all nodes, halt each system by entering Ctrl/P or by pressing the Halt button.¹
  6. If you have only one system disk for your cluster, go to Chapter 7 to begin the upgrade procedure.
     If you have more than one system disk, select the disk on which you already performed the preupgrade tasks and then go to Chapter 7 to begin the upgrade procedure.
     After the upgrade is complete, you will be instructed to reboot each computer in the OpenVMS Cluster environment before beginning other postupgrade procedures.

  ---

  Note

  ¹ For more information about halting your Alpha computer, see Appendix A.

  ---

  6.3 Rolling Upgrade

  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.

  6.3.1 How a Rolling Upgrade Works

  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. During a rolling upgrade, you keep some of the computers in the cluster running while you upgrade others (you must have more than one system disk).

  6.3.2 Notes and Restrictions

  Before performing a rolling upgrade, note the following:

  • Rolling upgrades are supported from Version 6.2 and 7.0 of the OpenVMS Alpha operating system. Rolling upgrades in mixed-architecture OpenVMS Cluster environments are supported with VAX computers running Versions 7.0 or 6.2 of the OpenVMS VAX operating system (see Table 6-1.
  • The upgraded system does not attempt to access any disk that is being accessed by one or more of the remaining OpenVMS Cluster systems.
  • The remaining OpenVMS Cluster systems do not attempt to access the target disk of the system being upgraded.
    If the target disk being upgraded is locally attached to the system performing the upgrade, then it is not accessible to the remaining OpenVMS Cluster systems. (The OpenVMS system booted from the operating system CD--ROM does not MSCP serve local disks.) Whenever possible, Digital recommends that you perform the upgrade on a local disk or that you perform a concurrent upgrade.
    During the upgrade, be sure that the target disk you select, as well as any disk you access from the DCL menu option, is either a local disk or one that is not being accessed by any of the remaining OpenVMS Cluster members.
  • Digital recommends that all Alpha computers in a cluster run the same (and preferably the latest) version of the OpenVMS Alpha operating system.
  • You cannot perform a rolling upgrade if all systems boot from a single system disk. Perform a concurrent upgrade instead.
  • The upgrade procedure affects the queuing system as follows:
    • The queuing system is not active on the system you are upgrading; do not attempt to execute a START/QUEUE/ MANAGER command.
    • You cannot create a queue database on the operating system CD--ROM (because it is not writable).
    • The queue manager process on other nodes in the cluster can continue to run during the upgrade if the queue database is not on the disk being upgraded.

  6.3.3 Preparing for a Rolling Upgrade

  To prepare for a rolling upgrade, follow these steps:

  1. Log in to any node where the disk is mounted as a data disk, rather than as the system disk. (That disk must be the one on which you already performed the preupgrade tasks described in Chapter 5.)
  2. 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.)
  3. Use the DCL command DISMOUNT/CLUSTER to dismount the data disk. (You can also perform this operation using the SYSMAN utility.)
     Note that you can ignore messages from nodes where the specified data disk is being used as the system disk.
  4. Verify that the data disk has been dismounted successfully by entering the following commands:

     $ MCR SYSMAN
     SYSMAN> SET ENVIRONMENT/CLUSTER
     SYSMAN> DO SHOW DEVICE disk-name
     

     
     Examine the display to be sure the disk is not mounted on any nodes as a data disk. Noting the value listed in the Trans Count field can help you make that determination: A value of less than 50 indicates that the disk is mounted as a data disk rather than as the system disk; a much larger value (for example, 300) indicates that the disk most likely is the system disk.
  5. If the disk is still mounted on any nodes as a data disk, use the SYSMAN utility to dismount the disk; otherwise exit from the SYSMAN utility.
  6. Shut down all nodes that boot from the system disk you are upgrading, including the node from which you will perform the upgrade. Enter the following command on each node:

     $ @SYS$SYSTEM:SHUTDOWN
     

  7. When the procedure asks if an automatic system reboot should be performed, enter N (No) and press the Return key.
  8. Choose the REMOVE_NODE option.
  9. 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 system that is still a cluster member:

     $ [Ctrl/P]
     >>> D SIRR C
     >>> C
     IPC> Q
     IPC> [Ctrl/Z]
     

  10. After the shutdown procedure is finished on all nodes, go to Chapter 7 to begin the upgrade procedure.

  ---

  Chapter 7
  Upgrading the OpenVMS Alpha Operating System

  This chapter describes the following tasks:

  • Beginning the upgrade from the operating system CD--ROM or from a running system
  • Specifying the target disk
  • Specifying the volume label
  • Updating time zone information
  • Choosing descriptive help text
  • Completing the upgrade
  • Performing postupgrade tasks (including booting the upgraded system)
  • Installing layered products

  7.1 Upgrading from CD--ROM or from a Running System

  The OpenVMS Alpha Version 7.1 operating system includes procedures that allow you to easily upgrade the operating system using the POLYCENTER Software Installation utility. In console mode, you can boot the operating system CD--ROM to begin the upgrade procedure. On a system that is already running the OpenVMS Alpha Version 7.1 operating system, you can invoke the upgrade procedure by entering a command at the DCL level.

  ---

  Previous | Next | Contents | [Home] | [Comments] | [Ordering info] | [Help]

  ---

  
  

    6486P004.HTM
    OSSG Documentation
     6-DEC-1996 10:35:12.97
  

  Copyright © Digital Equipment Corporation 1996. All Rights Reserved.

  Legal