[an error occurred while processing this directive]

HP OpenVMS Systems Documentation

Content starts here

HP OpenVMS Alpha Version 7.3--2 Release Notes


Previous Contents Index

1.8 SHADOW_MAX_UNIT Default Setting and Memory Usage

V7.3-2

This note updates an earlier note that discussed the default settings for this system parameter but did not describe the amount of main memory consumed by the default settings.

OpenVMS Alpha Version 7.3 introduced minicopy support in HP Volume Shadowing for OpenVMS. As part of the minicopy functionality, a new volume shadowing system parameter, SHADOW_MAX_UNIT, was introduced. On OpenVMS Alpha systems, the default value for this system parameter is 500, which consumes 24 KB of main memory. On OpenVMS VAX systems, the default value is 100, which consumes 5 KB of main memory.

If you do not plan to use Volume Shadowing for OpenVMS, you can change the setting to its minimum of 10 (which consumes 480 bytes of main memory). By setting the default to its minimum, you free up 23.5 KB of main memory on an OpenVMS Alpha system and 4.5 KB of main memory on a VAX system.

Note

SHAD_MAX_UNIT is a static system parameter. In order for a new setting to take effect, you must reboot your system.

Recommendations for SHADOW_MAX_UNIT settings for volume shadowing are discussed in the HP Volume Shadowing for OpenVMS manual.

1.9 Associated Products Affecting OpenVMS Installation and Upgrades

The remainder of this chapter concerns associated products that might affect the installation or upgrade of the OpenVMS operating system. See Chapter 2 for more associated products release notes.

1.9.1 Some Product Kits Ship in Compressed Format

V7.3-2

Starting with OpenVMS Version 7.3-2, some of the POLYCENTER Software Installation utility kits on the operating system and layered product CD-ROMs are provided in compressed format. You can identify these kits by their file types:

  • Compressed sequential kits have a .PCSI$COMPRESSED extension.
  • Uncompressed sequential kits have a .PCSI extension.

The compressed format was developed to save space on the CD-ROMs. A bonus is that user systems with a slow CD-ROM reader may experience a slightly faster installation time for compressed kits because less data must be transferred from the input device.

The installation of a compressed kit is completely transparent to the user; no qualifiers or special actions are required. The POLYCENTER Software Installation utility expands (decompresses) records on-the-fly as it installs the product, so no extra working disk space is required.

The POLYCENTER Software Installation utility supplied with OpenVMS Version 7.3-2 (and any later versions) can use compressed and uncompressed kits interchangeably. However, on versions of OpenVMS prior to 7.3-2, the compressed (.PCSI$COMPRESSED) kits cannot be read unless an appropriate POLYCENTER Software Installation utility remedial kit is installed. This remedial kit is expected to be available before the final release of OpenVMS Version 7.3-2.

Converting a Compressed Kit to an Uncompressed Kit

As an alternative to installing a POLYCENTER Software Installation utility remedial kit on an earlier system, you can easily convert a compressed kit into an uncompressed format. You can use the PRODUCT COPY command on OpenVMS Version 7.3-2 to create a standard .PCSI kit from a .PCSI$COMPRESSED kit and then transfer it to the target system for installation. Use a command similar to the following to perform the conversion:


$ PRODUCT COPY product-name /SOURCE=device:[dir] -
_$ /DESTINATION=device:[dir] /FORMAT=SEQUENTIAL

Not all kits provided on the OpenVMS Version 7.3-2 operating system and layered products CD-ROMs can be installed on prior versions of OpenVMS. Before you attempt to install a product on a prior version, consult the product's documentation to determine whether this kit installation is supported.

1.9.2 ACMS Kits: Problem with File Deletions

V7.3-1

If you have installed any of the following kits:

VMS73_ACMS-V0100
VMS722_ACMS-V0100
VMS721H1_ACMS-V0100
VMS721_ACMS-V0100

and then you upgrade to Version 7.3-1 or higher, the following ACMS files might get deleted:

ACMSTART.COM
ACMSBOOT.EXE

This will cause ACMS to fail after the upgrade. To avoid this problem (or recover from it), remove the old ACMS kit (select Option 6 "Remove installed products" on the installation CD main menu) and then install the ACMS_U1_044 kit either before or after you upgrade the operating system. This kit replaces the kits in the preceding list.

You can get the latest ACMS kit from the following web site (follow the version links to the ACMS_U1_044 kit):

http://ftp1.support.compaq.com/public/vms/axp/

1.9.3 COM for OpenVMS Upgrade in Clusters Running OpenVMS Version 7.2-1 or 7.2-1H1

V7.3-1

If you are running COM for OpenVMS in a cluster running OpenVMS Alpha Version 7.2-1 or Version 7.2-1H1, and you intend to do a rolling upgrade, see Section 1.9.10 for information about how to upgrade your cluster.

1.9.4 DECevent Version 3.1 or Higher Required for Certain Systems

V7.3-1

Analyzing Earlier Hardware Platforms

DECevent Version 3.1 or higher is required to analyze hardware error log files on certain supported, earlier hardware platforms (for example, the 1200, 8400, GS60, and GS140 platforms).

When you install or upgrade to OpenVMS Version 7.3 or higher, the DECevent DCL command DIAGNOSE is disabled. If you are installing OpenVMS on a hardware platform that needs DECevent and its DIAGNOSE command, perform the following steps:

  1. Install or upgrade to OpenVMS Version 7.3 or higher.
  2. Install the DECevent software (included in the DECevent kit on the HP System Tools CD-ROM).

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

Analyzing Later Platforms

The System Event Analyzer (SEA) is now the supported error log analysis tool for OpenVMS and for later hardware platforms (for example, the DSnn, ESnn, GS80, GS160, and GS320 platforms).

Additionally, you can use the new Error Log Viewer (ELV) utility to quickly examine an error log file that was created on these later hardware platforms. ELV is integrated into OpenVMS Version 7.3-2, and can be accessed by entering the DCL command ANALYZE/ERROR_LOG/ELV.

For more information about ELV, refer to the ELV chapter in HP OpenVMS System Management Utilities Reference Manual.

Analyzing Both Platforms

If you have both a DECevent-supported platform and SEA-supported storage devices, you will need both DECevent and the System Event Analyzer (SEA). Likewise, if you have both an SEA-supported platform and DECevent-supported storage or other devices, you will need both tools.

To install SEA, you must install the latest version of WEBES (Version 4.2 or higher). The current version of the DECevent kit is Version 3.4.

For detailed information about operating system requirements and supported hardware for DECevent, refer to the DECevent Release Notes, which are at the following web site:

http://h18023.www1.hp.com/support/svctools/decevent/

Follow the "Download the documentation" link.

For detailed information about operating system requirements and supported hardware for SEA, refer to the WEBES Installation Guide, which is with the other WEBES documentation at the following web site:

http://h18023.www1.hp.com/support/svctools/webes/

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

1.9.5 DECnet-Plus and DECwindows Require New Versions

V7.3-2

When you install or upgrade to OpenVMS Alpha Version 7.3-2, you must also install new versions of DECwindows and DECnet-Plus. One of the reasons that makes this necessary is a change of behavior in AUTOGEN (see Section 4.2).

Unlike the behavior of previous versions, DECnet-Plus for OpenVMS Version 7.3-2 now provides product information in NEWPARAMS.DAT records, as required by AUTOGEN. AUTOGEN anticipates this change in DECnet-Plus, so AUTOGEN does not print any warnings when it removes "bad" records from CLU$PARAMS.DAT; AUTOGEN presumes these records were made by an older DECnet-Plus kit and will be replaced by the new DECnet-Plus kit. So, under normal conditions, you will not see any striking differences in behavior during an OpenVMS Version 7.3-2 installation or upgrade.

However, if other products do not provide product information in NEWPARAMS.DAT records, as now required by AUTOGEN, AUTOGEN prints warning messages to both the report and the user's SYS$OUTPUT device. The warnings state that AUTOGEN cannot accept the parameter assignment found in NEWPARAMS.DAT (because no product name is attached) and that no records will be added to CLU$PARAMS.DAT. Since no records are added, the expected additions or other alterations to SYSGEN parameters will not be made, which could lead to resource exhaustion. Developers and testers of software products should be aware of this requirement; it may also be of interest to system managers.

This new behavior is intended to protect both the users and providers of layered products. By keeping this information ordered properly so that it can be updated properly, problems resulting from bad updates should be minimized.

A description of NEWPARAMS.DAT and CLU$PARAMS.DAT is included in the AUTOGEN chapter of the HP OpenVMS System Management Utilities Reference Manual.

1.9.6 DECnet-Plus Installation: PCSI-I-RETAIN Messages

V7.2

If you upgrade to OpenVMS Version 7.3 or higher 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.9.7 HP PATHWORKS and HP Advanced Server for OpenVMS Products

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

1.9.7.1 HP Advanced Server for OpenVMS

V7.3-2

Version 7.3A of Advanced Server for OpenVMS is supported on OpenVMS Alpha Version 7.3-1 and higher 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.9.7.5.

1.9.7.2 HP PATHWORKS for OpenVMS (Advanced Server)

V7.3-1

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

1.9.7.3 PATHWORKS V5 for OpenVMS (LAN Manager) Not Supported

V7.3-2

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

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

You cannot upgrade directly from PATHWORKS V5 for OpenVMS (LAN Manager) to Advanced Server V7.3x 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.9.7.4.

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

V7.3-2

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-2.
  3. At this point, you also have the option of upgrading PATHWORKS for OpenVMS (Advanced Server) to Advanced Server V7.3A for OpenVMS.

1.9.7.5 Upgrading Advanced Server Version 7.2x for OpenVMS

V7.3-2

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

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

Note

Because of changes to the OpenVMS Registry protocol, you cannot run Advanced Server for OpenVMS software on OpenVMS Alpha Version 7.2-2 (and higher) systems and on OpenVMS Alpha systems prior to Version 7.2-2 in the same cluster.

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

1.9.8 HP X.25 Version 1.6 Required Upgrade

V7.3-1

Customers with HP X.25 for OpenVMS Alpha systems software must upgrade to X.25 Version 1.6 prior to upgrading to OpenVMS 7.3-1 or higher. Failure to upgrade will result in system failures with an SPLINVIPL bugcheck when booting.

HP also recommends that you install the latest X.25 ECO kit, which is named X25ALP X25_V16ECO1 X.25 V1.6 for OpenVMS Alpha. This ECO kit contains two separate kits, one for X.25 and one for WANDD, which are named as follows:

  • DEC-AXPVMS-X25-V0106-1-1.PCSI
  • DEC-AXPVMS-WANDD-V0106-1-1.PCSI

You can access the X25_V16ECO1 kit from the following website if you are a contract customer and already have an account:


http://ftp.support.compaq.com/cgi-bin/entitlement.cgi/patches/entitled/

If you are not already a contract customer or if you do not have an account at the patch site, you can create an account at this site or contact a customer service representative to obtain the kit.

1.9.9 Kerberos V1.0: Remove Before Upgrading

V7.3-2

If you installed Kerberos Version 1.0 for OpenVMS using a POLYCENTER Software Installation kit, you must use the POLYCENTER Software Installation utility to remove Kerberos Version 1.0 before you upgrade the operating system. (You do not need to remove Kerberos if you are running Version 2.0 or if Version 1.0 was installed as part of the OpenVMS Version 7.3-1 operating system.)

To remove Kerberos, choose Option 6 "Remove installed products" from the installation CD main menu. During the removal, you are asked whether 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 in KRB$ROOT:[*...]. (KRB$ROOT is defined as a system-wide logical name when Kerberos is started.) Kerberos data is either created during configuration or moved from the old Kerberos directories and renamed. If you removed a previously installed Kerberos kit and saved the data and directories, the data will automatically be moved into the new directories and be renamed the first time the Kerberos startup procedure is run after the upgrade.

Start the Kerberos servers by entering the following command:


$ @sys$startup:krb$startup.com

Note that the Kerberos startup procedure moves and renames only known Kerberos files. Users who have created files in the old Kerberos directories must manually move those files.

For more information about installing and configuring Kerberos, refer to HP Open Source Security for OpenVMS, Volume 3: Kerberos.

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

V7.3-1

The Registry that shipped with OpenVMS Alpha Version 7.2-1 and Version 7.2-1H1 is different from and incompatible with the Registry that ships with Versions 7.2-2 and higher. If you are upgrading from an earlier version with the old Registry, you must take special steps, depending on what you want to do.

  • 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:
    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, 7.3-1, and 7.3-2 nodes in the cluster --- but not on both. Before you upgrade each node in the cluster, you must inhibit the startup of the following on the upgraded node:
    • The Registry
    • Advanced Server
    • COM for OpenVMS
    • Any other applications using the Registry

    At some point, you must 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 and higher nodes.

    Note

    If you are running Advanced Server V7.2 or V7.2A for OpenVMS on OpenVMS Version 7.2-1 or 7.2-1H1, you must upgrade all nodes to Advanced Server V7.3 for OpenVMS before you upgrade any OpenVMS Version 7.2-1 or 7.2-1H1 node to OpenVMS Version 7.3 or higher. If you are upgrading to OpenVMS Version 7.3-2, once you complete the upgrade, you must upgrade Advanced Server for OpenVMS again to V7.3A or higher.

The following steps describe the procedure you can use when upgrading from Version 7.2-1 or from 7.2-1H1 to Version 7.2-2 or higher 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 any applications specific to your environment that are known to use Registry services. Then shut down HP layered products that use Registry services. For example:
    • First shut down COM for OpenVMS using the following command:


      $ @SYS$STARTUP:DCOM$SHUTDOWN.COM
      
    • Then shut down Advanced Server using this command:


      $ @SYS$STARTUP:PWRK$SHUTDOWN.COM
      
  2. Create a snapshot of the Registry database by using the following commands:


    $ REG$CP :== $REG$CP
    $ REG$CP CREATE SNAPSHOT
    
  3. Export the Registry database by using the command:


    $ 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 is acting as the master Registry server. You can determine which node is 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 is 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, either comment out or set to FALSE any logical name definitions that contain the string:


      "TO_BE_STARTED"
      

      Make a note of the original settings for restoring later.
    2. If your SYS$MANAGER:SYSTARTUP_VMS.COM file includes commands that automatically start up layered products that use Registry services, comment those lines out of the file so that those products are not automatically started on that node. Look for lines such as the following, which starts up the Advanced Server:


      $ @SYS$STARTUP:PWRK$STARTUP.COM
      
  7. Proceed with the upgrade on each node. (For detailed upgrade information, refer to the HP OpenVMS Alpha Version 7.3--2 Upgrade and Installation Manual.)
  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 following commands:


    $ REG$CP :== $REG$CP
    $ REG$CP LIST KEY HKEY_LOCAL_MACHINE
    

    The last 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 HP 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 HP 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, comment out or set to FALSE the appropriate "TO_BE_STARTED" logical name definitions in the SYS$MANAGER:SYLOGICALS.COM file and comment out or remove any 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. In this order, restart the Advanced Server, COM for OpenVMS, and any other applications that use Registry on the upgraded nodes.


Previous Next Contents Index