HP OpenVMS Systems Documentation

Content starts here

OpenVMS System Manager's Manual

Previous Contents Index

9.13.2 Using Mount Verification

The following sections explain how to perform these tasks:

Task Section
Enable and disable mount verification Section
Control timeout periods for mount verification Section
Recover from offline errors Section
Recover from write-lock errors Section
Cancel mount verification using the DISMOUNT command Section Enabling Mount Verification

Mount verification is enabled by default when you mount a disk or tape. To disable mount verification, you must specify /NOMOUNT_VERIFICATION when you mount a disk or tape.

Note that this feature applies to standard mounted tapes, foreign mounted tapes, and Files-11 disks. Controlling Timeout Periods for Mount Verification

You can control the amount of time (in seconds) that is allowed for a mount verification to complete before it is automatically canceled. The MVTIMEOUT system parameter for disks and the TAPE_MVTIMEOUT system parameter for tapes define the time (in seconds) that is allowed for a pending mount verification to complete before it is automatically canceled.

The default time limit for tapes is 600 seconds (10 minutes); for disks, it is 3600 seconds (1 hour). (Refer to the OpenVMS System Management Utilities Reference Manual for more information about system parameters.)

Always set either parameter to a reasonable value for the typical operations at your site. Note that resetting the value of the parameter does not affect a mount verification that is currently in progress. Recovering from Offline Errors

When a mounted disk or tape volume goes off line while mount verification is enabled, you can try to recover, or you can terminate the mount request. The following options are available:

  • Try to put the device back on line by toggling the START or RUN button on disks or the LOAD button on tapes. If the device has failed, terminate mount verification.
  • Take the disk or tape out of the offline and verification-pending state by shutting down mount verification with one of the three techniques described in Section These techniques include canceling the mount request, dismounting the volume, and allowing mount verification to time out.

If you successfully put the device back on line, the mount verification software that polls the disk or tape drive begins verification in the following sequence of steps:

  1. The system checks to see that the currently mounted disk or tape has the same identification as the previously mounted volume. In this way, mount verification confirms that this is the same disk or tape that was previously mounted and no switching has occurred.
    If the drive contains the wrong volume, OPCOM issues a message in this format:

    %%%%%%%%%%% OPCOM, <dd-mmm-yyyy hh:mm:ss.cc> %%%%%%%%%%%
    Device <device-name> contains the wrong volume.
    Mount verification in progress.
  2. Once mount verification completes, the disk is marked as valid, and OPCOM issues a message in the following format:

    %%%%%%%%%%% OPCOM, <dd-mmm-yyyy hh:mm:ss.cc> %%%%%%%%%%%
    Mount verification completed for device <device-name>.
  3. I/O operations to the disk or tape proceed, as shown in the following example:

    %%%%%%%%%%% OPCOM, 28-MAY-2000 11:54:54.12 %%%%%%%%%%%
    Device DUA0: is offline.
    Mount verification in progress.
    %%%%%%%%%%% OPCOM, 28-MAY-2000 11:57:34.22 %%%%%%%%%%%
    Mount verification completed for device DUA0:.

    In this example, the message from OPCOM informs the operator that device DUA0: went off line and mount verification was initiated. The operator finds that the drive was accidentally powered down and successfully powers it up again.
    The last message in the example indicates that mount verification is satisfied that the same volume is on the drive as before the error. All I/O operations to the volume resume. Recovering from Write-Lock Errors

Devices become write-locked when a hardware or user error occurs while a disk or a tape volume is mounted for a write operation. For example, if a disk is write-locked or a tape is missing a write ring, the hardware generates an error. As soon as the software discovers that the disk or tape is write-locked (for example, when an I/O operation fails with a write-lock error), mount verification begins.

OPCOM issues a message in the following format to the operators enabled for DISKS and DEVICES or TAPES and DEVICES, announcing the unavailability of the disk or tape:

%%%%%%%%%%%% OPCOM, <dd-mmm-yyyy hh:mm:ss.cc> %%%%%%%%%%%
Device <device-name> has been write-locked.
Mount verification in progress.

You can either recover the operation or terminate mount verification. Your options include the following ones:

  • Enable the drive for writing by toggling the hardware WRITE LOCK switch of the disk, or check to see that a tape volume has a write ring.
  • If the disk or tape drive is faulty, but another functioning drive is available on the same controller, move the disk or tape to the functioning drive and swap the unit select plugs. (Note that switching to another drive causes the volume to undergo offline mount verification; once this completes, the write-lock mount verification continues.)
  • Terminate the mount operation by shutting down mount verification with one of the techniques described in Section

Once the mount verification software determines that the volume is in a write-enabled state, I/O operations to the tape or disk resume with no further messages. Canceling Mount Verification

You can cancel a mount verification request in one of the following ways:

  • Dismount the volume with the DCL command DISMOUNT from a process that is not hung.
  • If the device is off line, allow mount verification to time out. The default time limit for tapes is 600 seconds (10 minutes); for disks, it is 3600 seconds (1 hour). However, you can use the system parameter MVTIMEOUT (for disk) or TAPE_MVTIMEOUT (for tape) to set the value to whatever you want. When the time expires, the system automatically cancels the pending mount verification. Note that a mount verification initiated by a write-lock condition does not time out.
  • Invoke a special canceling routine, IPC, from the console terminal.

The following section describes the first method, using the DISMOUNT command, in more detail. See Section 9.14.2 for details about using the last method, IPC, to cancel mount verification.

Using the DISMOUNT Command

To dismount a volume:

  1. Log in at another terminal, or use any logged-in terminal that has access to the volume. (It does not need to be an operator terminal.)
  2. Enter the DISMOUNT/ABORT command for the volume. (To use the /ABORT qualifier with a volume that is not mounted group or system, you must have volume ownership or the user privilege VOLPRO.)
    If your system is in an OpenVMS Cluster environment, also specify the /CLUSTER qualifier.
    When you cancel a pending mount verification by dismounting the volume, OPCOM issues a message in the following format:

    %%%%%%%%%%%% OPCOM, <dd-mmm-yyyy hh:mm:ss.cc> %%%%%%%%%%%
    Mount verification aborted for device <device-name>.

    If you do not have access to the volume, you receive an error message. You can try again if you can find an appropriate process to use. If your process hangs, the system file ACP is hung, and you cannot use this technique to cancel mount verification.
  3. When the cancellation is complete, remove the volume from the drive.

9.14 Using Interrupt Priority Level C (IPC)

IPC is a special program that issues a software interrupt to gain the attention of the console terminal. You can use IPC commands to adjust quorum in an OpenVMS cluster, to cancel mount verification, or to enter the debugger. (The debugger in this case refers to the system-level debugger, XDELTA.)


IPC commands are intended to be used only for debugging and laboratory implementation. Use of the commands might cause unexpected results.

The IPC program converts lowercase letters to uppercase, issues the terminal bell character whenever it receives illegal characters (such as most control characters), compresses multiple spaces, and ignores leading spaces.

How to Invoke IPC

  1. On both OpenVMS VAX and Alpha systems, enter the following command from the console terminal:

    $ [Ctrl/P]

    This command does not echo. Responses to this command will be implementation-specific, which are indicated in the examples by ellipses
  2. Enter subsequent commands specific to the hardware you are using:
    • On VAX systems, enter the following commands:

      >>> D/I 14 C
      >>> CONT

      The first command tells the hardware to generate a software interrupt at level C (#12).
    • On Alpha systems, enter the following commands:

      >>> D SIRR C
      >>> CONT
  3. To exit from IPC, press Ctrl/Z:

    IPC> [Ctrl/Z]

9.14.1 Recalculating Quorum

You can enter the following commands at the console to recalculate quorum:

  • On VAX systems:

    >>> D/I 14 C
    >>> CONT
    IPC> Q
    IPC> [Ctrl/Z])
  • On Alpha systems, enter the following commands:

    >>> D SIRR C
    >>> CONT
    IPC> Q
    IPC> [Ctrl/Z])

Although IPC Q commands recalculate quorum in an OpenVMS Cluster, do not use these commands. Instead, use either of the following to recalculate cluster quorums:

  • On OpenVMS VAX systems, DECamds
  • On OpenVMS Alpha systems, the Availability Manager

9.14.2 Canceling Mount Verification

To cancel mount verification using IPC, enter the following command from the console terminal in response to the IPC> prompt:

IPC> C device-name

This command cancels any pending mount verification on the device specified. (A warning is given if no mount verification was in progress for that device.) For example:


When a pending mount verification is canceled, OPCOM prints a message in the following format:

%%%%%%%%%%% OPCOM, <dd-mmm-yyyy hh:mm:ss.cc> %%%%%%%%%%%
Mount verification aborted for device <device-name>.

After you successfully cancel a pending mount verification using this technique, you must dismount and then remount the volume before you can access it again.


%%%%%%%%%%% OPCOM, 28-MAY-2000 10:54:54.12 %%%%%%%%%%%
        Device DUA0: is offline.
        Mount verification in progress.

On VAX systems, you might enter the following commands:

$ [Ctrl/P]
>>> D/I 14 C
>>> CONT
IPC> [Ctrl/Z])
%SYSTEM-I-MOUNTVER, _DUA0: has aborted mount verification.
%%%%%%%%%%% OPCOM, 28-MAY-2000 10:56:26.13 %%%%%%%%%%%
Mount verification aborted for device DUA0:

On Alpha systems, you might enter the following commands:

$ [Ctrl/P]
>>> D SIRR C
>>> CONT
IPC> [Ctrl/Z])
%SYSTEM-I-MOUNTVER, _DUA0: has aborted mount verification.
%%%%%%%%%%% OPCOM, 28-MAY-2000 10:56:26.13 %%%%%%%%%%%
Mount verification aborted for device DUA0:

In both examples, device DUA0: is off line, but you are unable to spin the disk back up. No other drive is available on the controller, so you cannot switch the unit select plugs of the two drives.

Do not enter a DISMOUNT command for the disk because it was mounted as a private volume, and you do not have access to it. The %SYSTEM-I-MOUNTVER message also appears because this is the console terminal.

9.14.3 Entering the Debugger

To use the XDELTA debugger, enter the following commands from the console terminal:


You are now in the debugger. The X command transfers control to the debugging tool XDELTA (provided it was loaded with the system by setting the appropriate value in the boot file). If XDELTA has not been loaded, the prompt IPC> is reissued. For example:


To exit from the debugger, press Ctrl/Z:


For information about the XDelta debugger, refer to the OpenVMS Delta/XDelta Debugger Manual.

9.15 Using the Bad Block Locator Utility to Detect Media Errors

The DCL command ANALYZE/MEDIA invokes the optional Bad Block Locator utility (BAD), which analyzes block-addressable media and records the location of blocks that cannot reliably store data.


Many newer devices automatically check for bad blocks; therefore, BAD is more useful with older devices that do not check for bad blocks.

To test the blocks on a volume, ANALYZE/MEDIA performs the following tasks:

  • Writes a test pattern to each block on the media
  • Reads the contents of the block into a buffer
  • Compares the data read back with the data written

If the data does not compare exactly, a block cannot reliably store data.

When the Bad Block Locator utility locates a bad block, it records the address of the block. Consecutive bad blocks are recorded as single entries for non-last-track devices. After it finishes testing the disk, BAD writes the addresses of the bad blocks into a file called the detected bad block file (DBBF).


Testing a volume for bad blocks destroys its contents. However, you can update the detected bad block file (DBBF) without erasing the contents of the volume by using the ANALYZE/MEDIA qualifiers /NOEXERCISE and /BAD_BLOCKS.

How to Perform This Task

To use BAD, perform the following steps:

  1. Allocate the device with the DCL command ALLOCATE (to ensure that the device is not accessed by any other programs).
  2. Enter the DCL command MOUNT/FOREIGN.
    When the device is mounted as foreign, the system does not recognize it as a Files--11 volume, and BAD can execute.
  3. Enter the DCL command ANALYZE/MEDIA.

Refer to online help or to the archived manual OpenVMS Bad Block Locator Utility Manual for details on using the Bad Block Locator utility.

Chapter 10
Using Files and Directories

This chapter discusses concepts and tasks related to file protection, file manipulation, and data transfer.

Information Provided in This Chapter

This chapter describes the following tasks:

Task Section
Using Extended File Specifications features Section 10.1.1
Controlling access to ODS-5 volumes Section 10.2
Getting file information Section 10.4
Protecting disk files Section 10.5.3
Protecting disk directories Section 10.5.4
Protecting magnetic tape files Section 10.5.5
Accessing disk files Section 10.6
Accessing tape files Section 10.7
Copying and transferring files Section 10.8

This chapter explains the following concepts:

Concept Section
Extended File Specifications features Section 10.1
DCL commands with files Section 10.3
File protection Section 10.5.1
Tape file names Section 10.7.1

10.1 Understanding Extended File Specifications Features

Beginning with OpenVMS Version 7.2, Extended File Specifications remove many of the file-naming restrictions previously imposed by OpenVMS and offer full support for the following file-naming features. Together, these features provide consistent file handling across both OpenVMS and Windows NT systems in a Compaq Advanced Server for OpenVMS environment.

Feature Description
New on-disk structure Extended File Specifications support the latest volume On-Disk Structure (ODS): Level 5 (ODS-5). This volume structure provides the basis for creating and storing files with extended file names.
Additional character set support A broader set of characters is available for naming files on OpenVMS. Extended File Specifications offers support for file names that use the 8-bit ISO Latin-1 character and 16-bit Unicode (UCS-2) character sets.
Extended file naming File names can now exceed the traditional 39.39 character limit up to a maximum of 236 bytes.
Case preservation Extended File Specifications preserve the case of file specifications created with ODS-5 attributes. However, the system still performs case-insensitive string matching.
Deep directory levels To support deep directory levels, the length of directory specifications has been extended to a maximum of 512 characters.

For more information about each feature, refer to OpenVMS Guide to Extended File Specifications.

10.1.1 Using Extended File Specifications

Beginning with OpenVMS Version 7.2, RMS allows you to use directory levels deeper than 8 as well as the new RMS API extensions on both ODS-2 and ODS-5 volumes by default. However, you can create extended file names only on an ODS-5 volume. Section 9.3.3 and Section, respectively, explain how to create a new ODS-5 volume and how to convert an ODS-2 volume to an ODS-5 volume.

Once you change a volume to ODS-5, your programs can create and read extended file names. However, by default, DCL (as well as some applications) does not accept all extended names.1 DCL also capitalizes any lowercase file names that users enter at the command line prompt.2

Enabling the Extended File Specifications Parsing Feature

For DCL to accept all extended file names, you must enable the Extended File Specifications file name parsing feature. On OpenVMS Alpha systems, you can instruct DCL to accept ODS-5 file names on a per-process basis by entering the following command:


After you enter the command, DCL accepts a file name similar to the following:


For more details on setting parse styles, refer to the OpenVMS DCL Dictionary. The OpenVMS Record Management Services Reference Manual contains additional information about RMS default Extended File Specifications features.


1 Even with the TRADITIONAL parse style, DCL allows some ODS-5 file names; for example, DCL accepts x.x.x.
2 Some applications also use DCL internally to read file names that users type after an application prompt.

Previous Next Contents Index