HP OpenVMS Systems Documentation

The OpenVMS Frequently Asked Questions (FAQ)

In SYSTARTUP_VMS.COM, issue the command:

$ SET TERMINAL/NOTYPEAHEAD/PERMANENT ddcu:

This will prevent any unsolicited terminal input on ddcu:, and this unsolicited input is what triggers JOB_CONTROL to start up LOGINOUT on the terminal. Once LOGINOUT starts up on the serial line, you can see interesting behaviour (eg: audits, process creations, etc) as LOGINOUT tries to "chat" with whatever device is hooked onto the remote end of the serial terminal line.

5.28 How does PCSI use the image BUILD_IDENT field?

The (undocumented) build ident field in an OpenVMS Alpha image header is 16 bytes long, and is used as a counted string of 0-15 characters (ie, as an .ASCIC string, a string with the character count in byte 0) and was originally introduced to provide information for use by VMSINSTAL patch kits to determine whether an image should be replaced or not.

Starting with OpenVMS Alpha V7.1-2, OpenVMS Engineering uses the PCSI utility to package and install ECO kits for OpenVMS. PCSI uses the generation attribute (a 32-bit unsigned integer) specified for files in the product description file (PDF) of a PCSI kit as the basis for performing file conflict detection and resolution. When a product is installed, PCSI modifies the build ident field of Alpha image headers to store an encoded form of the generation number. It also looks at the build ident field of previously installed images to obtain the generation information for those files as input to the file conflict processing algorithm. (Only images have this field, obviously.)

PCSI interprets the build ident field of a previously installed image as follows:

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

Ranges of PCSI generation numbers for various OpenVMS releases are included in Table 5-1. The use of xxxx indicates a range of generations is available, from 0000 to 9999, inclusive. The format of, the particular operation of, and the assignment of PCSI generation numbers is subject to change without notice.

There is unfortunately 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) 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
• TCP/IP TCPIP SHOW VERSION command

The undocumented (prior to V8.2) DCL command CHECKSUM is the usual means, and provides a rather simple-minded checksum suitable to detect basic file corruptions. Starting with V8.2, additional algorithms beyond the classic XOR scheme are available.

One of the most common schemes beyond the CHECKSUM XOR scheme is MD5, and information and a source code example are available via the MD5 RFC. As of this writing, pre-built versions of MD5 are expected to be made available at or via the OpenVMS Freeware website ( http://www.hp.com/go/openvms/freeware/ ), and MD5 is expected to be made available on an OpenVMS Freeware release after V7.0. Also see the CHECKSUM/ALGORITHM=MD5 command on OpenVMS V8.2 and later.

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
$ SHOW SYMBOL CHECKSUM$CHECKSUM

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

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

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

The HP 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:

$ DEFRAG SHOW/VOLUME ddcu:

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

DFU> REPORT ddcu:

A message at the OpenVMS Alpha bootstrap such as the following:

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

indicates that the particular OpenVMS Alpha 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. Ensure that you have the most current firmware, and review the minimum version requirements for the platform.

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

Also see Section 14.4.4.1.

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

• 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.
• To customize the processing of file extensions within DCPS (to enable or disable graybar output, for instance), use the information available in:

  SYS$LIBRARY:DCPS$FILE_EXTENSION_DATA_TYPE.DAT_DEFAULT

to create your own site-specific:

SYS$LIBRARY:DCPS$FILE_EXTENSION_DATA_TYPE.DAT

Also see Section 5.15.

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

5.36 What software is needed for Postscript printers?

The NorthLake PrintKit (www.nls.com) and DECprint Supervisor (DCPS) are common choices for support of Postscript printers on OpenVMS.

• http://www.nls.com/
• http://www.openvms.compaq.com/openvms/Print/print_sw_prods.html

You may also require the installation of an IP transport stack.

Also please see Section 15.2.2 and Section 15.2.3.

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

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

In order to remove an ECO kit, 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 PRODUCT product-name. /FULL command. The "maintenance" column (132 column width) shows the patches that have been installed. Keep a copy of this listing.
2. Acquire kits for all of the maintenance kits listed.
3. Re-install the prior FULL version of the product. This will remove all patch kits, setting to product back to "original" condition.
4. Re-install all the patches in the list from step 1, except those patches which you have determined you do not want.

The above information also applies to PCSI PARTIAL kits.

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

$ HELP/MESSAGE /STATUS=%X72832C

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:

$ DEFINE/SYS/EXEC LMF$DISPLAY_OPCOM_MESSAGE TRUE

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.

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 Section 5.6 up through the use of the AUTHORIZE command. In place of the AUTHORIZE command, use the console to register the license PAKs. Also see Section 12.4 for licensing and troubleshooting information.

For information on licensing and on the numbers of license units required for various products and various platforms, the License Unit Requirements Table (LURT) is available at:

• http://h18000.www1.hp.com/products/software/info/

Fool your friends, baffle your enemies, run the OpenVMS version of your choice!

On OpenVMS Alpha systems:

$ SET DEFAULT SYS$COMMON:[SYS$LDR]
$ RUN SYSVER
REPLACE V9.9
WRITE
$ EXIT

On OpenVMS VAX systems:

$ set default SYS$COMMON:[SYS$LDR]
$ copy SYS.EXE SYS.EXE_IN-CASE-I-FAIL
$ patch SYS.EXE
define sys$gq_version=800044b8
set mode ascii
!examine sys$gq_version
!examine sys$gq_version+4
deposit sys$gq_version   = "V9.9"
deposit sys$gq_version+4 = "    "
update
exit
$ Exit

Then reboot the system at your leisure.

5.41 How to prevent users from choosing obvious passwords?

To prevent users from selecting obvious passwords on OpenVMS, you will want to use the reserved password (password screening) mechanism. Effectively, you merge your list of reserved passwords into the existing reserved words database maintained by OpenVMS. (You can also then require all users to reset their passwords---via the pre-expired password mechanism---thus forcing users to select new passwords.) For details on the password screening mechanism, of the reserved password database (VMS$PASSWORD_DICTIONARY.DATA), and details of how to merge your list of prohibited passwords into the database, please see the associated chapter in the OpenVMS security manual. For details of the password expiration mechanism, see the AUTHORIZE command qualifier /PWDEXPIRED.

You can also implement a site-specific password filter with the information provided in the back of the OpenVMS Programming Concepts manual. The password filter permits you to establish particular and site-specific password requirements. For details, please see the system parameter LOAD_PWD_POLICY and the programming concepts manual, and see the examples in SYS$EXAMPLES:. (Examples and documentation on V7.3 and later reflect both platforms, the examples are found only on OpenVMS VAX kits on earlier releases. The capabilities have existed on both the VAX and Alpha platforms for some time now.)

To verify current passwords, you can also use a technique known to system crackers as the "dictionary attack" -- the mechanism that makes this attack somewhat more difficult on OpenVMS is the hashing scheme used on OpenVMS, and the file protections used for the SYSUAF authorization database. Given a dictionary of words and the unprotected contents of the SYSUAF file, a search for obvious passwords can be performed. Interestingly, a "dictionary attack" also has the unfortunate side-effect of exposing the password to the user---while this is clearly the goal of a system cracker, authorized privileged and non-privileged system users should not know nor have access to the (cleartext) passwords of other users.

Accordingly, OpenVMS does not store the cleartest password. Further, OpenVMS uses a password hashing algorithm, not an encryption algorithm. This means that storage of a cleartext password is deliberated avoided, and the cleartext value is deliberately very difficult to obtain. The hash is based on a Purdy Polynomial, and the hash itself includes user-specific values in addition to the password, values that make the results of the password hash unique to each user.

Regardless of the use of a password hashing scheme, if a copy of your password file should become available to a system cracker, you will want to force all users to use new passwords immediately.

If you should require a user to verify a password, use the username, the user's salt value (this value is acquired via $getuai) and the user's specified cleartext password, and compare the resulting hashed value (using a call to $hash_password) against the saved hashed password value (this value also acquired via $getqui). For reasons of security, avoid saving a cleartext password value in any data files, and do not maintain the cleartext password in memory longer than required. (Use of sys$acm on V7.3-1 and later is recommended.)

Kerberos authentication (client and server) is available on OpenVMS V7.3 and later. Integration of Kerberos support into various Compaq and into third-party products is expected.

External authentication is available in V7.3-1 and later, with support for user-written external authentication in V7.3-2 and later.

If you are simply looking for OpenVMS access and the SYSTEM and all other privileged passwords are forgotten or otherwise unavailable, please see section Section 5.6 and/or the OpenVMS documentation set.

Also please see the NCSC C2 guidelines in the OpenVMS security manual.