Conference 7.286::fddi

709.0. "PATHWORKS Solution for Manual FDDI Address update.- Verell" by SCHOOL::BOAEN () Thu Sep 17 1992 09:30

Cross-posting here seems appropriate, as this is a general PATHWORKS
FDDI problem.

                <<< ISEQ::CAD$DISK:[NOTES$LIBRARY]MDF.NOTE;1 >>>
                                    -< MDF >-
================================================================================
Note 76.0                      PATHWORKS WITH FDDI                    No
replies
FILTON::MCCAUGHAN_S                                  23 lines   7-SEP-1992
15:25
--------------------------------------------------------------------------------
    Thought the following information may prove useful for other FDDI/MDF
    cluster builders:-

    PATHWORKS uses static LAT tables which are stored on the PC which
    contain the addresses of the nodes which the PC can connect via LAT.
    This works fine with Ethernet as the VAX node broadcasts the AA- format
    network address as opposed to the 08- style hardware address.

    However as soon as the DECNET/LAT traffic on the VAX is switched to the
    FDDI adapter the 08- style address is broadcast instead of the AA-
    format. This means that every PC using LAT will have to recreate
    manually its static LAT table. In the case I met this was over 200
PC's,
    also every time a DEMFA is changed in a VAX the operation would have to
    be repeated. In VMS 5.5 this is the default behaviour.

    Having discussed this with CSC they have issued new patches/LAT images
    which allow reversion to the old method of addressing. I understand
    these will be incorporated in a future VMS release.

    In the meantime if you have a large PATHWORKS network with FDDI
    adapters in the VAX the patches would save you a lot of time.

                             Shaun

IMHO, I think that is a flaw in Pathworks not being able to 
automaticly detect the address from the service announcements messages 
from the system with the fddi controller.

I agree.  Defeating a feature that was put into the FDDI adapters
specifically to help LAT (i.e., to avoid the "you must start things in the
right order or DECnet won't start" problem) is a tolerable short-term
workaround, but it is NOT an reasonable long term fix.  

	paul

    With Multicast On defined in LATCP, PATHWORKS should auto detect
    addresses...

I beleive the problem with pathworks is that if the node is defined 
in it's local decnet database, the lat will always try to us that 
address unless you staticly set with the hardware address in latcp.