Document revision date: 31 July 2002

V7.2

If you upgrade to OpenVMS Version 7.3-1 or 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.

1.8 Daylight Savings Time Error Message In Minimum Startup Boot

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

1.9 Registry Upgrade from OpenVMS Version 7.2-1 or 7.2-1H1

V7.3-1

The Registry shipped with OpenVMS Alpha Version 7.2-1 and Version 7.2-1H1 is different and incompatible with the Registry shipped with Versions 7.2-2, 7.3, and 7.3-1. If you are upgrading from an earlier version with the old Registry, you must take the following special steps:

If you choose to upgrade all Alpha nodes in the cluster at once, shut down 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 Version 7.2-1 and 7.2-1H1 nodes in the cluster, or on only the Version 7.2-2, 7.3, and Version 7.3-1 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 for OpenVMS
• Any other applications using Registry

At some point, you will have to shut down all remaining Registry-based activity in the cluster just before you start up Registry and applications using Registry services on the Version 7.2-2, 7.3 or 7.3-1 nodes.

The following steps describe the procedure you can use when upgrading from Version 7.2-1 OR 7.2-1H1 to Version 7.2-2, 7.3, or 7.3-1 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 Version 7.2-1 and 7.2-1H1 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, follow the steps in the COM, Registry, and Events for OpenVMS Developer's 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 (refer to the COM, Registry, and Events for OpenVMS Developer's 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 Version 7.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.

V7.3-1

The CONFIGURE process is one phase of the system startup procedure controlled by SYS$SYSTEM:STARTUP.COM. For OpenVMS Version 7.3, the QIO$CONFIGURE process replaced the CONFIGURE process. However, as of OpenVMS Version 7.3-1, QIO$CONFIGURE (along with the other software specific to QIOserver) is no longer supported. The CONFIGURE process (from versions prior to Version 7.3) is once again in effect. If you have included the QIO$CONFIGURE process in a command procedure, you must change its name to CONFIGURE.

There is a Version 7.3 remedial kit that has the CONFIGURE process (replacing QIO$CONFIGURE). This kit is VMS73_CLUSTER-V0200.

For more information about SYS$SYSTEM:STARTUP.COM and the role of the CONFIGURE process in system startup, refer to the OpenVMS System Manager's Manual.

1.11 Removing Kerberos V1.0 Before Upgrading

V7.3-1

If you have Kerberos Version 1.0 for OpenVMS Alpha installed, you must use the PCSI utility to remove it before you upgrade the operating system.

To remove Kerberos, select "Remove installed products" at the main menu. During the removal, you are asked if you want to remove the data and directories. (Data refers to the configuration data files along with the principal database, if one was created.) If you want to save this information for use later, respond "No" to the question. Return to the main menu and perform the upgrade of OpenVMS.

After the upgrade, the new Kerberos directories are located under SYSEXE in KERBEROS.DIR. New Kerberos data is either created during configuration or copied from the old Kerberos directories. If you removed a previously installed Kerberos PCSI kit and saved the data and directories, you can copy that data into the new directories. To do this, enter the following commands from the SYSTEM account:

$ @sys$manager:krb$logicals.com $ rename/log sys$common:[sysexe.etc]*.* krb$root:[etc]*.*; $ rename/log sys$common:[sysexe.bin]*.dat krb$root:[bin]*.*; $ rename/log sys$common:[sysexe.krb5kdc]*.* krb$root:[krb5kdc]*.*;

To optionally save the log files, enter the following:

$ rename/log sys$common:[sysexe.log]*.* krb$root:[log]*.*;

Start the Kerberos servers by entering the following command:

$ @sys$startup:krb$startup.com

1.12 Tuning BAP System Parameters

V7.3-1

OpenVMS Alpha Version 7.1 and higher contains system parameters that control the operation of bus-addressable pool (BAP). If one or more of your system adapters uses BAP, the BAP system parameters must be adjusted after installing or upgrading the operating system. No user action is required because AUTOGEN automatically sets these parameters correctly as part of the installation or upgrade.

If you change logical partition parameters (Alpha console environment variables beginning with lp) or boot in one logical partition from a system disk that was configured in a different logical partition, you must take explicit action to adjust BAP system parameters. Refer to the OpenVMS System Manager's Manual for details on setting the BAP parameters.

The remainder of this chapter concerns associated (layered) products that might affect the installation of the OpenVMS operating system.

1.14 Installing DECwindows and Insufficient Global Sections

V7.3

Compaq DECwindows does not calculate sufficient global sections to start up if you install it together with certain associated (layered) products. Therefore, 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]?

Type NO, because a manual adjustment is needed. (Some system 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 log in and adjust the system 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

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

   $ @SYS$MANAGER:DECW$GETPARAMS.COM

6. Run AUTOGEN again.

   $ @SYS$UPDATE:AUTOGEN GENPARAMS REBOOT NOFEEDBACK

V7.3-1

These notes pertain to PATHWORKS and Advanced Server for OpenVMS products, and include information about installing or upgrading OpenVMS systems running these products.

1.15.1 Compaq Advanced Server for OpenVMS

Version 7.3 of Compaq Advanced Server for OpenVMS is supported on OpenVMS Alpha Version 7.3-1 systems. Advanced Server Versions 7.2 and 7.2A for OpenVMS servers must be upgraded. For more information about upgrading Advanced Server for OpenVMS servers, see Section 1.15.6.

1.15.2 Compaq PATHWORKS for OpenVMS (Advanced Server)

Version 6.1 of Compaq PATHWORKS for OpenVMS (Advanced Server) is supported on OpenVMS Alpha Version 7.3-1 systems. Earlier versions of PATHWORKS for OpenVMS servers must be upgraded. For more information about upgrading earlier versions of PATHWORKS, see Section 1.15.5.

1.15.3 PATHWORKS V5 for OpenVMS (LAN Manager) Not Supported

PATHWORKS V5 for OpenVMS (LAN Manager) is not supported on OpenVMS Version 7.3-1.

If you are running PATHWORKS V5 for OpenVMS (LAN Manager) and you want to offer file and print services after you install OpenVMS Version 7.3-1, you must upgrade the file and print server to PATHWORKS V6.1 for OpenVMS (Advanced Server) before you install OpenVMS Version 7.3-1.

You cannot upgrade directly from PATHWORKS V5 for OpenVMS (LAN Manager) to Advanced Server V7.3 for OpenVMS. For information about upgrading from PATHWORKS V5 for OpenVMS (LAN Manager) to PATHWORKS V6.x for OpenVMS (Advanced Server), refer to the PATHWORKS for OpenVMS (Advanced Server) Server Installation and Configuration Guide provided with the kit documentation. For information about upgrading earlier versions of PATHWORKS for OpenVMS (Advanced Server) to PATHWORKS V6.1 for OpenVMS (Advanced Server), see Section 1.15.5.

1.15.4 Upgrading Systems Running PATHWORKS Version 6.x or Advanced Server Version 7.2x for OpenVMS

Version 6.1 of PATHWORKS for OpenVMS (Advanced Server) and Version 7.3 of Advanced Server for OpenVMS ship with OpenVMS Version 7.3-1 and provide file and print services for the OpenVMS system.

PATHWORKS servers earlier than Version 6.1 and Advanced Server for OpenVMS servers earlier than Version 7.3 are not supported on OpenVMS Version 7.3-1. If you want to run OpenVMS Version 7.3-1, you must first upgrade PATHWORKS and Advanced Server for OpenVMS servers to the appropriate versions.

For more details about upgrading PATHWORKS Version 6.x and Advanced Server Version 7.2x servers, see Section 1.15.5 and Section 1.15.6, respectively.

1.15.5 Upgrading Systems with Pre-V6.1 PATHWORKS Advanced Server

V7.3

If you are upgrading an OpenVMS system that is currently running a version of PATHWORKS for OpenVMS (Advanced Server) that is earlier than Version 6.1, follow these steps:

1. Upgrade your PATHWORKS for OpenVMS (Advanced Server) to Version 6.1.
2. Upgrade your OpenVMS system to OpenVMS Version 7.3-1.
3. At this point, you also have the option of upgrading PATHWORKS for OpenVMS (Advanced Server) to Advanced Server V7.3 for OpenVMS.

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

For more information about upgrading systems in mixed-version clusters, see Section 1.9.

1.16 Compaq SDK v 1.2.2-1 Incompatible with OpenVMS Version 7.3 or Higher

V7.3-1

The Compaq Software Development Kit (SDK) for the OpenVMS Operating System, for the Java^tm Platform, v 1.3.1-3, is the current version, and is included on the Compaq OpenVMS e-Business Infrastructure Package Version 1.3 CD-ROM.

Because of contractual agreements with Adobe Systems Incorporated, Compaq has removed the Display PostScript files and libraries from the Compaq DECwindows Motif for OpenVMS V1.2-6 software. Consequently, OpenVMS Alpha Version 7.3 or higher does not include the files necessary to run a Java^tm application with a GUI using the SDK v 1.2.2-1.

The restriction applies only to the SDK v 1.2.2-1 release. The Java Development Kit (JDK) version 1.1 as well as all SDK releases subsequent to v 1.2.2-1 are not dependent on the Adobe Display PostScript software or its libraries.

	privacy and legal statement
6652PRO_001.HTML