| Previous | \Contents | ^Index |
A If you have forgotten or do not have the password for the SYSTEM H username, you must perform the conversational bootstrap as described in e Section 5.6, and must enter the following commands once you have reached the dollar ($) prompt:
|
" A $ SET DEFAULT SYS$SYSTEM: ! or wherever your SYSUAF.DAT resides $ RUN SYS$SYSTEM:AUTHORIZE $ MODIFY SYSTEM /PASSWORD=newpassword EXIT |
7 You have now reset the password on the SYSTEM username. U 5.6.2 My product licenses have expired - what can I do?
G If you have a system with no licenses for OpenVMS or for OpenVMS users D and thus cannot log into the OpenVMS system normally, you should be D able to log into the console serial terminal---this is the terminal ; device known as OPA0:---and perform the commands necessary.
F For systems that are not configured with an accessable console serial H terminal---as can be the case with how some DECwindows workstations are E configured---you must log in over the network or from a local serial F connection. If you cannot log in over a network connection (SET HOST, H telnet, etc) or from another local serial terminal connection, you will B have to halt the system and perform a conversational bootstrap as d described in Section 5.6. You must then enter licensing-related F commands once the conversational bootstrap has reached the dollar ($) prompt.
B Use the following DCL command to invoke a menu that allows you to 7 manage and to register new or replacement license PAKs:
|
" $ @SYS$UPDATE:VMSLICENSE |
@ You have now registered the license PAKs. Direct use of the DCL G commands LICENSE and SHOW LICENSE and such is also obviously available.
H 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.
k For information on troubleshooting DECwindows, please see Section 11.5. n 5.7 How do I change the node name of an OpenVMS System?
G The first step is to get a BACKUP of the system disk before making any E changes---use the system disk backup procedures as documented in the H OpenVMS System Management Manual, making sure to use the procedures and ) commands appropriate for the system disk.
H Changing the node name involves a number of steps---the node name tends E to be imbedded in a number of different data files around the system.
F There are likely a few other areas where the nodename will be stored. H Local procedures and data files are one such example, and various sites G will have the system name loaded in the operator control panel via the E 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 G either the SCSNODE or the SCSSYSTEMID---but not both values---then you E will have to reboot the entire VMScluster. (The VMScluster remembers = the mapping between these two values, and will assume that a D configuration problem has occured if a mismatched pair appears, and F will refuse to let a node with a mismatched pair join the VMScluster.)
E To calculate the correct SCSSYSTEMID value, multiply the DECnet Phase E IV area number by 1024, and add the DECnet Phase IV node number. For G example, the SCSSYSTEMID value for a DECnet node with address 19.22 is ! 19478. ((19 * 1024) + 22 = 19478)
D This may well have missed one or two configuration tools (or more!) E that are needed at your site---the node name tends to get stored all = over the place, in layered products, and in local software...
u Also see Section 15.6.3 and Section 15.6.4. p 5.8 Why doesn't OpenVMS see the new memory I just added?
A When adding memory to an OpenVMS system, one should check for an existing A definition of the PHYSICALPAGES (OpenVMS VAX) or PHYSICAL_MEMORY D (OpenVMS Alpha) parameter in the SYS$SYSTEM:MODPARAMS.DAT parameter F database, use a text editor to reset the value in the file to the new B correct value as required, and then perform the following command:
|
" . $ @SYS$UPDATE:AUTOGEN GETDATA REBOOT FEEDBACK |
C This AUTOGEN command will reset various system parameters based on D recent system usage (FEEDBACK), and it will reset the value for the B PHYSICALPAGES parameter to the new value. It will also reboot the OpenVMS system.
C PHYSICALPAGES and PHYSICAL_MEMORY can also be used to deliberately F lower the amount of memory available for use by OpenVMS. This ability C can be useful in a few specific circumstances, such as testing the F behaviour of an application in a system environment with a particular * (lower) amount of system memory available.
F PHYSICALPAGES and PHYSICAL_MEMORY can be set to -1 (on OpenVMS Alpha) H or (better and simpler) the entry can be removed from the MODPARAMS.DAT ; file, to indicate that all available memory should be used. p 5.9 How do I change the text in a user's UIC identifier?
H The text translations of the numeric User Identification Code (UIC) are F based on identifiers present in the OpenVMS rightslist. Documentation C on this area is included in the _Guide to OpenVMS System Security_ manual.
F 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.
F 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 |
C If you should find yourself missing an identifier for a particular A user, you can add one for the user's UIC using a command such as:
|
" 3 UAF> add/ident/value=uic=[group,user] newuserid |
G The UIC user identifier text is assigned when the username is created, C and is the text of the username. The UIC group group identifier is F assigned when the first username is created in the UIC group, and the G text is based on the account name specified for the first user created H in the group. The value of this identifier is [groupnumber, 177777]. To ; add a missing group identifier, use an asterisk as follows:
|
" 1 UAF> add/ident/value=uic=[group,*] newgroupid |
H You may find cases where an identifier is missing from time to time, as H there are cases where the creation of a UIC group name identifier might H conflict with an existing username, or a user identifier might conflict C with an existing group identifier. When these conflicts arise, the D AUTHORIZE utility will not create the conflicting group and/or user ( identifier when the username is created.
F You can can add and remove user-specified identifiers, but you should ? avoid changing the numeric values associated with any existing H identifiers. You should also avoid reusing UICs or identifiers when you D add new users, as any existing identifiers that might be present on F objects in the system from the old user will grant the same access to 9 the new user. Please see the security manual for details. h 5.10 What are the OpenVMS version upgrade paths?
P 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, 7 you can update to V6.2-1H1, V6.2-1H2, or V6.2-1H3. 8 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. 1 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. |
9 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) 9 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 |
C Note that OpenVMS Alpha V7.0 does not include support for hardware A and/or configurations first supported in OpenVMS Alpha V6.2-1H1, F V6.2-1H2, or V6.2-1H3; one must upgrade to OpenVMS VAX V7.1, or later.
H 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 G prohibition holds for performing updates directly to V7.1-1Hx from any H release prior to V7.1---this is not supported, and does not produce the H expected results. The LHR kits can, however, be directly booted and can C be directly installed, without regard to any operating system that $ might be present on the target disk.
E OpenVMS Alpha updates for LHRs (through V7.1-1Hx) require the use of > VMSINSTAL for the update. These LHR releases use PCSI for the D installation, but not for the update. Non-LHR releases use PCSI for installs and upgrades.
A OpenVMS Alpha V7.1-2 and later use PCSI for LHRs and for OpenVMS E upgrades and for all OpenVMS ECO kit installations; V7.1-2 and later G 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, 7 VMSINSTAL-based ECO (update) kits are used for OpenVMS. @ 5.10.2 OpenVMS I64 Upgrade Paths
G OpenVMS I64 V8.2 is the first production release. OpenVMS I64 V8.0 and G V8.1 were intended for early adopters of OpenVMS on Integrity servers, 1 and are not considered to be production releases.
E To utilize OpenVMS I64 V8.2, you must perform a full installation of E V8.2. No supported upgrade path (to V8.2) is available from previous B releases; there is no upgrade from OpenVMS I64 E8.2, nor from the earlier V8.1 or V8.0 releases.
B Future OpenVMS I64 releases are expected to provide a traditional D PCSI-based upgrade path from specified previous releases of OpenVMS H I64, analogous to the long-standing tradition of OpenVMS Alpha upgrades. H 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. 7 From V5.5, V5.5-1, or V5.5-2, one can upgrade to V6.0. 9 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. 3 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) 4 V6.1 -> V6.1 with VAXBACK ECO -> (V7.2, V7.3) V6.2 -> V7.2 V6.2 -> V7.3 |
H Note that OpenVMS VAX V6.0 does not include support for hardware and/or H configurations first added in OpenVMS VAX V5.5-2H4, one must upgrade to OpenVMS VAX V6.1.
G Note that OpenVMS VAX V5.5-2HW is a pre-release version of V5.5-2. Any 9 system running it should be upgraded to V5.5-2, or later.
G If you attempt a direct upgrade from OpenVMS VAX V6.1 to V7.2 or later F without having first applied the VAXBACK ECO kit to your V6.1 system, " you will receive an error message:
|
" 5 %BACKUP-E-INVRECTYP, invalid record type in save set |
E 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 7 application of an ECO for an upgrade to V7.2 and later. P 5.10.4 OpenVMS Cluster Rolling Upgrade Paths
H Rolling Upgrades require multiple system disks. Rolling upgrades permit E the OpenVMS Cluster to remain available while individual systems are ( being upgraded to a new OpenVMS release.
H OpenVMS Cluster rolling upgrades for both OpenVMS VAX and OpenVMS Alpha H may (will) have different, or additional upgrade requirements, and have G requirements around which versions of OpenVMS can coexist in a OpenVMS ! Cluster than what is listed here.
C See the OpenVMS Upgrade and Installation Manual for the particular G release, and the OpenVMS Software Product Descriptions for OpenVMS and for OpenVMS Cluster software:
< for further details on the rolling upgrade, and for support A information. The documentation for older releases of OpenVMS VAX A includes various platform-specific manuals, manuals that include B instructions that are specific to installing and upgrading on the platform. U 5.10.5 OpenVMS Product Version and Support Information
. For information on Prior Version Support (PVS) and Mature Product Support D (including information on support end dates for OpenVMS and various layered products), please see:
B For information on the supported and required versions of layered H products, and the minimum required layered product versions for various A configurations, please see the Software Rollout Report (SWROLL), available at:
a 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:
F Additional release history information, as well as a variety of other 6 trivia, is available in the VAX 20th anniversary book:
SB OpenVMS Alpha and OpenVMS I64 use the POLYCENTER Software Product H Install Utility, occasionly refered to as SPIU and rather more commonly H known as PCSI. PCSI is a component of the OpenVMS operating system, and < is available on OpenVMS VAX, OpenVMS Alpha, and OpenVMS I64.
G The following terms apply to OpenVMS Alpha and to OpenVMS I64 Upgrades and Installations using PCSI:
i 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?
E Seeing a negative number in the reservable pages portion of the SHOW > MEMORY/FULL command can be normal and expected, and is (even) F documented behaviour. A pagefile with a negative number of reservable H pages is overcommitted, which is generally goodness assuming that every G process with reserved pages does not try to occupy all of the reserved pagefile space at the same time.
F To understand how the pagefile reservation process works, think about E how a traditional bank operates when accepting customer deposits and H making loans. It's the same idea with the pagefile space. There is less E money in the bank vault than the total deposits, because much of the B money has been loaned out to other customers of the bank. And the E behaviour parallels that of the pagefile down to the problems that a G "run on the bank" can cause for banking customers. (Though there is no 0 deposit insurance available for pagefile users.)
F If all of the running applications try to use the reserved space, the D system manager will need to enlarge the pagefile or add one or more additional pagefules.
E To determine if the pagefile is excessively overcommitted, watch for C "double overcommitment"---when the reservable space approaches the C negatation of the available total space---and watch that the total D amount of free space available in the pagefile remains adequate. If B either of these situations arises, additional pagefile storage is required.
G Additional pagefile information: Additional pagefiles can typically be E created and connected on a running OpenVMS system. New processes and A new applications will tend to use the new pagefile, and existing C applications can be restarted to migrate out of the more congested D pagefiles. Pagefiles are generally named PAGEFILE.SYS, and multiple G pagefiles are generally configured on separate disk spindles to spread E the paging I/O load across the available disk storage. When multiple E pagefiles are present on recent OpenVMS versions, each pagefile file D should be configured to be approximately the same total size as the other pagefiles.
H For additional information on pagefile operations and related commands, D see the system management and performance management manuals in the OpenVMS documentation set.
F With OpenVMS V7.3 and later, the displays have been changed and these & negative values are no longer visible. x 5.12 Do I have to update layered products when updating OpenVMS?
E The Software Public Rollout Reports for OpenVMS list the current and D future availability of HP software products shipping on the OpenVMS H Software Products Library kits (CDROM consolidations) for OpenVMS Alpha D and/or OpenVMS VAX. Specifically, the required minimum versions for product support are listed.
C Comprehensive Public Rollout Information, listing previous product H versions as well as currently shipping versions, has been compiled into F a separate set of reports. The product information is grouped to show Operating System support.
H You may or may not be able to use older versions of local applications, H third-party products, and various HP OpenVMS layered products with more D recent versions of OpenVMS. User-mode code is expected to be upward F compatible. Code executing in a privileged processor mode---typically D either executive or kernel mode---may or may not be compatible with more recent OpenVMS versions.
F These Software Rollout (SWROLL) Reports are updated regularly. Please see:
V For related information, see Section 2.6.1.
| Previous | YNext | \Contents | ^Index |