Conference 7.286::fddi

    I think there is something different, in a big way, between the way VMS
    treats these devices and the way ULTRIX and OSF/1 do.
    
    For example, if I unplug the cable from a working DEFZA, the LED goes
    to blinking green - either o/s.  When I plug it back in, on VMS, it
    goes to solid green for a second and then out and then after a few
    seconds back to solid green.  Whereas, with OSF or ULTRIX, it goes
    right back to solid green and stays.
    
    Also, I think there is some difference between how ULTRIX and OSF treat
    work in a point-to-point FDDI config and the way VMS does.
    
    I'ld love for someone to tell me I'm crazy.  Just clearing up that
    doubt would be helpful :-)

Solid green means you have a connection.  It sounds like the VMS system
gets confused by the device for some reason, resets it, lets it come back
up, gets confused again, ...

	paul

    I too have just experienced some "funnies" in an FDDI point-point (DEFZA to 
    DEFZA) setup.
  
    I was running the BRICKS demo on ALPHAs (Flamingos) OpenVMS 1.5, UCX for 
    same - all recent code.
  
    As I couldn't get my hands on a Concentrator I decided that direct links 
    would be the order of the day.....
  
    Ever tried getting two systems to "sync" in this config ? What a game !! 
    The DEFZAs would sit there all day winking at each other from time to time 
    but would not go into the "solid" green state.
  
    In the end I managed to get the systems running and talking to each other 
    in the following fashion:-
  
    - Boot the ALPHAS - at this stage they were cabled to each other correctly
    - Once up and running and DECnet was alive I had to "loop" the fibres in  
      the DEFZAs so that the system "saw" itself - presumably DECnet polling 
      was taking place. Apart from NCP to check the circuit/line states etc. I 
      also took the precaution of SHOWing the remote system - dunno if this 
      does anything but it worked for me
    - reconnect the cables to their correct position
  
    If I was lucky the systems would then sync at the next poll and the green 
    lights would go on solid..  If I was unlucky I had to go back and try again 
    etc.  Fun huh ?
  
    Is there any explanation for this behaviour after all it is a valid 
    configuration,  n'est ce pas ?
  
    Would things be any different if a Concentrator was used to link the two 
    machines or is it something peculiar to VMS ?
  
    I have to do this demo again very soon - an answer/solution would be useful 
    :^)
  
    Regards
  
    Rog

I'm also trying something similar (see Note 478.4 and replies). I have a 
concentrator, but the "game" doesn't seem to be much easier. One Flamingo
(DEFZA) has managed to form a connection to the concentrator (but some fluke,
I'm beginning to think), but I haven't been so lucky with the other one (the 
green LED just continues to blink).

Is there anything that I can do (play with the ST connectors, reboot, power-
cycle etc.) that will *consistently* allow the DEFZA and the concentrator to
talk sensibly to each other?

Thanks,

John

    
    Yes, OSF/Ultrix and OpenVMS drivers are different.  The OpenVMS driver
    will go offline when the ring becomes unavailable.  At this point, the
    driver waits for the ring to become available by polling at every 15
    seconds.  Currently, as soon as the ring becomes unavailable, the
    driver reports this condition to its clients.  As a result of this
    notification, all buffers owned by the driver are deallocated (which
    means a reset of the device so they device doesn't DMA into deallocated
    memory).
    
    This 'no cable' behaviour will be changing for future releases of 
    OpenVMS.
    
    After plugging the DEFZA back into the concentrator, the solid green 
    followed by turning off and then the lasting solid green is caused by 
    the normal reset sequence occuring during the driver's polling process.
    
    
    Note:
    
    Direct connection between two DEFZAs does work.  However, you do have
    to remember to switch the connections at one adapter (so you're not
    connecting xmit to xmit and recv to recv).  I used this local ring
    configuration quite often when testing the driver.
    
    Kirt
    
    P.S., The DEFTA is amaz'n...