Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Drive Mounted with Foreign Qualifier

 
SOLVED
Go to solution
fastfreddy
Occasional Advisor

Drive Mounted with Foreign Qualifier

A drive was mounted using the following command
MOUNT/FOR $1$DUA32 HIST

This caused the following result.

Device Device Error Volume
Name Status Count Label
$1$DUA32:(HSC003) Mounted alloc 0 HIST
foreign wrtlck

How do I dismount the drive such that it can be mounted properly?

Thanx Fred
13 REPLIES 13
Jan van den Ende
Honored Contributor

Re: Drive Mounted with Foreign Qualifier

Fred,

$ HELP is your friend! Try it.

And, this being VMS, you might try to guess the commands.

The command to dismount a drive is...
$ DISMOUNT
so, to dismount $1$DUA32 :
$ DISMOUNT $1$DUA32

The same principle holds for all commands (but sometimes you WILL have to search dor the correct synonym)

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
Aaron Sakovich
Super Advisor

Re: Drive Mounted with Foreign Qualifier

So you're saying that when you mounted it foreign, it mounted it foreign AND write-locked it? Curious...

$ Dismount Disk$Hist
or
$ Dismount $1$DUA32:

by itself should work. Of course, if you logged out, it should dismount automatically since the device is allocated to your process and you didn't do a /Group or /System mount (which you can't with a /Foreign device anyways, so I don't know why I brought that up!)
fastfreddy
Occasional Advisor

Re: Drive Mounted with Foreign Qualifier

That was the first command that I tried.

$dismount/override=checks $1$dua32:
%DISM-W-CANNOTDMT, $1$DUA32: cannot be dismounted
%SYSTEM-F-DEVNOTMOUNT, device is not mounted
labadie_1
Honored Contributor

Re: Drive Mounted with Foreign Qualifier

Are you in a Cluster ?

Maybe you mounted it on a node, and try the dismount on another Cluster node ?
fastfreddy
Occasional Advisor

Re: Drive Mounted with Foreign Qualifier

Just to clarify the issue the command was not issued by me rather by someone with limited OpenVMS knowledge.

The device was formerly a member of a shadow set that became dis-functional due to controller problems which since have been resolved.

The drive came back online and was then incorrectly mounted as foreign and cannot be dismounted because of a mounted allocate foreign writelock condition.

$ dismount/override=checks $1$dua32:
%DISM-W-CANNOTDMT, $1$DUA32: cannot be dismounted
%SYSTEM-F-DEVNOTMOUNT, device is not mounted

The process that mounted it has logged off.

How do I clear this condition such that the device can be dismounted and re-mounted as part of its shadow set.

Thanx Fred
Jim_McKinney
Honored Contributor

Re: Drive Mounted with Foreign Qualifier

This volume was mounted privately and must be dismounted by the same process that performed the mount (an implicit dismount would occur if that process was to log out). You can determine the owner process using

$ show device/full $1$DUA32:
fastfreddy
Occasional Advisor

Re: Drive Mounted with Foreign Qualifier

This is a clustered environment but no attempt was made to mount it on the other node. It shows the same condition on the other node but as a remote mount.

Thanx Fred
Jess Goodman
Esteemed Contributor

Re: Drive Mounted with Foreign Qualifier

If we could see the output from a SHOW DEVICE/FULL command, that would be a big help.

Did you try DISMOUNT/ABORT (I'm guessing that the volume is in mount verification).
I have one, but it's personal.
Hoff
Honored Contributor

Re: Drive Mounted with Foreign Qualifier

The volume appears mounted privately, given the allocation and given the command shown. Issue the DISMOUNT in the same process that issued the MOUNT, or issue a LOGOUT and cause that whole session to log out and which will then allow the automatic DISMOUNT(s) to run.

This case is sometimes called "operator error", and it's among the most common ways to trash production data and/or the system uptime stats.

The following is not intended as personal nor as rude, and I do not care who issued the errant commands. Mistakes happen. What follows is what I've learned from similar mistakes and errors I've encountered over the years.

Access to and the errant use of core OpenVMS system management commands such as MOUNT -- combined with inexperience or incautiousness -- is a very bad combination for continued data integrity and for continued operations in production configurations.

Here, I'd remove any and all non-default privileges from the user involved; from whomever issued the MOUNT command.

This for the continued integrity of the production data and the production environment. Not as punishment. "Privileges" are better thought of as "Responsibilities", and are the central mechanisms used by OpenVMS to protect against "operator error".

Next up would be creating or working with automated or local or tailored DCL procedures to perform whatever the target task might be. This to remove the need for privileges.

How good are the local disk backups, and how current are they? Given what I'm reading and what I'm inferring here, I could easily see an errant DCL command leading to data loss or downtime.

Mistakes can and do happen, and learning from and particularly working toward reducing exposure to future and similar mistakes is how better uptime is achieved. This can be through canned procedures, site policies, OpenVMS training, use of least privileges, or other approaches.

Stephen Hoffman
HoffmanLabs LLC