From:	SMTP%"Info-VAX-Request@Mvb.Saic.Com" 17-OCT-1994 10:26:11.40
To:	EVERHART
CC:	
Subj:	Re: LAT Problem

From: raspuzzi@mrlat.enet.dec.com (Michael D. Raspuzzi)
X-Newsgroups: comp.os.vms,comp.sys.dec
Subject: Re: LAT Problem
Date: 16 OCT 94 08:22:53
Organization: Digital Equipment Corporation
Lines: 55
Message-Id: <37r6fg$mon@mrnews.mro.dec.com>
Nntp-Posting-Host: mrlat.enet.dec.com
To: Info-VAX@Mvb.Saic.Com
X-Gateway-Source-Info: USENET


In article <1994Oct14.165458.1@uncvx1.oit.unc.edu>, murrell@uncvx1.oit.unc.edu writes...
> 
>Problem:  LAT comes up on our FDDI controller and allows periodic
>          connections that are usually aborted/dropped. Although
>          we have an Ethernet controller as well, we are unable
>          to delete LAT$LINK and create it again using /DEVICE=ETA0:
>          LATCP says "no such device available."

I would first suggest that you get the latest LAT software for OpenVMS VAX
V5.5-2.  It is called CSCPAT_0511 V3.6.  There were a couple of problems with
the software when 2 LAN controllers exist that may help you.

When a system has 2 LAN controllers, you can never be sure which one is going
to be chosen for LAT on startup.  So, you should explicitly create a logical
LAT link in your LAT$SYSTARTUP.COM file before setting the node state on:

	$ MCR LATCP CREATE LINK FDDI$LINK /DEVICE=FXA0
	$ MCR LATCP SET NODE /STATE=ON

If you create a logical link before the SET NODE /STATE=ON command, then
the LAT software will not create the gratuitous LAT$LINK.

Are you trying to run LAT on both controllers?  This will cause you
a lot of grief if the 2 networks are bridged together.  You can run
LAT over both controllers and things should work as long as the 2
logical networks are seperated by a router (and not a bridge).

The last time I had a problem at a site that was very similar to this it
was due to the fact that they had decided to use the DECnet address on the
FDDI controller as well as the Ethernet controller.  So, even though they
were not running LAT on the Ethernet controller, some of the LAT packets
that were sent to the AA-00-04-00-xx-xx address did not make it to the FDDI
controller - they went to the Ethernet controller and were discarded.
This was due tot he fact that the Ethernet controller was running DECnet
(so it set the hardware address to AA-00-04-00-xx-xx) and starting a logical
LAT link on the FDDI controller with /DECNET does the same thing.

This results in spurious LAT timeouts and typically horrible LAT performance.
It also confuses the bridges.  Another thing you might try is running
LAT on the FDDI controller but not with the DECnet address:

	$ MCR CREATE LINK FDDI$LINK /DEVICE=FXA0 /NODECNET

Note, when you start try to start 2 controllers with the same address
(as in the above scenario) the duplicate address test is supposed to take
place and you should receive a failure.  However, I recall a VMS LAN driver
expert telling me that the FXA0 (DEMFA) does not always handle the duplicate
address test properly.  Hence, you can get in a situation where both
controllers are running with the same hardware address and it slipped passed
the duplicate address test.

--
Mike Raspuzzi (raspuzzi@mrlat.enet.dec.com)
Digital Equipment Corporation