*With the help of Al Gauthier and Ed Murray we determined that the EN board
was not the problem. As Ed Murray suggested we moved it closer to the CPU
boards to reduce the chance of distance related delays.
*Since I am bridged to our company's bigger network we decided to pull the
bridge and to our surprise the problem went away.
*Assuming the problem was with the bridge, I temporarily replaced it w/ a
Delni connection but the problem persisted.
*Assuming it could be offending broadcast traffic on the network coming
across the bridge, we then hooked up a macintosh and ran a great program
called EtherPeek (fyi: etherpeek@aggroup.com) that allowed us to easily
monitor the traffic during the rcp transfer to my SGI computer. This is how
we found the problem. Periodically, an update of gateway addresses is sent
out from one main computer system (IGP packets). These packets are numerous
and large enough to interfere w/ the Bruker EN board (we are surmising that
the buffer on the board fills up and can not recover to complete the data
transfer) causing the EN board to crash (Status LED goes from 3 to 0 and only
a system re-boot will re-set it to status 3).
->Clearly the AMX EN boards are not as forgiving as the SGI boards in
handling unnecessary broadcast traffic.
*A quick solution is put a smart bridge or router in place capable of
filtering off these IGP packets from the company net and we are in the
process of setting this up.
Hope this helps the numerous users who contacted me with similar unexplained
EN crashes on their AMX.
** My thanks to Al Gauthier and Ed Murray for helping me establish that there
was nothing really wrong w/ the Bruker system.
Happy Networking!
deb