Another Question- Something about mapping F11BXQP?
Greg Linder
problems.
I am one of those psycho hobbyists with their own VAXClusters- I
have three machines, a uVAX II, a VAXstation 3100 m38, and a VAXstation
3500 running headless as a disk server. I recently re-installed VMS on my
uVAX II, as it was recently repaired and made functional. Now, on random
machines, I am getting an error informing me that:
%CNXMAN, Sending VAXcluster membership request to system AMANDA
%CNXMAN, Now a VAXcluster member -- system EISVEG
%SYSINIT-E- error mounting system device, status=007280B4
%SYSINIT-E- error opening or mapping F11BXQP, status = 00018272
I don't have any disks that share a label, as I made that mistake
last time, and my alloclass values are 1,2,3. Any thoughts?? It's done
this on my uVAX II and on my VAXstation 3100. I have a terminal on my
3500, and it comes up just fine. However, even though I mount all but my
system disks /cluster, EISVEG's (The 3100's) CD-ROM and all of my 3500's
DUBx devices don't show up to the uVAX II. I'm a bit confused.
Thanks for your help,
Greg Linder
fl...@mcs.net
Tim Shoppa
> I don't have any disks that share a label, as I made that mistake
> last time, and my alloclass values are 1,2,3. Any thoughts?? It's done
> this on my uVAX II and on my VAXstation 3100. I have a terminal on my
> 3500, and it comes up just fine. However, even though I mount all but my
> system disks /cluster, EISVEG's (The 3100's) CD-ROM and all of my 3500's
> DUBx devices don't show up to the uVAX II. I'm a bit confused.
What are the SYSGEN parameters MSCP_LOAD and MSCP_SERVE_ALL
set to on the 3100? Normally these would've been set up during
your @CLUSTER_CONFIG, but you may have misanswered these
questions at that time:
$ mcr sysgen help param mscp
Parameters
MSCP_LOAD
MSCP_LOAD controls the loading of the MSCP server during a system
boot. Specify one of the following values:
Value Description
0 Do not load the MSCP server. This is the default value.
1 Load the MSCP server and serve disks as specified by the
MSCP_SERVE_ALL parameter.
Parameters
MSCP_SERVE_ALL
MSCP_SERVE_ALL controls the serving of disks during a system
boot. Specify one of the following values:
Value Description
0 Do not serve any disks. This is the default.
1 Serve all available disks.
2 Serve only locally attached (nonHSC) disks.
If the MSCP_LOAD system parameter is 0, MSCP_SERVE_ALL is
ignored.
Tim.
Mark D. Jilson
already mounted) comes from 2 cases
1) 2 different disks with the same volume label
2) 2 disks with the same physical device name
In this case it's node EISVEG that has configured it's local disks and
when it tries to mount the system disk the lock manager finds another
resource some place in the cluster for the same physical device but it
has a different volume label. You need to map the physical devices seen
by every cluster system to the physical device names VMS creates for
them (remember that VMS names may/will be different from console names)
and find the duplicate and then figure out how to eliminate this
duplication.
Greg Linder wrote:
>
> I would like to thank all of you who helped me with my TK-50
> problems.
> I am one of those psycho hobbyists with their own VAXClusters- I
> have three machines, a uVAX II, a VAXstation 3100 m38, and a VAXstation
> 3500 running headless as a disk server. I recently re-installed VMS on my
> uVAX II, as it was recently repaired and made functional. Now, on random
> machines, I am getting an error informing me that:
>
> %CNXMAN, Sending VAXcluster membership request to system AMANDA
> %CNXMAN, Now a VAXcluster member -- system EISVEG
> %SYSINIT-E- error mounting system device, status=007280B4
> %SYSINIT-E- error opening or mapping F11BXQP, status = 00018272
>
> I don't have any disks that share a label, as I made that mistake
> last time, and my alloclass values are 1,2,3. Any thoughts?? It's done
> this on my uVAX II and on my VAXstation 3100. I have a terminal on my
> 3500, and it comes up just fine. However, even though I mount all but my
> system disks /cluster, EISVEG's (The 3100's) CD-ROM and all of my 3500's
> DUBx devices don't show up to the uVAX II. I'm a bit confused.
--
Jilly - Working from Home in the Chemung River Valley - Lockwood, NY
- ji...@clarityconnect.com - Brett Bodine fan
- m_ji...@csc32.enet.dec.com - since 1975 or so
- http://www.clarityconnect.com/webpages2/jilly -
Hoff Hoffman
When posting, please remember to indicate the OpenVMS version.
I will assume V6.1.
In article <Pine.BSF.3.95.990111...@Venus.mcs.net>, Greg Linder <fl...@Venus.mcs.net> writes:
: I am one of those psycho hobbyists with their own VAXClusters- I
:have three machines, a uVAX II, a VAXstation 3100 m38, and a VAXstation
:3500 running headless as a disk server. I recently re-installed VMS on my
:uVAX II, as it was recently repaired and made functional. Now, on random
:machines, I am getting an error informing me that:
Given that you reinstalled, I'd tend to look *very* carefully
at the disk volume labels -- reinstallation *will* reset the
volume disk labels.
:%CNXMAN, Sending VAXcluster membership request to system AMANDA
:%CNXMAN, Now a VAXcluster member -- system EISVEG
:%SYSINIT-E- error mounting system device, status=007280B4
:%SYSINIT-E- error opening or mapping F11BXQP, status = 00018272
:
: I don't have any disks that share a label, as I made that mistake
:last time, and my alloclass values are 1,2,3.
Based solely on the condition values shown in the message, it would
appear that you do have duplicate labels:
$ exit %x00018272
%RMS-E-DNR, device not ready, not mounted, or unavailable
$ exit %x07280B4
%MOUNT-F-VOLALRMNT, another volume of same label already mounted
There is no need for the use of non-zero allocation classes in this
cluster configuration, all nodes can operate in allocation class zero.
(Non-zero allocation classes are of interest when there are multiple
paths into a storage device -- that is not feasible in this cluster
configuration, unless you've a pair of KFQSA DSSI adapters you're not
telling us about...)
I will assume that the entire cluster has been rebooted since you
last changed any SCSSYSTEMID, SCSNODE, or allocation class values.
:Any thoughts?? It's done
:this on my uVAX II and on my VAXstation 3100. I have a terminal on my
:3500, and it comes up just fine. However, even though I mount all but my
:system disks /cluster, EISVEG's (The 3100's) CD-ROM and all of my 3500's
:DUBx devices don't show up to the uVAX II. I'm a bit confused.
I would tend to use SYS$EXAMPLES:MSCPMOUNT.COM to mount the disks
(thus using MOUNT/SYSTEM mounting on each node), rather than using
the MOUNT/CLUSTER command.
Please provide the following information:
o the OpenVMS version (V6.1 assumed),
o the labels on all disks present,
o the specific types of disk(s) present,
o the DSSI storage configuration, if DSSI controllers are present,
o if you have OpenVMS Cluster satellite nodes present,
o output from a SYSGEN> SHOW/CLUSTER on each of the nodes.
-------------------------- pure personal opinion ---------------------------
Hoff (Stephen) Hoffman OpenVMS Engineering hof...@xdelta.ZZenet.dec.com
note to those folks not contributing spam -- there is no ZZ in my address
w...@gate.fim.fgan.de
if you have two local disks on two different cluster members (MSCP loaded)
with the same volumelabel, you will have that problem. I did have thsame problem
with local page-/swapfile disks (two did have the same label). The system,
which booted as second host was unable to mount this disk.
Regards Rudolf Wingert
Bob Koehler
>%CNXMAN, Sending VAXcluster membership request to system AMANDA
>%CNXMAN, Now a VAXcluster member -- system EISVEG
>%SYSINIT-E- error mounting system device, status=007280B4
>%SYSINIT-E- error opening or mapping F11BXQP, status = 00018272
I've seen this when one of the other members of the cluster still had
the system disk for the rebooting node mounted. Go to the other members
of the cluster and dismount the disk.
----------------------------------------------------------------------
Bob Koehler | Computer Sciences Corporation
Hubble Space Telescope Payload | Federal Sector, Civil Group
Flight Software Team | please remove ".aspm" when replying
Andy Goldstein
>
> This error 7280B4 (%MOUNT-F-VOLALRMNT, another volume of same label
> already mounted) comes from 2 cases
> 1) 2 different disks with the same volume label
> 2) 2 disks with the same physical device name
>
what looks like the same device on different nodes in the cluster. We
did a major rework of the device / volume correspondence logic in V7.1
(and backported to V6.2 in the "MOUNT / Shadowing Compatibility kit"),
and the latter case was split out to a separate error message,
"MOUNT-F-DIFVOLMNT, different volume mounted on same device".
> In this case it's node EISVEG that has configured it's local disks and
> when it tries to mount the system disk the lock manager finds another
> resource some place in the cluster for the same physical device but it
> has a different volume label.
More precisely, the checks worked like this (I'm assuming you're running
V6.1): For each mounted volume and device, there is a lock for the
device and a lock for the volume label. The value block in each has a
bit that says "I'm mounted". The value block for the first lock on a
resource starts out zero, so MOUNT can deduce whether it's getting the
first lock on each resource. Thus you have the following four possible
conditions:
Device lock 0, volume lock 0: first node to mount this device and volume
- OK
Device lock 1, volume lock 1: another node has the volume mounted on the
same device - OK
Device lock 0, volume lock 1: volume of the same label is mounted on
some other device
Device lock 1, volume lock 0: same device has a different volume mounted
elsewhere in the cluster
Unfortunately there are some really perverse cases (involving multiple
errors) that cause this check to get the wrong answer (a false OK). To
fix this, in the V7.1 rework we added a volume label hash to the device
lock value block.
> You need to map the physical devices seen
> by every cluster system to the physical device names VMS creates for
> them (remember that VMS names may/will be different from console names)
> and find the duplicate and then figure out how to eliminate this
> duplication.
>
We also had some nagging problems in MOUNT where the locks sometimes got
screwed up, and you got this error even though your device and volume
label configuration was perfectly in order. Rebooting all the nodes in
the cluster clears this problem. We never did work out what caused the
problem, but it has for all practical purposes gone away with the V7.1
rework. If this problem persists across a clean reboot of the cluster,
you have a device or volume configuration problem.
> Greg Linder wrote:
> >
> > I would like to thank all of you who helped me with my TK-50
> > problems.
> > I am one of those psycho hobbyists with their own VAXClusters- I
> > have three machines, a uVAX II, a VAXstation 3100 m38, and a VAXstation
> > 3500 running headless as a disk server. I recently re-installed VMS on my
> > uVAX II, as it was recently repaired and made functional. Now, on random
> > machines, I am getting an error informing me that:
> >
> > %CNXMAN, Sending VAXcluster membership request to system AMANDA
> > %CNXMAN, Now a VAXcluster member -- system EISVEG
> > %SYSINIT-E- error mounting system device, status=007280B4
> > %SYSINIT-E- error opening or mapping F11BXQP, status = 00018272
> >
> > I don't have any disks that share a label, as I made that mistake
> > last time, and my alloclass values are 1,2,3. Any thoughts?? It's done
Jan Vorbrueggen
[lucid explanation of technical details as usual]
> We did a major rework of the device / volume correspondence logic in V7.1
> (and backported to V6.2 in the "MOUNT / Shadowing Compatibility kit"),
> and the latter case was split out to a separate error message,
> "MOUNT-F-DIFVOLMNT, different volume mounted on same device".
Hey, you changed an error message in an incompatible way? Naughty, naughty!
Jan
PS: read with large grains of salt added...
Bob Koehler
Now if could just get them to update all those routines that return
SS$_EXQUOTA.
Jan Vorbrueggen
> >Hey, you changed an error message in an incompatible way? Naughty, naughty!
>
> Now if could just get them to update all those routines that return
> SS$_EXQUOTA.
...and SS$_NOPRIV...
Jan