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:
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:
The undocumented DCL command CHECKSUM is the usual means, and provides a rather simple-minded checksum suitable to detect basic file corruptions. For information and an OpenVMS version of the MD5 checksum tool, see:
The OpenVMS Alpha ECO (patch) kit checksums available at the ECO website are determined using the following DCL command sequence:
$ CHECKSUM kitname.pcsi-dcx_axpexe $ 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:
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 184.108.40.206.
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:
$ LIBRARY/TEXT/CREATE - SYS$COMMON:[SYSLIB]HP4050_DEVCTL.TLB LPS$$UNRECOGNIZED*
$ DEFINE/SYSTEM/EXECUTIVE DCPS_HP4050_LIB - SYS$LIBRARY:HP4050_DEVCTL.TLB, - SYS$LIBRARY:DCPS$DEVCTL.TLB
to create your own site-specific:
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.
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
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:
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?
5.41.1 Why isn't BACKUP/SINCE=BACKUP working?
If you are seeing more files backed up than previously, you are seeing
the result of a change that was made to ensure BACKUP can perform an
incrementation restoration of the files. In particular, if a directory
file modification date changes, all files underneath it are included in
the BACKUP, in order to permit incremental restoration should a
directory file get renamed.
220.127.116.11 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.
18.104.22.168 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:
When working with BACKUP, you will want to:
When working with the BACKUP callable API: