Document revision date: 9 May 2001

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 Registry Considerations When Upgrading From OpenVMS V7.2-1 to OpenVMS V7.3

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

V7.3

The CONFIGURE process is one phase of the system startup procedure, which is controlled by SYS$SYSTEM:STARTUP.COM. Starting with OpenVMS Version 7.3, the QIO$CONFIGURE process replaces the CONFIGURE process. The QIO$CONFIGURE process contains the CONFIGURE process and other software specific to QIOserver. If you have included the CONFIGURE process in a command procedure, you must change its name to QIO$CONFIGURE.

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

2.2.3 Java^tm 2 SDK v 1.2.2-1 Is Incompatible with OpenVMS Version 7.3

V7.3

Due to 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 does not include the files necessary to run a Java application with a GUI using the Java Software Development Kit (J2SDK) v 1.2.2-1.

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

Note that the Java 2 SDK v 1.2.2-3 is included on the Compaq OpenVMS e-Business Infrastructure Package Version 1.1 CD-ROM.

2.2.4 Error When Upgrading Compaq TCP/IP Services for OpenVMS

V7.2

When upgrading a version of Compaq TCP/IP Services for OpenVMS Alpha that is earlier than Version 5.0, you may encounter the following error:

%PCSI-I-PRCOUTPUT, output from subprocess follows ... %LIBRAR-E-LOOKUPERR, error looking up UCX in $4$DKA300:[SYS0.SYSCOMMON.][SYSHLP]SDA.HLB;1 -LBR-E-KEYNOTFND, key not found %PCSI-E-EXERMVFAIL, product supplied EXECUTE REMOVE procedure failed %PCSI-E-OPFAILED, operation failed Terminating is strongly recommended. Do you want to terminate? [YES]

This error can occur either when you are upgrading Compaq TCP/IP Services as part of an OpenVMS upgrade, or during a separate TCP/IP Services upgrade. When the old version of TCP/IP Services is removed, it attempts to remove the module UCX from the SDA Help library. However, if OpenVMS has been upgraded since TCP/IP Services was installed, the SDA Help library has been replaced by a new library and the UCX module that TCP/IP Services inserted into the old SDA Help library is not found.

This problem can also occur if you attempt to remove Compaq TCP/IP Services for OpenVMS.

The workaround to upgrade or remove Compaq TCP/IP Services is to answer "NO" to the question "Do you want to terminate?" A NO response allows the operation to complete.

V7.3

If you are performing a rolling upgrade from Version 7.1 (or a Version 7.1 variant) to Version 7.2 (or a Version 7.2 variant), or to Version 7.3, and are using MEMORY CHANNEL adapters (CCMAA-xx), see Section 5.9.11 for special instructions before you upgrade.

2.2.6 Using the Extended File Cache (XFC) in Mixed Version OpenVMS Cluster Systems

V7.3

If you have an OpenVMS Cluster system that contains earlier versions of OpenVMS Alpha or OpenVMS VAX and you want to use XFC with OpenVMS Version 7.3, see Table 5-1 for a list of remedial kits you must install on the systems that are running the earlier versions of OpenVMS.

2.2.7 X.25 Version 1.2 and Earlier Not Supported

V7.3

X.25 Version 1.2 and earlier will not operate on OpenVMS Version 7.3.

If you are planning to upgrade to OpenVMS Version 7.3, make sure you remove X.25 Version 1.2 or earlier before you initiate the upgrade. Compaq recommends that you install X.25 Version 1.5.

2.3 Installation and Upgrade Information Specific to VAX

The release notes in this section pertain only to installations or upgrades of OpenVMS VAX 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 VAX Version 7.3, refer to the OpenVMS VAX Version 7.3 Upgrade and Installation Manual.

2.3.1 Magnetic Tape Media for OpenVMS VAX to Be Retired

V7.3

OpenVMS VAX Version 7.3 is the last OpenVMS release for which TK50 and magnetic tape media will be distributed. All future OpenVMS VAX releases will be available on CD-ROM media only. For more information, see Appendix A.

2.3.2 Error at Shutdown After Booting CD-ROM for Full Environment Installation

V7.2

When you select to shut down the system (option 2) after booting a CD-ROM during a full OpenVMS VAX environment installation, you may encounter a problem on certain CPU types. However, these problems do not adversely affect the installation. The problems affect the following CPU types:

• VAXstation 4000-96
  After completing the shutdown on a VAXstation 4000-96, the keyboard no longer responds. To recover, power down your CPU, then power it back up.
• VAX 3100 or a VAX 3100-M48
  On either a VAX 3100 or a VAX 3100-M48, the system may crash with a fatal bugcheck. To continue the installation, boot the new system disk.

	privacy and legal statement
6637PRO_001.HTML