The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Поиск:  Каталог документации | DEC

OpenVMS Frequently Asked Questions (FAQ), Part 2/5

This posting contains answers to frequently asked questions about the OpenVMS operating system from Compaq Computer Corporation, and the computer systems on which it runs.
Archive-name: dec-faq/vms/part2
Posting-Frequency: quarterly
Last-modified: 2 Oct 2001
Version: VMS-FAQ-2.TXT(7)

This is the OpenVMS Frequently Asked Questions Part 2/5. 
Please see Part 1/5 for administrivia, indexing, archiving, etc.

MGMT1.  What is an installed image?

The term "install" has two distinct meanings in OpenVMS.  The first relates to
"installing a product", which is done with either the SYS$UPDATE:VMSINSTAL.COM
command procedure or the POLYCENTER Software Installation (PCSI) utility 
(PRODUCT command).  The second meaning relates to the use of the INSTALL
utility, which is what concerns us here.

The INSTALL utility is used to identify to OpenVMS a specific copy of an
image, either executable or shareable, which is to be given some set of
enhanced properties.  For example, when you issue the SET PASSWORD command,
the image SYS$SYSTEM:SETP0.EXE is run.  That image needs to have elevated
privileges to perform its function.

The other important attribute is /SHARED.  This means that shareable parts
of the image (typically read-only code and data) are loaded into memory
only once and are shared among all users on a system.  Executable images
can be installed /SHARED as well as shareable library images.  (The term
"shareable" has dual meanings here, too.  See the OpenVMS Programming
Concepts Manual for further details.)

It's important to note that there is no such thing as "installing a shareable
image with privileges".  The INSTALL utility will let you do it, but the
privileges you specify will be ignored.  To have a callable routine run with
enhanced privileges that are not available to its caller, you must construct
your routines as "user-written system services" and install the shareable
image with the /PROTECT qualifier.  See the OpenVMS Programming Concepts
Manual for more information on user-written system services.  Note also
that in many cases the need to grant privileges to an image can be replaced
with the use of the "Protected Subsystems" feature that grants a rights
identifier to an image.  See the OpenVMS Guide to System Security for
information on Protected Subsystems.

MGMT2.  Are there any known viruses for OpenVMS?

Viruses are very common on PCs because the PC operating systems such as MS-DOS
and MacOS do not implement any sort of scheme to protect the operating system
or the file system against hostile action by programs.  On these operating
systems, any running program can subvert the operating system and take over
the hardware, at which point it can do anything it wishes, including hiding
copies of itself in other programs or in the file system.

This is unlikely on OpenVMS, Unix, and MVS for three reasons.  First, the 
operating system runs in a privileged mode in memory that is protected 
against modification by normal user programs.  Any old program cannot 
take over the hardware as it can on PC operating systems.  Secondly,
OpenVMS, Unix, and MVS have file systems that can be set up so that
non-privileged programs cannot modify system programs and files on disk.  
Both of these protection schemes mean that traditional PC virus schemes 
don't work on these OSes.  Third, typical applications and configurations
tend to prevent the uncontrolled execution of untrusted code as part of
email messages or web access.

It is possible for OpenVMS, etc., to be infected by viruses, but to do so, 
the program containing the virus must be run from a user account that has
amplified privileges.  As long as the system administrator is careful that
only trusted applications are run from such accounts (and this is generally
the case), there is no danger from viruses.
					[Paul Winalski]
					[Stephen Hoffman]

To protect against viruses and other attempts at system interference or
misuse, follow the recommendations in the "OpenVMS Guide to System Security". 
You may also want to consider optional software products which can monitor
your system for intrusion or infection attempts.  Computer Associates (CA)
offers various products in this area.

Rocksoft offers the Veracity data integrity tool (for info, send mail to

[Contributions to this list welcomed]

MGMT3.  How do I mount an ISO-9660 CD on OpenVMS?

ISO-9660 support was added in the following releases:

    OpenVMS VAX V6.0
    OpenVMS AXP V1.5

An add-on ISO-9960 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, Customer Support Center
kit CSCPAT #1071012, or the F11CD ECO kit.  (Upgrades to V6 and
later are strongly recommended.)

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:


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.

					[Jim Dunham]
					[Stephen Hoffman]

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:

MGMT4.  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:


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.

MGMT5.  I've forgotten the SYSTEM password - what can I do?

If you need to break into an OpenVMS system because you do not have
access to any privileged passwords, such as the password to the SYSTEM
username, you  will need physical access to the system console, and you
will need to perform a conversational reboot.  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 syntax for the conversational bootstrap varies by
      system model -- this typically involves specifying a flag of 1, for


          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:

          @<console media procedure name varies widely>

          b -flags e,1
      If your 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 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 in order
      to reset the hardware console password.  The syntax used for the
      console password mechanism varies.

  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:


  4.  At the $ prompt, the system will now be accepting startup commands
      directly from the console.  Type the following two DCL commands:


      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
      privileged username.  Without the use of the SPAWN command, you
      would be logged out when the startup completes.

      If necessary, you can skip the invocation of the system startup
      temporarily, and perform tasks such as egistering license PAKs 
      or various other "single-user" maintenance operations.

  5.  Use the following commands to reset the SYSTEM password:

        SET DEFAULT SYS$SYSTEM:  ! or wherever SYSUAF.DAT resides
        MODIFY SYSTEM /PASSWORD=newpassword

      These steps will change the SYSTEM password to the specified new
      newpassword password value.

   Reboot the system normally -- the SYSTEM password should now be set to
   the value you specified in Step 5.

   Some people will suggest a method using the UAFALTERNATE SYSGEN parameter.
   This approach is not always reliable and is not recommended, as there can
   easily be an alternate user authorization file configured on the system.

   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.

   You can also use the conversational bootstrap technique shown above (the
   steps through Step 3) to alter various system parameters.  At the SYSBOOT>
   prompt, you can enter new parameters values:

     SET . 64

   The "." is a shorthand notation used for the last parameter examined.

					[Stephen Hoffman]

MGMT6.  How do I connect a PostScript printer via TCP/IP?

Using UCX as the TCP/IP stack, it is possible to setup queues using the 
UCX$TELNETSYM in order to print to postscript printers.  This assumes 
however that the printer itself can convert whatever is passed to it into 
something intelligible.  As an example, if the printer has an IP address 
of 123.456.789.101 and jobs should be passed to port 9100 then :

The port number of 9100 is typical of HP JetDirect cards but may be 
different for other manufacturers cards.

As a better alternative, DCPS Version 1.4 and later support IP queues 
using either Compaq TCP/IP Services for OpenVMS software or Cisco 
Multinet for OpenVMS.  The usage of this type of interface is documented 
in the Release Notes and the DCPS$STARTUP.TEMPLATE file.

For general and additional (non-Postscript) IP printing information, see: topic (1020)
					[Steve Reece]
                                        [Arne VajhЬj]

MGMT7 moved to TIME10.

MGMT8 removed. superceded by TIME section

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

    Update the SCSNODE in MODPARAMS.DAT, and then run AUTOGEN as
      far as the SETPARAMS phase.  (Do not reboot yet.)
    Modify the DECnet node name.  (NETCONFIG is the DECnet Phase
      IV tool, and NET$CONFIGURE is the DECnet-Plus tool.)
    Modify the 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.)
    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.)
    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.)
    Rename the SYS$NODE_oldnodename rightslist identifier to match
      the new name.  (Do not change the binary value of this
    Reset any license PAKs that are restricted to the old node name
      to the new node name.
    If the node name is part of a disk volume label, see MGMT19.
    Reboot the node or -- if in a VMScluster -- reboot the whole
      VMScluster.  (This tends to catch any errors immediately.)

  There are likely a few other areas where the nodename will be stored.

  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)

  I expect I may 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...

					[Stephen Hoffman]

MGMT10. What is the correct value for EXPECTED_VOTES in a VMScluster?

The VMScluster connection manager uses the concept of votes and quorum
to prevent disk and memory data corruptions -- when sufficient votes are
present for quorum, then access to resources is permitted.  When sufficient
votes are not present, user activity will be blocked.  The act of blocking
user activity is called a "quorum hang", and is better thought of as a
"user data integrity interlock".  This mechanism is designed to prevent
a partitioned VMScluster, and the resultant massive disk data corruptions.

On each OpenVMS node in a VMScluster, one sets two values in SYSGEN: VOTES,
and EXPECTED_VOTES.  The former is how many votes the node contributes to
the VMScluster.  The latter is the total number of votes expected when the
full VMScluster is bootstrapped.

Some sites erroneously attempt to set EXPECTED_VOTES too low, believing
this will allow when only a subset of voting nodes are present in a
VMScluster.  It does not.  Further, an erroneous setting in EXPECTED_VOTES
is automatically corrected once VMScluster connections to other nodes are
established, meaning user data is at risk of severe corruption only during
the initial system bootstrap.

One can operate a VMScluster with one, two, or many voting nodes.  With
any but the two-node configuration, keeping a subset of the nodes active
when some nodes fail can be easily configured.  With the two-node
configuration, one must use a primary-secondary configuration (where the
primary has all the votes), a peer configuration (where when either node
is down, the other hangs), or (preferable) a shared quorum disk.

Use of a quorum disk does slow down VMScluster transitions somewhat --
the addition of a third voting node that contributes the vote(s) that
would be assigned to the quorum disk makes for faster transitions -- but
the use of a quorum disk does mean that either node in a two-node VMScluster
configuration can operate when the other node is down.

If you choose to use a quoum disk, a QUORUM.DAT file will be automatically
created when OpenVMS first boots and when a quorum disk is specified -- 
well, the QUORUM.DAT file will be created when OpenVMS is booted without 
also needing the votes from the quorum disk.

In a two-node VMScluster with a shared storage interconnect, typically each
node has one vote, and the quorum disk also has one vote.  EXPECTED_VOTES
is set to three.

Using a quorum disk on a non-shared interconnect is unnecessary -- the
use of a quorum disk does not provide any value, and the votes assigned
to the quorum disk should be assigned to the OpenVMS host serving access
to the disk.

For information on quorum hangs, see the OpenVMS documentation.  For
information on changing the EXPECTED_VOTES value on a running system,
see the SET CLUSTER/EXPECTED_VOTES command, and see the OpenVMS system
console documentation for the processor-specific console commands used
to trigger the IPC (Interrrupt Priority Level %x0C; IPL C) handler.
The IPC handler can be used to clear a quorum hang, and to clear disk
mount verification hangs.

The quorum scheme is a set of "blade guards" deliberately implemented 
by OpenVMS Engineering to provide data integrity -- remove these blade
guards at your peril.  OpenVMS Engineering did not implement the quorum
mechanism to make your life more difficult -- quorum was implemented to
keep your data from getting scrambled. 

						[Stephen Hoffman]

MGMT11. Why doesn't OpenVMS see the new memory I just added?

When adding memory to an OpenVMS system, one should check for an existing
Alpha) parameter in the SYS$SYSTEM:MODPARAMS.DAT parameter database, use
a text editor to reset the value in the file to the new correct value as
required, and then perform the following command:


This AUTOGEN command will reset various system parameters based on recent
system usage (FEEDBACK), and it will reset the value for the PHYSICALPAGES
parameter to the new value.  It will also reboot the OpenVMS system.
PHYSICALPAGES and PHYSICAL_MEMORY can also be used to deliberately lower
the amount of memory available for use by OpenVMS.  This ability can be
useful in a few specific circumstances, such as testing the behaviour of
an application in a system environment with a particular (lower) amount
of system memory available.

PHYSICALPAGES and PHYSICAL_MEMORY can be set to -1 (on OpenVMS Alpha) or 
(better and simpler) the entry can be removed from the MODPARAMS.DAT file, 
to indicate that all available memory should be used.

						[Stephen Hoffman]

MGMT12. How do I write a BACKUP saveset to a remote tape?

How to do this correctly was described at DECUS a long time ago. On the
node with the tape drive, create SAVE-SET.FDL:

        FORMAT                  fixed
        SIZE                    8192


  $ !
  $ ! BACKUP_SERVER.COM - provide remote tape service for BACKUP.
  $ !
  $ set noon
  $ set rms/network=16
  $ allocate mka500 tapedev
  $ mount/nounload/over:id/block=8192/assist tapedev
  $ convert/fdl=SAVE-SET sys$net tapedev:save-set.
  $ dismount/unload tapedev
  $ stop/id=0

On the node where you want to do the backup, use the DCL command:

  $ backup -
     srcfilespec -
     node"user pwd"::"task=backup_server"/block=8192/save

The only thing that doesn't completely work here is multi-reel savesets.
Since the tape is being written through RMS and the magtape ACP, BACKUP
won't see the reel switch and will split an XOR group across the reel
boundary. As far as I remember, BACKUP will be willing to read such a
multi-reel save set (directly, not over the net) since the XOR blocks
are simply ignored on read, but it definitely wouldn't be able to do a
recovery across the reel boundary.

Unfortunately BACKUP can't read tapes over the network because the RMS
file attributes on a network task access look wrong (variable length
						[Stephen Hoffman]

MGMT13. Tell me about SET HOST/DUP and SET HOST/HSC

The OpenVMS DCL commands SET HOST/DUP and SET HOST/HSC are used to connect 
to storage controllers via the Diagnostics and Utility Protocol (DUP).  These
commands require that the FYDRIVER device driver be connected.  This device
driver connection is typically performed by adding the following command(s) 
into the system startup command procedure:

    On OpenVMS Alpha:

    On OpenVMS VAX:

Alternatives to the DCL SET HOST/DUP command include the console >>> SET HOST
command available on various mid- to recent-vintage VAX consoles:

    Access to Parameters on an Embedded DSSI controller:
      >>> SET HOST/DUP/DSSI[/BUS:{0:1}] dssi_node_number PARAMS

    Access to Directory of tools on an Embedded DSSI controller:
      >>> SET HOST/DUP/DSSI[/BUS:{0:1}] dssi_node_number DIRECT

    Access to Parameters on a KFQSA DSSI controller:
      >>> SHOW UQSSP ! to get port_controller_number PARAMS
      >>> SET HOST/DUP/UQSSP port_controller_number PARAMS

These console commands are available on most MicroVAX and VAXstation 3xxx
series systems, and most (all?) VAX 4xxx series systems.  For further
information, see the system documentation and -- on most VAX systems -- see
the console HELP text.

EK-410AB-MG, _DSSI VAXcluster Installation and Troubleshooting_, is a good
resource for setting up a DSSI VMScluster on OpenVMS VAX nodes. (This manual
predates coverage of OpenVMS Alpha systems, but gives good coverage to all
hardware and software aspects of setting up a DSSI-based VMScluster -- and
most of the concepts covered are directly applicable to OpenVMS Alpha systems. 
This manual specifically covers the hardware, which is something not covered
by the standard OpenVMS VMScluster documentation.)

Also see MGMT58.
						[Stephen Hoffman]

MGMT14. How do I install DECnet Phase IV on VMS 7.1?

On OpenVMS V7.1, all DECnet binaries were relocated into separate installation
kits -- you can selectively install the appropriate network: DECnet-Plus
(formerly known as DECnet OSI), DECnet Phase IV, and Compaq TCP/IP Services
(often known as UCX).

On OpenVMS versions prior to V7.1, DECnet Phase IV was integrated, and there
was no installation question.  You had to install the DECnet-Plus (DECnet OSI)
package on the system, after the OpenVMS upgrade or installation completed.

During an OpenVMS V7.1 installation or upgrade, the installation procedure
will query you to learn if DECnet-Plus should be installed. If you are
upgrading to V7.1 from an earlier release or are installing V7.1 from a
distribution kit, simply answer "NO" to the question asking you if you want
DECnet-Plus.  Then -- after the OpenVMS upgrade or installation completes --
use the PCSI PRODUCT INSTALL command to install the DECnet Phase IV binaries
from the kit provided on the OpenVMS software distribution kit.

If you already have DECnet-Plus installed and wish to revert, you must
reconfigure OpenVMS.  You cannot reconfigure the "live" system, hence you must
reboot the system using the V7.1 distribution CD-ROM.  Then select the DCL
($$$ prompt) option.  Then issue the commands:


The above commands assume that the target system device and system root are
"DKA0:[SYS0.]".  Replace this with the actual target device and root, as
appropriate.  The RECONFIGURE command will then issue a series of prompts. 
You will want to reconfigure DECnet-Plus off the system, obviously.  You will
then want to use the PCSI command PRODUCT INSTALL to install the DECnet Phase
IV kit from the OpenVMS distribution media.

Information on DECnet support, and on the kit names, is included in the
OpenVMS V7.1 installation and upgrade documentation.

						[Stephen Hoffman]

MGMT15. 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:

    UAF> rename/ident oldgroupid newgroupid
    UAF> rename/ident olduserid  newuserid

If you should find yourself missing an identifier for a particular user, you
can add one for the user's UIC using a command such as:

    UAF> add/ident/value=uic=[group,user] newuserid

The UIC user identifier text is assigned when the username is created, and is
the text of the username.  The UIC group group identifier is assigned when the
first username is created in the UIC group, and the text is based on the
account name specified for the first user created in the group.  The value of
this identifier is [groupnumber, 177777]. To add a missing group identifier,
use an asterisk as follows:

    UAF> add/ident/value=uic=[group,*] newgroupid

You may find cases where an identifier is missing from time to time, as there
are cases where the creation of a UIC group name identifier might conflict
with an existing username, or a user identifier might conflict with an
existing group identifier.  When these conflicts arise, the AUTHORIZE utility
will not create the conflicting group and/or user identifier when the username
is created.

You can can add and remove user-specified identifiers, but you should avoid
changing the numeric values associated with any existing identifiers.  You
should also avoid reusing UICs or identifiers when you add new users, as any
existing identifiers that might be present on objects in the system from the
old user will grant the same access to the new user.  Please see the security
manual for details.

MGMT16. What are the OpenVMS version upgrade paths?

   Note: See "OpenVMS Alpha Terminology" section, below.

   OpenVMS Alpha release upgrade (or update) paths:

     From V1.0, one can upgrade to V1.5.
     From V1.5, or V1.5-1H1, one can upgrade to V6.1.
     From 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, V6.2-1H(1,2,3), or V7.0, one can upgrade to V7.1.
     From V6.2, one 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, one can update to V7.1-1H(1,2), ... to V7.2-1H1, to 7.3

     Some typical OpenVMS Alpha upgrade (or update) paths are:
         V1.0 -> V1.5 -> V6.1 -> (V6.2, V7.0, V7.1, V7.2, V7.3)
         V1.5-1H1 -> V6.1 -> (V6.2, V7.0, V7.1, V7.2, V7.3)
         V6.2 -> V6.2-1H3
         V6.2 -> V7.2-1
         V6.2 -> V7.3
         V6.2-1H(1,2,3) -> V7.1
         V6.2-1H(1,2,3) -> V7.2-1
         V7.1 -> V7.1-2
         V7.1 -> V7.2-1
         V7.1-1H(1,2) -> V7.1-2
         V7.1-1H(1,2) -> V7.2-1
         V7.2 -> V7.2-1H1
         V7.2 -> V7.3

     Note that OpenVMS Alpha V7.0 does not include support for hardware
     and/or configurations first supported in OpenVMS Alpha V6.2-1H1,
     V6.2-1H2, or V6.2-1H3; one must upgrade to OpenVMS VAX V7.1.

     One cannot update directly to a V6.2-1Hx Limited Hardware Release
     (LHR) from any release prior to the baseline V6.2 release.  The
     same prohibition holds for performing updates directly to V7.1-1Hx
     from any release prior to V7.1 -- this is not supported, and does
     not produce the expected results.  The LHR kits can, however, be
     directly booted and can be directly installed, without regard to
     any operating system that might be present on the target disk.

     OpenVMS Alpha updates for LHRs (through V7.1-1Hx) require the use
     of VMSINSTAL for the update.  These LHR releases use PCSI for the
     installation, but not for the update.  Non-LHR releases use PCSI
     for installs and upgrades.  

     OpenVMS Alpha V7.1-2 and later use PCSI for LHRs and for OpenVMS 
     upgrades and for all OpenVMS ECO kit installations.  VMSINSTAL
     OpenVMS ECO kits are not used on OpenVMS Alpha V7.1-2 and later.
     Prior to V7.1-2, VMSINSTAL-based ECO kits are used for OpenVMS.

   OpenVMS VAX release upgrade paths:

     From V5.0 through V5.4-3 inclusive, one can upgrade to V5.5.
     From V5.5, V5.5-1, or V5.5-2HW, one can upgrade to V5.5-2.
     From V5.5, V5.5-1, or V5.5-2, one can upgrade to V6.0.
     From V5.5-2, V5.5-2H4, or V6.0, one can upgrade to V6.1.
     From V6.0, or V6.1, one can upgrade to V6.2.
     From V6.1, or V6.2, one can upgrade to V7.0.
     From V6.1, V6.2, or V7.0, one can upgrade to V7.1.
     From V6.1, one can upgrade to V7.3 (with VAXBACK ECO for V6.1).

     Some typical OpenVMS VAX upgrade paths are:
         V5.x -> V5.5 -> V6.0 -> V6.2 -> (V7.1, V7.2, V7.3)
         V5.5-2HW -> V5.5-2
         V5.5-2, or V5.5-2H4 -> V6.1 -> (V6.2, V7.0, or V7.1)
         V6.1 -> V6.1 with VAXBACK ECO -> (V7.2, V7.3)
         V6.2 -> V7.2
         V6.2 -> V7.3

     Note that OpenVMS VAX V6.0 does not include support for hardware
     and/or configurations first added in OpenVMS VAX V5.5-2H4, one
     must upgrade to OpenVMS VAX V6.1.

     Note that OpenVMS VAX V5.5-2HW is a pre-release version of V5.5-2.
     Any system running it should be upgraded to V5.5-2, or later.

     If you attempt a direct upgrade from OpenVMS VAX V6.1 to V7.2 or
     later without having first applied the VAXBACK ECO kit to your V6.1
     system, you will receive an error message:

       %BACKUP-E-INVRECTYP, invalid record type in save set

     and the upgrade will fail.  Acquire and apply the VAXBACK ECO kit
     for OpenVMS VAX V6.1.  OpenVMS VAX V6.2 and later do not require 
     an application of an ECO for an upgrade to V7.2 and later.

   OpenVMS Cluster Rolling Upgrades:

     Rolling Upgrades require multiple system disks.  Rolling upgrades
     permit the OpenVMS Cluster to remain available while individual systems
     are being upgraded to a new OpenVMS release.

     OpenVMS Cluster rolling upgrades for both OpenVMS VAX and OpenVMS Alpha
     may (will) have different, or additional upgrade requirements, and
     have requirements around which versions of OpenVMS can coexist
     in a OpenVMS Cluster than what is listed here.

     See the _OpenVMS <platform> Version <Version> Upgrade and Installation
     Manual_, and the OpenVMS Software Product Descriptions
       OpenVMS typically uses SPD 25.01.xx and/or SPD 41.87.xx.

     for further details on the rolling upgrade, and for support information.  
     The documentation for older releases of OpenVMS VAX includes various
     platform-specific manuals, manuals that include instructions that
     are specific to installing and upgrading on the platform.

   OpenVMS and Layered Products -- 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:

     For information on supported versions of layered products, and
     minimum required layered product versions, see:

     For information on the release history of OpenVMS, including
     information on the code names of various releases and the
     major features:

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

   OpenVMS Alpha Terminology:

     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.

     upgrade:   Performed via PCSI.  Upgrades can typically be applied
                to a release-specific (and documented) range of prior
                OpenVMS releases.

     install:   Performed via PCSI.  With an installation, no existing
                version of the operating system is assumed present, nor
                are any files from any copy of the operating system might
                be present preserved, and the entire contents of the target
                disk are destroyed via a disk initialization.

     preserve:  Performed via PCSI.  Otherwise similar to an installation,
                this option skips the disk reinitialization.  User files
                on the target disk are preserved.  Any existing operating
                system files on the target disk are clobbered.

     LHR:       Limited Hardware Release.  LHRs are specific to and are
                targeted at new hardware configurations, and are not
                shipped to customers with support contracts.  At least
                one LHR kit must be specifically acquired when purchasing
                new hardware, new hardware that is not (yet) supported by
                any mainline (non-LHR) release.  LHRs have an "H" in the
                OpenVMS version string, indicating a "Hardware" release.

  For minimum OpenVMS versions for various platforms, see VMS13.

MGMT17. Why do I have negative number in the pagefile reservable pages?

Seeing a negative number in the reservable pages portion of the SHOW 
MEMORY/FULL command can be normal and expected, and is (even) documented 
behaviour.  A pagefile with a negative number of reservable pages is
overcommitted, which is generally goodness assuming that every process with
reserved pages does not try to occupy all of the reserved pagefile  space at
the same time. 

To understand how the pagefile reservation process works, think about  how a
traditional bank operates when accepting customer deposits and  making loans. 
It's the same idea with the pagefile space. There is  less money in the bank
vault than the total deposits, because much of  the money has been loaned out
to other customers of the bank.  And the behaviour parallels that of the
pagefile down to the problems that a  "run on the bank" can cause for banking
customers.  (Though there is  no deposit insurance available for pagefile

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

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.
					[Stephen Hoffman]

MGMT18. Do I have to update layered products when updating OpenVMS?

The Software Public Rollout Reports for OpenVMS list the current and future
availability of Compaq's software products shipping on the Software Products
Library kits (CDROM consolidations) for OpenVMS Alpha and 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 Compaq 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 reports are updated monthly.

Please see:

					[Stephen Hoffman]

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

  On OpenVMS V6.0 and later, issue the following PCSI command:

    $ PRODUCT REGISTER VOLUME <old-label> <device>

  To reset the label information stored in the PCSI database to reflect
  the new disk volume label.

  Locate any references in the system startup (typically including the
  disk MOUNT commands) and any DISK$label references in application files,
  and change the references appropriately.

  If this is a system disk (for the host or for a satellite), also check 
  the DECnet MOP or LANCP boot database, as well as any references to the
  disk created by CLUSTER_CONFIG*.COM.

  Remount the disk appropriately.
					[Stephen Hoffman]
                                        [John E. Malmberg]

MGMT20.  How do I fix a corrupt BACKUP saveset?

  BACKUP savesets can be corrupted by FTP file transfers and by tools
  such as zip (particularly when the zip tool has not been asked to
  save and restore OpenVMS file attributes or when it does not support
  OpenVMS file attributes), as well as via other means of corruptions.

  If you have problems with the BACKUP savesets after unzipping them
  or after an FTP file transfer, you can try restoring the appropriate
  saveset attributes using the tool:


  This tool is available on the OpenVMS Freeware (in the [000TOOLS]
  directory).  The Freeware is available at various sites -- see the
  Freeware location listings elsewhere in the FAQ -- and other similar
  tools are also available from various sources.

  In various cases, a SET FILE/ATTRIBUTES command can also be used.  
  As the parameters of this command must be varied as the target BACKUP 
  saveset attributes vary, this approach is not recommended.

  Also see the "SITE VMS", /FDL, and various other file-attributes options 
  available in various FTP tools.  (Not all available FTP tools support
  any or all of these options.)

  Browser downloads (via FTP) and incorrect (binary or ascii FTP transfer
  modes) are notorious for causing RMS file corruptions and particularly
  BACKUP saveset corruptions.  You can sometimes help encourage the browser 
  to select the correct FTP transfer type code (via RFC1738):

    ftp://host/urlname.ext;type=i   ! request ftp image/binary transfer
    ftp://host/urlname.ext;type=a   ! request ftp ascii/text transfer

  You can also often configure the particular web browser to choose the 
  appropriate transfer mode by default, based on the particular file 
  extensions, using a customization menu available in most web browsers.
  You can select that the specific file extentions involved use the FTP 
  binary transfer mode, which will reduce the number of corruptions seen.

					[Stephen Hoffman]

MGMT21.  How can I set up a shared directory?

To set up a shared directory -- where all files created in the directory
are accessable 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 AUTHORIZE:

Grant the identifier to each user in the group using AUTHORIZE:
  GRANT/IDENTIFIER groupidentifier username

If disk quotas are in use, add an entry via SYSMAN for each disk:

Set the shared directory to have an ACL similar to the following using the
SET SECURITY (V6.0 and later) or SET ACL (versions prior to V6.0) command:

If there are files already resident in the directory, set their protections
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.

MGMT22 relocated to SUPP3

MGMT23. 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):

  There are a variety of discussions of this and of related printing topics 
  in the Ask The Wizard area.

  Also see MGMT51.
					[Stephen Hoffman]

MGMT24. Configure ELSA GLoria Synergy or PowerStorm 300/350 graphics?

  On OpenVMS Alpha V7.1-2, V7.2, and V7.2-1, acquire the appropriate 
  GRAPHICS PCSI kit, and all prerequisite OpenVMS ECO kits:

    VMS712_GRAPHICS-V0300 or later
    VMS72_GRAPHICS-V0100 or later
    VMS712_GRAPHICS-V0300 or later


  The ELSA GLoria Synergy is the PBXGK-BB.

  On OpenVMS Alpha V7.2-1, the files necessary for this graphics
  controller are located in the distribution CD-ROM directory:


  Also check for any available (later) ECO kits.

  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-1H1 and later should directly support the controller.

  Additional information: topics (3419), (5448).


  PowerStorm 300 : PBXGD-AC
  PowerStorm 350 : 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:
    DEC-AXPVMS-VMS712_P350-V0100--4 or later
    DEC-AXPVMS-VMS712_GRAPHICS-V0300--4 or later

  For OpenVMS Alpha V7.2-1:
    DEC-AXPVMS-VMS721_P350-V0100--4 or later
    DEC-AXPVMS-VMS721_GRAPHICS-V0300--4 or later


  PowerStorm 3D30, PowerStorm 4D20: topic (2041).


  Support for the ELSA GLoria Synergy and the PowerStorm 300 and 350
  controllers is expected to be integrated in the OpenVMS Alpha V7.3 
  and later releases.

					[Stephen Hoffman]

MGMT25. How do I acquire OpenVMS patches, fixes, and ECOs?

You can acquire and download kits containing OpenVMS fixes (ECOs) for various 
releases via:

You can subscribe to an email notification list at:

A quarterly distribution is also available on CD-ROM:

  QT-3CQAA-C8      OpenVMS Alpha
  QT-3CRAA-C8      OpenVMS VAX

For a list of OpenVMS ECO kits recently released, you can use:

You can also sign up for ECO kit email notifications (Digest or
individual notifications) directly from Compaq at:

Examples and ECO kit installation instructions are included in the
cover letter.   For available ECO kits, cover letters and other
associated documentation, look in:

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 MGMT46 for information on ECO kit checksums.

					[Stephen Hoffman]

MGMT26. How do I rename a DSSI disk (or tape?)

  If you want to renumber or rename DSSI disks or DSSI tapes, it's 
  easy -- if you know the secret incantation...

  From OpenVMS:

    SYSGEN> ^Z
    <The software version is normally near the top of the display.>

  From the console on most 3000- and 4000-class VAX system consoles...
  (Obviously, the system must be halted for these commands...)

    Integrated DSSI:

        >>> SET HOST/DUP/DSSI[/BUS:[0:1]] dssi_node_number PARAMS


        >>> SET HOST/DUP/UQSSP port_controller_number PARAMS

  For information on how to get out into the PARAMS subsystem, also see
  the >>> HELP at the console prompt for the SET HOST syntax, or see the
  HELP on SET HOST /DUP (once you've connected FYDRIVER under OpenVMS).

  Once you are out into the PARAMS subsystem, you can use the FORCEUNI
  option to force the use of the UNITNUM value and then set a unique
  UNITNUM inside each DSSI ISE -- this causes each DSSI ISE to use the
  specfied unit number and not use the DSSI node as the unit number.
  Other parameters of interest are NODENAME and ALLCLASS, the node name
  and the (disk or tape) cluster allocation class.

  Ensure that all disk unit numbers used within an OpenVMS Cluster disk 
  allocation class are unique, and all tape unit numbers used within an
  OpenVMS Cluster tape allocation class are also unique.
					[Stephen Hoffman]

MGMT27. 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:

   0. Checkpoint the journal file.  This reduces the file size to the in-memory
      database size.  This will cause the noted delay.  


   1. Stop the queue manager


   2. Backup the .QMAN$QUEUES and .QMAN$JOURNAL files from the present location
      for safety.
   3. 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]

   4. Copy the .QMAN$QUEUES and .QMAN$JOURNAL files to the new directory

	$ copy SYS$COMMON:[SYSEXE]SYS$QUEUE_MANAGER.QMAN$*  fast_disk:[qman]

   5.  Delete the old queue database.  


   6. Restart the queue manager pointing to the new location

	$START/QUEUE/MANAGER fast_disk:[qman]

					[Dave Sweeney]

MGMT28. How do I set a default IP route or gateway on OpenVMS?

If you have TCP/IP Services, then use the command:

  For TCP/IP Services V5.0 and later:


  For earlier TCP/IP Services versions:


MGMT29 relocated to ALPHA21

MGMT30. 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
relevent host component has an ECO, acquire and apply it.

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 
process quota recommendations for operator BACKUP accounts.

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 it 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
					[Stephen Hoffman]

MGMT31. How do I reset the error count(s)?

The system reboot is the only supported approach, but it is obviously 
undesirable in various situations -- there is presently no supported 
mechanism to reset error counts once the error(s) have been logged.

As for an unsupported approach -- and be aware of the potential for
causing a system crash...

To reset the error count, one needs 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_ERRCNT.  The former is a word in size; the latter is
a longword.  (Could it be that Alpha devices are more error prone? ;)

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})

SDA>  SHOW DEVICE <ddnc:>    ! device designation of device with error
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:


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

You're 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:


For an IPID, use the IPID of the SWAPPER process.  It is always: 00010001

Thus, to ZAP the error count, you would enter:


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<cr>                    ! output on VAX    1 error
00010001:80D9C6C8/00000001 0<cr>                ! output on Alpha  1 error

Now type the command EXIT and a carriage return.
                                      [Brian Schenkenberger]

MGMT32. 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"

MGMT33. 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 and 
OpenVMS Alpha 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.)


  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.

  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.

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).
					[Stephen Hoffman]

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

  A related package (for DECwindows sessions) is xtermlock.

  If the forgetful users are in an application menu environment, the menu
  can potentially be extended to provide this capability.

MGMT35. Why isn't BACKUP/SINCE=BACKUP working?

  If you are seeing more files backed up than previously, you are seeing
  the result of a change that was made to ensure BACKUP can perform an
  incrementation restoration of the files.  In particular, if a directory
  file modification date changes, all files underneath it are included in 
  the BACKUP, in order to permit incremental restoration should a directory 
  file get renamed.

  Why has OpenVMS gone through the agony of this change?

    When a directory is renamed, the modified date is changed.  When the
    restoration needs to restore the directory and its contents, and the
    restoration should not result in the restoration of the older directory
    name when a series of incremental BACKUPs are restored.  Thus an
    incremental BACKUP operation needs to pick up all of the changes.

  What can you do to improve BACKUP performance?

    Use the documented commands in the manual for performing incremental
    BACKUPs.  Use the documented incremental procedures.  Don't try to use
    incremental commands in a non-incremental context.

    Also consider understanding and then using /NOALIAS, which will likely
    be a bigger win than will anything to do with the incremental BACKUPs,
    particularly on system disks and any other disks with directory aliases.

  Can you get the old BACKUP behaviour back?

    Yes, please see the /NOINCREMENTAL qualifier available on recent 
    OpenVMS versions (and ECO kits).  Use of this qualifier informs BACKUP 
    that you are aware of the limitations of the old BACKUP behaviour around 
    incremental disk restorations.

  Consider performing an incremental restoration, to test the procedures.
  Attempting this is how we found out about the problem that was latent
  with the old scheme -- the old incremental BACKUP scheme would have 
  missed restoring any files under a renamed directory.  Hence the change.

  See the OpenVMS V6.2 release notes for additional details.

MGMT36. How can I set up reverse telnet (like reverse LAT)?

  Though it may seem obvious, Telnet and LAT are quite different -- with
  differing capabilities and design goals.

  Please see the documentation around the TCP/IP Services for OpenVMS
  TELNET command CREATE_SESSION.  This command is the equivilent of the
  operations performed in LTLOAD.COM or LAT$SYSTARTUP.COM.  There is no
  TELNET equivilent to the sys$qio[w] control interface for LTDRIVER (as
  documented in the I/O User's Reference Manual) available, though 
  standard sys$qio[w] calls referencing the created TN device would 
  likely operate as expected.

MGMT37. Do I need a PAK for the DECevent (Compaq Analyze) tool?

  DECevent and Compaq Analyze are avalable 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 DECevent FAQ for additional details:

  The current version of the DECevent (Compaq Analyze) tool can
  be downloaded from:

MGMT38. 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)

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.

                                               [Hoffman, Dachtera]

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

MGMT40. How can I prevent a serial terminal line from initiating a login?

  In SYSTARTUP_VMS.COM, issue the command:


  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, etc) as LOGINOUT tries to "chat" with whatever device
  is hooked onto the remote end of the serial terminal line.

MGMT41. 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, a 
  an .ASCIC string with 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

    - 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.
    - for V7.1-2 through V7.2-1, inclusive, if the above test fails, the 
      information is obtained from the PCSI product database.
    - 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.

  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.

MGMT42. How to configure allocation classes and Multi-Path SCSI?

The HSZ allocation class is applied to devices, starting with OpenVMS V7.2.
It is considered a port allocation class (PAC), and all device names with a 
PAC have their controller letter forced to "A".  (You might infer from the
the text in the "Guidelines for OpenVMS Cluster Configurations" that this
is something you have to do, though OpenVMS will thoughtfully handle this 
renaming for you.)

You can force the device names back to DKB by setting the HSZ allocation 
class to zero, and setting the PKB PAC to -1.  This will use the host
allocation class, and will leave the controller letter alone (that is, 
the DK controller letter will be the same as the SCSI port (PK) controller).
Note that this won't work if the HSZ is configured in multibus failover 
mode.  In this case, OpenVMS requires that you use an allocation class 
for the HSZ.

When your configuration gets even moderately complex, you must pay careful
attention to how you assign the three kinds of allocation class: node, port
and HSZ/HSJ, as otherwise you could wind up with device naming conflicts 
that can be painful to resolve.

The display-able path information is for SCSI multi-path, and permits the
multi-path software to distinguish between different paths to the same 
device.  If you have two paths to $1$DKA100, for example by having two 
KZPBA controllers and two SCSI buses to the HSZ, you would have two UCBs 
in a multi-path set.  The path information is used by the multi-path 
software to distinguish between these two UCBs.

The display-able path information describes the path; in this case, the SCSI
port.  If port is PKB, that's the path name you get.  The device name is no 
longer completely tied to the port name; the device name now depends on the 
various allocation class settings of the controller, SCSI port or node.

The reason the device name's controller letter is forced to "A" when you 
use PACs is because a shared SCSI bus may be configured via different ports 
on the various nodes connected to the bus.  The port may be PKB on one node, 
and PKC on the other.  Rather obviously, you will want to have the shared 
devices use the same device names on all nodes.  To establish this, you will
assign the same PAC on each node, and OpenVMS will force the controller 
letter to be the same on each node. Simply choosing "A" was easier and 
more deterministic than negotiating the controller letter between the 
nodes, and also parallels the solution used for this situation when DSSI 
or SDI/STI storage was used.

This information is also described in the Cluster Systems and Guidelines 
for OpenVMS Cluster Configurations manuals.
                                               [John Croll]

MGMT43. How can I tell what software (and version) is installed?

  There is unfortunatly no consistent nor single way to make this
  determination -- this is one of the reasons that a move to PCSI
  installations is underway.

  On OpenVMS Alpha, you can use VMSINSTAL.HISTORY and PRODUCT SHOW
  PRODUCT to determine what packages have been installed via the
  VMSINSTAL and PCSI tools, respectively.

  To see which OpenVMS Alpha ECO kits have been applied, look in 
  VMSINSTAL.HISTORY on OpenVMS Alpha prior to V7.1-2, and use 
  PRODUCT SHOW PRODUCT/FULL on OpenVMS Alpha V7.1-2 and later.

  On OpenVMS VAX, you can use PRODUCT SHOW PRODUCT and (for
  software that is installed via VMSINSTAL on V7.3 and later)

  For products installed on OpenVMS VAX prior to V7.3 using
  VMSINSTAL, there is no reliable way to determine what products
  have been installed.  If the product provides a RELEASE_NOTES
  file (as many do), you can look for the list of these files
  via DIRECTORY SYS$HELP:*.RELEASE_NOTES.  Again, this approach
  is NOT reliable: some kits do not provide release notes, some 
  system managers will install only the release notes, some system 
  managers will delete release notes, and release notes for multiple 
  versions can be present.

  On most packages, you can generally use ANALYZE/IMAGE on one of the
  core images, looking at the image identification area.  Some of the
  product-specific mechanisms available are:

    DQS   DQS$VERSION logical name
    C     CC/VERSION

MGMT44. Where can I get Fibre Channel Storage (SAN) information?

MGMT45. How can I split up an OpenVMS Cluster?

  Review the VMScluster documentation, and the System Management
  documentation.  The following are the key points, but are likely
  not the only things you will need to change.

  OpenVMS Cluster support is directly integrated into the operating system,
  and there is no way to remove it.  You can, however, remote site-specific
  tailoring that was added for a particular cluster configuration.

  First: Create restorable image BACKUPs of each of the current system 
  disks.  If something gets messed up, you want a way to recover, right?

  Create standalone BACKUP kits for the OpenVMS VAX systems, and create
  or acquire bootable BACKUP kits for the OpenVMS Alpha systems.

  Use CLUSTER_CONFIG or CLUSTER_CONFIG_LAN to remove the various system
  roots and to shut off boot services and VMScluster settings.

  Create as many architecture-specific copies of the system disks as
  required.  Realize that the new systems will all likely be booting
  through root SYS0 -- if you have any system-specific files in any
  other roots, save them.

  Relocate the copies of the VMScluster common files onto each of the
  new system disks.

  Reset the console parameters and boot flags on each system for use
  on a standalone node.

  Reset the VAXCLUSTER and NISCS_LOAD_PEA0 parameters to 0 in SYSGEN

  Clobber the VMScluster group ID and password using SYSMAN.

  Reboot the systems seperately, and run AUTOGEN on each.

  Shut off MOP services via NCP or LANCP on the boot server nodes.

  Permanent seperation also requires the duplication of shared files.  
  The following files are typically shared within a cluster:

  Filename:              default directory (in common root) and file type:
    SYSUAF                      SYS$SYSTEM:.DAT
    SYSUAFALT                   SYS$SYSTEM:.DAT
    SYSALF                      SYS$SYSTEM:.DAT
    RIGHTSLIST                  SYS$SYSTEM:.DAT
    NETPROXY                    SYS$SYSTEM:.DAT
    NET$PROXY                   SYS$SYSTEM:.DAT
    NETOBJECT                   SYS$SYSTEM:.DAT
    QMAN$MASTER                 SYS$SYSTEM: (this is a set of related files)
    LMF$LICENSE                 SYS$SYSTEM:.LDB
    VMS$OBJECTS                 SYS$SYSTEM:.DAT

  Information on changing node names is included in MGMT9.

MGMT46. What file checksum tools are available for OpenVMS?

The undocumented DCL command CHECKSUM is the usual means, and provides
a rather simple-minded checksum suitable to detect basic file corruptions.
For information and an OpenVMS version of the MD5 checksum tool, see:

The OpenVMS Alpha ECO (patch) kit checksums available at the ECO website
are determined using the following DCL command sequence:

  CHECKSUM kitname.pcsi-dcx_axpexe

See MGMT25 for information on acquiring OpenVMS ECO (patch) kits.

MGMT47.  Configuring Cluster SCS for path load balancing?

SCS: Systems Communication Services.  The protocol used to communicate 
between VMSCluster systems and between OpenVMS systems and SCS-based
storage controllers.  (SCSI-based storage controllers do not use SCS.)

PORT: A communications device, such as DSSI, CI, Ethernet or FDDI.  Each 
CI or DSSI bus is a different local port, named PAA0, PAB0, PAC0 etc. 
All Ethernet and FDDI busses make up a single PEA0 port.  

VIRTUAL CIRCUIT: A reliable communications path established between a 
pair of ports.  Each port in a VMScluster establishes a virtual circuit 
with every other port in that cluster.

All systems and storage controllers establish "Virtual 
Circuits" to enable communications between all available pairs of ports.

SYSAP: A "system application" that communicates using SCS.  Each SYSAP
communicates with a particular remote SYSAP.  Example SYSAPs include:

    The disk class driver is on every VMSCluster system.
    MSCP$DISK is on all disk controllers and all VMSCluster
    systems that have SYSGEN parameter MSCP_LOAD set to 1

    The tape class driver is on every VMSCluster system.
    MSCP$TAPE is on all tape controllers and all VMSCluster
    systems that have SYSGEN parameter TMSCP_LOAD set to 1

    This SYSAP contains the connection manager, which manages 
    cluster connectivity, runs the cluster state transition 
    algorithm, and implements the cluster quorum algorithm. 
    This SYSAP also handles lock traffic, and various other 
    cluster communications functions.

    This SYSAP is used to find SYSAPs on remote systems

    The Mass Storage Control Protocol and the Tape MSCP servers
    are SYSAPs that provide access to disk and tape storage, 
    typically operating over SCS protocols.  MSCP and TMSCP 
    SYSAPs exist within OpenVMS (for OpenVMS hosts serving 
    disks and tapes), within CI- and DSSI-based storage 
    controllers, and within host-based MSCP- or TMSCP storage 
    controllers.  MSCP and TMSCP can be used to serve MSCP and
    TMSCP storage devices, and can also be used to serve SCSI
    and other non-MSCP/non-TMSCP storage devices.

SCS CONNECTION: A SYSAP on one node establishes an SCS connection to its 
counterpart on another node.  This connection will be on ONE AND ONLY ONE 
of the available virtual circuits.


When there are multiple virtual circuits between two OpenVMS systems 
it is possible for the VMS$VAXCLUSTER to VMS$VAXCLUSTER connection to 
use any one of these circuits.  All lock traffic between the two systems 
will then travel on the selected virtual circuit.

Each port has a "LOAD CLASS" associated with it.  This load class helps 
to determine which virtual circuit a connection will use.  If one port 
has a higher load class than all others then this port will be used.  
If two or more ports have equally high load classes then the connection 
will use the first of these that it finds.  Normally all CI and DSSI 
ports have a load class of 14(hex), the Ethernet/FDDI port has a load 
class of A(hex).

For instance, if you have multiple DSSI busses and an FDDI, the 
VMS$VAXCLUSTER connection will chose the DSSI bus as this path has the 
system disk, and thus will always be the first DSSI bus discovered when
the OpenVMS system boots.

To force all lock traffic off the DSSI and on to the FDDI, an adjustment
to the load class value is required, or the SCS port must be disabled.

Note that with PE ports, you can typically immediately re-enable the path, 
permitting failover to occur should congestion or a problem arise -- a 
running average of the path latency is checked when the virtual circuit 
is formed, and at periodic intervals (circa every three seconds), and when 
a problem with a virtual circuit arises. 

In the case of PEDRIVER, the driver handles load balancing among the 
available Ethernet and FDDI connections based on the lowest latency 
path available to it.  Traffic will be routed through that path until
an event occurs that requires a fail-over.

In all OpenVMS versions, you can use the tools:


These tools permit you to disable or enable all SCS traffic on the
on the specified paths.

You can also use a prefered path mechanism that tells the local MSCP 
disk driver (DUDRIVER) which path to a disk should be used.  Generally, 
this is used with dual-pathed disks, forcing I/O traffic through one 
of the controllers instead of the other.  This can be used to implement 
a crude form of I/O load balancing at the disk I/O level.

Prior to V7.2, the prefered path feature uses the tool:


In OpenVMS V7.2 and later, you can use the following DCL command:


The prefered path mechanism does not disable nor affect SCS operations
on the non-prefered path.
                              [Kevin Jenkins, Verell Boaen, John Croll]

MGMT48. What (and where) is the OpenVMS Management Station?

  For information and current kits for the OpenVMS Management Station
  (OMS), a PC-based tool that permits you to manage an OpenVMS system, 
  please see:

MGMT49. How to determine current disk fragmentation level?

  The Compaq OpenVMS Disk File Optimizer (DFO) defragmentation package 
  provides a fragmentation monitoring tool, and a DFO product authorization 
  key (PAK) is not required for the fragmentation reporting tool:


  The DFU tool available on the OpenVMS Freeware can generate a report 
  on the disk fragmentation:

  DFU> REPORT ddcu:


  A message at the OpenVMS bootstrap such as the following:

%SYSBOOT-E-LDFAIL, failed to load execlet, status = 00000910

  indicates that the particular OpenVMS release does not contain
  support for the target platform.  In this case, OpenVMS does
  not recognize Alpha family 1C member 02 as a supported platform.
  A later version of OpenVMS might support the platform, or there
  might be no support on any release.

  The execlet load failure and other similar bootstrap status values 
  can often be decoded using either of the following techniques:

$ exit %x910
%SYSTEM-W-NOSUCHFILE, no such file

$ x = f$message(%x910)
$ show symbol x
  X = "%SYSTEM-W-NOSUCHFILE, no such file"

MGMT51. How can I customize the DCPS device control for a new printer?

  To customize DCPS for an otherwise unsupported printer, you can try
  the following sequence:

  o Extract the most closely-associated setup modules from the existing 
    device control library, DCPS$DEVCTL.TLB.  (For instance, you can 
    probably extract and use the HP LaserJet 4000 series definitions 
    for the HP LaserJet 4050 series.  Each printer will vary, please
    consult the printer documentation for specifics and requirements.)

  o rename each extracted setup module to a corresponding:

  o Insert all of the above-renamed setup modules into a newly-created 
    device control library specific to the new printer:

    The above assumes the filename HP4050_DEVCTL.TLB, alter as required.

  o Set up your DCPS startup procedures to include a search-list logical
    name such as:


  o Supply DCPS_HP4050_LIB as the library parameter in the queue startup 
    for this printer, this is the P3 parameter to the command procedure

  o The HP4050_DEVCTL library may/will need to be recreated and modules
    re-edited and replaced with each DCPS upgrade, particularly if any
    modules are updated in the original library.  You will also want to
    determine if the upgraded version of DCPS directly supports the 
    particular printer.

  o To customize the processing of file extensions within DCPS (to
    enable or disable graybar output, for instance), use the information 
    available in:


    to create your own site-specific:


  Also see MGMT23.
                                         [Ken Fairfield, with typos 
                                         introduced by Stephen Hoffman]

MGMT52. Why do $GETDEV MOUNTCNT and SHOW DEVICE mount counts differ?

  MOUNTCNT returns the local mount count, while SHOW DEVICE returns
  the cluster-wide mount count.

                                         [Stephen Hoffman]

MGMT53. What software is needed for Postscript printers?

  The NorthLake PrintKit ( and DECprint Supervisor
  are common choices for support of Postscript printers on OpenVMS.

MGMT54. Does volume shadowing require a non-zero allocation classes?

  Yes, use of host-based volume shadowing requires that the disk(s)
  involved be configured in a non-zero allocation class.

  Edit SYS$SYSTEM:MODPARAMS.DAT to include a declaration of an
  non-zero allocation class, such as setting the host allocation 
  class to the value 7:


  Then AUTOGEN the system, and reboot.

  You should now be able to form the shadow set via a command such
  as the following:

    MOUNT dsa1007: /SHADOW=($7$dkb300:,$7$dkb500:) volumelabel

  When operating in an OpenVMS Cluster, this sequence will typically
  change the disk names from the SCSNODE prefix (scsnode$dkann) to
  the allocation-class prefix ($7$dkannn).  This may provide you with
  the opportunity to move to a device-independent scheme using logical
  name constructs such as the DISK$volumelabel logical names in your
  startup and application environments; an opportunity to weed out
  physical device references.
                                              [Veli Korkko]

MGMT55. section duplicated MGMT28

MGMT56. How do I remove a PCSI-installed patch (ECO) kit?

You cannot PRODUCT REMOVE a PCSI patch (ECO) kit.

In order to do this, PCSI would have to have copies of all the other 
version of the files from all other patches and products that previously 
were installed.  This can clearly involve a large number of files and
a large archive of old file versions and a substantial quantity of
disk space.  While removal is clearly theoretically possible, it is
not currently implemented.

The following is the supported mechanism to remove a PCSI patch kit.

(1) Execute a PRODUCT SHOW PRODUCE <product-name. /FULL command.
    The "MAINTENANCE" column (132 col width) shows the patches that
    have been installed.  Keep a copy of this.

(2) Re-install the prior FULL version of the product.  This will
    remove all patch kits, setting to product back to "original" 

(3) Re-install all the patches in the list from step 1, *EXCEPT*
    those which you have determined you do not want.

The above information also applies to PCSI PARTIAL kits.

MGMT57. SYSINIT-E, error mounting system device, status=0072832C

  This message can arise during an OpenVMS system bootstrap...

  %MOUNT-F-DIFVOLMNT, different volume already mounted on this device

  For details and further information, use the DCL command:


MGMT58. Performing SET HOST/MOP in DECnet-Plus?


  Let's say you have a circuit known as FDDI-0.
  Here is an example of the SET HOST/MOP command syntax:


  Also see MGMT13.

MGMT59. Resolving License PAK Problems?

  The PAK release date, the PAK termination date, and the PAK version
  are the usual culprits when a license product authorization key (PAK)
  check failure occurs.

  The PAK termination date is the date when the license PAK will expire.

  The PAK release date is the date of the most recent release date of the
  software package that will be permitted by the particular license PAK.
  (The release date check is analogous to a product version check.)
  The PAK version indicates the most recent product version that is
  permitted by the license.

  Having multiple license PAKs registered (and active) can also cause
  problems if an expired PAK gets loaded.  You will want to DISABLE
  license PAKs you do not wish to have loaded.

  Other problems include a failure to register each PAK in all license
  databases throughout a multiple-system-disk cluster, with a consistent
  set of /INCLUDE lists specified across each of the duplicated PAKs.

  Additionally, you could have an invalid LMF$LICENSE logical name defined.
  (If no LMF$LICENSE logical name is defined, the standard license database
  named SYS$SYSTEM:LMF$LICENSE.LDB will be used.)

  You can display license failures by defining the following logical name:


  Enable your terminal as a license operator (REPLY/ENABLE=LICENSE), define
  the LMF$DISPLAY_OPCOM_MESSAGE logical name, and then try the failing
  operation again.  You should see one or more OPCOM messages displayed.

  If you have the LMF$DISPLAY_OPCOM_MESSAGE logical name defined, you can
  (will?) see spurious license check failures -- various products will
  check for multiple licenses, and a few products will check for PAKs that
  either have not yet been or will not be issued.  Once you figure out which
  license has failed, you will want to deassign this logical name.

  Note: that there is no license check failure does NOT indicate that
  the particular product or operation is permissible per the license.

  To register a license PAK on a DECwindows system when DECwindows cannot
  start (because of an expired license or other licensing problem), follow 
  the steps outlined in section MGMT5 up through step 4 (inclusive).  Using 
  the console -- analogous to what is done in step 5 to access the OpenVMS
  AUTHORIZE utility -- use the console to register the license PAKs.

[End of Part 2/5]

 --------------------------- pure personal opinion ---------------------------
   Hoff (Stephen) Hoffman   OpenVMS Engineering

Inferno Solutions
Hosting by

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру