On 7 Oct, 13:34, Baxt...@tessco.com wrote:
> I am using TCPIP services with DECnet Phase V on 2 x Itanium Blades
> running OVMS 8.3-1H1.
>
> Here is the situation.
>
> Node 1
>
> SCSNode = OESTST
> DNS Host name OESTST-TAB
>
> In DECNET I have it set up as
> NodeName = oestst-tab
> Synonym = oestst
> -------------------------------------
> Node 2
>
> SCSNODE = TABTST
> DNS Host Name = TABTST
>
> In DECNET it is set up as
> NodeName = tabtst
> Synonym = tabtst
>
> I have 2 DNS servers
> tab-dns1.myplace.com
> glc-dns2.myplace.com
>
> -----------------------------
> I would primarily like the DNS servers to provide the name resolution.
> However the
> DNS host names are currently set up in the local tables on each node,
> (they are also defined in the DNS Servers coincidentally).
>
> how should I set up the naming information in DECNet Phase V.?
>
> i.e. "local,domain" or "domain", and how would I format the entries???
>
> Dave.

My understanding is that you need LOCAL, no matter what.

I would suggest that you use LOCAL,DOMAIN as this will then dive off
into the TCP/IP transport if you can't resolve the name through the
LOCAL address towers. I'm not certain that the TCP/IP naming will
actually go off through DNS or whether it will return remote node is
unknown if the address is neither in the local DECnet database nor in
the local host table. I suspect it'll return remote node is unknown
because DECnet doesn't use DNS lookup for the IP stack.

Steve

@net$configure in advanced mode

Answer "local,domain" to the naming service question.

Answer "127.0.0.1" for the name / address of the name server - actually they
really mean "BIND resolver". "127.0.0.1" equates to "localhost", so you
always query your local HOSTS database first, then it will use whatever DNS
nameserver list you have set up in your local IP stack. It's a useful trick
that doesn't seem to be documented anywhere.

All you then do is delete the 'old' DECnet style name from the local naming
service (using DECNET_REGISTER) and insert the new name into the local HOSTS
database, then move it out to your DNS if you ever need to.

You might find the article I wrote some time ago for the VMS technical
update useful, plus some of the slide sets available at
www.xdelta.co.uk/seminars

Don't forget that you can test the connectivity without relying on the
naming by using things like set host ip$. You can check the
naming at each end by looking at the SYS$*NODE* logical names. Beware that
proxies work by node fullname, so expect to have to re-add your proxies.

--
Cheers, Colin.
Legacy = Stuff that works properly!

On 7 Oct, 13:34, Baxt...@tessco.com wrote:
> I am using TCPIP services with DECnet Phase V on 2 x Itanium Blades
> running OVMS 8.3-1H1.
>
> Here is the situation.
>
> Node 1
>
> SCSNode = OESTST
> DNS Host name OESTST-TAB
>
> In DECNET I have it set up as
> NodeName = oestst-tab
> Synonym = oestst
> -------------------------------------
> Node 2
>
> SCSNODE = TABTST
> DNS Host Name = TABTST
>
> In DECNET it is set up as
> NodeName = tabtst
> Synonym = tabtst
>
> I have 2 DNS servers
> tab-dns1.myplace.com
> glc-dns2.myplace.com
>
> -----------------------------
> I would primarily like the DNS servers to provide the name resolution.
> However the
> DNS host names are currently set up in the local tables on each node,
> (they are also defined in the DNS Servers coincidentally).
>
> how should I set up the naming information in DECNet Phase V.?
>
> i.e. "local,domain" or "domain", and how would I format the entries???
>
> Dave.


LOCAL, DOMAIN

LOCAL means DECnet local host file
DOMAIN means whatever the DNS Name resolver is setup to do. Currently
that would be the local host file but could be the DNS servers if you
configured it like that.

On Oct 7, 10:03*am, "Colin Butcher"
wrote:
> @net$configure in advanced mode
>
> Answer "local,domain" to the naming service question.
>
> Answer "127.0.0.1" for the name / address of the name server - actually they
> really mean "BIND resolver". "127.0.0.1" equates to "localhost", so you
> always query your local HOSTS database first, then it will use whatever DNS
> nameserver list you have set up in your local IP stack. It's a useful trick
> that doesn't seem to be documented anywhere.
>
> All you then do is delete the 'old' DECnet style name from the local naming
> service (using DECNET_REGISTER) and insert the new name into the local HOSTS
> database, then move it out to your DNS if you ever need to.
>
> You might find the article I wrote some time ago for the VMS technical
> update useful, plus some of the slide sets available atwww.xdelta.co.uk/seminars
>
> Don't forget that you can test the connectivity without relying on the
> naming by using things like set host ip$. You can check the
> naming at each end by looking at the SYS$*NODE* logical names. Beware that
> proxies work by node fullname, so expect to have to re-add your proxies.
>
> --
> Cheers, Colin.
> Legacy = Stuff that works properly!

Hi guys,
thanks for your replies. I appreciate your "undocumented"
solution, however as a newbe to this I think I have to stick to the
"proper" stuff. Anyway, here is what I have concluded from your
joint comments,

SCSNODE = TABTST
DNS Host Name = TABTST
DNS Server Name = TAB-DNS1.myplace.com


1. @net$configure.
2. Select option 2 (Change naming information)
3. * Enter the directory services to use on the system [LOCAL] :
local,domain
4. * Enter the full name for directory service LOCAL
[LOCAL:.TABTST] :
5. * Enter the fully qualified host name for DNS/BIND :
tab-dns1.myplace.com
6. * What is the synonym name for this node? [TABTST] :


will this do the job?? And does this have to be set up on both
originator and destination in order to work??

Also, once this is set up, should it work immediately, or do I have to
wait, or flush cache, or anything?

thanks

Dave.

Using "127.0.0.1" as the local IP name BIND resolver is not an
"undocumented" solution in that you can enter whatever you like as the DNS
nameserver. I'm just surprised that it's not the standard recommendation,
because it's so easy and flexible in terms of setting up the name service
lookup precedence order once you've jumped sideways into the IP stack.

So, put "127.0.0.1" in as the name server, then set up the list of DNS name
servers you wish to use in your IP stack in the usual manner. That way you
get the HOSTS file first, followed by whatever name servers you choose to
use. Means you don't have to go back to your DECnet configuration if you
ever change your name servers. Easy.

You should make consistent naming changes everywhere. In practice a
destination node will accept inbound DECnet-over-IP connections without
having all the naming in place, but you'll see "back translate" failures
from the naming service until you have the naming consistent.

You'll also need to flush the naming caches everywhere too. NCL> FLUSH
SESSION CONTROL NAMING CACHE ENTRY "*" is what you need.

Don't forget to enable the PWIP driver and allow ports 102 and 399 through
the firewalls. You can also control which IP subnets you accept inbound
connections from if you're on a recent version (can't remember which right
now) - look at the NCL help for the rfc 1006 and rfc 1006-plus (aka rfc
1869) OSI transport templates.

--
Cheers, Colin.
Legacy = Stuff that works properly!

On Oct 7, 1:17*pm, "Colin Butcher"
wrote:
> Using "127.0.0.1" as the local IP name BIND resolver is not an
> "undocumented" solution in that you can enter whatever you like as the DNS
> nameserver. I'm just surprised that it's not the standard recommendation,
> because it's so easy and flexible in terms of setting up the name service
> lookup precedence order once you've jumped sideways into the IP stack.
>
> So, put "127.0.0.1" in as the name server, then set up the list of DNS name
> servers you wish to use in your IP stack in the usual manner. That way you
> get the HOSTS file first, followed by whatever name servers you choose to
> use. Means you don't have to go back to your DECnet configuration if you
> ever change your name servers. Easy.
>
> You should make consistent naming changes everywhere. In practice a
> destination node will accept inbound DECnet-over-IP connections without
> having all the naming in place, but you'll see "back translate" failures
> from the naming service until you have the naming consistent.
>
> You'll also need to flush the naming caches everywhere too. NCL> FLUSH
> SESSION CONTROL NAMING CACHE ENTRY "*" is what you need.
>
> Don't forget to enable the PWIP driver and allow ports 102 and 399 through
> the firewalls. You can also control which IP subnets you accept inbound
> connections from if you're on a recent version (can't remember which right
> now) - look at the NCL help for the rfc 1006 and rfc 1006-plus (aka rfc
> 1869) OSI transport templates.
>
> --
> Cheers, Colin.
> Legacy = Stuff that works properly!

Thanks Colin,

One more question before I try this out. Just for testing
purposes, I would like to stop the NAME_Service under TCPIP
services. If I have all of my test nodes defined in the local host
table, will this definition (i.e. 127.0.0.1) still work??? Or do I
need the name service running to be able to query the local table.

Dave

Haven't tried it myself, so I don't know. Why would you want to stop the
NAME service? There's only one way to find out for real...

--
Cheers, Colin.
Legacy = Stuff that works properly!