If you have forgotten or do not have the password for the SYSTEM username, you must perform the conversational bootstrap as described in Section 5.6, and must enter the following commands once you have reached the dollar ($) prompt:
$ SET DEFAULT SYS$SYSTEM: ! or wherever your SYSUAF.DAT resides $ RUN SYS$SYSTEM:AUTHORIZE MODIFY SYSTEM /PASSWORD=newpassword EXIT
You have now reset the password on the SYSTEM username.
5.6.2 My product licenses have expired - what can I do?
If you have a system with no licenses for OpenVMS or for OpenVMS users and thus cannot log into the OpenVMS system normally, you should be able to log into the console serial terminal---this is the terminal device known as OPA0:---and perform the commands necessary.
For systems that are not configured with an accessable console serial terminal---as can be the case with how some DECwindows workstations are configured---you must log in over the network or from a local serial connection. If you cannot log in over a network connection (SET HOST, telnet, etc) or from another local serial terminal connection, you will have to halt the system and perform a conversational bootstrap as described in Section 5.6. You must then enter licensing-related commands once the conversational bootstrap has reached the dollar ($) prompt.
Use the following DCL command to invoke a menu that allows you to manage and to register new or replacement license PAKs:
You have now registered the license PAKs. Direct use of the DCL commands LICENSE and SHOW LICENSE and such is also obviously available.
If you wish to connect a serial console on your DECwindows workstation, please see Section 22.214.171.124, Section 14.3.6, Section 11.10, and Section 14.19.
For information on troubleshooting DECwindows, please see Section 11.5.
5.7 How do I change the node name of an OpenVMS System?
The first step is to get a BACKUP of the system disk before making any changes---use the system disk backup procedures as documented in the OpenVMS System Management Manual, making sure to use the procedures and commands appropriate for the system disk.
Changing the node name involves a number of steps---the node name tends to be imbedded in a number of different data files around the system.
There are likely a few other areas where the nodename will be stored. Local procedures and data files are one such example, and various sites will have the system name loaded in the operator control panel via the OCP_TEXT console environment variable available at the SRM prompt on some Alpha systems is another.
If the system is configured in a VMScluster and you change either the SCSNODE or the SCSSYSTEMID---but not both values---then you will have to reboot the entire VMScluster. (The VMScluster remembers the mapping between these two values, and will assume that a configuration problem has occured if a mismatched pair appears, and will refuse to let a node with a mismatched pair join the VMScluster.)
To calculate the correct SCSSYSTEMID value, multiply the DECnet Phase IV area number by 1024, and add the DECnet Phase IV node number. For example, the SCSSYSTEMID value for a DECnet node with address 19.22 is 19478. ((19 * 1024) + 22 = 19478)
This may well have missed one or two configuration tools (or more!) that are needed at your site---the node name tends to get stored all over the place, in layered products, and in local software...
Also see Section 15.6.3 and Section 15.6.4.
5.8 Why doesn't OpenVMS see the new memory I just added?
When adding memory to an OpenVMS system, one should check for an
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
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 V7.3, V7.2-2, V7.2-1H1, V7.2-1, and V7.1-2, you can upgrade to V7.3-1 or to V7.3-2. From V7.3-1, you can upgrade to V7.3-2 or to V8.2. From 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 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 VAX 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.
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
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.
Future OpenVMS I64 releases are expected to provide a traditional
PCSI-based upgrade path from specified previous releases of OpenVMS
I64, analogous to the long-standing tradition of OpenVMS Alpha upgrades.
5.10.3 OpenVMS VAX Release Upgrade Paths
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 require multiple system disks. Rolling upgrades permit the OpenVMS Cluster to remain available while individual systems are being upgraded to a new OpenVMS release.
OpenVMS Cluster rolling upgrades for both OpenVMS VAX and OpenVMS Alpha may (will) have different, or additional upgrade requirements, and have requirements around which versions of OpenVMS can coexist in a OpenVMS Cluster than what is listed here.
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. The documentation for older releases of OpenVMS VAX
includes various platform-specific manuals, manuals that include
instructions that are specific to installing and upgrading on the
5.10.5 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:
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:
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:
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.