HP OpenVMS Systems Documentation

The OpenVMS Frequently Asked Questions (FAQ)

The MCR is an artifact of RSX compatibility mode, the operating system from which OpenVMS is descended. MCR is the Monitor Console Routine, and the command is intended to activate RSX compatibility mode utilities. When used on OpenVMS, the command is most commonly used to run the specified image and---because the tool detects the image is not a compatibility-mode image---it acts as a form of RUN command with the default file specification of SYS$SYSTEM:.EXE. MCR passes any (optional) command line arguments in a fashion similar to a foreign command. In other words:

$ MCR FOO BAR

is equivalent to:

 $ FOO :== $FOO
 $ FOO BAR

MCR is not documented. Use of a foreign command or the DCL$PATH mechanism is preferred. For details on this, see Section 8.2.

8.7 How do I change the OpenVMS system prompt?

You can use the SET PROMPT command for this purpose. SET PROMPT sets the DCL prompt to the specified string.

When you want to display variable information, you will need to establish a tie-in that provides the information to the SET PROMPT command as required.

If you wish to display the default directory for instance, you will have to establish a tie between the SET DEFAULT command and the SET PROMPT commands, as there is no direct way to get the default directory as the DCL prompt. You can easily acquire or create a set of DCL command procedures that perform the SET DEFAULT and SET PROMPT for you. These DCL command procedures often use a command such as:

$ set prompt='f$environment("default")'

More advanced users could implement a system service or other intercept, and use these tools to intercept the directory change and reset the prompt accordingly. (This approach likely involves some kernel-mode programming, and requires write access to various undocumented OpenVMS data structures.)

There are related tools available from various sources, including the following web sites:

• ftp://ftp.hhs.dk/pub/vms/setpmt/
• ftp://ftp.tmesis.com/sys_service_hook.src
• James F. Duff has also made available a Macro32 tool known as TIME_PROMPT, a tool that sets the prompt to the current system time.
• Many folks have contributed DCL procedures to perform this task. Visit the newsgroup archives for information and examples.

Yes, you can do this with DCL.

The OpenVMS DECnet documentation shows various simple examples using the task object and the TYPE command to trigger the execution of a DCL command procedure on a remote node. An example DCL command procedure that is rather more advanced than using the TYPE command as a trigger is included in the Ask The Wizard area:

• http://www.hp.com/go/openvms/wizard/

For additional information on the OpenVMS Ask The Wizard (ATW) area and for a pointer to the available ATW Wizard.zip archive, please see Section 3.8.

DCL does not include support asynchronous I/O, thus a predetermined protocol or a predetermined "turn-around" command sequence must be implemented in order to avoid protocol deadlocks---cases where both tasks are trying to write or both tasks are trying to read. The task that is writing messages to the network must write (or write and read) a predetermined sequence of messages, or it must write a message that tells the reader that it can now start writing messages. (This is the essence of a basic half-duplex network protocol scheme.)

8.9 How can I get the width setting of a terminal?

$ width = f$getdvi(terminal,"DEVBUFSIZ")

The DCL symbol substitution processing occurs only at the DCL prompt, not within data and not within files. If you wish to perform symbol substitution in this environment, you typically write a small file containing the command(s) and data to be invoked---potentially only the data---and you then invoke the created procedure or reference the specified data.

In this case, use of a file containing nolinemode commands or other techniques might be useful---you will want to ensure that the text editor you use does not attempt to use screen mode or similar, as this is not generally considered adventageous within a command procedure.

Tools such as FTP have alternatives: COPY/FTP.

DCL symbol substitution occurs in two passes, using the ampersand and the apostrophe. In most cases, only the apostrophe is necessary. In a few cases---such as the DCL PIPE command---you will may need to use the ampersand to get the substitution to work. The following example uses ampersand substitution to transfer the contents of the header into a logical name:

$ PIPE CC/VERSION | (READ SYS$PIPE hdr ; DEFINE/JOB/NOLOG hdr &hdr )

A logical name (in the job logical name table; shared by all processes in the current job) was used as DCL symbols cannot be returned back out from a DCL PIPE or other spawned subprocess.

For related materials, please see Section 8.1 and Section 8.11.

8.11 How can I substitute symbols in a PIPE?

Use DCL ampersand substitution, and not apostrophe substitution.

$ pipe show system | search sys$input opcom | (read sys$input pid ;
    pid=f$element(0," ",pid) ; define/system opcom_pid &pid)
$ show log opcom_pid
    "OPCOM_PID" = "0000020B" (LNM$SYSTEM_TABLE)

With a command to create a detached process such as:

$ RUN/DETACHED SYS$SYSTEM:LOGINOUT /INPUT=TEMP_INPUT.COM

If you are trying to use a logical name as the /INPUT, /OUTPUT or /ERROR on a RUN/DETACH command, then you must translate the logical name specifications to physical references before passing them, or the definitions must reside in a logical name table that is visible to the newly-created process.

Also note that LOGINOUT only creates the SYS$LOGIN, SYS$LOGIN_DEVICE, and SYS$SCRATCH logical names if it is processing a login that is based on the contents of a SYSUAF record---without access to the associated SYSUAF record, this information is not available to LOGINOUT. (If you want to see these particular logical names created, then please specify the /AUTHORIZE qualifier on the RUN/DETACHED command.)

If you do not specify LOGINOUT as the image, then there is no easy way to get these logical names. Also, any logical names that are used in the target image file specification must also be in a logical name table accessible (by default) by the newly-created detached process. Shared tables include the group (if the process is in the same UIC group) and the system table. (If the target process is to be in another UIC group, a suitablly privileged user or application can create the necessary logical name(s) directly in the other group logical name table.)

When in doubt, create a short DCL command file as input, and use a SHOW LOGICAL and similar commands to examine the context. (And use physical device and directory references on the RUN/DETACH of the LOGINOUT image, when specifying this command file as /INPUT.) Also remember to check both security auditing and system accounting when troubleshooting problems with the RUN/DETACH.

Also see Section 8.2.

8.13 How to use escape and control characters in DCL?

To write a message and then the bell character, use:

$ bell[0,7] = 7
$ write sys$output "Hello''bell'"

To write blinking text, use:

$ esc[0,7] = 27
$ text = "Blinking Text"
$ write sys$output "''esc'[5m''text'''esc'[m"

Also see sections Section 11.6, Section 12.1.

If you are searching for something here, please consider using the text-format FAQ.

OpenVMS doesn't have an "undelete" function. However, if you are quick to write-protect the disk or if you can guarantee that no new files get created or existing files extended, your data is still on the disk and it may be possible to retrieve it. The FLORIAN tool available from various websites can potentially recover the file, see question Section 13.1 for pointers. Other alternatives here include the DFU tool, available on the OpenVMS Freeware CD-ROM distribution.

If you are setting up a user environment for yourself or for others, it is quite easy to use DCL to intercept the DELETE command, using a symbol:

$ DEL*ETE :== @SYS$LOGIN:MYDELETE.COM

The DELETE symbol will cause the procedure to be invoked whenever the user enters the DELETE command, and it can copy the file(s) to a "trashcan" subdirectory before issuing a "real" DELETE on the files. Other procedures can retrieve the file(s) from the "trashcan" subdirectory, and can (and should) clean out the "trashcan" as appropriate. (Realize that this DELETE symbol can interfere with DELETE/GLOBAL and other similar DCL commands.)

9.2 Why does SHOW QUOTA give a different answer than DIR/SIZE?

DIRECTORY/SIZE doesn't take into account the size of file headers which are charged to your quota. Also, unless you use DIRECTORY/SIZE:ALL, you will see only the "used" size of the file, not the allocated size which is what gets charged against your quota. Also, you may have files in other directories.

$ DIRECTORY/SIZE=ALL/GRAND [username...]
Grand total of D1 directories, F1 files, B1/B2 blocks.
$ DIRECTORY/SIZZ=ALL/GRAND [-]username.DIR
Grand total of 1 directory, 1 file, B3/B4 blocks.
$ SHOW QUOTA
User [username] has B5 blocks used, B6 available
of B7 authorized and permitted overdraft of B8 blocks on disk

If the user has no files in other directories and all file-headers are only 1 block, then the following should apply:

  B5=B2+B4+F1+1

If the diskquota has drifted out of synchronization, then the system-manager can force a quota rebuild---due to various factors, the quota file can potentially drift from the actual use over time, and a periodic rebuild can be performed at appropriate intervals.

Also be aware that the DIRECTORY/SIZE command can report larger values than might otherwise be expected when used to evaluate files and/or directories that are alias links---such as the system roots on OpenVMS system disks---as the command reports a total that is cumulative over all of the files and directories examined, without regard for which ones might be alias entries and which are not. (In other words, a DIRECTORY/SIZE of an entire OpenVMS system disk will report a disk useage value larger than the (usually more accurate) value reported by the SHOW DEVICE command. This as a result of the alias entries linking each SYS$SYSDEVICE:[SYSCOMMON]SYS*.DIR directory file and the SYS$SYSDEVICE:[000000]VMS$COMMON.DIR file together.)

9.3 How do I make sure that my data is safely written to disk?

If your application must absolutely guarantee that data is available, no matter what, there's really no substitute for RMS Journaling and host- or controller-based shadowing. However, you can achieve a good degree of data integrity by issuing a SYS$FLUSH RMS call at appropriate times (if you're using RMS, that is.) If you're using a high-level language's I/O system, check that language's documentation to see if you can access the RMS control blocks for the open file. In C you can use fflush followed by fsync.

For details on disk bad block handling on MSCP and on SCSI disk devices, please see Ask The Wizard (ATW) topic (6926).

• http://www.hp.com/go/openvms/wizard/

For additional information on the OpenVMS Ask The Wizard (ATW) area and for a pointer to the available ATW Wizard.zip archive, please see Section 3.8.

9.4 What are the limits on file specifications and directories?

A file specification has an aggregate maximum size of 255 characters (NAM$C_MAXRSS) at present, assuming ODS-2 limits and traditional DCL process parsing settings (SET PROCESS/PARSE_STYLE). The node and device specification may be up to 255 characters each---file name and file types may be up to 39 characters each. File versions are from 1 through 32767, though 0 (latest version), -0 (oldest version) and -n (n'th previous version) can be used in most contexts. A file specification may not have more than 8 directories and subdirectories or---with a rooted directory, two sets of eight are possible---and while it is possible to create subdirectories of greater depth, accessing them under ODS-2 is somewhat problematic in most cases, and thus should be avoided.

Under ODS-5 with extended DCL parsing (SET PROCESS/PARSE_STYLE), the filename length limits are up around 4,095 (NAML$C_MAXRSS) characters, and directories can be around 255 levels deep.

Application developers should use OpenVMS-supplied routines for parsing file specifications - this ensures that changes in what is allowable will not tend to break your application. Consider that various parts of the file specification may contain quoted strings with embedded spaces and other punctuation! Some routines of interest are SYS$FILESCAN, SYS$PARSE and LIB$TRIM_FILESPEC. For further information, see the OpenVMS Guide to File Applications.

Performance of larger directory files improves (greatly) with OpenVMS V7.2 and later---operations on directory files of 128 blocks and larger were rather slower on earlier OpenVMS releases due to the smaller size of the directory cache and due to the directory I/O processing logic.

For fastest directory deletions, consider a reverse deletion---delete from the last file in the directory to the first. This reversal speeds the deletion operation by avoiding unnecessary directory I/O operations as the files are deleted. Tools such as the Freeware DFU can be used for this purpose, as can various available reverse-DELETE DCL command procedures.

Also see Section 5.44.

9.5 What is the largest disk volume size OpenVMS can access?

One Terabyte (TB; 2**31 blocks of 2**9 bytes; 0x07FFFFFFF blocks). 255 volumes in a volume set. The largest contiguous allocation possible for any particular file is 0x03FFFFFFF blocks.

Prior to the release of V6.0, the OpenVMS file system was limited to disk volumes of 8.38 GB (2**24 blocks, 16777216 blocks) or less.

On some systems, there are restrictions in the console program that limit the size of the OpenVMS system disk. Note that data disks are not affected by console program limits. For example, all members of the VAXstation 3100 series are limited to a system disk to 1.073 GB or less due to the console, though larger data disks are possible. This limit due to the SCSI drivers used by and built into the console ROM to read the OpenVMS bootstrap files, and these same drivers are also used by OpenVMS to write the system crashdump.

There are numerous discussions of this VAXstation 3100 in the comp.os.vms newsgroup archives. Please use Google newsgroup search to search the archives for further details, for discussions of the workarounds, and for details of the potential for a simple failed bootstrap and particularly for discussions of the potential for severe system disk corruptions on crashes.

Some SCSI disks with capacities larger than 8.58 gigabytes (GB) will require the use of an OpenVMS ECO kit (eg: ALPSCSI04_062 or later; see Section 14.25 for details) for new SCSI device drivers. Failure to use this ECO can cause "rounding errors" on the SCSI disk device capacity---OpenVMS will not use nor display the full capacity of the drive---and "%sysinit-e-error mounting system device status equals 000008C4" (8C4 -> "%SYSTEM-?-FILESTRUCT, unsupported file structure level") errors during bootstrap. (One workaround for the bootstrap when the bitmap is located far into the disk is the use of INIT/INDEX=BEGIN.) The problem here involves the particular extensions and fields used for larger capacity disks within the SCSI specifications and within the various intepretations of same.

For ATA (IDE) disk drives:

• Versions of SYS$DQDRIVER *BEFORE* X-15 topped out at 8.455 GB.
  Fixed drivers (equal or greater than "X-15") were shipped in:
  • OpenVMS Alpha V7.2-1, and later
  • V7.2 UPDATE V1.0 ECO, and later
  • V7.1-2 UPDATE V1.0 ECO, and later
  • V7.1-2 UPDATE V3.0 ECO, and later
• The newer SYS$DQDRIVER driver operates to disks up to 33 GB without (known) problems, and effectively works with rather larger disks (up to circa 137 GB) but is known to report an incorrect number of "cylinders" with disks above 33 GB.

See Section 14.4.4.2 for additional ATA SYS$DQDRIVER information.

Be aware that a known restriction in certain older versions of the Alpha SRM Console prevents booting most ATA (IDE) drives larger than 8.455 GB, depending on exactly where the various files are located on the volume. Updated SRM consoles for systems with SRM and ATA (IDE) drive support are (will be) available. (OpenVMS Engineering has successfully bootstrapped 20GB ATA (IDE) disks using the appropriate SRM console version.)

Be aware that larger disks that are using an extension of SCSI-2--- disks that are using a mode page field that the SCSI-2 specifications normally reserved for tape devices---to permit a larger disk volume size will require a SCSI driver update for OpenVMS, and this change is part of V7.1-2 and later, and also part of ALPSCSI07_062 and later. (These larger disks disks will typically report a DRVERR, or will see the volume size "rounded down".) SCSI disks larger than 16777216 blocks cira 8.455 GB (base ten); 8GB (base two) require this ECO, or require the use of OpenVMS Alpha V7.1-2 or later.

Applications written in C can be limited to file sizes of two gigabytes and less, as a result of the use of longword values within C file operations, and specifically off_t. This restriction is lifted in OpenVMS V7.3-1 and later, and with the application of the C ECO kits available for specific earlier releases. The use of a longword for off_t restricts applications using native C I/O to file sizes of two gigabytes or less, or these applications must use native RMS or XQP calls for specific operations.

Also see Section 14.13, Section 14.25.

9.6 What is the maximum file size, and the RMS record size limit?

RMS can store individual files of a size up to the maximum supported volume size. Under OpenVMS V6.0 and later, the volume size and the RMS maximum file size limit is 2**31 * 512 bytes---one terabyte (1 TB).

"Use a volume set to provide a large, homogeneous public file space. You must use a volume set to create files that are larger than a single physical disk volume. (The file system attempts to balance the load on the volume sets, for example, by creating new files on the volume that is the least full at the time.)"

"You can add volumes to an existing volume set at any time. The maximum number of volumes in a volume set is 255."

The RMS formats---sequential, relative, and indexed---are limited by the one terabyte maximum volume size. RMS relative files are further limited to a number of records that will fit in 32 bits---4 billion records. Sequential and indexed formats do not have a record limit.

Also see Section 2.17.1, Section 14.25.

9.7 How do I write CD-Recordable or DVD media on OpenVMS?

How to create CD-R, CD-RW, DVD-R, DVD+R, DVD-RW, or DVD+RW media on OpenVMS?

For information on CD and DVD optical media drives on OpenVMS, please see Section 14.29. For information on the creation of OpenVMS media and of OpenVMS bootable media, a full step-by-step sequence is documented in the OpenVMS Ask The Wizard topic (9820). An abbreviated version of the sequence is included here.

Recording (writing) of CD and DVD optical media requires a recording or media mastering application or tool, and both commercial and non-commercial options are available. Please see CDRECORD (both non-DVD and DVD versions are available, and at least one commercial version is available), and also see DVDwrite (commercial) or DVDRECORD (open source). A port of CDRECORD is present in OpenVMS V7.3-1 and later.

• Acquire a comparatively recent SCSI-based or ATAPI (IDE) CD-R or DVD-R/RW or DVD+R/RW drive. Older drives can be very problematic, while newer drives are readily available, and are cheap and very fast, and tend to have better compliance with current standards. Use of older drives is not recommended. Related device requirements information is available in Section 14.29.
• Get the most recent LDDRIVER available on the Freeware, or activate and use the LD version latent in OpenVMS Alpha V7.3-1 and V7.3-2 by loading the LD command verb (look within SYS$MANAGER:CDRECORD.COM for related details), or use the integrated LD found in OpenVMS V8.2 and later.
  In particular, you will want to use the current ECO kit for LDDRIVER (as available), or the version of LD distributed with V8.2. The OpenVMS V8.2 version of LDDRIVER was also kitted on Freeware V7.0 as LD071.
  If you are not running OpenVMS V8.2, the specified LD071 kit or later, or a current ECO with the update, you will want to upgrade, or you will want to use the DCL command:

  SET FILE/CACHING_ATTRIBUTES=NO_CACHING

  on the LD partition file. This is a workaround for an incompatibility found between older LDDRIVER versions and the XFC caching support.
  As an alternative to LD and LDDRIVER, you can acquire and load the VD64 package from the Freeware.
• Get CDRECORD or CDWRITE or other similar recording tool.
  CDRECORD (part of CDRTOOLS), CDWRITE, and DVDRECORD (part of DVDRTOOLS) packages (DVDRECORD is a fork of CDRECORD) are freely available, and versions of CDRECORD are available on the Freeware V6.0 distribution. ( http://www.hp.com/go/openvms/freeware/ ) An OpenVMS port of the cmcd CD audio ripper is also reportedly available. http://www.amb.org/xmcd/
  Versions of CDRECORD (non-DVD) are latent in OpenVMS Alpha V7.3-1 and later. Commercial versions of CDDRECORD---with DVD capabilities---are also available for various platforms, and particularly a variant of CDRECORD known as CDRECORD-ProDVD.
  Beware the tool chosen: some versions and configurations of CDRECORD can record DVD media, as can the DVDRECORD package, as can the commercial DVDwrite package. Many versions of CDRECORD cannot record DVD media, including the version of CDRECORD latent within OpenVMS and the version found on Freeware V6.0; these versions cannot record DVD media.
• Build the contents of the disk on the LD or VD64 device partition.
• Use the chosen recording tool to record the contents of the LD or VD64 partition directly onto the optical medium.

Alternatively, consider the following command on OpenVMS Alpha V7.3-1 and later:

@SYS$MANAGER:CDRECORD.COM HELP

While folks have had success getting PC-based CD-R/RW or DVD-R/RW or DVD+R/RW tools to work with OpenVMS partitions, it is far easier and more reliable to use the OpenVMS-based versions of these tools and directly-attached devices. If you use a Windows-based tool, you will want to specifically select its raw mode, image mode, or block-copy mode, depending on the terminology within the particular tool. The transfer mode and selections is variously refered to as a disk-at-once (DAO) 2048-byte block ISO Mode 1 raw/image/block data disk recording mode.

More details: Creation of CD recordable or DVD recordable media under OpenVMS typically involves one of two approaches: the use of the optional CD-R (`Scribe') capabilities available for the InfoServer or other "offline" hardware packages (PC-based packages will be included in this), or the use of a host-based package such as the CDRECORD or CDWRITE13_VMS or other utilities, including OpenVMS ports of common open-source tools made available by Dr. Eberhard Heuser-Hofmann and various others. Commercial packages and options are also available. Dr. Heuser-Hofmann has DVDwrite , a commercial package which can record DVD media. (