port allocation class

[Gregg Parmentier]

I'm adding a new SAN to my cluster once I get it upgraded to 7.3-2, and I've been reading up on setting the port allocation class for the fiber channel controllers connecting to the shared device.

The documentation says to use CLUSTER_CONFIG.COM, CLUSTER_CONFIG_LAN.COM or, if nether of those can be used for some reason, to use SYSBOOT> SET /CLASS to make port allocation class changes. These methods make a change to SYS$SYSTEM:SYS$DEVICES.DAT.

Is there anything the recommended methods do that isn't done by just editing the file? I do see by experimentation that editing the file does change the port allocation class. I was wondering if there's anything editing the file doesn't do that should be done.

[Jim_McKinney · Accepted solution]

> I was wondering if there's anything editing the file doesn't do that should be done.

Not that I've noticed - I've frequently just edited SYS$DEVICES.DAT, got the expected result, and not experienced any problems.

[Jim_McKinney]

> setting the port allocation class for the fiber channel controllers

Why?

[Gregg Parmentier]

>> I was wondering if there's anything editing the file doesn't do that should be done.

> Not that I've noticed - I've frequently just edited SYS$DEVICES.DAT, got the expected result, and not experienced any problems

Thanks. That's what I was expecting.

>> setting the port allocation class for the fiber channel controllers

> Why?

The node alloclass is set to different values on the two servers to allow for access to all internal disks from both systems for temporary storage space. I need to set the port alloclass so the controllers in both machines have the same alloclass for the shared device.

Or does a Sun/Hitachi 9985 identify itself to VMS in a way that makes that unnecessary?

[Jim_McKinney]

> Sun/Hitachi 9985

You just left my universe... I'm only familiar with HP FC offerings which present an allocation class of 1 for disks and 2 for tapes.

[Duncan Morris]

Gregg,

the fibre disks will appear as $1$DG, and fibre tapes as $2$MG, regardless of your SYSGEN ALLOCLASS values, or any port allocation classes.

On our clusters we have a unique ALLOCLASS on each of servers for use with their locally attached devices. It doesn't matter if you already use 1 or 2 as your ALLOCLASS setting.

See the attachment for a sample listing of devices:



Duncan

[Bill Hall]

Gregg,

Fibre channel disks are always allocation class 1, device class DG, controller A. Multipathing set "hide" the any other controllers from you. So all of your fibre channel attached disks will have device names if the format $1$DGAnnnn. Fibre channel attached tape drives are always prefixed with $2$MGA.

Just wait until you try to figure out the conversion between the array's LUN designation and the unit number that the SRM and VMS will see ;-). And then there's the manual configuration of the array's ports and boot device paths with WWIDMGR. And then there's probably something else that I always forget...

Bill

[Hoff]

FC SAN widgets are $1$ and $2$, as discussed else-thread.

As for the other part of the question, hand-edited files can sometimes trigger parser errors. No two folks ever seem to hand-edit a file in quite the same way, and some edits can sometimes lead to weird and obscure errors during upgrades and ECOs such, or if the file formats change.

I've had a few bad experiences with hand-edited files over the years, and particularly with files and formats that don't have a lint-like verification tool available.

[Bill Hall]

Gregg,

Your storage folks will probably give you a list of LDevs (logical devices) that they are going to present to your cluster. LDev's are comprised of two hex numbers, as in 10:ae. This LDev will be seen by VMS as $1$DGA4270:.
The conversion:
$write sys$output %x10*256+%xae
4270

Bill

[Gregg Parmentier]

I've connected it on a free-standing system, so I know the LUN issues and have no problem working with them. I hadn't set any alloclass on the test system, so never thought to look for a default alloclass. I'm also not booting from the SAN. So I think I'm set.

The storage guy was impressed that the VMS 7.3-2 system took less time to get working with the HDS end than solaris or windows. A lot less. Fifteen minutes, vs a few hours. Gotta love VMS.

It's nice to know I don't need to do anything with port alloclass until I put the old SAN out to pasture and just delete the sys$devices.dat file.

[Jess Goodman]

Yes, but CLUSTER_CONFIG.COM does not support DV or DQ devices. Setting the port allocation class of these non-shared devices to 0 can be important to avoid device name conflicts in the cluster that would prevent MSCP serving.

So in this case the only options left are to EDIT SYS$DEVICES.DAT or use the SYSBOOT> SET /CLASS console commands. Personally I thinks editting a text file myself is safer than depending on console commands to do it for me. With the console command methood I won't even have a chance to look at the file before it is used for booting.

[Jim_McKinney]

Regarding the editing of SYS$DEVICES.DAT: i once wrote a DCL tool to standardize and automate the construction of this file based upon discovery of certain hardware that I was interested in. Initially it didn't work - though the records written by the tool were individually correct, the portion of the bootstrap that read the file wasn't interested in the VFC format that DCL used to create the file - it wanted carriage-return control (like the editors are want to use). I had to have the tool CONVERT the file after writing it with DCL. fwiw...

[Gregg Parmentier]

more than enough information from y'all.