Network issues with PersonalAlpha container

Gremlin,

you haven't even started the DECnet routing protocol on this LAN adapter yet. Assuming it's still defined to use the ESA0 LAN interface (from PersonalAlpha).

Check SYS$MANAGER:NET$CMSACD_STARTUP.NCL:
...
CREATE NODE 0 CSMA-CD STATION CSMACD-0 COMMUNICATION PORT = ESA
...
Just change ESA to EWA and reboot or use NCL to change the information in the running system.

Also check NET$ROUTING_STARTUP.NCL for

SET NODE 0 ROUTING CIRCUIT CSMACD-0 ENABLE PHASEIV ADDRESS = TRUE

This will force the MAC address of the LAN adapter to be changed. If you don't like this, make it: PHASEIV ADDRESS = FALSE

Volker.

Hi

Perhaps this could be included in some FAQs/instructions for those converting from PA - there may be many places where networking changes and updates are required?

I think, however, it has made no difference to the underlying network problem. After I rebooted, I still get this showing....


jumping to bootstrap code


OpenVMS (TM) Alpha Operating System, Version V8.3
© Copyright 1976-2007 Hewlett-Packard Development Company, L.P.

%DECnet-I-LOADED, network base image loaded, version = 05.13.00

%SYSINIT-I- waiting to form or join an OpenVMS Cluster
%VMScluster-I-LOADSECDB, loading the cluster security database
%EWA0, FastFD mode set by console
%EWA0, Link state: UP
%MSCPLOAD-I-CONFIGSCAN, enabled automatic disk serving
%CNXMAN, Proposing formation of a VMScluster
%CNXMAN, Now a VMScluster member -- system GAMMA
%CNXMAN, Completing VMScluster state transition
%STDRV-I-STARTUP, OpenVMS startup begun at 21-MAY-2010 23:26:14.06

No communication with other cluster members across the EWA0 link....

and...


$ mc ncp sho exe


Node Volatile Summary as of 21-MAY-2010 23:34:28

Executor node = 1.3 (GAMMA)

State = on
Identification = DECnet-OSI for OpenVMS


So, DECnet is running, EWA0 is selected but.....maybe using a PA image is not a good idea?

Gremlin,

you're running DECnet-OSI, so NCP is the wrong tool ! Use MC NCL SHOW ROUTING CIRCUIT * ALL to see the state of your routing circuit. I bet it's off, because the underlying CSMA-CD STATION is still set to use ESA0 (instead of EWA0). SDA> SHOW LAN will show the protocols active on your LAN device. Look for DECNETV and DECNET in the Client column ...

The fact that this node builds a cluster of it's own seems to indicate, that it does not see any cluster hello messages from another cluster node on the same LAN with the same cluster group number.

Check with SDA> SHOW LAN/COUNTER if the node is receiving any messages at all, this data is per protocol (i.e. SCS; DECNETV, ARP, IP etc.).

There is nothing like an 'OpenVMS PersonalAlpha image'. You can boot an OpenVMS system disk on ANY system of the correct architecture. You may need to adapt your configuration to the underlying hardware (or emulator). If you're clever enough, you can even do this with some IF F$GETDVI(...) statements dynamically during boot in SYLOGICALS.COM or SYSCONFIG.COM.

I can boot my OpenVMS .vdisk on my notebook with PersonalAlpha or FreeAXP alternatively and have a working environment (including an IP address received via DHCP).

So if you say your .vdisk works correctly with PersonalAlpha (using ESA0) and it doesn't work with FreeAXP (.271) (using EWA0), then you need to systematically troubleshoot the network stacks.

Volker.

Hi

Thanks for the info, it is well beyond my skill to trace in detail. I had hoped that I could pick up the image and run it under FreeAXP - clearly I can't without significant modification to cater for underlying network differences between PA and FreeAXP - no problem at all.

I guess that the best option would be to build clusters under either PA or FreeAXP and not try to "migrate" images from one to the other?

Cheers

How about running NET$CONFIGURE.COM and rebuilding the DECnet configuration for EWA0. Be sure to shutdown TCP/IP services before initiating DECnet. Then run TCPIP$CONFIG.COM to set up TCP/IP services on EWA0.