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

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

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

• http://www.support.compaq.com/svctools/md5-instructions.html

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.16 for information on acquiring OpenVMS ECO (patch) kits.

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

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

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.33 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.14.

5.34 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.35 What software is needed for Postscript printers?

The NorthLake PrintKit (http://www.nls.com/) and DECprint Supervisor (DCPS; http://www.openvms.compaq.com/openvms/Print/print_sw_prods.html) are common choices for support of Postscript printers on OpenVMS.

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

Also please see Section 15.2.2 and Section 15.2.3.

5.36 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 PRODUCE <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.37 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

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

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

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 Section 5.5 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.5 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://www.compaq.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.40 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 $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.5 and/or the OpenVMS documentation set.

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

5.41 Please help me with the OpenVMS BACKUP utility?

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.

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

Consider performing an incremental restoration, to test the procedures. This testing was how OpenVMS Engineering found out about the problem that was latent with the old BACKUP selection scheme---the old incremental BACKUP scheme would have missed restoring any files under a renamed directory. Hence the change to the selection mechanisms mentioned in Section 5.41.1.

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

5.41.2 What can I 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.

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

5.41.3 Why is BACKUP not working as expected?

First, PLEASE READ THE BACKUP MANUAL.

Second, PLEASE GET THE CURRENT BACKUP ECO KIT.

Third, PLEASE SET THE PROCESS QUOTAS PER THE DOCUMENTATION.

BACKUP has a very complex interface, and there are numerous command examples and extensive user documentation available. For a simpler user interface for BACKUP, please see the documentation for the BACKUP$MANAGER tool.

As for recent BACKUP changes, oddities, bugs, etc:

• A change made in OpenVMS V6.2 WILL cause more files to be included into a file-based BACKUP saveset using /SINCE=BACKUP as all files underneath any directory with a sufficiently recent (selected) date will be included in the saveset. This change was deliberate and intentional, and was mandated by the need to provide a functional incremental restoration.
  Without the inclusion of these apparently-extra files, an incremental saveset can NOT be reliably restored.
• As part of the OpenVMS V6.2 change, the /SINCE command---without the specification of the =BACKUP keyword---selected more files than it should have. This is a bug. This bug has been remedied in the OpenVMS BACKUP source code and in some of (all of?) the BACKUP ECO kits.

When working with BACKUP, you will want to:

• Ensure you have your process quotas set per the recommendations in the OpenVMS System Management documentation. Deviation from these values can and will lead to access violation (ACCVIO) and other untoward behaviour.
• Get the current BACKUP ECO kit and install it BEFORE you attempt to troubleshoot any problems.
• Learn about the /NOINCREMENTAL (new) and /NOALIAS (V6.2 and later) command qualifiers. The former qualifier returns to the pre-V6.2 behaviour of the /SINCE file selection mechanism, while the latter (specified with /IMAGE) reduces the replication of files on system disks and other disks with file alias and directory alias entries. Both of these can reduce the numbers of files that will be selected and thus included into the saveset.
  Learn what /IGNORE=INTERLOCK means. This command probably does not provide what you think it does---those file system interlocks that this command is ignoring were implemented for a reason, after all. Ignoring these interlocks can lead to missed data and potentially to corruptions to individual files stored within the output saveset, corruptions that may or may not be reported. For details on this BACKUP command qualifier, please see the Ask The Wizard topic (2467).

When working with the BACKUP callable API:

• Build your applications with the most current BACKUP API available. Changes made to the V7.1-2 and V7.2 API were incompatible with the V7.1 and V7.2-1 and later APIs, and this incompatibility was repaired via a BACKUP ECO kit. Do NOT build your application with the versions of the BACKUP API that shipped with V7.1-2 and V7.2, as these are incompatible with the BACKUP API constants that were used on other versions.