Document revision date: 19 July 1999
[Compaq] [Go to the documentation home page] [How to order documentation] [Help on this site] [How to contact us]
[OpenVMS documentation]

OpenVMS System Manager's Manual


Previous Contents Index

8.13.2 Using Mount Verification

The following sections explain how to perform these tasks:
Task Section
Enable and disable mount verification Section 8.13.2.1
Control timeout periods for mount verification Section 8.13.2.2
Recover from offline errors Section 8.13.2.3
Recover from write-lock errors Section 8.13.2.4
Cancel mount verification using the DISMOUNT command Section 8.13.2.5

8.13.2.1 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.

8.13.2.2 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.

8.13.2.3 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:

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-1998 11:54:54.12 %%%%%%%%%%% 
    Device DUA0: is offline. 
    Mount verification in progress. 
     
    %%%%%%%%%%% OPCOM, 28-MAY-1998 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.

8.13.2.4 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:

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.

8.13.2.5 Canceling Mount Verification

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

The following section describes the first method, using the DISMOUNT command, in more detail. See Section 8.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.

8.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.)

Note

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:
  3. To exit from IPC, press Ctrl/Z:


    IPC> [Ctrl/Z]
    

8.14.1 Recalculating Quorum

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

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:

8.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:


IPC> C MUA1:

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.

Examples


%%%%%%%%%%% OPCOM, 28-MAY-1998 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> C DUA0:
IPC> [Ctrl/Z]) 
%SYSTEM-I-MOUNTVER, _DUA0: has aborted mount verification.
%%%%%%%%%%% OPCOM, 28-MAY-1998 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> C DUA0:
IPC> [Ctrl/Z]) 
%SYSTEM-I-MOUNTVER, _DUA0: has aborted mount verification.
%%%%%%%%%%% OPCOM, 28-MAY-1998 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.

8.14.3 Entering the Debugger

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


IPC> X

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:


IPC> X
IPC> 

To exit from the debugger, press Ctrl/Z:


 [Ctrl/Z]) 

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

8.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.

Note

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:

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).

Caution

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 9
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 9.1.1
Controlling access to ODS-5 volumes Section 9.2
Getting file information Section 9.4
Protecting disk files Section 9.5.3
Protecting disk directories Section 9.5.4
Protecting magnetic tape files Section 9.5.5
Accessing disk files Section 9.6
Accessing tape files Section 9.7
Copying and transferring files Section 9.8

This chapter explains the following concepts:
Concept Section
Extended File Specifications features Section 9.1
DCL commands with files Section 9.3
File protection Section 9.5.1
Tape file names Section 9.7.1

9.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 7.2 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.

9.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 8.3.3 and Section 8.5.5.1, 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:


$ SET PROCESS/PARSE_STYLE=EXTENDED 

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


$ CREATE MY^[FILE 

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.

Note

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

  [Go to the documentation home page] [How to order documentation] [Help on this site] [How to contact us]  
  privacy and legal statement  
6017PRO_038.HTML