[Info-vax] LAT query

[Rich Jordan]

On Thursday, January 7, 2021 at 1:43:34 PM UTC-6, Hans Bachner wrote:
> Hans Bachner schrieb am 07.01.2021 um 20:14: 
> > Rich, 
> > 
> > Rich Jordan schrieb am 05.01.2021 um 17:50: 
> >> Running into a novel (for me) LAT issue. We have a site with a DS20 
> >> and a DECserver 708 with current software. LAT is used for a couple 
> >> of faxmodem connections and one management terminal that still 
> >> connects that way. 
> >> 
> >> We are putting an emulator in to replace the alpha. The machine was 
> >> setup offline, IP and DECNet address changed but we missed adding a 
> >> service name parameter to the LAT startup so when it initially booted 
> >> on the customer network, it also presented the same LAT service name 
> >> as the actual Alpha. That was quickly corrected, the emulator 
> >> rebooted, and the emulator now has its separate LT service name. The 
> >> emulator and the alpha are on the same subnet/VLAN/switch with no 
> >> filtering or load balancing or other possible known problem causers. 
> > 
> > Did you configure the emulator to use the same MAC address as the 
> > physical DS20? This must be avoided if they are in the same LAN 
> > (specifically: same broadcast domain). Different DECnet addresses 
> > should/might hide this problem, but it's better to avoid that in the 
> > first place. 
> > 
> >> Now the DECserver keeps 'losing' the alpha and the emulator as 
> >> services it will connect to. Only one of them shows up as an 
> >> available service at a time, either 'alpha' or 'emu'. You cannot 
> >> connect to 'alpha' when the DECserver sees 'emu' and vice versa. The 
> >> services on both machines appear to be running normally. One day (or 
> >> for several hours) one will be available, then for reasons unknown it 
> >> switches to the other. 
> >> 
> >> We can bounce the decserver if that is likely to help, but I don't 
> >> recall ever seeing behavior like this before, albeit with older 
> >> DECservers than the 708. Any ideas? 
> >> 
> >> Thanks 
> > 
> > Make sure LAT is started after DECnet during system startup. On the 
> > running system, stop LAT ($ MC LATCP SET NODE /STATE=OFF if LAT is not 
> > actively used by some process) and restart it with 
> > $ @SYS$STARTUP:LAT$STARTUP 
> > 
> > If this does not help, please post the results of the following commands: 
> > 
> > - on both physical and emulated Alpha: 
> > $ MC LATCP SHOW NODE 
> > $ MC LATCP SHOW SERVICE <service-offered-by-this-node> 
> > $ MC LATCP SHOW LINK /FULL 
> > 
> > - on the DECserver: 
> > Local> show node <ds20> 
> > Local> show service <service-on-ds20> 
> > Local> show node <emulated> 
> > Local> show service <service-on-emulated> 
> > 
> > Thanks regards, 
> > Hans.
> Btw, it should not be a problem for the DECserver to see the same 
> service offered by multiple nodes. In fact, this is a feature of LAT 
> which helps to achieve load balancing and failover. 
> 
> Hans.

THanks for all the replies and sorry for taking so long to respond.

The emulator was brought up on a separate network.  Before it was moved to the production network (for testing and to make DECnet available between it and the current server), its SCSNODE, SCSSYSTEMID, DECnet nodename, DECnet address, IP address, IP nodename were changed to EMU and available addresses.  The SCSSYSTEMID is compatible with the DECnet address.  So the MAC, post DECnet, is definitely unique on the production net.

I just forgot about LAT so it kept calling itself Alpha (even after all of the above were updated).

I will try rebooting the emulator this weekend and changing the startup to have both service and nodenames specified as EMU and see what happens.  The customer doesn't want to reboot the DECserver unless absolutely necessary; turns out is is also used for actual remote sites dialing in still at all hours though they don't connect to the VMS system.  

Getting on the DECserver shortly to review all teh other info suggested.  Thanks!

Rich