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:

$ @SYS$UPDATE:VMSLICENSE

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 14.3.3.3, 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.

• Update the SCSNODE in MODPARAMS.DAT, and then run AUTOGEN as far as the SETPARAMS phase. (Do not reboot yet.)
• Modify the DECnet node name. (NETCONFIG is the DECnet Phase IV tool, and NET$CONFIGURE is the DECnet-Plus tool.)
• Modify the host node name on the various queues in the queue database. (each queue has a host name, and it defaults to the SCS node name of the queue's host system. See the command INIT/QUEUE/ON=node for information.) Site-specific startup command procedures can explicitly specify the node on the /ON parameter in an INIT/QUEUE/START/ON= command.
• Modify the node name saved in any application databases, or any local node-conditional operations present in the site-specific system startup, etc. (SEARCH for the node name, specifying all types of files.)
• Use the AUTHORIZE utility command RENAME/IDENTIFIER to rename the SYS$NODE_oldnodename rightslist identifier to match the new node name. (Do not change the binary value of this identifier, and do not delete the identifier.)
  If you have erroneously deleted or duplicate the identifier, you can locate existing references to the binary identifier value using the Freeware DFU package, and specifically the commands SEARCH/ACE and /OWNER. You must (re)create the correctly-named identifier using the binary value that is often stored in various Access Control List Entry (ACE) structures and object owner fields associated with files and objects present in the OpenVMS system.
• Reset any license PAKs that are restricted to the old node name to the new node name.
• If the node name is part of a disk volume label, see Section 5.13.
• Reboot the node or---if in a VMScluster---reboot the whole VMScluster. (This tends to catch any errors immediately.)
• Modify the IP node name. (The TCP/IP Services tool is UCX$CONFIG prior to V5.0, and is TCPIP$CONFIG in V5.0 and later releases.) Note that TCP/IP Services ties the IP host name to the current SCSNODE value within its database. Thus if SCSNODE is changed, the IP host name reconfiguration must occur only after a system reboot. Accordingly, it is best to perform the TCP/IP Services host name reconfiguration step after the reboot.

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?

$ @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?

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:

• http://h18000.www1.hp.com/info/spd/
  OpenVMS typically uses SPD 25.01.xx, SPD 41.87.xx, and SPD 82.35.xx.

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

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:

• http://www.hp.com/hps/os/os_pvs.html
• http://www.hp.com/hps/os/os_ovms.html
• http://www.hp.com/go/openvms/

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:

• http://h71000.www7.hp.com/openvms/os/swroll/

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:

• http://www.openvms.compaq.com/openvms/os/openvms-release-history.html

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

• http://www.openvms.compaq.com/openvms/20th/vmsbook.pdf

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:

• http://h71000.www7.hp.com/openvms/os/swroll/

For related information, see Section 2.6.1.