DECNET_REGISTER problem

[Bart Zorn_1]

Hello,

I am trying to cleanup the local node databases on our systems. To make sure I have everything correct, I first remove a node difinition, then register it with only the NSP DECnet Phase IV address, and then use option 3 of DECNET_REGISTER to obtain the full information.

Most of the time this works. However, sometimes I get the message:

Error - Node towers modification was unsuccessful

A specified tower contains an address that is already in use by another node
Used by node: LOCAL:.SOMEND
NET value: /0A016400

When I do a full listing of what I have up to that point, I cannot find anything that resembles that NET value.

Does anyone have a clue what is wrong here?

Thanks in advance!

Regards,

Bart Zorn

[Volker Halle]

Bart,

a NET is a Network Entity Title, which is the NSAP (Network Service Access Point) address of a node without a transport selector (or with a selector of 00).

According to the DECnet-OSI manuals, a NET may be displayed in it's binary form, if it's invalid, i.e. /0A016400

I've tried this on our systems as well and also get this message. To me, it looks like this is the encoded IP network address with the last byte replaced by 00 or it's the IP subnet address:

/0A016400 = 10.1.100.0 - is this your subnet addr ?

Volker.

[Bart Zorn_1]

Volker,

Indeed, 10.1.100.0 is one of the ip subnets.

But how could this impose a conflict?

Thanks for your response!

Bart

[Volker Halle]

Bart,

I would assume, that this could have something to do with nodes running DECnet-over-IP and being in the same subnet. As we only have one subnet, I may not be able to provide addition value, but you could try and find out, if you maybe get this error only on nodes which are in the same subnet as the local node.

This probably is some subtle bug in DECNET_REGISTER or some configuration problem - who knows.

Volker.

[Bart Zorn_1]

Volker,

DECnet over ip is running without problems, regardless of the nodes being registered with their SC2/TP2/IP tower or not. DECNET_REGISTER wants to register these towers as well, so I am inclined to think that it is a DECNET_REGISTER problem.

The nodes are in several different subnets, but they all can reach each other in one common subnet as well. Our DNS entries do not point to this subnet and that is why I would like to have the towers in the local name database right.

I will probably log a call with HP for this.

Have a nice weekend!

Bart

[Colin Butcher]

Hello Bart,

Volker has done sterling work here with tracking down the "NET value" issue. It seems to me as if your problems come from the way you have the various naming services configured and which naming service provides the name to address resolution.

I'm slightly surprised that you have "DECnet over IP" nodes registered in the DECnet namespace. Assuming that you're using the DECnet local naming option then I generally set things up as follows (as seen from the DECnet Phase V machine you're working with):

Other DECnet Phase IV nodes - register them with NSP transport only using their Phase IV address.

Other DECnet Phase V machines with Phase IV compatible addressing - register them with either NSP or OSI TRANSPORT transport using their Phase IV address. I generally prefer to use NSP in preference to OSI TRANSPORT as I've seem a few performance issues with OSI TRANSPORT and DECdfs / BACKUP. Don't register the nodes with both transports as it will double your timeouts if the node is unreachable - it will try the first transport, then the second transport.

Other DECnet Phase V machines with Phase V addressing - register them with OSI TRANSPORT transport using their Phase V addresses.

If one (or more) of the other Phase V mchines has multiple LAN adapters connected to the same LAN (or VLAN) then you might have both a Phase IV address and a Phase V address, so register the node with both addresses and the OSI TRANSPORT transport.

Other DECnet Phase V mchines connected to by "DECnet over IP" - don't register them in the local DECnet namespace (in fact remove them), but use the local BIND resolver to resolve the name to an IP address. I generally configure the local DOMAIN nameserver (IP BIND resolver) address (as set up in the NET$CONFIGURE naming section) to be 127.0.0.1 (ie: localhost) and then use the local TCP/IP HOSTS file or the locally specified TCP/IP DNS server list to provide the name to IP address lookup.

In general my preference is for local DECnet naming and for local HOST file IP naming for the DECnet over IP nodes, unless there is a very large population of nodes to be maintained. Command files can then be used to update the naming information around the DECnet network.

Hope that helps.

Cheers, Colin.

[Bart Zorn_1]

Hello Colin,

Thanks for your explanation!

Generally what I do is not much different from what you describe. I was not aware of performance problems with OSI, so I did not really have a preference for OSI or NSP.

But what I was doing now was using option 3 of DECNET_REGISTER to update address information, and that gives you all the towers that a node supports, including the ip one. It is at that point that I get the duplicate address errors.
This looks like a problem in DECNET_REGISTER or CML.

If I find the time, I will call HP. I will let you know.

Regards,

Bart

[Pim van Velzen]

There is a fix-image available for this problem, from your local HP support centre.

It is not available yet in an official ECO-kit for DECnet-plus.

Regards, /\Pim.