Search the FAQ Archives

3 - A - B - C - D - E - F - G - H - I - J - K - L - M
N - O - P - Q - R - S - T - U - V - W - X - Y - Z
faqs.org - Internet FAQ Archives

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

( Part1 - Part2 - Part3 - Part4 - Part5 - Part6 - Part7 - Part8 - Part9 - Part10 - Part11 )
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Schools ]

See reader questions & answers on this topic! - Help others by sharing your knowledge
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

User Contributions:

Comment about this article, ask questions, or add new information about this topic:

CAPTCHA




Part1 - Part2 - Part3 - Part4 - Part5 - Part6 - Part7 - Part8 - Part9 - Part10 - Part11

[ Usenet FAQs | Web FAQs | Documents | RFC Index ]

Send corrections/additions to the FAQ Maintainer:
hoff@hp.nospam





Last Update March 27 2014 @ 02:11 PM