I85PREP
⌘ K
HPOC study materials
HPOC study resources

DECnet Phase IV Node Cannot Reach a New Host

HPOC · Put your knowledge to work in context.

All case studies

DECnet Phase IV Node Cannot Reach a New Host

A legacy OpenVMS Alpha system still runs DECnet Phase IV for a manufacturing control application. Its node address is 12.345. The site adds a new OpenVMS Integrity host that must exchange files with the Alpha over DECnet. The new host is configured with DECnet Phase IV address 12.500 and a DECnet-over-TCP/IP (DECnet Phase IV over IP) transport because the site no longer has native DECnet routers. The Alpha can see its own node but SET HOST to 12.500 fails with "network partner unreachable." The new host can ping the Alpha's IP address but cannot reach it via DECnet. The Alpha's DECnet database has no entry for 12.500. The network team confirms IP routing between the two hosts works.

1. Identify the most likely reasons the DECnet connection fails, covering both addressing and transport.

Read the worked answer

Two independent problems are likely:

1. DECnet Phase IV address validity

  • Phase IV addresses are area.node where the node number is limited (node ≤ 1023 in classic Phase IV). 12.500 is within range, but the area must match the routing topology. If the Alpha is in area 12 and the new host is also area 12, they are intra-area; if the site's routing expects a different area, reachability fails.
  • More importantly, the Alpha's DECnet database has no entry for 12.500, so even if routing works, name/address resolution and connectivity tests may fail. SET HOST 12.500 needs the address to be reachable via the routing layer; a missing database entry alone does not block numeric addressing, but it blocks node-name use and can mask the real issue.

2. Transport mismatch

  • The Alpha uses native DECnet Phase IV (no IP transport configured). The new host uses DECnet over TCP/IP. Native Phase IV and DECnet-over-IP are different transports. Without a DECnet-over-IP gateway/router or configuring the Alpha to also use the IP transport, the two cannot exchange DECnet traffic even though IP routing works.
  • IP ping success only proves IP reachability, not DECnet adjacency.

So the failure is a combination of a transport gap and a possibly incomplete DECnet database/routing configuration.

2. What configuration changes on each host would you make to establish connectivity, and in what order?

Read the worked answer

On the new Integrity host

  • Verify its DECnet Phase IV address is unique and in the correct area; confirm 12.500 does not collide with any existing node.
  • Confirm the DECnet-over-IP transport is configured and that its IP peer/gateway settings point to a reachable DECnet-over-IP router or to the Alpha if the Alpha will also run the IP transport.
  • Add the Alpha (12.345) to its DECnet database with SET NETWORK NODE 12.345 NAME ALPHA (or equivalent) so it can address it by name.

On the Alpha

  • Either (a) configure the Alpha to also use the DECnet-over-IP transport so it can peer directly with the new host, or (b) ensure a DECnet router/gateway bridges native Phase IV to the IP transport and that the Alpha's routing knows the path to area 12.500.
  • Add the new host to the Alpha's DECnet database: SET NETWORK NODE 12.500 NAME NEWHOST.
  • Verify NCP/SET NETWORK shows the expected circuits and that the transport is active.

Order

  1. Fix addressing/uniqueness and database entries on both sides.
  2. Establish the transport path (IP transport on Alpha or a gateway).
  3. Test with NCP LOOP/SET HOST numeric first, then by name.
  4. Only then enable application file exchange.

3. How would you verify each layer independently so you can pinpoint the remaining failure if `SET HOST` still fails?

Read the worked answer

Test bottom-up:

Layer 1 - IP

  • PING / TCPIP SHOW ROUTE between hosts; confirm bidirectional IP reachability. Already known to work, but re-confirm after changes.

Layer 2 - DECnet transport

  • On each host, NCP SHOW KNOWN CIRCUITS / SHOW CIRCUIT to confirm the DECnet-over-IP circuit is up and has a peer.
  • NCP SHOW EXECUTOR CHARACTERISTICS to confirm the transport is enabled and the node address is correct.

Layer 3 - DECnet routing/adjacency

  • NCP SHOW KNOWN NODES on each side to see whether the other node is reachable and via which circuit.
  • Check that the area/node addressing is consistent with the routing design.

Layer 4 - DECnet session

  • NCP LOOP to the peer by numeric address first (isolates name resolution), then by name (tests the database entry).
  • SET HOST 12.500 as the final end-to-end test.

If numeric works but name fails → database entry problem. If circuit is down → transport/gateway problem. If circuit is up but LOOP fails → routing/area mismatch. This isolates the layer before changing anything else.