What is an installed image?

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.

Are there any known viruses for OpenVMS?

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]

Rocksoft offers the Veracity data integrity tool (for info, send mail to demo@rocksoft.com).

[Contributions to this list welcomed]

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

• OpenVMS VAX V6.0
• OpenVMS AXP V1.5

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.

					[dunham@star.enet.dec.com]
					[Stephen Hoffman]

  http://pdp-11.trailing-edge.com/www/ods1.txt

How do I extract the contents of a PCSI kit?

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

    DEC-VAXVMS-FORTRAN-V0603-141-1.PCSI

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 example:
   VAX:

             B/1
             B/R5:1
             @GENBOO
   

   
   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:
   VAX:

             B/E0000001
             B/R5:E0000001
             @<console media procedure name varies widely>
   

   
   Alpha:

             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 parameter changes for subsequent system reboots:

           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
   

   
   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 registering 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
           RUN SYS$SYSTEM:AUTHORIZE
           MODIFY SYSTEM /PASSWORD=newpassword
           EXIT
   
   

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:

     SHOW MAXPROCESSCNT
     SET . 64
     CONTINUE

					[Steve Hoffman]

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

   $ INITIALIZE/QUEUE/ON="123.456.789.101:9100"/PROCESSOR=UCX$TELNETSYM  -
                my_ip_queue

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.

					[Steve Reece]
                                        [Arne Vajhøj]

Why can't I do a SET TIME command? Help managing DTSS

How do I change the node name of an OpenVMS System?

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.

1. Update the SCSNODE in MODPARAMS.DAT, and then run AUTOGEN as far as the SETPARAMS phase. (Do not reboot yet.)
2. Modify the DECnet node name. (NETCONFIG is the DECnet Phase IV tool, and NET$CONFIGURE is the DECnet-Plus tool.)
3. Modify the IP node name. (The UCX tool is UCX$CONFIG.)
4. 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.)
5. 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.)
6. Rename the SYS$NODE_oldnodename rightslist identifier to match the new name. (Do not change the binary value of this identifier.)
7. Reset any license PAKs that are restricted to the old node name to the new node name.
8. If the node name is part of a disk volume label see MGMT19
9. 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...

					[Steve Hoffman]

What is the correct value for EXPECTED_VOTES in a VMScluster?

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.

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.

						[Steve Hoffman]

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

      $ @SYS$UPDATE:AUTOGEN GETDATA REBOOT FEEDBACK

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, to indicate that all available memory should be used.

						[Steve Hoffman]

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:

  RECORD
        FORMAT                  fixed
        SIZE                    8192

Then create BACKUP_SERVER.COM:

  $ !
  $ ! 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, do:

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

Unfortunately BACKUP can't read tapes over the network because the RMS file attributes on a network task access look wrong (variable length records).

						[Steve Hoffman]

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:

      $ RUN SYS$SYSTEM:SYSMAN
      SYSMAN> IO CONNECT FYA0/NOADAPTER/DRIVER=SYS$FYDRIVER

      $ RUN SYS$SYSTEM:SYSGEN
      SYSGEN> CONNECT FYA0/NOADAPTER

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

						[Steve Hoffman]

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. Select the DCL ($$$ prompt) option. Then issue the commands:

    $$$ DEFINE/SYSTEM PCSI$SYSDEVICE DKA0:
    $$$ DEVINE/STSTEM PCSI$SPECIFIC DKA0:[SYS0.]
    $$$ PRODUCT RECONFIGURE VMS /REMOTE/SOURCE=DKA0:[VMS$COMMON]

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

						[Steve Hoffman]

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

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

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

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.

What are the OpenVMS version upgrade paths?

Note: See the OpenVMS Alpha Terminology section, below.

OpenVMS Alpha release upgrade paths:

From :	one can upgrade to :
1.0	1.5
V1.5, or V1.5-1H1	V6.1
V6.1	V6.2
V6.2	V6.2-1H1, V6.2-1H2, or V6.2-1H3
V6.1 or V6.2	V7.0
V6.1, V6.2, V6.2-1H(1,2,3) or V7.0	V7.1
V6.2, V6.2-1H(1,2,3), V7.1, V7.1-1H(1,2), or V7.2	V7.2-1
V7.1	V7.1-1H(1,2) , V7.1-2, V7.2, V7.2-1

Some typical OpenVMS Alpha upgrade paths are:

V1.0	->	V1.5	->	V6.1	->	V6.2, V7.0, or V7.1
V6.2	->	V6.2-1H3
V1.5-1H1	->	V6.1	->	V6.2, V7.0, or V7.1
V6.2-1H(1,2,3)	->	V7.1
V6.2-1H(1,2,3)	->	V7.2-1
V7.1	->	V7.1-1H(1,2)
V7.1	->	V7.1-2
V7.1	->	V7.2-1
V7.1-1H(1,2)	->	V7.2-1

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 :	one can upgrade to :
V5.0 through V5.4-3 inclusive	V5.5
V5.5, V5.5-1, or V5.5-2HW	V5.5-2
V5.5, V5.5-1, or V5.5-2	V6.0
V5.5-2, V5.5-2H4, or V6.0	V6.1
V6.0, or V6.1	V6.2
V6.1, or V6.2	V7.0
V6.1, V6.2, or V7.0	V7.1
V6.1   (with VAXBACK ECO for V6.1)	V7.2

Some typical OpenVMS VAX upgrade paths are:

V5.x	->	V5.5	->	V6.0	->	V6.2	->	V7.0, or V7.1
V5.5-2, or V5.5-2H4	->	V6.1	->	V6.2, V7.0, or V7.1
V6.1	->	VAXBACK V6.1 ECO	->	V7.2
V6.2	->	V7.2

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.

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

VMScluster 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 VMScluster than what is listed here.

See the OpenVMS <platform> Version <Version> Upgrade and Installation Manual, and the OpenVMS Software Product Description

     http://www.compaq.com/info/spd/)

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:

          http://www.compaq.com/services/software/ss_mature.html
          http://www.compaq.com/services/software/ss_pvs_se_amap.html
          http://www.compaq.com/services/software/ss_mps_pvs_eur.html

       http://www.openvms.compaq.com/openvms/os/swroll/index.html

       http://www.openvms.compaq.com/openvms/os/openvms-release-history.html

       http://www.openvms.compaq.com/openvms/20th/vmsbook.pdf

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.

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

					[Steve Hoffman]

Do I have to update layered products when updating OpenVMS?

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:

    http://www.openvms.compaq.com/openvms/os/swroll/index.html

					[Steve Hoffman]

How do I change the volume label of a disk?

1. Dismount the disk, and mount it privately. If the disk is mounted by more than one node in an OpenVMS Cluster, dismount it from all other nodes. If this disk is an OpenVMS system disk, shut down all other nodes that are bootstrapped from this disk.
2. Issue the SET VOLUME/LABEL command, specifying the new label.
3. 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.
4. 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.

5. Remount the disk appropriately.

					[Stephen Hoffman]
                                        [John E. Malmberg]

How do I fix a corrupt BACKUP saveset?

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:

    $ @RESET_BACKUP_SAVESET_ATTRIBUTES.COM

In various cases (note that not all savesets use the default record size!), the following command might work:

    $ SET FILE/ATTRIBUTES=(RFM:FIX,MRS:32256,LRL:32256,RAT:NONE) file.bck

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

    ftp://host/url?type=binary

					[Stephen Hoffman]

How can I set up a shared directory?

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:

  ADD/IDENTIFER/ATTRIBUTES=RESOURCE groupidentifier

  GRANT/IDENTIFIER groupidentifier username

  DISKQUOTA ADD groupidentifier/PERMQUOTA=pq/OVERDRAFT=od/DEVICE=ddcu:

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

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.

Why do I get extra blank pages on my HP Printer?

    http://www.openvms.compaq.com/wizard/
    http://www.openvms.compaq.com/wizard/wiz_1020.html

Also seeMGMT51.

					[Stephen Hoffman]

How do I configure ELSA GLoria Synergy or PowerStorm 300/350 graphics?

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

    VMS72_GRAPHICS-V0100 or later
    VMS712_GRAPHICS-V0300 or later

    DISK$ALPHA0721:[ELSA.KIT]

OpenVMS V7.2-1H1 and later should directly support the controller.

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

    DEC-AXPVMS-VMS721_P350-V0100--4 or later
    DEC-AXPVMS-VMS721_GRAPHICS-V0300--4 or later

					[Stephen Hoffman]

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

  http://search.service.digital.com/
  ftp://ftp.service.digital.com/public/vms/
  http://ftp.digital.com.au/pub/ecoinfo
  http://ftp.digital.com.au/cgi-bin/grep

  http://www.service.digital.com/patches/mailing-list.shtml

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

  http://www1.service.digital.com/svctools/decevent/md5-instructions.html


					[Stephen Hoffman]

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

From OpenVMS:

    $ RUN SYS$SYSTEM:SYSGEN
    SYSGEN> CONNECT FYA0/NOADAPTER
    SYSGEN> ^Z
    $ SET HOST/DUP/SERV=MSCP$DUP/TASK=PARAMS <DSSI-NODE-NAME>
    ...
    PARAMS> STAT CONF
    <The software version is normally near the top of the display.>
    PARAMS> EXIT
    ...

Integrated DSSI:

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

KFQSA:

        >>> SET HOST/DUP/UQSSP port_controller_number PARAMS

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]

How do I move the queue manager database?

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.

   	$ mcr JBC$COMMAND
   	JBC$COMMAND> DIAG 0 7
   

2. Stop the queue manager

   	$STOP/QUEUE/MANAGER/CLUSTER
   

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]
   

					[Dave Sweeney]

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

  $ TCPIP SET ROUTE/GATE=x.x.x.x/DEF/PERM

  $ UCX SET ROUTE/GATE=x.x.x.x/DEF/PERM

How do I delete an undeletable/unstoppable (RWAST) process?

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

					[Stephen Hoffman]

How do I reset the error count(s)?

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

$ ANALYZE/SYSTEM
SDA>  READ SYS${SYSTEM|LOADABLE_IMAGES}:SYSDEF.STB
SDA>  SHOW DEVICE <ddnc:>    ! device designation of device with error
SDA>  EVALUATE UCB+UCB${W|L}_ERRCNT
Hex = hhhhhhhh   Decimal = -dddddddddd         UCB+offset

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

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. Remember 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 enter the system address and view its contents. The format of the command to do this is of the form:

<IPID>:<hhhhhhhh>/

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

00010001:hhhhhhhh/

00010001:80D9C6C8/0001                          ! output on VAX    1 error

00010001:80D9C6C8/00000001                      ! output on Alpha  1 error

00010001:80D9C6C8/0001 0<cr>                    ! output on VAX    1 error
00010001:80D9C6C8/00000001 0<cr>                ! output on Alpha  1 error

                                      [Brian Schenkenberger]

How do I find out if the tape drive supports compression?

    $ 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_sup THEN -
        WRITE SYS$OUTPUT "Compression enabled"

Can I copy SYSUAF to another version? To VAX? To Alpha?

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:

• applications often hold SYSUAF or RIGHTSLIST open, meaning a system reboot is often the best way to activate new files.
• the meanings of the RESTRICTED and CAPTIVE flags settings on the UAF entries have changed over time.
• 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.
• 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.

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.

					[Stephen Hoffman]

How do I delete (timeout) idle processes?

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.

Why isn't BACKUP/SINCE=BACKUP working?

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.

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

Please see the documentation around the TCP/IP Services for OpenVMS TELNET command CREATE_SESSION. This command is the equivalent 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.

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

Please see the DECevent FAQ for additional details:

      http://www1.service.digital.com/svctools/decevent/DECevent_FAQ.html

INITIALIZE ACCVIO and ANSI tape label support?

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.

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]

How do I recover from INSVIRMEM errors?

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.

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

    SET TERMINAL/NOTYPEAHEAD/PERMANENT ddcu:

How does PCSI use the image BUILD_IDENT field?

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 descripton 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:

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

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.

How to configure allocation classes and Multi-Path SCSI?

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]

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

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) in VMSINSTAL.HISTORY.

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
    C++   CXX/VERSION

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

 http://www.openvms.compaq.com/openvms/fibre/index.html

How can I split up an OpenVMS Cluster?

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

1. First: Create restorable image BACKUPs of each of the current system disks. If something gets messed up, you want a way to recover, right?
   
2. Create standalone BACKUP kits for the OpenVMS VAX systems, and create or acquire bootable BACKUP kits for the OpenVMS Alpha systems.
   
3. Use CLUSTER_CONFIG or CLUSTER_CONFIG_LAN to remove the various system roots and to shut off boot services and VMScluster settings.
   
4. 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.
   
5. Relocate the copies of the VMScluster common files onto each of the new system disks.
   
6. Reset the console parameters and boot flags on each system for use on a standalone node.
   
7. Reset the VAXCLUSTER and NISCS_LOAD_PEA0 parameters to 0 in SYSGEN and in MODPARAMS.DAT.
   
8. Clobber the VMScluster group ID and password using SYSMAN.
   
9. Reboot the systems seperately, and run AUTOGEN on each.
   
10. Shut off MOP services via NCP or LANCP on the boot server nodes.

Permanent separation 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
NETNODE_REMOTE	SYS$SYSTEM:.DAT
QMAN$MASTER	SYS$SYSTEM: (this is a set of related files)
LMF$LICENSE	SYS$SYSTEM:.LDB
VMSMAIL_PROFILE	SYS$SYSTEM:.DATA
VMS$OBJECTS	SYS$SYSTEM:.DAT
VMS$AUDIT_SERVER	SYS$MANAGER:.DAT
VMS$PASSWORD_HISTORY	SYS$SYSTEM:.DATA
NETNODE_UPDATE	SYS$MANAGER:.COM
VMS$PASSWORD_POLICY	SYS$LIBRARY:.EXE
LAN$NODE_DATABASE	SYS$SYSTEM:LAN$NODE_DATABASE.DAT

Information on changing node names is included in MGMT9.

What file checksum tools are available for OpenVMS?

  http://www.service.digital.com/svctools/decevent/md5-instructions.html

  CHECKSUM kitname.pcsi-dcx_axpexe
  SHOW SYMBOL CHECKSUM$CHECKSUM

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:

• VMS$DISK_CL_DRIVER connects to MSCP$DISK
  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
• VMS$TAPE_CL_DRIVER connects to MSCP$TAPE
  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
• VMS$VAXCLUSTER connects to VMS$VAXCLUSTER
  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.
• SCS$DIR_LOOKUP connects to SCS$DIRECTORY
  This SYSAP is used to find SYSAPs on remote systems
• MSCP and TMSCP
  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:

  SYS$EXAMPLES:LAVC$STOP_BUS 
  SYS$EXAMPLES:LAVC$START_BUS 

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:

  SYS$EXAMPLES:PREFER.MAR

  SET PREFERED_PATH

                              [Kevin Jenkins, Verell Boaen, John Croll]

What (and where) is the OpenVMS Management Station?

    http://www.openvms.compaq.com/openvms/products/argus/

How to determine current disk fragmentation level?

  $ DEFRAG SHOW/VOLUME ddcu:

  DFU> REPORT ddcu:

SYSBOOT-I-FILENOTLOC, Unable to locate SYS$CPU_ROUTINES?

%SYSBOOT-I-FILENOTLOC, Unable to locate SYS$CPU_ROUTINES_1C02.EXE
%SYSBOOT-E-LDFAIL, failed to load execlet, status = 00000910

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"
  $

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

• 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.)
• rename each extracted setup module to a corresponding: LPS$$UNRECOGNIZED_*
• Insert all of the above-renamed setup modules into a newly-created device control library specific to the new printer:

        $ LIBRARY/TEXT/CREATE -
            SYS$COMMON:[SYSLIB]HP4050_DEVCTL.TLB 
            LPS$$UNRECOGNIZED*
  

  The above assumes the filename HP4050_DEVCTL.TLB, alter as required.
• Set up your DCPS startup procedures to include a search-list logical name such as:

       $ DEFINE/SYSTEM/EXECUTIVE DCPS_HP4050_LIB  -
           SYS$LIBRARY:HP4050_DEVCTL.TLB, -
           SYS$LIBRARY:DCPS$DEVCTL.TLB
  

• Supply DCPS_HP4050_LIB as the library parameter in the queue startup for this printer, this is the P3 parameter to the command procedure SYS$STARTUP:DCPS$EXECUTION_QUEUE.COM.
• 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.

                                         [Ken Fairfield, with typos 
                                         introduced by Stephen Hoffman]

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

                                         [Stephen Hoffman]

What software is needed for Postscript printers?

Does volume shadowing require a non-zero allocation classes?

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:

  ALLOCLASS = 7

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

                                              [Veli Korkko]

How can I reset the TCP/IP Services default IP gateway?

      $ UCX SET ROUTE/GATEWAY=x.x.x.x/DEFAULT_ROUTE/PERMANENT

      $ TCPIP SET ROUTE/GATEWAY=x.x.x.x/DEFAULT_ROUTE/PERMANENT

How do I remove a PCSI-installed 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"" condition.
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.

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

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

    $ HELP/MESSAGE /STATUS=%X72832C