Conference 7.286::fddi

We have run into the same problem here in the CSC. The LTdriver V6.0-405 was 
released from somewhere, we don't know exactly where it came from, but it was
suppose to fix some problems with AllIN1 and also provide LAT with the ability
to use the DECnet address on the fddi. Well, it caused a problem with loading
fonts, so all the fonts don't get loaded. A colleague of mine wrote a patch for
it and sent it to engineering, until they bless it, we can't give it out. The
engineer that needs to ok it is on vacation. As a work around, if you get a copy
of CSCPAT 511 V3.3, which has an older driver, but your fonts will load with it.
You will also lose the ALLIN1 fix and LAT will only be able to use the 
hardware address of the fddi controller. 

Once we get an ok from engineering on the patch, it will be rolled into CSCPAT
511, maybe next week sometime.

Brad Goodwin
CSC/CS Network Support

btw, you should get your DEFMA's to V1.4

>> As a work around, if you get a copy of CSCPAT 511 V3.3, which has an older
>> driver, but your fonts will load with it. You will also lose the ALLIN1 fix
>> and LAT will only be able to use the hardware address of the fddi controller

I had the CSCPAT 511 V3.3 installed. Then, before putting in place the DEMFA,
I put the new version of the LTDRIVER and LATCP to avoid the problem of the
addresses AA- that become 08- (the famous problem of the preferred services
stored in static table on the PCs) !

>> btw, you should get your DEFMA's to V1.4

Yes. I finally found the DEMFA014.SYS yesterday and will install it asap.

Thanks very much for your support.

Michel.

    Hi folks,
    
    	We have already been through the ringer on this.  The exact same
    	problems happend to us here in MKO.  We first noticed that LAT
    	wasn't using the physical (AA-00-04-00-) address via the DEMFA,
    	and exactly like Mr Goodwin (-.1) said, we lost are ability to do
    	any font loads which dropped application sessions and didn't allow
    	X-window sessions.  BTW: Our environment is identical (VMS 5.5-1,
    	DEMFA firmware 1.4, LT driver, etc..).  Then we noticed on of our
    	system that was running VMS 5.5-2 had neither of these problems.
    	We assumed it was the fix, so we upgraded our 5.5-1 system(s).
    	We no longer have the font problem, but we are back to square one,
    	sort of.  We are not able to start LAT with the physical address.
    	This is very important to us, becuase of the hundred plust PC users
    	we have that use static tables.  I believe that static tables are
    	a bad thing, but in the big sites, and most arear are consolidating
    	and creating very very large extened LAT LANs or MANs, the PC use
    	up all there memory trying to table all the service even with group
    	codes set.  Anyway, we have copared the vms 5.5-2 node that works
    	properly with the one that doesn't, but we can not find any
    	differences.  Anybody have any ideas?
    
    NEI-North
    Network Management,
    Mike

    
    
    re .3   - can you clarify what was working/not working on the two
    nodes. On the one you upgraded 5.5-1 to 5.5-2, it sounds like you
    replaced LTdriver ident 405 with 398 (assuming the suspicion is
    correct- 405 was built from an older source so that it introduces
    the ability to use the AA address on FDDI but reintroduces the 
    font problem where font frames were sent out on FDDI four bytes too
    large). 
    Is the other node ok on both counts - ie can you use the AA address
    on FDDI and load fonts ok  - it doesn't make sense if the rumour
    about 405 is true.
    
    
    re .1  - I can reveal that Mike Raspuzzi (sorry Mike!) produced the
    405 patch - I'll check with him the origin of this code. The following
    comparison of link dates suggests that 405 may not be built from the 
    398 source:
    
    V6.0-348    link date/time  8-JUL-1992 01:27:11.22
    
    V6.0-398    link date/time 23-JUN-1992 10:32:53.61
    
    V6.0-405    link date/time 20-JUL-1992 21:27:04.57
    
    
    John.

John,

We have been working with John Hassencahl. He patched our 405 driver and made
it work. He is going to submit it to Mike Raspuzzi for approval, but Mike is 
suppose to be on vacation this week and won't be back until next week.

Brad

    A little background here.  At the MKO campus, we are consolidating a
    few dozen major systems/clusters onto 12 64XX and 65XX series systems
    with DEMFA's, and they are all running VMS5.5-1.  A differnet 64XX
    (MK2DNS) that we use for MCC/DNS/DCM was already running VMS 5.5-2
    when we decided to connect it to FDDI.  We haven't had any problems
    with MK2DNS.  Then we connected system CGHUB to FDDI and noticed the
    physical address problem, so we installed the patch.  Then we noticed
    the font problem with CGHUB.  We are still living with the font problem
    on that system.  At that point we noticed that MK2DNS had neither
    problem and the only differnece was the VMS version, so when it was
    time to connect BRAT onto FDDI, we upgraded BRAT to VMS 5.5-2.  Now
    Brat does not have the font problem, but we can not get it to use the
    physical address for LAT.  So we started to compare MK2DNS to BRAT.
    Everything that we have found has been the same.   BTW: both MK2DNS
    and BRAT are using LTDRIVER V6.0-348 (8-JUL-1992) and no patches.
    
    We are still puzzled. 
    
    Mike.

With the 348 driver, you won't be able to use the physical address for lat. 
You can only use the physical address with the 405 driver, but you will have 
problems loading fonts, a fix is in the works.

    .7,
    	If what you say is true, then how can you explain the fact that
    	we are using the physical address for lat with the 348 driver
    	on MK2DNS?  Also, are you implying that the LAT engineering group
    	is taking away this critical feature?  The LATcp help file still
    	lists "/DECNET" as a valid qualifier.
    
    	Mike

    re .8  -we are talking about the LAT interface to FDDI. The DEMFA is 
    different from ethernet cards in that it can use multiple addresses
    (ie 08xxx and AAxxx) so that while Decnet insists on the AA address, 
    it does not impose this on other protocols. While this sounds ok,
    there was a historical problem whereby PCs with static databases 
    populated by AA addresses could not connect to nodes now using
    hard addresses.
    If you have problems with ident 348 on ethernet, this sounds like
    some other problem,
    
    
    John.

A number of Ethernet cards support multiple addresses too, though not all
drivers take advantage of that capability.  In fact, even the late unlamented
DEQNA can do this...

	paul

    	Something else to consider!
    I've seen a problem with some Lat applications using an FDDI host from
    Ethernet, one of which is decwindows. At session startup I've seen on a
    sniffer trace the "max lat msg size" is negotiated to be 1518 . Thats 18 too
    many bytes according to the lat spec.
    	Symptoms are vt1200 sessions disconnect for retransmission
    timeouts, as soon as a frame too large for Ethernet is built by an FDDI
    host. 
    	This may not be the case here, but I thought it was worth
    mentioning. Thanks for the pointer here John.
    
    	Scott