I'd like to change SCA priorities based on a particular cpu booting

[Mitchell Bell]

I am switching two nodes in my cluster and want to be able to write code that will
based on serial number or so will use EWA & EWB or EWA & EWD based on the wiring.

Is node_csid available for this?

What does this parameter mean?

write sys$output f$getsyi("node_csid")

[Ian Miller.]

CSID is not a value which always be the same. Why not use SCSNODE ?

[Duncan Morris]

Hi Mitchell,

as Ian has pointed out, the csid is not a serial number. Here is a quick explanation of the csid:

The cluster-system-id of an OpenVMS node is assigned by the cluster-connection software and may be obtained by the DCL command SHOW CLUSTER. The value of the cluster-system-id for an OpenVMS node is not permanent; a new value is assigned to an OpenVMS node whenever it joins or rejoins the OpenVMS Cluster.

If you are loading the same system root, then obviously any of the USERxxx etc SYSGEN parameters will be the same on both boxes, so you need to get some hardware id that changes between boxes. Why not consider using something like the adapter(s) MAC address to distinguish between hardware (assuming that the NICs actually differ between the boxes!!), or WWID of an HBA?

Are these node Vax /Alpha/ or Itanium?

Duncan

Duncan

[Mitchell Bell]

Your response is not valid - the point is that scsnode will be changing depending on what root I boot.

The root will be right but I need to vary which network cards are prioritized based on which actual hardware I'm using.

So I need to check against Serial Number or some such.

[Robert Gezelter]

Mitchell,

As Ian mentioned, you want to use something like the SCSSYSTEMID (or alternatively, the System Root Number). Depending upon your configuration, and contingencies, a given node may boot on different hardware boxes.

I have often used different system roots for this purpose, generalizing the concept of a node. Some examples of this type of concept were included in my OpenVMS Technical Journal paper on the use of inheritance, see http://www.rlgsc.com/publications/vmstechjournal/inheritance.html for some examples.

I would recommend using the logical name facility to define the primary, secondary, and other adapters, and then issue the appropriate common commands referencing the logical names, it should work (I am not in a location where I can check it easily at this instant).

Using the inheritance concept can make this sort of thing substantially easier to implement and maintain.

- Bob Gezelter, http://www.rlgsc.com

[Mitchell Bell]

Duncan,

I guess I can do that. I know that I can go into SDA and get the FGA adapter cards...is there an easy way to retrieve Mac address?

Thanks.

[Duncan Morris]

Mitchell,

a quick and dirty way would be using lancp and parsing the output. Similar info could be extracted from SDA.

I suppose that it all depends on how you are doing your "code". If it is just DCl, then the lancp route would probably suffice

> mc lancp show dev/par

Device Characteristics EIA0:
Value Characteristic
----- --------------
1500 Device buffer size
Normal Controller mode
External Internal loopback mode
00-50-8B-65-F1-F9 Hardware LAN address
Multicast address list
CSMA/CD Communication medium
FF-FF-FF-FF-FF-FF Current LAN address
128 Minimum receive buffers
256 Maximum receive buffers
Yes Full duplex enable
Yes Full duplex operational
TwistedPair Line media type
100 Line speed (mbps)
Disabled/No Failset Logical LAN state
0 Failover priority

[Mitchell Bell]

Alpha - so if I can depend on the Current Lan address being consistent I can use this.

mcr scacp sho lan


Device Errors + Mgt Buffer MgtMax Line Total Current
Device Type Events Status Priority Size BufSiz Speed Pkts(S+R) LAN Address
------ ---- ------ ------ -------- ---- ------ ----- --------- -----------
LCL 0 Run Online Local Restart 0 1426 0 N/A 386532 00-00-00-00-00-00
EWA DEGXA 0 Run Online Restart 0 1426 0 1000 4816753 AA-00-04-00-CB-04
EWD DEGXA 0 Run Online Restart 4 1426 0 1000 58338910 AA-00-04-00-CB-04
EWB DEGXA 0 Not in use by SCA 0 0 0 1000 0 00-00-00-00-00-00
EWC DEGXA 0 Not in use by SCA 0 0 0 1000 0 00-00-00-00-00-00
On the other node

mcr scacp sho lan

Device Errors + Mgt Buffer MgtMax Line Total Current
Device Type Events Status Priority Size BufSiz Speed Pkts(S+R) LAN Address
------ ---- ------ ------ -------- ---- ------ ----- --------- -----------
LCL 0 Run Online Local Restart 0 1426 0 N/A 3207162 00-00-00-00-00-00
EWA DEGPA 121 Run Online Restart 4 1426 0 1000 2056716311 00-60-6D-21-08-A4
EWC DEGPA 0 Run Online Restart 0 1426 0 1000 78399182 AA-00-04-00-CA-04
EWB DE500 0 Not in use by SCA 0 0 0 100 0 00-00-00-00-00-00

[Duncan Morris]

Just make sure you don't depend on the AA-00-04.... addressing. The Decnet address will be the same on both boxes!

Go for it with the SCACp output.

Duncan

[Robert Gezelter]

Mitchell,

I similarly would not recommend using the Hardware MAC address. The hardware MAC address is different for each board. When Field Service swaps out a board in an emergency, you will have to make changes to your configuration files to accomodate the change. This is painful, as many discovered when software licensing schemes (generally not Digital/Compaq) relied on LAN adapter numbers. Everything broke when hardware was swapped.

It is easier to use alternate roots to boot the systems, as follows:

Box 1 Box 2
Node A Root 0 Root 2
Node B Root 1 Root 3

Creating a SYS$NODESPECIFIC (in the search path in addition to SYS$SPECIFIC) is straightforward, and will keep the different incarnations of the nodes straight, In short, you normal boot roots are 0 & 1, alternate roots are 2 & 3, respectively.

Thus, if you want Node A running on Box 1, you boot off of system root 0. If Box 2, system root 2. The exact topology information that is different on the boxes is included in a file in SYS$SPECIFIC (say [SYSMGR]SCSTOPOLOGY.COM).

No device scanning necessary, no dependency on the vaguarities of output report formats (and parsing them).

- Bob Gezelter, http://www.rlgsc.com

[Robert Brooks_1]

Coming soon (VMS V8.3) . . .

$ write sys$output f$getdvi( "ewa0", "lan_default_mac_address" )
00-06-2B-00-1D-93

$ write sys$output f$getdvi( "ewa0", "lan_mac_address" )
AA-00-04-00-1F-0C

[Hoff]

I understand what your immediate goals are here and your proposed solution; could you provide some background details on the particular problem you are solving?

In years past, I've tied into controllers and ports and MAC addresses, and I've ended up causing myself some extra work here. This either directly, through the added maintenance entailed in some solutions, or as the underlying OpenVMS implementation has changed.

The IPC services are a good option in clusters, for instance, as are locks and files with global buffers. LDAP or DNS/BIND can be options for locating components, too.

As for controller MAC addresses, there's a program posted at the Ask The Wizard area (left navigation) that has been around forever, and works nicely. It taps into the driver-level interfaces for this stuff.

With some details on the problem and related background materials, folks here may be able to provide a solution that's easy, fast, maintainable -- and meets your particular requirements.

Stephen Hoffman
HoffmanLabs LLC

[Jan van den Ende]

Mitchel,

the reason why tou can NOT use the CSID: it is unique to THIS incarnation of a cluster node, ane will NOT be reused during the life of THIS cluster. Only after a fll cluster shutdown the numer mar be used again...

maybe little help, but at least some explanation about what will NOT work.

Proost.

Have one on me.

jpe