Conference 7.286::fddi

That's how it should work (at least under VMS).  If ULTRIX or OSF/1 ever 
develop a real datalink layer, they will work the same way.

Re .0: could you explain a bit more?  

What adapter are you referring to in the "4000 model 90"?

What exactly are the messages that you are seeing?

Meanwhile, some comments:

On FDDI, there is no such thing as "the physical address".  Instead, each
protocol specifies what individual address it wants.  Most don't care, so
they get (or SHOULD get) the hardware address.  DECnet does care, and is
given what it asks for.  The DECnet address should not be given to any
other protocol (unless that protocol asks for it specifically, of course).
I vaguely remember a LAT feature that allows it to ask for the DECnet style
address, in order to avoid startup problems on Ethernet.  Is that feature
being used on your 4000?  If not, it sounds like a driver bug.

Secondly: why does it matter which address is used?  The purpose of the LAT
multicast is to let the other LAT boxes know that the node is out there and
what address to use for LAT messages destined to that node.  This purpose
is served no matter what address is used.  Are you saying that someone is
keeping tables of those addresses and expecting them to remain static?  If so,
that's a mistake.  Why is this being done?

	paul

    Paul,
    
    Yes, there are static tables being used in the configuration described
    in .0. PCSA allows you the option of using static tables, because of
    memory limitations under MS-DOS. When you start the LAT listener TSR,
    you can tell it how many services to listen for. Each slot takes up
    memory in the PC. However, in  large LAN configurations, this can be
    hundreds of services, and consequently, lots of memory. The LAT static
    tables in PCSA (sorry, PATHWORKS) allow you to set up a common
    environment without having to reserve memory for all of the other
    services that may be out in the network.
    
    You may want to talk with the PCSA folks about this, to see if there
    might be a better solution around.
    
    Cheers,
    Geoff.

      Paul,
    
    
        I don't know what the controller is called, but it had a FCAxx:
    designation. I did show it under sda but can't remember the name it
    gave me.
    
        There were no messages, for LAT and DECNET were running fine. The
    questions is, why does lat use the hardware address on one fddi
    controller and the physical address on another. Under sda, the lat
    protocol showed the physical address as an AA-00-04 address. Under
    sda, the controller showed 00-00-00-00-00-00 as the physical address.
    
        I know the customer could have his users update their lat preferred
    service database periodicly, but this is difficult in a large user
    base. I also see a problem that when a fddi controller is replaced late
    one night and the only people that know are the FE and the night time
    operator. I can see some major grief the next morning when thousands of
    users come in and can't connect to a service. 
    
    
        I am just looking for what we should expect and tell our customers
    what they should expect.  Thanks.
    
    
          Mark

Well, now you know why static tables are a bad idea.

I don't know what, if anything, the SDA display means.  Can you get messages
from the network with a datascope?  Also, are you telling LAT to ask for a
DECnet style address on one of the two systems?

Incidentally, the solution to the large table problem is the LAT directory
service sollicit function, which was added in a recent version of  the LAT
protocol specifically to deal with this problem of LAT.

	paul

    
    Tell your customer that the final release of FCDRIVER (for the DEFZA on
    the 4000-90) will behave in a manner similar to FXDRIVER in this regard
    (using the default HW address instead of the DECnet assigned physical
    address).
    
    This was a bug discovered in Field Test.
    
    Kirt
    

    We just got bit by the same ...
    
    Our customer who started using FDDI for LAST, LAT, Decnet also found
    that Pathworks uses 'static' tables for services. Since they have 
    *many* DOS machines they decided to transition back to ethernet, since
    their calldesk would not be able to handle 100's of phonecalls about
    not beeing able to use the cluster services..
    
    Any known solution.. the latcp /decnet qualifier has no effect
    whatsoever on the mac address.
    
    Gullik
    

One workaround would be for those applications to use a "supplied" address,
same as DECnet does.  The right answer, of course, is to get rid of that
static tables stuff.

	paul

    I know that LAT was changed to force the DECnet address when the
    /DECNET qualifier is used; but I don't know which version of LAT
    has the change.