seemingly two paths to same HSG80, how to clean up?

[Verne Britton]

I wanted to find out just how easy or hard it would be to move a shadow set member from one HSG80 pair to another ... so I dismounted it using /COPY=MINI, then deleted the unit, then physically moved the 9gb disk to the other HSG80 cabinet, then created the disk and unit using the same unit ID number.

Then I used MCR SYSMAN IO AUTO so the Alpha ES45 would "find" the unit in its new home (maybe a mistake).

I have played around with this a bit now and frankly forgot exactly what all I have done :-)

I was able to see and mount the disk back up into the shadow.

THEN ... I wanted to move it back :-)

So I reversed all my steps ...

Now I have 21 paths to that device :-)

$ sh dev dga299/ful

Disk $1$DGA299: (ALPHA), device type HSG80, is online, file-oriented device,
shareable, device has multiple I/O paths, served to cluster via MSCP Server,
error logging is enabled.

Error count 0 Operations completed 1195523
Owner process "" Owner UIC [SYSTEM,MANAGER]
Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G:R,W
Reference count 0 Default buffer size 512
Current preferred CPU Id 1 Fastpath 1
WWID 01000010:6000-1FE1-000B-ACC0-0009-8300-0447-00D5
Total blocks 17769177 Sectors per track 169
Total cylinders 5258 Tracks per cylinder 20
Host name "ALPHA" Host type, avail AlphaServer ES45 Model
2, yes
Alternate host name "GAMMA" Alt. type, avail AlphaServer ES45 Model
2, yes
Allocation class 1

I/O paths to device 21
Path PGA0.5000-1FE1-000B-ACC3 (ALPHA), primary path.
Error count 0 Operations completed 916
Path PGA0.5000-1FE1-000B-ACC4 (ALPHA).
Error count 0 Operations completed 890
Path PGA0.5000-1FE1-000B-ACC1 (ALPHA).
Error count 0 Operations completed 890
Path PGA0.5000-1FE1-000B-ACC2 (ALPHA).
Error count 0 Operations completed 890
Path PGB0.5000-1FE1-000B-ACC3 (ALPHA).
Error count 0 Operations completed 890
Path PGB0.5000-1FE1-000B-ACC4 (ALPHA).
Error count 0 Operations completed 1095210
Path PGB0.5000-1FE1-000B-ACC1 (ALPHA).
Error count 0 Operations completed 890
Path PGB0.5000-1FE1-000B-ACC2 (ALPHA).
Error count 0 Operations completed 890
Path MSCP (GAMMA).
Error count 0 Operations completed 82
Path PGA0.5000-1FE1-0005-71F3 (ALPHA).
Error count 0 Operations completed 1906
Path PGA0.5000-1FE1-0005-71F2 (ALPHA).
Error count 0 Operations completed 1906
Path PGB0.5000-1FE1-0005-71F3 (ALPHA).
Error count 0 Operations completed 2397
Path PGB0.5000-1FE1-0005-71F2 (ALPHA).
Error count 0 Operations completed 1906
Path PGA0.5000-1FE1-000B-ACC3 (ALPHA), current path.
Error count 0 Operations completed 85844
Path PGA0.5000-1FE1-000B-ACC4 (ALPHA).
Error count 0 Operations completed 2
Path PGA0.5000-1FE1-000B-ACC1 (ALPHA).
Error count 0 Operations completed 2
Path PGA0.5000-1FE1-000B-ACC2 (ALPHA).
Error count 0 Operations completed 2
Path PGB0.5000-1FE1-000B-ACC3 (ALPHA).
Error count 0 Operations completed 2
Path PGB0.5000-1FE1-000B-ACC4 (ALPHA).
Error count 0 Operations completed 4
Path PGB0.5000-1FE1-000B-ACC1 (ALPHA).
Error count 0 Operations completed 2
Path PGB0.5000-1FE1-000B-ACC2 (ALPHA).
Error count 0 Operations completed 2


when I try things like

SET DEVICE/SWITCH/PATH=xxxx ZZZZZ

I see:

$ set dev $1$dga299/switch/path=PGA0.5000-1FE1-000B-ACC4
%SET-E-NOTSET, error modifying $1$DGA299
-SYSTEM-E-PATHAMBIG, path is ambiguous


Since I see 21 paths, and some of them seem to be duplicates, how do I really see the full complete path name?

Can I delete one or more of these paths?

Or am I screwed and must reboot !!

SORRY, my goal is to stop the many many mount verify msgs that are coming from this three member shadow set ... by removing the "funny" disk from the shadow, all the msgs have stopped (shadow set is my system disk).

VMS 8.2, three ES45s booted from a common system disk, two HSG80 cabinets running 8.8-4 (each HSG80 cabinet has two controllers in multibus failover mode), two fabric switches, each ES45 has two HBAs.

I am tempted, mostly for testing and stability, to invent a new unit number for the third shadow member and thus get away from the 21 path issue ...

Everything has been very very stable for months/years until I starting messing with it today :-)

Ideas anyone ?


Verne

[Jim_McKinney]

> Ideas anyone ?

Haven't encountered this before but

$ mcr sysman io scsi_path_verify

might help. See help within SYSMAN for the particulars.

[Jan van den Ende]

Verne,

>>>
I am tempted, mostly for testing and stability, to invent a new unit number for the third shadow member and thus get away from the 21 path issue ...
<<<

Well, THAT is exactly what WE (finally) did! (Alpha, VMS 7.3-2. Not HSG80, but EVA).

I do not have the details anymore (moved away from that site), but I do recall that we had to do something (then?) badly or not documented to get the new unit # to be made available to, and thereafter recognised by, the cluster. The unit (your $1$DGA299:) stayed in existence on each node until it was (much later) rebooted; but it did not pose any issues any more.

hth

Proost.

Have one on me.

jpe

[Robert Brooks_1]

I'm pretty sure you have an annoying, but benign, situation that can only be cleared by rebooting. Sorry.

I believe that it's not a problem, because in the event of a path failure, multipath will find a working path, even if the DCL interface does not allow a manual path switch.

During various phases of multipath development, this was a quite common happening, as we tried out various configurations and scenarios, in an effort to get multipath to fall on its face.

While it was easy in the early days of multipath to get it to do bad things, this duplicate path name issue is not one of them.

SCSI Unit control blocks (UCB's) are not deleteable once created, so there is no (supported) way to remove them from the multipath set.

-- Rob

[Richard W Hunt]

These extra paths probably correspond to extra connections in your HSG80. If you have an appropriately dumb terminal, you can connect to the HSG80 console software and look at the connections. You will be able to tell by looking at them which connections are current and which are obsolete. You can manually delete the obsolete connections from a running HSG80 if you are careful.

I think you can just do a SHOW ? and see the keywords you can show. One of them should be CONNECTIONS but it has been a while and my documentation isn't right at hand.

If you can show the connections, you can remove them with a delete command using their long names, which is usually something like CONNECTION_35 or whatever number was used. Delete them by the name that includes the _number portion. However, once the path has been defined, you might need to reboot the OpenVMS box because it won't flush its own I/O database without a reboot.

[marsh_1]

to follow up richards comment the connection names by default are !NEWCON and a number , you can see whether they are online or offline on the right hand side of the show conn display.it's always a good idea to rename the in use connections to something more meaningful.

[Verne Britton]

I gave up and just created a new unit (DGA298) and went with that.

Nothing else I tried seemed to make the mount verify issue go away :-)

Thanks to all who responded !!


Verne

[Jan van den Ende]

Verne,

from your Forum Profile:


I have assigned points to 17 of 47 responses to my questions.

Some of the un- or not fully assigned questions date back too 2005!

Maybe you can find some time to do some assigning?

http://forums1.itrc.hp.com/service/forums/helptips.do?#33

Mind, I do NOT say you necessarily need to give lots of points. It is fully up to _YOU_ to decide how many. If you consider an answer is not deserving any points, you can also assign 0 ( = zero ) points, and then that answer will no longer be counted as unassigned.
Consider, that every poster took at least the trouble of posting for you!

To easily find your streams with unassigned points, click your own name somewhere.
This will bring up your profile.
Near the bottom of that page, under the caption "My Question(s)" you will find "questions or topics with unassigned points " Clicking that will give all, and only, your questions that still have unassigned postings.

Thanks on behalf of your Forum colleagues.

PS. nothing personal in this. I try to post it to everyone with this kind of assignment ratio in this forum. If you have received a posting like this before please do not take offence none is intended!

PPS. Zero points for THIS entry, please.

Proost.

Have one on me.

jpe