Connections in rejected on HSG80

[VMS Support]

We have recently hit the maximum connection limit on our HSG80's. The limit is 96.
Each OpenVMS server has 4 connections into the HSG80 pair. We have 4 pair of HSG's.
In order to facilitate some extra servers (2) we would require an extra 8 connections. Thats 4 per new new server.
The best solution was to reduce the number of connections that could be seen from some of development servers.
We were going to go from 4 per server.
2 Top - Port 1 + Port 2
2 Bottom - Port 1 + Port 2

to 2 per server
1 Top - Port 1
1 Bottom Port 2.

Plan was to shutdown the four development servers and power off.
Delete connections we did not want.
Power up new servers.
4 !newcon per server. Rename them.

Power up development server.
Now each development server has 2 connection in main table and 2 in rejected table.
(All disk path were changed to reflect less path to disk - in fact you cant delete connections until they are no longer referenced).

The 2 OpenVMS 7.3 development servers boot just fine. With conn in main table and rejected.
The 2 OpenVMS 7.2-1H1 development servers hang during boot for approx 87 minutes because they have connections in the rejected table.
Reverse the process and they boot o.k.

So it looks like something was fixed in 7.3 to enable servers to boot with connections in rejected table.
Has anyone seen this prior ? or have knowledge of what was fixed ?
I have a call open with HP.

After backout of change.
We have new servers with all 8 connections in the rejected table.
Development servers with 4 connections each in main table, 2 as !newconns with no reference to them via disk path and the two original connections with reference on disk path. However development servers now boot o.k.
Well one does not correctly ...but thats another long story.

Kevin Raven

[Robert Brooks_1 · Accepted solution]

The 2 OpenVMS 7.3 development servers boot just fine. With conn in main table and rejected.
The 2 OpenVMS 7.2-1H1 development servers hang during boot for approx 87 minutes because they have connections in the rejected table.
Reverse the process and they boot o.k.

---

Why are you using V7.2-1H1? That release was hardware-specific for the GS80/GS160/GS320.

You really should upgrade to V7.3-2 in order to run on a supported configuration

Failing that, V7.3-1 is a *much* better release for multipath -- we cleaned up a lot of stuff for V7.3-1 within multipath -- that work was not backported to V7.3, because it came in the context of doing the work to support the MSCP path with multipath on V7.3-1, and the effort to backport would have been rather large.

-- Rob

[Uwe Zessin]

So the 'unwanted paths' still do exist, otherwise you would not have rejected connections.

That should be fixed by implementing zoning in the Fibre Channel switches which ensures that only the paths you want are possible.

[VMS Support]

We are running OpenVMS 7.2-1H1 on Alpha Server ES40 model 2.
This is what was recommended to us by Compaq back in 2001.
We are currently engaged in a project to upgrade to 7.3-2.

This is what the new boxes joining the SAN will be used for (parallel running under 7.3-2).

Bit of a rock and a hard place.

Seems to work ok under 7.3 however.