|
HP OpenVMS Systems Documentation |
|
The OpenVMS Frequently Asked Questions (FAQ)
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:
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.
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:
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:
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:
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.
Some typical OpenVMS Alpha upgrade (or update) paths are:
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.
Some typical OpenVMS I64 upgrade (or update) paths are:
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.
Some typical OpenVMS VAX upgrade paths are:
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:
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.
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.
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.
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 TerminologyOpenVMS 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.
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.
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.
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:
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.
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:
Grant the identifier to each user in the group using AUTHORIZE:
If disk quotas are in use, add an entry via SYSMAN for each disk:
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:
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.
|