HP OpenVMS Systems Documentation
The OpenVMS Frequently Asked Questions (FAQ)
8.6 What does the MCR command do?
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:
is equivalent to:
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:
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:
8.8 Can I do DECnet task-to-task communication with DCL?
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:
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.10 Why doesn't DCL symbol substitution work?
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:
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.
Use DCL ampersand substitution, and not apostrophe substitution.
8.12 Use of RUN/DETACH, LOGINOUT, and logical names?
With a command to create a detached process such as:
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.
To write a message and then the bell character, use:
To write blinking text, use:
$ 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:
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: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 additional information on the OpenVMS Ask The Wizard (ATW) area and
for a pointer to the available ATW Wizard.zip archive, please see
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.
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.
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:
See Section 18.104.22.168 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.)
All disk-related listed in this section are stated in units of "disk (base ten) gigabytes" (1 GB = 10^9 bytes) and not in units of "software (base two) gigabytes" (1 GB = 2^30; 1 GB = 1073741824.) bytes. Please see Section 14.25 for details of the nomenclature and of the units.
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.
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.)"
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.
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.
Alternatively, consider the following command on OpenVMS Alpha V7.3-1 and later:
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. (