HP OpenVMS Systems Documentation

Content starts here

The OpenVMS Frequently Asked Questions (FAQ)


Previous Contents Index

5.8 Why doesn't OpenVMS see the new memory I just added?

When adding memory to an OpenVMS system, you should check for an existing definition of the PHYSICALPAGES (OpenVMS VAX) or PHYSICAL_MEMORY (OpenVMS Alpha) parameter in the SYS$SYSTEM:MODPARAMS.DAT parameter database, use a text editor to reset the value in the file to the new correct value as required, and then perform the following command:


$ @SYS$UPDATE:AUTOGEN GETDATA REBOOT FEEDBACK

This AUTOGEN command will reset various system parameters based on recent system usage (FEEDBACK), and it will reset the value for the PHYSICALPAGES parameter to the new value. It will also reboot the OpenVMS system.

PHYSICALPAGES and PHYSICAL_MEMORY can also be used to deliberately lower the amount of memory available for use by OpenVMS. This ability can be useful in a few specific circumstances, such as testing the behaviour of an application in a system environment with a particular (lower) amount of system memory available.

PHYSICALPAGES and PHYSICAL_MEMORY can be set to -1 (on OpenVMS Alpha) or (better and simpler) the entry can be removed from the MODPARAMS.DAT file, to indicate that all available memory should be used.

5.9 How do I change the text in a user's UIC identifier?

The text translations of the numeric User Identification Code (UIC) are based on identifiers present in the OpenVMS rightslist. Documentation on this area is included in the _Guide to OpenVMS System Security_ manual.

To control the identifiers shown for a user's UIC, you use AUTHORIZE. Each user has an associated group identifier, and an identifier specific to the user. And each user should have a unique UIC.

To alter the text of a user or group identifier, use commands such as:


$ RUN SYS$SYSTEM:AUTHORIZE
UAF> rename/ident oldgroupid newgroupid
UAF> rename/ident olduserid  newuserid

If you should find yourself missing an identifier for a particular user, you can add one for the user's UIC using a command such as:


UAF> add/ident/value=uic=[group,user] newuserid

The UIC user identifier text is assigned when the username is created, and is the text of the username. The UIC group group identifier is assigned when the first username is created in the UIC group, and the text is based on the account name specified for the first user created in the group. The value of this identifier is [groupnumber, 177777]. To add a missing group identifier, use an asterisk as follows:


UAF> add/ident/value=uic=[group,*] newgroupid

You may find cases where an identifier is missing from time to time, as there are cases where the creation of a UIC group name identifier might conflict with an existing username, or a user identifier might conflict with an existing group identifier. When these conflicts arise, the AUTHORIZE utility will not create the conflicting group and/or user identifier when the username is created.

You can can add and remove user-specified identifiers, but you should avoid changing the numeric values associated with any existing identifiers. You should also avoid reusing UICs or identifiers when you add new users, as any existing identifiers that might be present on objects in the system from the old user will grant the same access to the new user. Please see the security manual for details.

5.10 What are the OpenVMS version upgrade paths?

5.10.1 OpenVMS Alpha Upgrade (or Update) Paths

Note

Upgrade path information here has occasionally been found to be wrong. Information here does not reflect cluster rolling upgrade requirements; see Section 5.10.4 for related rolling upgrade information; versions permissible for rolling upgrades can be and often are more constrained. When upgrade information here conflicts with the official documentation, please assume that the information here is wrong. Corrections and updates to this material are welcome.


From V1.0,
    you can upgrade to V1.5.
From V1.5, or V1.5-1H1,
    you can upgrade to V6.1.
From V6.1,
    you can upgrade to V6.2.
From V6.1, or V6.2,
    you can upgrade to V7.0.
From V6.1, V6.2, V6.2-1H(1,2,3), or V7.0,
    you can upgrade to V7.1.
From V6.2,
    you can update to V6.2-1H1, V6.2-1H2, or V6.2-1H3.
From V6.2, V6.2-1H(1,2,3), V7.1, V7.1-1H(1,2), or V7.2,
    to V7.2-1.
From V6.2, ... or V7.2,
    to V7.2-1H1, to 7.3.
From V7.1, you can update to V7.1-1H(1,2), ...
    to V7.2-1H1, to 7.3.
From 7.2, 7.2-1, 7.2-1H1, 7.2-2, 7.3 or 7.3-1,
    you can upgrade to V7.3-2
From V7.3, V7.2-2, V7.2-1H1, V7.2-1, and V7.1-2,
    you can upgrade to V7.3-1
From V7.3-1,
    you can upgrade to V7.3-2 or to V8.2.
From V7.3-1 or V7.3-2,
    you can upgrade to V8.2.

Some typical OpenVMS Alpha upgrade (or update) paths are:


V1.0 -> V1.5 -> V6.1 -> (V6.2, V7.0, V7.1, V7.2, V7.3)
V1.5-1H1 -> V6.1 -> (V6.2, V7.0, V7.1, V7.2, V7.3)
V6.2 -> V6.2-1H3
V6.2 -> V7.2-1
V6.2 -> V7.3
V6.2-1H(1,2,3) -> V7.1
V6.2-1H(1,2,3) -> V7.2-1
V6.2 through 7.1-1H2 inclusive -> V7.3
V7.1 -> V7.1-2
V7.1 -> V7.2-1
V7.1-1H(1,2) -> V7.1-2
V7.1-1H(1,2) -> V7.2-1
V7.1-2 -> V7.3-1
V7.2 -> V7.2-1H1
V7.2 -> V7.3 -> V7.3-1
V7.2-1 -> (V7.3, V7.3-1)
V7.2-2 -> (V7.3, V7.3-1, V7.3-2)
V7.3 -> (V7.3-1, V7.3-2)
V7.3-1 -> (V7.3-2, V8.2)
V7.3-2 -> V8.2

Note that OpenVMS Alpha V7.0 does not include support for hardware and/or configurations first supported in OpenVMS Alpha V6.2-1H1, V6.2-1H2, or V6.2-1H3; one must upgrade to OpenVMS Alpha V7.1, or later.

One cannot update directly to a V6.2-1Hx Limited Hardware Release (LHR) from any release prior to the baseline V6.2 release. The same prohibition holds for performing updates directly to V7.1-1Hx from any release prior to V7.1---this is not supported, and does not produce the expected results. The LHR kits can, however, be directly booted and can be directly installed, without regard to any operating system that might be present on the target disk.

Users of OpenVMS Alpha V7.1-1H1, V7.1-1H2, V7.2-1H1 or other hardware are encouraged to upgrade to the next available non-hardware-release, and should preferably upgrade to the current or to a supported OpenVMS Alpha release.

OpenVMS Alpha updates for LHRs (through V7.1-1Hx) require the use of VMSINSTAL for the update. These LHR releases use PCSI for the installation, but not for the update. Non-LHR releases use PCSI for installs and upgrades.

OpenVMS Alpha V7.1-2 and later use PCSI for LHRs and for OpenVMS upgrades and for all OpenVMS ECO kit installations; V7.1-2 and later use upgrades and not updates. VMSINSTAL OpenVMS ECO kits (updates) are not used on OpenVMS Alpha V7.1-2 and later; prior to V7.1-2, VMSINSTAL-based ECO (update) kits are used for OpenVMS.

5.10.2 OpenVMS I64 Upgrade Paths

Note

Upgrade path information here has occasionally been found to be wrong. Information here does not reflect cluster rolling upgrade requirements; see Section 5.10.4 for related rolling upgrade information; versions permissible for rolling upgrades can be and often are more constrained. When upgrade information here conflicts with the official documentation, please assume that the information here is wrong. Corrections and updates to this material are welcome.


From V8.2
    you can upgrade to V8.2-1

Some typical OpenVMS I64 upgrade (or update) paths are:


V8.2 -> V8.2-1

OpenVMS I64 V8.2 is the first production release. OpenVMS I64 V8.0 and V8.1 were intended for early adopters of OpenVMS on Integrity servers, and are not considered to be production releases.

To utilize OpenVMS I64 V8.2, you must perform a full installation of V8.2. No supported upgrade path to V8.2 is available from previous releases; there is no upgrade from OpenVMS I64 E8.2, nor from the earlier V8.1 or V8.0 releases.

5.10.3 OpenVMS VAX Release Upgrade Paths

Note

Upgrade path information here has occasionally been found to be wrong. Information here does not reflect cluster rolling upgrade requirements; see Section 5.10.4 for related rolling upgrade information; versions permissible for rolling upgrades can be and often are more constrained. When upgrade information here conflicts with the official documentation, please assume that the information here is wrong. Corrections and updates to this material are welcome.


From V5.0 through V5.4-3 inclusive, one can upgrade to V5.5.
From V5.5, V5.5-1, or V5.5-2HW, one can upgrade to V5.5-2.
From V5.5, V5.5-1, or V5.5-2, one can upgrade to V6.0.
From V5.5-2, V5.5-2H4, or V6.0, one can upgrade to V6.1.
From V6.0, or V6.1, one can upgrade to V6.2.
From V6.1, or V6.2, one can upgrade to V7.0.
From V6.1, V6.2, or V7.0, one can upgrade to V7.1.
From V6.1, one can upgrade to V7.3 (with VAXBACK ECO for V6.1).

Some typical OpenVMS VAX upgrade paths are:


V5.x -> V5.5 -> V6.0 -> V6.2 -> (V7.1, V7.2, V7.3)
V5.5-2HW -> V5.5-2
V5.5-2, or V5.5-2H4 -> V6.1 -> (V6.2, V7.0, or V7.1)
V6.1 -> V6.1 with VAXBACK ECO -> (V7.2, V7.3)
V6.2 -> V7.2
V6.2 -> V7.3

Note that OpenVMS VAX V6.0 does not include support for hardware and/or configurations first added in OpenVMS VAX V5.5-2H4, one must upgrade to OpenVMS VAX V6.1.

Note that OpenVMS VAX V5.5-2HW is a pre-release version of V5.5-2. Any system running it should be upgraded to V5.5-2, or later.

If you attempt a direct upgrade from OpenVMS VAX V6.1 to V7.2 or later without having first applied the VAXBACK ECO kit to your V6.1 system, you will receive an error message:


%BACKUP-E-INVRECTYP, invalid record type in save set

and the upgrade will fail. Acquire and apply the VAXBACK ECO kit for OpenVMS VAX V6.1. OpenVMS VAX V6.2 and later do not require an application of an ECO for an upgrade to V7.2 and later.

5.10.4 OpenVMS Cluster Rolling Upgrade Paths

Rolling Upgrades permit the OpenVMS Cluster and the applications to remain available while individual systems are being upgraded to a new OpenVMS release.

Rolling Upgrades require multiple system disks.

OpenVMS Cluster Rolling Upgrades for OpenVMS Alpha, OpenVMS I64 and OpenVMS VAX may (will) have architecture-specific, or additional upgrade requirements or prerequisites, and have requirements around which versions and architectures of OpenVMS can coexist within a OpenVMS Cluster than what are listed here.

For specific details on Rolling Upgrades, please see the OpenVMS Upgrade and Installation Manual for the particular release, and the OpenVMS Software Product Descriptions for OpenVMS and for OpenVMS Cluster software:

for further details on the Rolling Upgrade, and for support information.

5.10.5 OpenVMS VAX Manual Organization

The documentation for older releases of OpenVMS VAX was comprised of various platform-specific manuals, manuals that include instructions that are specific to installing and upgrading on the particular VAX platform. These older manuals can be useful for learning platform- or console-specific operations or requirements for the particular (and older) VAX platform.

There is far less console command syntax, and console storage media variability, among the more recent Alpha and Integrity processors. The newer platform operator and management interfaces are far more consistent across the platform lines.

5.10.6 OpenVMS Product Version and Support Information

For information on Prior Version Support (PVS) and Mature Product Support (including information on support end dates for OpenVMS and various layered products), please see the support resources link available at the main OpenVMS website or the services links available at the main services website:

And see the following links, with the caveat that the direct "/hps" links shown here may become stale:

For information on the supported and required versions of layered products, and the minimum required layered product versions for various configurations, please see the Software Rollout Report (SWROLL), available at:

For additional related information, see Section 2.6.1.

For information on the release history of OpenVMS, including information on the code names of various releases and the major features:

Additional release history information, as well as a variety of other trivia, is available in the VAX 20th anniversary book:

5.10.7 OpenVMS Alpha and I64 Upgrade Terminology

OpenVMS Alpha and OpenVMS I64 use the POLYCENTER Software Product Install Utility, occasionly refered to as SPIU and rather more commonly known as PCSI. PCSI is a component of the OpenVMS operating system, and is available on OpenVMS VAX, OpenVMS Alpha, and OpenVMS I64.

The following terms apply to OpenVMS Alpha and to OpenVMS I64 Upgrades and Installations using PCSI:

  • UPDATE: Typically used for Limited Hardware Releases (LHR) releases. Performed via VMSINSTAL. Applies only to the OpenVMS release that the LHR is based on, or to an intermediate LHR. (eg: V7.1-1H2 applies only to V7.1-1H1 and to V7.1, not to any other releases.) LHRs within a series are cumulative, containing all files and features of previous LHRs in the same series.
    VMSINSTAL-based Updates and VMSINSTAL-based ECO kits are not generally used to upgrade OpenVMS on releases of OpenVMS Alpha V7.1-2 and later, nor are thse used on OpenVMS I64; only PCSI-based Upgrades and Installs are used. VMSINSTAL remains available for other uses and other products; for upgrades and installations of products other than OpenVMS itself.
  • UPGRADE: Performed via PCSI. Upgrades can typically be applied directly to a release-specific range of earlier OpenVMS releases. The product release documentation specifies the prior OpenVMS releases; if your release is not one of the specified releases, you will have to perform one or more additional upgrades (through intermediate OpenVMS releases) to reach one of the prerequisite releases.
  • INSTALL: Performed via PCSI. With an installation, no existing version of the operating system is assumed present, nor are any files from any copy of the operating system might be present preserved, and the entire contents of the target disk are destroyed via a disk initialization.
  • PRESERVE: Performed via PCSI. Otherwise similar to an installation, this option skips the disk reinitialization. User files on the target disk are preserved. Any existing operating system files on the target disk are clobbered.
  • LHR: Limited Hardware Release. LHRs are specific to and are targeted at new hardware configurations, and are not shipped to customers with support contracts. At least one LHR kit must be specifically acquired when purchasing new hardware, new hardware that is not (yet) supported by any mainline (non-LHR) release. LHRs have an "H" in the OpenVMS version string, indicating a "Hardware" release.
    You will not generally want to continue using an LHR once a subsequent OpenVMS release is available; you will want to upgrade off the LHR at your earliest convenience.

For minimum OpenVMS versions for various platforms, see Section 2.12.

5.11 Why do I have a negative number in the pagefile reservable pages?

Seeing a negative number in the reservable pages portion of the SHOW MEMORY/FULL command can be normal and expected, and is (even) documented behaviour. A pagefile with a negative number of reservable pages is overcommitted, which is generally goodness assuming that every process with reserved pages does not try to occupy all of the reserved pagefile space at the same time.

To understand how the pagefile reservation process works, think about how a traditional bank operates when accepting customer deposits and making loans. It's the same idea with the pagefile space. There is less money in the bank vault than the total deposits, because much of the money has been loaned out to other customers of the bank. And the behaviour parallels that of the pagefile down to the problems that a "run on the bank" can cause for banking customers. (Though there is no deposit insurance available for pagefile users.)

If all of the running applications try to use the reserved space, the system manager will need to enlarge the pagefile or add one or more additional pagefules.

To determine if the pagefile is excessively overcommitted, watch for "double overcommitment"---when the reservable space approaches the negatation of the available total space---and watch that the total amount of free space available in the pagefile remains adequate. If either of these situations arises, additional pagefile storage is required.

Additional pagefile information: Additional pagefiles can typically be created and connected on a running OpenVMS system. New processes and new applications will tend to use the new pagefile, and existing applications can be restarted to migrate out of the more congested pagefiles. Pagefiles are generally named PAGEFILE.SYS, and multiple pagefiles are generally configured on separate disk spindles to spread the paging I/O load across the available disk storage. When multiple pagefiles are present on recent OpenVMS versions, each pagefile file should be configured to be approximately the same total size as the other pagefiles.

For additional information on pagefile operations and related commands, see the system management and performance management manuals in the OpenVMS documentation set.

With OpenVMS V7.3 and later, the displays have been changed and these negative values are no longer visible.

5.12 Do I have to update layered products when updating OpenVMS?

The Software Public Rollout Reports for OpenVMS list the current and future availability of HP software products shipping on the OpenVMS Software Products Library kits (CDROM consolidations) for OpenVMS Alpha and/or OpenVMS VAX. Specifically, the required minimum versions for product support are listed.

Comprehensive Public Rollout Information, listing previous product versions as well as currently shipping versions, has been compiled into a separate set of reports. The product information is grouped to show Operating System support.

You may or may not be able to use older versions of local applications, third-party products, and various HP OpenVMS layered products with more recent versions of OpenVMS. User-mode code is expected to be upward compatible. Code executing in a privileged processor mode---typically either executive or kernel mode---may or may not be compatible with more recent OpenVMS versions.

These Software Rollout (SWROLL) Reports are updated regularly. Please see:

For related information, see Section 2.6.1.

5.13 How do I change the volume label of a disk?

Dismount the disk, and mount it privately. If the disk is mounted by more than one node in an OpenVMS Cluster, dismount it from all other nodes. If this disk is an OpenVMS system disk, shut down all other nodes that are bootstrapped from this disk.

Issue the SET VOLUME/LABEL command, specifying the new label.

On OpenVMS V6.0 and later, issue the following PCSI command to reset the label information stored within the PCSI database to reflect the new disk volume label:


$ PRODUCT REGISTER VOLUME old-label device

Locate any references in the system startup (typically including the disk MOUNT commands) and any DISK$label references in application files, and change the references appropriately.

If this is a system disk (for the host or for a satellite), also check the DECnet MOP or LANCP boot database, as well as any references to the disk created by CLUSTER_CONFIG*.COM.

If Compaq Analyze is in use, check the system startup procedures for the Compaq Analyze tool. Certain versions of Compaq Analyze will record specific disk volume labels within the startup procedures.

Remount the disk appropriately.

5.14 How can I set up a shared directory?

To set up a shared directory---where all files created in the directory are accessible to the members of specified group of users---you can use an access control list (ACL) and an identifier.

The following also shows how to set up a resource identifier, which further allows the disk resources to be charged to the specified identifier rather than each individual user. (If you don't want this, then omit the attributes option on the identifier creation and omit the entry added in the disk quota database.

Add an identifier using the AUTHORIZE utility:


ADD/IDENTIFER/ATTRIBUTES=RESOURCE groupidentifier

Grant the identifier to each user in the group using AUTHORIZE:


GRANT/IDENTIFIER groupidentifier username

If disk quotas are in use, add an entry via SYSMAN for each disk:


DISKQUOTA ADD groupidentifier -
  /PERMQUOTA=pq/OVERDRAFT=od/DEVICE=ddcu:

Set the shared directory to have an ACL similar to the following using the SET SECURITY (V6.0 and later) or SET ACL (versions prior to V6.0) command:


(DEFAULT_PROTECTION,S:RWED,O:RWED,G,W)
(IDENTIFIER=groupidentifier,OPTIONS=DEFAULT,-
  ACCESS=READ+WRITE+EXECUTE+DELETE)
(IDENTIFIER=groupidentifier, -
  ACCESS=READ+WRITE+EXECUTE+DELETE)
(CREATOR,ACCESS=READ+WRITE+ACCESS+DELETE)

If there are files already resident in the directory, set their protections similarly. (The OPTIONS=DEFAULT, DEFAULT_PROTECTION, and CREATOR ACEs apply to directories.)

The default protection mask is used to establish the default file protection mask, this mask does not prevent the users holding the specified groupidentifier from accessing the file(s), as they can access the file via the explicit identifier granting access that is present in the ACL.

For further information, see the OpenVMS Guide to System Security Manual, specifically the sections on ACLs and identifiers, and resource identifiers.


Previous Next Contents Index