Conference 7.286::fddi

Can anybody provide me with information or point me to someone to determine what
S/W support will be provided for FDDI on ALPHA and in what time frame? I'm 
assuming DECnet, but what about UCX? 

    Ask in vaxwrk::alphanotes.  Also, you may need to be more specific
    about which FDDI device you want supported.  Like, "When will Alpha VMS
    support the TURBOchannel-FDDI adapter for an Alpha machine with a TC bus?"

    As far as device support in the operating system,.. it is generally 
    ready at the end of field test.
    
    As far as software "layered products" (DECnet, LAT, UCX, whatever)
    you have to ask each one individually for their schedules.
    
    Sorry I can't be of more help
    
    							/Bill
    

Here's a question that maybe Bill Salkewicz would care to answer - but anyone
else is welcome to have a go ;-):

I'm trying to get two Flamingos (OpenVMS T1.5) connected back-to-back with FDDI
- but haven't managed thus far.

I've set PE3=1, and FCA1: exists on both systems. The PHY LED of both DEFZAs 
blinks regularly, which is not what I'm after. .0 mentions the use of a 
logical to overcome the fact that DECnet doesn't support the DEMFA in this
version of EVMS - do I need to do something similar to map FZA-0 onto FCA0:?

Both DEFZAs are at V1.2, and the cable is good. Both Flamingos are in a LAVc 
(one Flamingo is a satellite of the other).

Does anyone have a check list of the things that I need to do in order to get
an FDDI circuit up between the two systems? It would be tremendously 
appreciated...

Best regards,

John

P.S. cross-posted in Alphanotes 

    The problem with directly connecting two FDDI adapters (on VMS) is that
    the drivers for the two devices do not continually try to make them
    join the ring.  We do this to save CPU cycles.  So because the drivers
    work this way, it's difficult to get the two drivers to attempt to
    join/create a ring at the same time.
    
    One person told me that they put a loopback on both devices (to get
    them running) and then very quickly pulled the two loopbacks out and
    plugged the two devices together with a "regular" cable.
    
    Of course, the easiest way to do this is to use a concentrator.  The
    concentrator is always looking down the wire for the other end.  So
    once you plug the cable into the adapter, it will join the ring.

HUH?

I don't understand why cycling through restart attempts saves CPU cycles.
The normal procedure is to start the device and wait to see what happens.

In any case, it now sounds like that approach actually creates a bug, so
it should be fixed.  S to S connections are legal, and the ability to create
them is important.  Telling the customer that he's got to buy a concentrator
is the wrong answer.

	paul

    If there is no cable plugged in then the device does not "start".
    That is, the device does not leave itself in a state where the driver
    gets an interrupt when the cable is plugged in.  The driver is forced
    to continually check if it can "start" the device.  We fall back to
    checking once per minute (or once per five minutes).  Also different
    versions of VMS wait different times.  Now that we have several FDDI
    devices we are working on getting them to all have the same behavior.
    
    If the device could operate more independently with regards to being
    able to tell the driver when it's ready to be started or when the cable
    has been plugged in, then we could wait for the interrupt - or even
    check the device once per second (if it's one instruction).  But to
    spend many CPU cycles is a waste when you figure there will be times
    when the device may not be plugged in for days/weeks/months.

    A concentrator is also not the right answer (in some cases) because it
    prevents full duplex.

Well, I've tried using a concentrator, and still no joy. The LEDs on both
the concentrator and the DEFZAs blink as opposed to staying solid green.
Both Flamingos are plugged in to M-ports, so theoretically I should be able 
to establish a connection.

I used NDU on a DS5000 to upgrade the DEFZAs to V1.2, the Flamingos both
run T1.5, the driver is SYS$FCDRIVER linked on 18-JAN-1993 10:37:29.79.

Any ideas on what I can do to get a connection?

Thanks,

John 

P.S. The current VMS driver behaviour (as described in .5) clearly needs to be
revised.

Re .7: with fiber, the adapter has no idea, and doesn't care, whether there
is a cable or not.  All it knows is that, once you tell it to start, it will
try to make the connection, and it will report when it's finished.

	paul

In all of the FDDI drivers that our group does (NT, DOS, OS2, SCO, Novell)
we just enable the link and wait for an interrupt from the adapter
indicating that it has made a connection.  This seems to work fine
for all of the protocols above us.

Of course, there may be some perfectly reasonable mitigating circumstances
in VMS or OSF/1 or ULTRIX which make this scheme unreasonable...

doug

    
    DEFZA to DEFZA works for me (after seeing the notes in here, I think
    it needs some more attention).  First of all, when connecting DEFZA to
    DEFZA, don't forget to switch the connection on one adapter so you
    aren't connecting xmit to xmit and recv to recv.  I used this
    configuration quite often when testing the driver (primarily with the 
    cluster protocol).  I'll have to retry this with other protocols.
    
    As Dave may or may not have eluded to, this is an area that we've
    talked about redesigning.  At this point, we have to decide what the
    correct and most efficient thing to do is.
    
    Kirt
    
    P.S., Bill Salkewicz no longer works for the company.
    

    
    I just re-read .9...
    
    There's something else basically wrong with your setup if using a
    concentrator doesn't work.  If the boards are not greater than rev C01,
    I wouldn't trust them.  
    

Aside: re .8: the presence of a concentrator doesn't necessarily prevent
full duplex mode.  What does is the presence of a third MAC.  If you're
trying to test full duplex, and this problem prevents you from getting
connections to work reliably, you might use as a workaround a concentrator
with NO management card.  No third MAC, no problem with full duplex.

	paul

For the sake of completeness, my problem was the hardware revision of the 
DEFZAs. My conclusion is that anything less than Rev C03 is about as close to
useless as one can get.

-John