HP OpenVMS Systems Documentation
The OpenVMS Frequently Asked Questions (FAQ)
5.27 How can I prevent a serial terminal line from initiating a login?
In SYSTARTUP_VMS.COM, issue the command:
This will prevent any unsolicited terminal input on ddcu:, and this
unsolicited input is what triggers JOB_CONTROL to start up LOGINOUT on
the terminal. Once LOGINOUT starts up on the serial line, you can see
interesting behaviour (eg: audits, process creations, etc) as LOGINOUT
tries to "chat" with whatever device is hooked onto the
remote end of the serial terminal line.
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:
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.
5.29 How can I tell what software (and version) is installed?
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:
5.30 What file checksum tools are available for OpenVMS?
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:
See Section 5.17 for information on acquiring OpenVMS ECO (patch) kits.
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:
5.32 How to determine current disk fragmentation level?
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:
The DFU tool available on the OpenVMS Freeware can generate a report on the disk fragmentation:
5.33 SYSBOOT-I-FILENOTLOC, Unable to locate SYS$CPU_ROUTINES?
A message at the OpenVMS Alpha bootstrap such as the following:
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:
To customize DCPS for an otherwise unsupported printer, you can try the following sequence:
to create your own site-specific:
MOUNTCNT returns the local mount count, while SHOW DEVICE returns the
cluster-wide mount count.
The NorthLake PrintKit (www.nls.com) and DECprint Supervisor (DCPS) 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.
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.
The above information also applies to PCSI PARTIAL kits.
This message can arise during an OpenVMS system bootstrap...
For details and further information, use the DCL command:
5.39 Resolving License PAK Problems?
The PAK release date, the PAK termination date, and the PAK version are the usual culprits when a license product authorization key (PAK) check failure occurs.
The PAK termination date is the date when the license PAK will expire.
The PAK release date is the date of the most recent release date of the software package that will be permitted by the particular license PAK. (The release date check is analogous to a product version check.) The PAK version indicates the most recent product version that is permitted by the license.
Having multiple license PAKs registered (and active) can also cause problems if an expired PAK gets loaded. You will want to DISABLE license PAKs you do not wish to have loaded.
Other problems include a failure to register each PAK in all license databases throughout a multiple-system-disk cluster, with a consistent set of /INCLUDE lists specified across each of the duplicated PAKs.
Additionally, you could have an invalid LMF$LICENSE logical name defined. (If no LMF$LICENSE logical name is defined, the standard license database named SYS$SYSTEM:LMF$LICENSE.LDB will be used.)
You can display license failures by defining the following logical name:
Enable your terminal as a license operator (REPLY/ENABLE=LICENSE), define the LMF$DISPLAY_OPCOM_MESSAGE logical name, and then try the failing operation again. You should see one or more OPCOM messages displayed.
If you have the LMF$DISPLAY_OPCOM_MESSAGE logical name defined, you can (will?) see spurious license check failures---various products will check for multiple licenses, and a few products will check for PAKs that either have not yet been or will not be issued. Once you figure out which license has failed, you will want to deassign this logical name.
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.
5.40 Changing the OpenVMS Version Number?
Fool your friends, baffle your enemies, run the OpenVMS version of your choice!
On OpenVMS Alpha systems:
On OpenVMS VAX systems:
Then reboot the system at your leisure.
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.)
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.