[Comp.Sci.Dept, Utrecht] Note from archiver<at>cs.uu.nl: This page is part of a big collection of Usenet postings, archived here for your convenience. For matters concerning the content of this page, please contact its author(s); use the source, if all else fails. For matters concerning the archive as a whole, please refer to the archive description or contact the archiver.

Subject: OpenVMS Frequently Asked Questions (FAQ), Part 4/11

This article was archived around: Sun, 04 Sep 2005 19:57:20 GMT

All FAQs in Directory: dec-faq/vms
All FAQs posted in: comp.os.vms, comp.sys.dec
Source: Usenet Version


Archive-name: dec-faq/vms/part4 Posting-Frequency: quarterly Last-modified: 02 Sep 2005 Version: VMSFAQ_20050902-04.TXT
System Management Information Rocksoft offers the Veracity data integrity tool (for info, send mail to demo@rocksoft.com). MD5 tools are also available. Tools to scan OpenVMS file systems for Microsoft Windows infections are and have been available, including a commercial package from Sophos , and a port of the open source Clam Antivirus scanner at http://www.clamav.net/ and with an OpenVMS port at http://fafner.dyndns.org/~alexey/clamav.zip. These scanning tools are particularly useful for systems running Samba or Advanced Server (PATHWORKS), as these servers tend to have a higher population of files intended for Microsoft Windows systems users, and as common virus and worm attacks can find and infect files on the file shares that these products can provide. These infections do not target OpenVMS itself, though the OpenVMS server (and any other platform and any other server capable of storing files for Windows systems) can silently host files containing common Microsoft Windows infections. __________________________________________________________ 5.3 Sources of OpenVMS security information? Where can I get information on OpenVMS system security? o http://www.hp.com/go/openvms/doc o http://www.blacksheepnetworks.com/security/resources/openvms/ __________________________________________________________ 5.4 How do I mount an ISO-9660 CD on OpenVMS? ISO-9660 support was added in the following releases: o OpenVMS VAX V6.0 o OpenVMS AXP V1.5 An add-on ISO-9660 kit was also available for OpenVMS VAX V5.5, V5.5-1, V5.5-2, and V5.5-2H4. This requires the installation of the F11CD kit from the InfoServer CD, from the Consolidated Distribution CD under the InfoServer area, or the F11CD ECO kit. (Upgrades to V6 and later are strongly recommended.) 5-4 System Management Information By default, OpenVMS senses the specific type of media. If you are working with dual-format media-media that uses both the ODS-2 and ISO-9660 formats on the same CD-ROM-then MOUNT will first detect and then default to the ODS-2 format. If you wish to override this and explicitly mount the media using ISO-9660, use the command: $ MOUNT/MEDIA_FORMAT=CDROM device-name[:] [volume-label] In most circumstances, you will not need nor will you want to include an explicit /MEDIA_FORMAT specification. For further information, please refer to the OpenVMS MOUNT Utility Manual. Particularly note the information on the MOUNT /MEDIA_FORMAT and /UNDEFINED_ FAT qualifiers. The MOUNT /UNDEFINED_FAT qualifier is of interest because ISO-9660 media can be mastered on a wide variety of operating system platforms, and these platforms do not necessarily support the semantics needed for files containing predefined record formats. The /UNDEFINED_FAT allows you to specify the default attributes for files accessed from volumes using the ISO-9660 format. An example which works for most CD-ROMs is: $ MOUNT/MEDIA_FORMAT=CDROM/UNDEFINED_FAT=STREAM:2048 DUA0: FREEWARE This particular MOUNT command forces access to the CD-ROM media using the ISO-9660 volume structure, and the use of the MOUNT /UNDEFINED_FAT qualifier causes any file whose file attributes are "undefined" to be returned with "stream" attributes with a maximum record length 2048. On OpenVMS, the ISO-9660 format is (internally) considered to be the ODS-3 file structure, while the High Sierra extensions to the standard are considered to be the ODS-4 file structure. The Rock Ridge extensions are not currently available on OpenVMS. 5-5 System Management Information For details on ODS-1 and ODS-2 file specifications, see Kirby McCoy's VMS File System Internals Manual (published by Digital Press, but potentially out of print), and see: o http://pdp-11.trailing-edge.com/www/ods1.txt o Look for the Freeware V5.0 directory ODS2 at http://www.hp.com/go/openvms/freeware/ __________________________________________________________ 5.5 How do I extract the contents of a PCSI kit? A growing number of OpenVMS products are being provided in PCSI (POLYCENTER Software Installation) kits which are installed using the PRODUCT INSTALL command. These are alternatives to or replacement for VMSINSTAL kits which were BACKUP savesets. PCSI kits are not BACKUP savesets and are structured differently from VMSINSTAL kits. If you want to extract product files from a PCSI kit, create a directory into which the kit should be expanded and use the following command: $ PRODUCT COPY prodname /SOURCE=[where-the-kit-is] - /DEST=[destination-directory] /FORMAT=REFERENCE A PCSI kit file has a file specification of the following form: DEC-VAXVMS-FORTRAN-V0603-141-1.PCSI In this example, "FORTRAN" is the "prodname". PCSI will expand the kit files into the directory you specify and subdirectories beneath such as [SYSEXE], [SYSLIB], etc., reflecting the eventual destination of files found there. Most of the actual product files (images, etc.) will be in the subdirectories. In the top-level directory will be a file with the file type PCSI$DESCRIPTION that specifies where various files should go. For more details, see the POLYCENTER Software Installation Developer's Guide for OpenVMS, which can be found in the OpenVMS documentation on the Consolidated Online Documentation CD-ROM. 5-6 System Management Information __________________________________________________________ 5.6 Emergency (Conversational) System Startup? If you need to perform system management operations on an OpenVMS system and cannot access the system through normal means-the password on the SYSTEM username was forgetten and no other privileged usernames are available, or one or more core system product authorization key (PAK) software licenses are unavailable or expired-then you must perform a conversational (emergency) bootstrap. Here are the steps: 1 Halt the system. Exactly how this is done depends on the specific system model: Depending on the model, this can involve pressing the <HALT> button, entering <CTRL/P> on the console, or pressing the <BREAK> key on the console. 2 At the console prompt, use a console command to boot into the SYSBOOT utility. (SYSBOOT allows conversational changes to system parameters.) (The console syntax for the conversational bootstrap varies by system model and by system architecture- this typically involves specifying a flag with the lowest bit set. See Section 14.3.5 for related details.) For example: On VAX, use one of the following three commands depending on the particular model of VAX system involved: B/R5:1 B/1 @GENBOO On Alpha: b -flags 0,1 If your system has a non-zero system root (such as root SYSE, shown here), you will have to use a console command such as the following: 5-7 System Management Information On VAX: B/E0000001 B/R5:E0000001 @<console media procedure name varies widely> On Alpha: b -flags e,1 On the IA-64 architecture systems, you can establish and manage an EFI boot alias for a conversational bootstrap as discussed in Section 14.3.5.1 and in Section 14.3.10, or you can use VMS_LOADER.EFI interactively as shown here. Of the core mechanisms discussed in Section 14.3.5.1, the following uses an EFI Shell command to perform a conversational bootstrap of root SYSE via the partition device fsn:. There are alternative mechanisms available. fsn:\efi\vms\vms_loader.efi -flags e,1 If your Alpha system has a hardware password (various systems support a password that prevents unauthorized access to the console), you will need to know theis password and will need to enter it using the LOGIN or similar command at the console. If you get an "Inv Cmd" error trying to perform a conversational bootstrap, and you do not have the hardware console password for the console LOGIN command, you are stuck-you will need to call for hardware service for assistance in resetting the hardware console password. The implementation and the syntax used for the console password mechanism does vary by implementation. 3 Once at the SYSBOOT prompt, request that OpenVMS read the system startup commands directly from the system console, that the window system (if any) not be started, and that OpenVMS not record these particular parameter changes for subsequent system reboots: 5-8 System Management Information SET/STARTUP OPA0: SET WINDOW_SYSTEM 0 SET WRITESYSPARAMS 0 CONTINUE 4 At the $ prompt, the system will now be accepting startup commands directly from the console. Type the following two DCL commands: $ SPAWN $ @SYS$SYSTEM:STARTUP 5 You should now see the dollar ($) prompt of DCL. The result of these two commands will be the normal system startup, but you will be left logged in on the console, running under a fully privileged username. Without the use of the SPAWN command, you would be logged out when the startup completes. Perform the task(s) required, such as resetting the password on the SYSTEM username as described in Section 5.6.1 or registering one or more license product authorization keys (PAKs) as described in Section 5.6.2. 6 Once you log out of this session, the system will complete the startup and can be used normally. You can choose to reboot the system, but that is not necessary. Some system managers will suggest a method using the UAFALTERNATE system parameter rather than the SET/STARTUP OPA0: command shown. This approach is not always available and is accordingly less commonly recommended, as there can easily be an alternate user authorization database (SYS$SYSTEM:SYSUAFALT.DAT) configured on the system. With a system manager that has configured an alternate SYSUAFALT.DAT file, the UAFALTERNATE method will fail-well, assuming you do not know the password of a privileged username stored within SYSUAFALT.DAT, of course. 5-9 System Management Information The UAFALTERNATE system parameter is used to trigger what is sometimes known as the console backdoor. The OPA0: system console is critical to system operations and system security, and will allow access when the SYSUAF system authorization database is unavailable or corrupted, when core product license PAKs are not registered, expired or disabled (NOLICENSE errors), or in various other cases of system failures. All this is in addition to the role of the console in the display of certain system-critical event messages. Access to the OPA0: console has a security exposure that is equivalent to direct access to the system hardware. When LOGINOUT detects an error (such as a SYSUAF corruption, by a missing SYSUAF, missing product licenses, or other trigger), it will prevent access to the OpenVMS system from all terminals except the system console. The OPA0: system console will be allowed access, and the resulting process will be fully privileged. Resetting the UAFALTERNATE system parameter-in the absence of an alternate SYSUAF system authorization database-will cause the console backdoor to be opened simply because LOGINOUT cannot locate SYS$SYSTEM:SYSUAFALT.DAT. When the authorization database cannot be located, access will be granted from the console only. For further information on emergency startup and shutdown, as well as for the official OpenVMS documentation on how to change the SYSTEM password from the console in an emergency, please see the OpenVMS System Manager's Manual in the OpenVMS documentation set. For information and recommendations on setting up OpenVMS system security, please see the NCSC Class C2 appendix of the Guide to OpenVMS System Security manual, also in the OpenVMS documentation set. You can also use the conversational bootstrap technique shown earlier (the steps until SET/STARTUP) to alter various system parameters, as well. At the SYSBOOT prompt, you can enter new parameters values: 5-10 System Management Information SHOW MAXPROCESSCNT SET . 64 CONTINUE The <.> is a shorthand notation used for the last parameter examined within SYSGEN and SYSBOOT. _____________________________ 5.6.1 I've forgotten the SYSTEM password - what can I do? 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. 5-11 System Management Information 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.17. 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. o Update the SCSNODE in MODPARAMS.DAT, and then run AUTOGEN as far as the SETPARAMS phase. (Do not reboot yet.) o Modify the DECnet node name. (NETCONFIG is the DECnet Phase IV tool, and NET$CONFIGURE is the DECnet-Plus tool.) o 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 (local or even the current) node on the /ON parameter in an INIT/QUEUE/START/ON= command. 5-12 System Management Information o 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.) o 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. o Reset any license PAKs that are restricted to the old node name to the new node name. o If the node name is part of a disk volume label, see Section 5.13. o Reboot the node or-if in a VMScluster-reboot the whole VMScluster. (This tends to catch any errors immediately.) o 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 UCX$CONFIGURATION.DAT or TCPIP$CONFIGURATION.DAT database. Thus if SCSNODE is changed, the IP host name reconfiguration must occur, and the required reconfiguration can occur only after a system reboot. Accordingly, it is best to perform the TCP/IP Services host name reconfiguration step after the reboot. 5-13 System Management Information 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, 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. 5-14 System Management Information 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: 5-15 System Management Information 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. 5-16 System Management Information 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: 5-17 System Management Information 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. 5-18 System Management Information 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-19 System Management Information _____________________________ 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 5-20 System Management Information 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: o 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. _____________________________ 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. 5-21 System Management Information 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: o http://www.hp.com/go/openvms/ o http://www.hp.com/go/services And see the following links, with the caveat that the direct "/hps" links shown here may become stale: o http://www.hp.com/hps/os/os_pvs.html o http://www.hp.com/hps/os/os_ovms.html 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: o 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: o http://www.openvms.compaq.com/openvms/os/openvms- release-history.html 5-22 System Management Information Additional release history information, as well as a variety of other trivia, is available in the VAX 20th anniversary book: o http://www.openvms.compaq.com/openvms/20th/vmsbook.pdf _____________________________ 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: o 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. o 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. 5-23 System Management Information o 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. o 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. o 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. 5-24 System Management Information 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-25 System Management Information __________________________________________________________ 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: o http://h71000.www7.hp.com/openvms/os/swroll/ 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. 5-26 System Management Information 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 5-27 System Management Information 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. __________________________________________________________ 5.15 Why do I get extra blank pages on my HP Printer? For information on configuring telnet print symbiont, on device control libraries such as SYSDEVCTL.TLB, and for ways of dealing with the extra blank pages that can arise on various HP printers, please see the OpenVMS Ask The Wizard area, starting particularly with topic (1020): o http://www.hp.com/go/openvms/wizard/ 5-28 System Management Information For additional information on the OpenVMS Ask The Wizard (ATW) area and for a pointer to the available ATW Wizard.zip archive, please see Section 3.8. There are a variety of discussions of this and of related printing topics in the Ask The Wizard area, in addition to topic (1020). Also see Section 5.34. __________________________________________________________ 5.16 Drivers and Configuration of New Graphics Controllers? This section contains information on various graphics controllers supported by OpenVMS Alpha, and specifically information on where and how to obtain device drivers for specific early OpenVMS releases- device drivers for controllers are integrated into and shipped with OpenVMS Alpha, but versions of these device drivers are sometimes made available for specific earlier OpenVMS releases. _____________________________ 5.16.1 The ELSA GLoria Synergy On OpenVMS Alpha V7.1-2, V7.2, and V7.2-1, acquire the appropriate GRAPHICS PCSI kit, and all prerequisite OpenVMS ECO kits: o VMS712_GRAPHICS-V0300 or later o VMS72_GRAPHICS-V0100 or later o VMS712_GRAPHICS-V0300 or later The ELSA GLoria Synergy is the PBXGK-BB; the PowerStorm 3D10T. Please ensure you have the most current ECOs for this and other graphics controllers installed; check for and install the current GRAPHICS kit. (See Section 4.3.2 for some unexpectedly related details.) On OpenVMS Alpha V7.2-1, the files necessary for this graphics controller are located in the distribution CD-ROM directory: DISK$ALPHA0721:[ELSA.KIT] Also check for any available (later) ECO kits. 5-29 System Management Information An earlier kit (ALP4D20T01_071) (for V7.1, V7.1- 1H1, and V7.1-1H2) was once available, but has been superceded and is not recommended. Use of V7.1-2 or later (and use of one the above GRAPHICS kits as required) is typically the best approach. OpenVMS V7.2-2 and later mainline releases directly support the controller. Additional information is available in topics (3419) and (5448) in the Ask The Wizard area: o http://www.hp.com/go/openvms/wizard/ For additional information on the OpenVMS Ask The Wizard (ATW) area and for a pointer to the available ATW Wizard.zip archive, please see Section 3.8. Support for the ELSA GLoria Synergy is integrated into all current OpenVMS Alpha releases. _____________________________ 5.16.2 PowerStorm 300, PowerStorm 350 The PowerStorm 300 is the PBXGD-AC, while the PowerStorm 350 is the PBXGD-AE. For support of the PowerStorm 300 and PowerStorm 350 graphics controllers, acquire and install the following available ECO kits: For OpenVMS Alpha V7.1-2: o DEC-AXPVMS-VMS712_P350-V0100-4 or later o DEC-AXPVMS-VMS712_GRAPHICS-V0300-4 or later For OpenVMS Alpha V7.2-1: o DEC-AXPVMS-VMS721_P350-V0100-4 or later o DEC-AXPVMS-VMS721_GRAPHICS-V0300-4 or later Support for the PowerStorm 300 and PowerStorm 350 series graphics controllers is integrated into current OpenVMS Alpha releases. 5-30 System Management Information _____________________________ 5.16.3 PowerStorm 3D30, PowerStorm 4D20 PowerStorm 3D30 (PBXGB-AA), PowerStorm 4D20 (PBXGB- CA) information is available in Ask The Wizard topics including topic (2041): o http://www.hp.com/go/openvms/wizard/ For additional information on the OpenVMS Ask The Wizard (ATW) area and for a pointer to the available ATW Wizard.zip archive, please see Section 3.8. _____________________________ 5.16.4 Radeon 7500 Install the current GRAPHICS ECO kit for OpenVMS Alpha V7.2-2 or V7.3-1 for support of the Radeon 7500 series PCI and AGP graphics controllers. Support for this controller (without an ECO kit) is first integrated into and available in OpenVMS Alpha V7.3-2. (Please do always install the most current GRAPHICS ECO kit whenever one is available, however.) __________________________________________________________ 5.17 How can I acquire OpenVMS patches, fixes, and ECOs? You can acquire and download kits containing OpenVMS fixes (ECOs) for various releases, as well as related support information, via the ITRC support center: o http://www.itrc.hp.com/ o ftp://ftp.itrc.hp.com/openvms_patches/ Some systems with Internet firewalls may/will have to use passive mode FTP to access the above sites. Assuming recent/current versions of the TCP/IP Services package, the DCL FTP command necessary is: $ DIRECTORY/FTP/ANONYMOUS/PASSIVE ftp.itrc.hp.com:: You can subscribe to an email notification list at the ITRC site. 5-31 System Management Information For a list of OpenVMS ECO kits recently released, you can use: o http://Eisner.DECUS.org/conferences/OpenVMS-patches_ new_1.HTML Examples and ECO kit installation instructions are included in the cover letter. For ECO kit email notifications, lists of available ECO kits, cover letters and other associated documentation, look in: o http://www.itrc.hp.com/ o ftp://ftp.itrc.hp.com/openvms_patches/ For additional information, please see Section 5.17. Do NOT attempt to install a VMSINSTAL-based OpenVMS ECO kit on OpenVMS Alpha V7.1-2 and later. While VMSINSTAL itself remains available, it is not used for OpenVMS Alpha ECO kits starting in OpenVMS Alpha V7.1-2. OpenVMS Alpha V7.1-2 and later use PCSI for OpenVMS ECO kits. See Section 5.30 for information on ECO kit checksums. __________________________________________________________ 5.18 How do I move the queue manager database? To move the location of the queue database, the SYS$QUEUE_MANAGER.QMAN$QUEUES and SYS$QUEUE_ MANAGER.QMAN$JOURNAL files, to a disk that is fast(er), has plenty of free space, and that is not heavily used. If the queue database is on a (busy) OpenVMS system disk, you can and probably should move it off the system disk to another disk spindle. To move the queue database: 1 Checkpoint the journal file. This reduces the file size to the in-memory database size. This will cause the noted delay. $ RUN SYS$SYSTEM:JBC$COMMAND JBC$COMMAND> DIAG 0 7 2 Stop the queue manager $ STOP/QUEUE/MANAGER/CLUSTER 5-32 System Management Information 3 Backup the .QMAN$QUEUES and .QMAN$JOURNAL files from the present location for safety. $ backup SYS$COMMON:[SYSEXE]SYS$QUEUE_MANAGER.QMAN$* DISK:[DIR] 4 Create a new directory for the queue database. Insure that this disk is accessible to all nodes that can run the queue manager. If the /ON list for the queue manager is "/ON=(*)", the disk must be available to all nodes in the cluster $ CREATE/DIR fast_disk:[qman] 5 Copy the .QMAN$QUEUES and .QMAN$JOURNAL files to the new directory $ copy SYS$COMMON:[SYSEXE]SYS$QUEUE_MANAGER.QMAN$* fast_disk:[qman] 6 Delete the old queue database. $ DELETE SYS$COMMON:[SYSEXE]SYS$QUEUE_MANAGER.QMAN$*;* 7 Restart the queue manager pointing to the new location $ START/QUEUE/MANAGER fast_disk:[qman] __________________________________________________________ 5.19 How do I delete an undeletable/unstoppable (RWAST) process? "Undeleteable" jobs are usually "undeleteable" for a reason-this can track back to insufficient process quotas, to a kernel-mode error in OpenVMS or a third- party device driver, or to other odd problems. These undeletable jobs typically become of interest because they are holding onto a particular resource (eg: tape drive, disk drive, communications widget) that you need to use... If the particular device supports firmware, ensure that the device firmware is current - TQK50 controllers are known for this when working with old firmware. (That, and the infamous "MUA4224" firmware bug.) If this device has a driver ECO kit available, acquire and apply it... If the particular relevant host component has an ECO, acquire and apply it. 5-33 System Management Information Useful tools include SDA (to see what might be going on) and DECamds (which increase and thus potentially fix quota-related problems). (nb: Applications with quota leaks will obviously not stay fixed.) If the stuck application is BACKUP, ensure you have the current BACKUP ECO and are directly following the V7.1 or (better) V7.2 or later process quota recommendations for operator BACKUP accounts. Quota details are in the OpenVMS System Manager's Manual. If the firmware and ECO levels are current, the best approach is to take a system crashdump, and pass a copy of the dump file along to whomever is maintaining the device driver for the particular device/widget/driver involved, with any details on how you got into this situation. (The reboot involved with taking the crashdump will obviously clear the problem.) There was some kernel-mode code (typically for OpenVMS VAX) that can reset the device ownership field, but that is rather obviously only an interim solution- the real fix is avoiding the loss of the IRP, the process quota leak, or whatever else is "jamming up" this particular process... __________________________________________________________ 5.20 How do I reset the error count(s)? The system reboot is the only supported approach prior to V7.3-2, but a reboot is obviously undesirable in various situations-there is presently no supported mechanism to reset error counts once the error(s) have been logged on these older releases. On V7.3-2 and later, you can use the DCL command: $ SET DEVICE/RESET=ERROR_COUNT As for an unsupported approach-and be aware of the potential for triggering a system crash, you need to determine the system address of the error count field. For a device, this is at an offset within the device's UCB structure. On VAX, the field is at an offset symbolically defined as UCB$W_ERRCNT. On Alpha, this field's offset is symbolically defined as UCB$L_ 5-34 System Management Information ERRCNT. The former is a word in size; the latter is a longword. You now need to locate the system address of the UCB$%_ ERRCNT field of the device you wish to reset. Enter SDA. In the following, you will see designations in {} separated by a /. The first item in braces is to be used on the VAX and the second item should be used on an Alpha. (ie. {VAX/Alpha}) $ ANALYZE/SYSTEM SDA> READ SYS${SYSTEM/LOADABLE_IMAGES}:SYSDEF.STB SDA> ! SHOW DEVICE the device with the error(s) SDA> SHOW DEVICE <ddnc:> SDA> EVALUATE UCB+UCB${W/L}_ERRCNT Hex = hhhhhhhh Decimal = -dddddddddd UCB+offset Record the hexadecimal value 'hhhhhhhh' returned. You can now exit from SDA and $ RUN SYS$SHARE:DELTA or do what I prefer to do, issue the following: SDA> SPAWN RUN SYS$SHARE:DELTA On both VAX and Alpha, the DELTA debugger will be invoked and will ident- ify itself. On Alpha, there will be an Alpha instruction decoded. For those unfamiliar with DELTA, it does not have a prompt and only one error message-Eh? (Well, for sake of argument, there might be another error produced on the console if you're not careful. This second error is more commonly known as a system crash.) If you are on a VAX, enter the command: [W If you are on Alpha, enter the command: [L These set the prevailing mode to word and longword respectively. Remem- ber the UCB${W/L)_ERRCNT differences? Now issue the command 1;M DELTA will respond with 00000001 5-35 System Management Information You are now poised to ZAP the error count field. To do so you need to en- ter the system address and view its contents. The format of the command to do this is of the form: IPID:hhhhhhhh/ For an IPID, use the IPID of the SWAPPER process. It is always: 00010001 Thus, to ZAP the error count, you would enter: 00010001:hhhhhhhh/ When you enter the / SDA will return the content of the address hhhhhhhh. This should be the error count (in hexadecimal) of the device in question. If it is not, you did something wrong and I'd suggest you type a carriage return and then enter the command EXIT to get out of DELTA. Regroup and see where your session went awry. If you entered your address correctly and the error count was returned as in the following example, you can proceed. 00010001:80D9C6C8/0001 ! output on VAX, 1 error 00010001:80D9C6C8/00000001 ! output on Alpha, 1 error You can now ZAP the error count by entering a zero and typing a carriage return. For example: 00010001:80D9C6C8/0001 0<return> ! output on VAX. 1 error 00010001:80D9C6C8/00000001 0<return> ! output on Alpha, 1 error Now type the command EXIT and a carriage return. Alternatively, reboot the system. 5-36 System Management Information __________________________________________________________ 5.21 How do I find out if the tape drive supports compression? For various SCSI-based MK-class magnetic tape devices: $ Devdepend2 = F$GETDVI("$n$MKcxxx:","DEVDEPEND2") $ Comp_sup = %X00200000 $ Comp_ena = %X00400000 $ IF (Devdepend2.AND.Comp_sup).EQ.Comp_sup THEN - WRITE SYS$OUTPUT "Compression supported" $ IF (Devdepend2.AND.Comp_ena).EQ.Comp_ena THEN - WRITE SYS$OUTPUT "Compression enabled" __________________________________________________________ 5.22 Can I copy SYSUAF to another version? To VAX? To Alpha? The format of the SYSUAF.DAT, RIGHTSLIST, and associated files are upward-compatible, and compatible across OpenVMS VAX, OpenVMS Alpha and OpenVMS I64 systems. (This compatibility is a a basic requirement of mixed-version OpenVMS Cluster configurations and OpenVMS upgrades-for specific support information, please see the OpenVMS Cluster rolling upgrade and mixed-version requirements.) That said, it's the contents of the SYSUAF and RIGHTSLIST files that will make this more interesting. The same basic steps necessary for moving RIGHTSLIST and SYSUAF files to another node are rather similar to the steps involved in merging these files in an OpenVMS Cluster-see the appendix of the OpenVMS Cluster documentation for details of merging files. (You might not be merging the contents of two (or more) files, but you are effectively merging the contents of the files into the target system environment.) Considerations: o applications often hold SYSUAF or RIGHTSLIST open, meaning a system reboot is often the best way to activate new files. o the meanings of the RESTRICTED and CAPTIVE flags settings on the UAF entries have changed over time. 5-37 System Management Information o the new NET$PROXY.DAT file that is initially created based on the contents of the NETPROXY.DAT during the OpenVMS VAX V6.1 upgrade and during the OpenVMS Alpha V6.2 upgrade. This file is maintained in parallel with NETPROXY.DAT. o the RIGHTSLIST identifier values and UIC values that end up scattered around the target system must be rationalized with the contents of the new RIGHTSLIST and SYSUAF files. The lattermost case-resolving the identifier values- is often the most interesting and difficult part. If you find that an identifier value (or identifier name) from the source RIGHTSLIST collides with that of an identifier existing on the target system, you must first determine if the two identifiers perform the same function. In most cases, they will not. As such, you will have to find and chance all references to the identifier value(s) (or name(s)) to resolve the "collision". If you encounter a collision, changing both of the identifier binary values (or names) involved in the collision to new and unique values can prevent security problems if you should miss a couple of identifiers embedded somewhere on the target system during the whole conversion process-rather than the wrong alphanumeric value for the identifier being displayed, you'll simply see the binary format for the identifier displayed, and no particular access will be granted. And any DCL commands or such that reference the old alphanumeric name will fail, rather than silently (and potentially erroneously) succeeding. Similar requirements exist for UIC values, as these too tend to be scattered all over the system environment. Like the binary identifier values, you will find UIC values associated with disks, ACLs, queues, and various other structures. 5-38 System Management Information For a list of the various files shared in an OpenVMS Cluster and that can be involved when relocating an environment from one node to another (or merging environments into an OpenVMS Cluster), please see the SYLOGICALS.TEMPLATE file included in OpenVMS V7.2 and later releases. Procedures to extract the contents of a (potentially corrupt) queue database are provided on the OpenVMS Freeware (V5) and can be used to combine two queue databases together while shuffling files between OpenVMS Cluster hosts. For related discussions of splitting a cluster into two or for removing a node from cluster (political divorce, etc), see topics (203), (767), (915) and others in the Ask The Wizard area: o http://www.hp.com/go/openvms/wizard/ For additional information on the OpenVMS Ask The Wizard (ATW) area and for a pointer to the available ATW Wizard.zip archive, please see Section 3.8. __________________________________________________________ 5.23 How do I delete (timeout) idle processes? There is no such command integrated within OpenVMS, though there are (optional) timers available within certain terminal servers and similar devices, and there is an integrated time-of-day mechanism that provides control over when a user can access OpenVMS. As for available tools, there are DECUS, freeware, and third-party tools known variously as "idle process killers" (IPK) or "terminal timeout" programs, as well as various other names. Examples include: Saiga Systems Hitman, Watchdog, MadGoat Watcher (via the MadGoat site or the OpenVMS Freeware), Kblock, the Networking Dynamics tool known as Assassin, and the Zap tool. Also available is the XLNperformance system management utility, from XLNsystems. A related package (for DECwindows sessions) is xtermlock. 5-39 System Management Information If the forgetful users are in an application menu environment, the menu can potentially be extended to provide this capability. __________________________________________________________ 5.24 Do I need a PAK for the DECevent (HP Analyze) tool? DECevent and HP (Compaq) Analyze are available to customers with support contracts. The PAK is required only for the advanced functions of DECevent, the basic bits-to-text translation of the error log does not require a license PAK. Ignore the prompt, in other words. (The PAK should be available to you if you have a hardware support contract or warrantee, and the PAK enables the use of the advanced error analysis and notification capabilities within DECevent.) Please see the following website for details and downloads: Analyze) o http://www.compaq.com/support/svctools/ Also see the tool that is available on V7.3-2 and later. $ ANALYZE/ERROR/ELV __________________________________________________________ 5.25 INITIALIZE ACCVIO and ANSI tape label support? A change was made (back in 1988) to (as it was then known) VAX/VMS V5.1-1 that added support for the then- new ANSI X3.27-1987 magnetic tape label standard. Prior to the ANSI X3.27-1987 standard, the date field in the ANSI HDR1 record permits dates only as far as the end of Year 1999. With ANSI X3.27-1987, dates through Year 1999 and dates from Years 2000 to 2099 are permitted. Versions of INIT.EXE and MTAACP.EXE from VAX/VMS releases prior to V5.1-1 will potentially have problems properly processing ANSI magnetic tapes when Y2K and later dates are involved-the DCL INITIALIZE command is known to encounter access violation (ACCVIO) errors. 5-40 System Management Information The available solutions include upgrades, or setting the date back. Direct initialization of the tape with the new headers (via $qio) is also clearly possible, though the limitation within the old MTAACP.EXE magtape ACP image is not nearly so easy to bypass. __________________________________________________________ 5.26 How do I recover from INSVIRMEM errors? Prior to OpenVMS Alpha V7.0 and on all OpenVMS VAX releases, VIRTUALPAGECNT and PGFLQUOTA limit the amount of virtual address space that is available to each process. Further limiting the amount of address space is the size of system space (S0 and S1 space). On OpenVMS Alpha versions prior to V7.0 and on all OpenVMS VAX releases, VIRTUALPAGECNT and MAXPROCESSCNT together determine the size of the page table data structures that occupy large tracts of system space. When no system virtual address space is available for the stuff that needs it-this includes the page tables, non-paged pool, and various other structures-then the values of VIRTUALPAGECNT and MAXPROCESSCNT cannot be increased. In OpenVMS Alpha V7.0 and later, the page table data structures have been moved out of S0 and S1 space and into page table space. In OpenVMS Alpha V7.2 and later, certain large data structures found in non-paged pool (eg: lock management structures) have been moved into 64-bit space, thus freeing up room in non-paged pool and in S0 and S1 space (where non-paged pool resides) while also permitting much larger data structures. __________________________________________________________ 5.27 How can I prevent a serial terminal line from initiating a login? In SYSTARTUP_VMS.COM, issue the command: $ SET TERMINAL/NOTYPEAHEAD/PERMANENT ddcu: This will prevent any unsolicited terminal input on ddcu:, and this unsolicited input is what triggers JOB_CONTROL to start up LOGINOUT on the terminal. Once LOGINOUT starts up on the serial line, you can see interesting behaviour (eg: audits, process creations, 5-41 System Management Information etc) as LOGINOUT tries to "chat" with whatever device is hooked onto the remote end of the serial terminal line. __________________________________________________________ 5.28 How does PCSI use the image BUILD_IDENT field? The (undocumented) build ident field in an OpenVMS Alpha image header is 16 bytes long, and is used as a counted string of 0-15 characters (ie, as an .ASCIC string, a string with the character count in byte 0) and was originally introduced to provide information for use by VMSINSTAL patch kits to determine whether an image should be replaced or not. Starting with OpenVMS Alpha V7.1-2, OpenVMS Engineering uses the PCSI utility to package and install ECO kits for OpenVMS. PCSI uses the generation attribute (a 32-bit unsigned integer) specified for files in the product description file (PDF) of a PCSI kit as the basis for performing file conflict detection and resolution. When a product is installed, PCSI modifies the build ident field of Alpha image headers to store an encoded form of the generation number. It also looks at the build ident field of previously installed images to obtain the generation information for those files as input to the file conflict processing algorithm. (Only images have this field, obviously.) PCSI interprets the build ident field of a previously installed image as follows: o if the string length is 15, the 5th character is a hyphen, and the last ten characters are a ten digit number with leading zeros, then the last ten characters are treated as a valid generation number. o for V7.1-2 through V7.2-1, inclusive, if the above test fails, the information is obtained from the PCSI product database. o in releases after V7.2-1 and with current PCSI ECO kits, if the above test fails, an invalid generation number is treated as 0000000000 so that the ECO kit will simply replace the image rather than assuming the PCSI database is in error. 5-42 System Management Information So, what will you see in the image identification displayed via the ANALYZE/IMAGE command? For an image that has been built as part of an OpenVMS Engineering system build, you will generally see a build ID string in the format "X6TE-SSB-0000"-X6TE is the build number for the OpenVMS Alpha V7.2-1 release. This id format is used within the OpenVMS system build, and can generally only be seen associated with images that have not yet been processed via PCSI. During the installation of V7.2-1, PCSI will modify the image header to have a build ident string of "X6TE-0050120000". During installation of an ECO kit containing this image with a generation number of 50130052, for example, PCSI would determine that 50130052 is greater than 50120000, and will replace the existing image on the target disk with the version of the image included in the ECO kit. Ranges of PCSI generation numbers for various OpenVMS releases are included in Table 5-1. The use of xxxx indicates a range of generations is available, from 0000 to 9999, inclusive. The format of, the particular operation of, and the assignment of PCSI generation numbers is subject to change without notice. ________________________________________________________________ Table 5-1 PCSI Generation Number _______________________________________________________ Generation Number____________Generation_Source____________________ 0040100000 V7.1-2 004011xxxx V7.1-2 ECOs 0050100000 V7.2 005011xxxx V7.2 ECOs 0050120000 V7.2-1 005013xxxx V7.2-1 ECOs 0050140000 V7.2-1H1 005015xxxx V7.2-1H1 ECOs 5-43 ---------------------------- #include <rtfaq.h> ----------------------------- For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq --------------------------- pure personal opinion --------------------------- Hoff (Stephen) Hoffman OpenVMS Engineering hoff[at]hp.com