HP OpenVMS Systems Documentation

This chapter contains information that applies to installations and upgrades of the OpenVMS Alpha and OpenVMS VAX operating systems.

The installation and upgrade notes in this chapter are organized into the following categories:

• Installation and upgrade notes common to both Alpha and VAX systems (see Section 2.1)
• Alpha specific installation and upgrade notes (see Section 2.2)
• VAX specific installation and upgrade notes (see Section 2.3)

For information about layered product installation and support, see Chapter 3.

For hardware and firmware release notes, see Appendix B.

2.1 Installation and Upgrade Information Common to Alpha and VAX

The following release notes document installation and upgrade information common to both OpenVMS Alpha and OpenVMS VAX platforms.

For Alpha-specific notes, see Section 2.2.

For VAX-specific installation and upgrade notes, see Section 2.3.

2.1.1 Compatibility Kits Required in Some OpenVMS Cluster Systems

V7.3

If you are planning to install OpenVMS Version 7.3 in an OpenVMS Cluster system, in either a mixed-version cluster or a mixed-architecture cluster, you need to install certain remedial kits (if you have not already installed them). For more information, see Section 5.9.5.

2.1.2 Networking Options

V7.3

OpenVMS provides customers with the flexibility to choose the network protocol of their choice. Whether you require DECnet or TCP/IP, OpenVMS allows you to choose the protocol or combination of protocols that works best for your network. OpenVMS supports both Compaq and third-party networking products.

During the main installation procedure for OpenVMS Version 7.3, you have the option of installing the following Compaq networking software:

• Compaq TCP/IP Services for OpenVMS
  TCP/IP Services and DECnet can run concurrently on your system. Once you have installed Compaq DECnet-Plus for OpenVMS and TCP/IP Services on your system, you can run DECnet applications and OSI applications, or both, over your TCP/IP network. Refer to the DECnet-Plus for OpenVMS Management Guide for more information about running DECnet over TCP/IP (RFC 1859) and OSI over TCP/IP (RFC 1006).
• Either DECnet-Plus for OpenVMS or Compaq DECnet for OpenVMS Phase IV for OpenVMS. (Note that both DECnet products cannot run concurrently on your system.)
  DECnet-Plus contains all the functionality of the DECnet Phase IV product, plus the ability to run DECnet over TCP/IP or OSI protocols.
  Support for DECnet Phase IV is provided to customers with a Prior Version Support Contract. For more information about the Prior Version Support service, see Section 1.4.

Or, after you install OpenVMS, you can install a supported third-party networking product of your choice.

For information about how to configure and manage your Compaq networking software after installation, see the manuals listed in Table 2-1. The manuals in online format are available on the OpenVMS Documentation CD-ROM and can be ordered in printed format through Compaq (800-282-6672).

V7.3

Both the PATHWORKS V6.0D for OpenVMS (Advanced Server) and the Compaq Advanced Server V7.3 for OpenVMS ship with OpenVMS Version 7.3 and provide file and print services for the OpenVMS system. Advanced Server V7.3 for OpenVMS runs on OpenVMS Alpha Versions 7.2-1 and 7.3 only and is based on, and succeeds, PATHWORKS Version 6.0. PATHWORKS V6.0D for OpenVMS runs on OpenVMS Alpha Versions 7.3, 7.2-1, and 6.2 and on OpenVMS VAX Versions 7.3, 7.2, and 6.2.

If you want to run OpenVMS V7.3, you must upgrade PATHWORKS and Advanced Server for OpenVMS servers to their latest versions. PATHWORKS servers prior to V6.0D, and Advanced Server for OpenVMS servers prior to V7.3 do not run on OpenVMS Version 7.3.

For more details about upgrading PATHWORKS V6.0 and Advanced Server V7.2x servers, see Section 2.1.4 and Section 2.1.5, respectively.

For more information about the Advanced Server for OpenVMS product, see Section 3.2.

2.1.4 Upgrading Systems Running PATHWORKS V6.0 Advanced Servers Prior to V6.0D

V7.3

If you are upgrading an OpenVMS system that is currently running older versions of the PATHWORKS for OpenVMS (Advanced Server), follow these steps:

1. Upgrade your PATHWORKS for OpenVMS (Advanced Server) to V6.0D.
2. Upgrade your OpenVMS Version 7.2 system to OpenVMS Version 7.3.
3. To upgrade a PATHWORKS for OpenVMS server to Advanced Server V7.3 for OpenVMS:
   1. If you are on a VAX-based system, migrate to an Alpha-based system.
   2. Upgrade your Alpha system to OpenVMS Version 7.3.
   3. Upgrade your PATHWORKS server to Advanced Server V7.3 for OpenVMS.

For information on PATHWORKS (LAN Manager) servers, see Section 3.3.2. For more information about the Advanced Server for OpenVMS product, see Section 3.2.

2.1.5 Upgrading Advanced Server for OpenVMS V7.2 or V7.2A

V7.3

If you you want to upgrade your Advanced Server for OpenVMS server, follow these steps:

1. Upgrade your Advanced Server V7.2/7.2A for OpenVMS server to Advanced Server V7.3 for OpenVMS.
2. Upgrade your OpenVMS Alpha system to OpenVMS Version 7.3.

For more information about the Advanced Server for OpenVMS product, see Section 3.2.

2.1.6 DECevent Version 3.1 or Later Required to Analyze Errors

V7.3

DECevent Version 3.1 or later is required to analyze OpenVMS error log files on supported computers.

In OpenVMS Version 7.0 and earlier releases of OpenVMS, the DECevent DCL command DIAGNOSE was defined during the operating system installation or upgrade.

When you install OpenVMS Version 7.3, the DIAGNOSE command is disabled. To enable the DIAGNOSE command, you must install the DECevent software (included in the DECevent kit on the Compaq Systems Tool CD-ROM) after you install OpenVMS Version 7.3. Otherwise, when you attempt to use the DIAGNOSE command, you will receive the following system message:

$ DIAGNOSE [parameters]
%DIA-E-NOINSTAL, DIAGNOSE has not been installed on this system

For more information about DECevent, see OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems.

2.1.7 PCSI-I-RETAIN Messages During DECnet-Plus Installation

V7.2

If you upgrade to OpenVMS Version 7.3 and your system has either DCE for OpenVMS or DECnet-Plus for OpenVMS installed on it, when you install DECnet-Plus you may get PCSI-I-RETAIN informational messages for the following files:

[SYSEXE]DTSS$SET_TIMEZONE.EXE
[SYSLIB]DTSS$RUNDOWN.EXE
[SYSUPD]DTSS$TIMEZONE_RULES.DAT
[SYSLIB]DTSS$SHR.EXE

For example:

%PCSI-I-RETAIN, file [SYSEXE]DTSS$SET_TIMEZONE.EXE was not replaced
because file from kit has a lower generation number

You can ignore these messages. The DECnet-Plus kit has been properly installed.

2.1.8 Installing DECwindows with Some Layered Products May Cause Insufficient Global Sections

V7.3

Compaq DECwindows does not calculate sufficient global sections to start up if you install it together with certain layered products. If you install DECwindows together with one or more other layered products, DECwindows may fail to start up during the first system startup after reboot. You will see a message similar to the following on the console:

%DECW-W-BADVALUE, Free GBLSECTIONS is 251, should be at least 280

At this point, DECwindows offers to run AUTOGEN for you:

Do you want the system to run AUTOGEN for you [YES]?

Some SYSGEN parameters must be reset for DECwindows to start. If you type YES, AUTOGEN changes these parameters and reboots your system, but DECwindows does not start. If you type NO, AUTOGEN does not run or cause a reboot, allowing you to login and adjust the SYSGEN parameters manually to enable DECwindows to start.

Perform the following steps so that DECwindows starts:

1. Type NO to the question:

   Do you want the system to run AUTOGEN for you [YES]?

2. When the system completes startup, log in to the console.
3. Manually update SYS$SYSTEM:MODPARAMS.DAT to increase the size of the global sections. For example, you may add the following line to SYS$SYSTEM:MODPARAMS.DAT:

   MIN_GBLSECTIONS = 700

4. Run AUTOGEN to correct the system parameters.

   $ @SYS$UPDATE:AUTOGEN GETDATA TESTFILES NOFEEDBACK $ @SYS$UPDATE:AUTOGEN GENPARAMS REBOOT NOFEEDBACK

5. Check whether current values are sufficient to run DECwindows by running:

   $ @SYS$MANAGER:DECW$GETPARAMS.COM

V7.3

When you boot with minimum startup (STARTUP_P1 "MIN"), the job controller indicates that Daylight Savings Time adjustments are not possible with the following message:

%JBC-W-SYSERROR, SYS$MANAGER:JBC$DST_COMMAND.COM daylight savings time process
failed system service error at PC 00000000

This is correct and normal information to ensure awareness of a possible effect on the system time during the minimum startup procedure. It can safely be ignored if it does not affect your own requirements for the startup of the system (such as, during an upgrade or installation).

2.2 Installation and Upgrade Information Specific to Alpha

The release notes in this section pertain only to installations or upgrades of OpenVMS Alpha operating systems. See Section 2.1 for additional notes that pertain to both Alpha and VAX systems. For complete information about installing or upgrading to OpenVMS Alpha Version 7.3, refer to the OpenVMS Alpha Version 7.3 Upgrade and Installation Manual.

2.2.1 Upgrading to OpenVMS Alpha Version 7.3 from V7.2-1 or V7.2-1H1

V7.3

If you are upgrading from OpenVMS Alpha Version 7.2-1 or 7.2-1H1, and you have any of the following remedial kits installed on your system, follow these instructions before performing the upgrade:

• DEC-AXPVMS-VMS721_DRIVER-V0200-4.PCSI
• DEC-AXPVMS-VMS721_MANAGE-V0100-4.PCSI
• DEC-AXPVMS-VMS721_VX1-V0200-4.PCSI
• DEC-AXPVMS-VMS721H1_CPU2308-V0100-4.PCSI
• DEC-AXPVMS-VMS721H1_ACRTL-V0200-4.PCSI

During an OpenVMS Version 7.3 upgrade, operating system files from the previous version of OpenVMS are deleted. Due to errors in the above remedial kits, files from the newly installed system may be deleted. This may cause the system to be unbootable.

To prevent the Version 7.3 files from being deleted, you must perform the following steps on your system prior to installing the OpenVMS Version 7.3 Operating System:

1. Edit the file SYS$COMMON:[SYSUPD]VMS$REMEDIAL_OLD_FILES.TXT.
   Change the incorrect lines (as shown in the following table) with the corrected lines. Note that the lines may appear within the file in any order, not necessarily in the order of this table.

   Incorrect lines
   [SYSLIB]SYS$ICBM.EXE	VMS721_DRIVER-V0200
   [SYSLIB]SMI$SHR.EXE	VMS721_MANAGE-V0100
   [SYS$LDR]SYS$GFDRIVER.EXE _OLD	VMS721_VX1-V0200
   [SYSEXE]SYS$CONFIG.DAT_0LD	VMS721_VX1-V0200
   [SYSLIB]DECC$SHR_OLD	VMS721H1_ACRTL-V0200
   [SYS$LDR]SYS$CPU_ROUTINES_2308.EXE	VMS721H1_CPU2308-V0100
   [SYSEXE]SYS$SMHANDLER_SLAVE_2308.EXE	VMS721H1_CPU2308-V0100

   Corrected lines
   [SYSLIB]SYS$ICBM.EXE_OLD	VMS721_DRIVER-V0200
   [SYSLIB]SMI$SHR.EXE_OLD	VMS721_MANAGE-V0100
   [SYS$LDR]SYS$GFDRIVER.EXE_OLD	VMS721_VX1-V0200
   [SYSEXE]SYS$CONFIG.DAT_OLD	VMS721_VX1-V0200
   [SYSLIB]DECC$SHR.EXE_OLD	VMS721H1_ACRTL-V0200
   [SYS$LDR]SYS$CPU_ROUTINES_2308.EXE_OLD	VMS721H1_CPU2308-V0100
   [SYSEXE]SYS$SMHANDLER_SLAVE_2308.EXE_OLD	VMS721H1_CPU2308-V0100

   Corrections explained
   [SYSLIB]SYS$ICBM.EXE_OLD	adds _OLD to name
   [SYSLIB]SMI$SHR.EXE_OLD	adds _OLD to name
   [SYS$LDR]SYS$GFDRIVER.EXE_OLD	deletes a space
   [SYSEXE]SYS$CONFIG.DAT_OLD	changes 0 (zero) to O
   [SYSLIB]DECC$SHR.EXE_OLD	adds .EXE in name
   [SYS$LDR]SYS$CPU_ROUTINES_2308.EXE_OLD	adds _OLD to name
   [SYSEXE]SYS$SMHANDLER_SLAVE_2308.EXE_OLD	adds _OLD to name

2. Close the SYS$COMMON:[SYSUPD]VMS$REMEDIAL_OLD_FILES.TXT file.
3. Purge the previous version of the file.

After changing the SYS$COMMON:[SYSUPD]VMS$REMEDIAL_OLD_FILES.TXT file, you can install the OpenVMS Version 7.3 Operating System kit using the documented installation instructions.

A remedial kit that automates this workaround will be available at the following web site:

V7.3

Because Registry components in OpenVMS Version 7.3 are incompatible with their counterparts in OpenVMS Version 7.2-1, you may need to take special steps when upgrading Alpha cluster members from V7.2-1 to V7.3.

If you choose to upgrade all Alpha nodes in the cluster at once, then Compaq recommends that you shutdown only the Registry and all applications using the Registry before upgrading, and then reverse the process for startup after upgrading.

If you choose to upgrade only some nodes in the cluster at a time, then be aware that you can run Registry servers and applications on only the V7.2-1 nodes in the cluster, or on only the V7.3 nodes in the cluster, but not both. Thus, before you upgrade each node in the cluster, you need to inhibit the startup of the following on the upgraded node:

• The Registry
• Advanced Server
• COM layered products
• Any other applications using Registry

At some point, you will have to shutdown all remaining Registry-based activity in the cluster just before you start up Registry and applications using Registry services on the V7.3 nodes.

The following steps describe the procedure you can use when upgrading from V7.2-1 to V7.3 on systems running the OpenVMS NT Registry:

1. Though not required, it is best to shut down the Registry in a graceful manner. Before shutting down the Registry, shut down all layered products that use the Registry. First, shut down applications specific to your environment, if any, which are known to use Registry services. Next, shut down layered products which use Registry services: for example, first shut down COM for OpenVMS, then Advanced Server. COM can be shut down using the command:

   $ @SYS$STARTUP:DCOM$SHUTDOWN.COM

   
   Advanced Server can be shut down using the command:

   $ @SYS$STARTUP:PWRK$SHUTDOWN.COM

2. Create a snapshot of the Registry database by using the command:

   $ MCR REG$CP CREATE SNAPSHOT

3. Export the Registry database by using the command:

   $ MCR REG$CP EXPORT DATABASE [/LOG/OUTPUT=filename]

4. If you are upgrading all nodes in the cluster at the same time, make a note as to which node was acting as the master Registry server. You can determine which node was the master by issuing the command:

   $ SHOW SERVER REGISTRY/MASTER

5. Shut down the Registry server or servers. If you are upgrading all nodes in the cluster at the same time, this can be performed using the command:

   $ SET SERVER REGISTRY/CLUSTER/EXIT

   
   If you are upgrading just one node in the cluster, issue the following command on the node:

   $ SET SERVER REGISTRY/EXIT

   
   If that node was the master, wait until it exits before you take any other action. Another node in the cluster will become the master.
6. Ensure that the Registry server does not restart on the node or nodes you are upgrading until the upgrade is complete, or, if you are selectively upgrading nodes, until you determine that you wish to switch over to the new server.
   To prevent Registry startup on reboot, you need to check two things on each node:
   1. In the file SYS$MANAGER:SYLOGICALS.COM, comment out any logical name definitions that contain the string:

      "TO_BE_STARTED"

   2. Make a note of the original settings for restoring later.
   3. If your SYS$MANAGER:SYSTARTUP_VMS.COM automatically starts up Advanced Server, for example, by issuing the command:

      $ @SYS$STARTUP:PWRK$STARTUP.COM

      
      Comment out that line so that Advanced Server does not start on that node.
7. Proceed with the upgrade on each node.
8. Once all nodes have been upgraded, restart the master server by using the following command on the node that was originally running the master server:

   $ SET SERVER REGISTRY/START

   
   If you are selectively upgrading nodes, and you are ready to switch to using Registry services on the upgraded nodes, shut down the Registry server, and applications using Registry services, on all remaining OpenVMS V7.2-1 nodes in the cluster using steps 1-6 outlined above. Then you can start the Registry server on one of the upgraded nodes.
9. Verify that the Registry is operational by using the command:

   $ MCR REG$CP LIST KEY HKEY_LOCAL_MACHINE

   
   This command should display at least four subkeys of the HKEY_LOCAL_MACHINE root key. The same command should be repeated with the HKEY_USERS root key, which should display at least one subkey.

   Note In the unlikely event that the Registry is not operational, perform the following: follow the steps in the OpenVMS Connectivity Developer Guide describing how to restore your database from the snapshot files. If this fails, delete all the files in the SYS$REGISTRY directory, or rename the directory, and invoke SYS$STARTUP:REG$CONFIG to reconfigure the Registry server (see the OpenVMS Connectivity Developer Guide for details), then import the database file that was saved in step 3.

10. Start the backup Registry servers on the other upgraded nodes using the command:

    $ SET SERVER REGISTRY/START

11. Restore the values of "TO_BE_STARTED" logical name definitions in SYS$MANAGER:SYLOGICALS.COM and the invocation of Advanced Server startup in the SYS$MANAGER:SYSTARTUP_VMS.COM file.
    If you are selectively upgrading nodes, you should comment out the "TO_BE_STARTED" logical name definitions in the SYS$MANAGER:SYLOGICALS.COM file and the invocation of Advanced Server startup in the SYS$MANAGER:SYSTARTUP_VMS.COM file on any remaining OpenVMS V7.2-1 nodes in the cluster, as described in step 6.
12. Restart the Advanced Server, COM for OpenVMS and any other applications that use Registry on the upgraded nodes. If you are using Advanced Server, but not COM for OpenVMS, you will also have to start the ACME Server using the command file:

    $ @SYS$STARTUP:NTA$STARTUP_NT_ACME