Differenze between NCP on Openvms Versions?

[Maurizio Rondina]

The Decnet network of site B, have the following terminal servers

1.401 90L+
1.402 90M
1.405 90L+
1.406 90L+
1.408 90L+
1.409 90L+

Some have address beginning with 00-.. others with 08-...

I try on all six, but none of them replies to
MC NCP LOOP NODE

I try to reach all the 6 address with command
MC NCP CONNECT NODE 1.xxx

only 1.408 respond.

The command set host/mop/circ=eia-0/add=00.. doesn't work, it reply with
%DCL-W-ACTIMAGE, error activating image NET$CCR image not found...

May be that when was executed NETCONFIG to someone of the questions of creation DECNET ACCOUNT, FAL, PHONE, etc. was replied in wrong mode.

Maybe that models of terminal servers, aren't manageable remotely. Note, they aren't 90TL, only 90L+ with only LAT protocol, and one 90M.


Now i ask to the customer, to verify very very well with 4 eyes, the hardware address, to avoid confusion between 8 and B, 0 and O, and so on. I think there was a mistake, on commands defining Decnet Database (DEFINE NODE .... HARDWARE .....), or all the terminal servers (except 1.408) have local problems (serial no. too old).

I think that now, after i correct the name of the circuit from SVA-0 to EIA-0, the server and the network work fine.

I will inform you about the reply of the customer, and I will assign points to you. Thanks.

[Bob Blunt]

First and foremost the NCP database definitions for the two terminal servers HAVE to have the correct information on both nodes. This means that each node's NCP permanent and volatile databases have to have the right stuff. In order for the "MC NCP CONNECT NODE 1.401" command to work properly the following minimum info MUST be defined in the database for each terminal server:

node address
node name
service circuit
hardware address (the MAC addr)

It helps if the terminal servers are defined with identical node name, node address and hardware address. If they're not consistant then you either can't connect from one node or you'll connect to the wrong terminal server. You can see the permanent database definitions for your terminal servers by entering (for example):

"LIST NODE 1.401 CHAR"

on both nodes. The service circuit MUST match the hardware that each host uses, so if one uses a SVA-0 circuit in it's database should show SVA-0 as the service circuit. If the other node has circuit EWA-0 its nodes should have EWA-0 for their service circuit.

The acid test for connectivity would be to issue the following command from both nodes, but you must have the correct destination MAC address and service circuit for each host:

"MC NCP CONNECT VIA SVA-0 PHYSICAL ADDRESS 08-00-2B-0F-FF-13"

Proper definition of the nodes in the NCP permanent database means you don't have to remember the gory details but you have to keep the information up-to-date or it stops working. Keeping that information updated and consistant can be painful but without the effort you're making yourself more work.


Hope that helps

bob

[Wim Van den Wyngaert]

It seems that set ho/mop was only implemented for decnet+. Didn't know that (we only have +).

Wim

[Wim Van den Wyngaert]

And I was wrong on the suspicion with 00. We have 08 and 00 too. I thought 00 was reserved for decnet nodes and that all dec stuff was 08.

Wim

[Maurizio Rondina]

To Bob:

In a NCPSTART.COM file whose execute on the startup procedure the system had the following NCP commands for each terminal server

DEFINE NODE 1.106 NAME T406 HARDWARE 08-00-.... SERVICE CIR EIA-0
SET NODE 1.106 NAME T406 HARDWARE 08-00-.... SERVICE CIR EIA-0
SET NODE T406

So we can use the command
NCP CONNECT NODE with 1.406, with T406 or with Hardware Addres, as we want.

To Wim:
i never use decnet+, only decnet fase IV

[Wim Van den Wyngaert]

Both address ranger belong to DEC.
http://standards.ieee.org/regauth/oui/oui.txt

Learned again. I thought only the first 4 address positions were used to denote the supplier. And it's 6.

Wim

[Bob Blunt]

Maurizo, your last response is confusing. In your original question you state that you're unable to communicate to a terminal server from a specific node and your example output from NCP shows inconsistancies between definitions for those terminal servers from the separate permanent databases. In your last response you show a portion of a startup command procedure where you're DEFINE-ing and SET-ing terminal servers.

Your NCP definitions have to be consistant across all your nodes or you can't expect consistant behavior, that's first. Second, there should never be any reason that you need to DEFINE and SET node characteristics for a normal system running DECnet during each boot. The permanent database retains the configuration data for that exact purpose. Aren't you getting errors during startup from this?

When you have consistant definitions and your attempts to connect from some nodes still fail, then you look at connectivity or network configuration as Hoff suggested.

[Hoff]

Maurizio: consider getting somebody in to review and to tailor this DECnet Phase IV network.

That the startup is issuing SET and DEFINE commands at startup is clearly indicating some DECnet network cleanup is needed, and that all DECnet routing traffic is being sent over the inter-site link are probably not goodness. There are configuration and operational improvements available here, above and beyond (likely) determining why the inter-site link is blocking the MOP protocols.

And it could be that MOP is simply lit on the wrong network controller(s), too.

Stephen Hoffman
HoffmanLabs LLC

[Colin Butcher]

Hello Maurizio,

Let me briefly summarize:

DECservers and other "MOP clients" do not run DECnet. The fact that they exist at all in the DECnet Phase IV node database is a kludge to associate them with a load image.

The protocols (at ethernet layer 2) you're using for DCservers are usually: MOP (boot / downline load support), Remote Console (NCP CONNECT to a remote device's virtual console port) and LAT (terminal access to systems and reverse LAT printer access from systems).

In addition you're probably running DECnet and TCP/IP.

I recommend that you remove the DECservers from the DECnet databases and use LANCP instead. It does a better job of MOP and Remote Console. If you need to manage multiple DECservers then get TSM (Terminal Server Manager) from the Freeware CD set).

I'd also recommend that you consider moving to DECnet Phase V (aka DECnet-Plus).

It sounds to me as if your WAN doesn't pass all the protocols: DECnet, MOP, Remote COnsole, LAT etc. If you want to continue woth this equipment then you need to fix that. If you can change your equipment then move to TCP/IP as the protocol between the DECservers and the systems, update to a version of terminal server firmware that supports BOOTP and then set everything up carefully.

It's not that hard, but is does require care and attenmtion.

Cheers, Colin,.

[Wim Van den Wyngaert]

Colin,

1 decserver worked so all protocols must be working.

Wim