DECnet will not start on boot

[geir_2]

Hi,

My Server is configured with IP and DECnet. After reboot only IP is ok and DECnet will not start normally.

If I use following commands:
1) mc ncp set exe stat shut, and
2) stop IP (UCX$config). Next
3) Netconfig, and enter values,
4) Start IP through UCX$config

Then everyting is normall until next reboot. The Alphaserver is connected through ethernet to a Cisco 3560 (12.2), and from Switch to a cisco router (2821).

I also know that the server tries to start DECnet before IP, but DEcnet get a "sync lost" , and next the system start IP.

I assume that I can use some ncp commands that solve the problem.

Geir

PS:
I will this time start a new thread,

[labadie_1]

Can you post the exact error messages you have in sys$manager:operator.log (or opc$logfile_name, if this logical is defined).

If you log the boot process in SYS$SPECIFIC:[SYSEXE]STARTUP.LOG, can you post the relevant part here ?
If not, can you set it (mc sysman startup set option/output=file...) for the next boot ?

[Vladimir Fabecic]

"I also know that the server tries to start DECnet before IP, but DEcnet get a "sync lost" , and next the system start IP."

That can be switch port / NIC settings.
First try to disable autonegotiation both on alpha server NIC and network switch port.
Things like that happens because of those settings.
Also send output of:
$ ANAL/SYS
SDA> show lan/error

[Hoff]

You seem to assume this is the host OpenVMS box, and assume that this is the OpenVMS configuration. That might well be the case, but I'd start with a wider view of the problem.

DECnet Phase IV should be started before most everything else -- it should to be started before anything else that touches the NIC, including (for instance) LAT.

In this case and as a test, I'd start ONLY DECnet, then exit the startup, reboot, and see if that works. Reduce the size of the problem.

Check for mandatory ECOs for OpenVMS and any ECOs for LAN-related pieces, ECOs for DECnet, and for the TCP/IP Services V4.* release involved here. Apply these preemptively.

The next spot would be to target the synchronization and the NIC settings, on whichever box this is and on the Cisco. Some NICs suck at negotiation -- see the OpenVMS FAQ over at www.hoffmanlabs.com/vmsfaq for the DE500 series negotiation matrix.

This might be that the Cisco needs some sort of a nudge or a delay to allow it deal with the address change performed by DECnet.

If you are running DECnet Phase IV, then the Cisco must be set to deal with DECnet Phase IV. (In my experience, it is quote common to encounter a mis-configured DECnet routing setting within Cisco. Empirical evidence indicates this isn't easy. It wasn't until I started dealing with Cisco and other gear that I learned why most IT teams wanted to get rid of all network protocols other than IP.)

Please post the output from SHOW EXEC CHAR, SHOW KNOWN LINE CHAR, and SHOW KNOWN CIRC CHAR -- from both the OpenVMS box and from the Cisco box. From both the OpenVMS box and from the next Cisco box in the chain.

Or you can call somebody in to sort out this problem for you, and to work with OpenVMS and DECnet and with the Cisco support folks.

Stephen Hoffman
HoffmanLabs

[Volker Halle]

Geir,

another entry for the same problem discussed previously...

To make sure that this problem is not triggered by some anomaly in your startup procedures, try the following:

Put an $ EXIT in the first line of SYSTARTUP_VMS.COM

Reboot your node.

Login and run: @STARTNET
check whether DECnet works o.k.

then: @SYS$STARTUP:UCX$STARTUP
check whether DECnet still works and UCX works as well.

Volker.