I get a copy  of all these messages, so I guess  I should be coordinating
the troubleshooting. Anyway here is the synopsis:
 
AKRONVM (1.7a) -> OHSTVMA (1.6e) -> PSUVM (1.6e) -> X (1.7a)
 
where X is PUCC, NDSUVM1, QUCDN,  RICEVM1, UWAVM, NUSVM, USCVM and UGA. A
message  was  posted to  the  BANYAN-L  list  at  AKRONVM, where  it  got
checksummed. Neither OHSTVMA nor PSUVM checked the CRC - they just passed
the checksum onwards. All the 'X'  servers reported a checksum error, and
they  all  got  exactly  the  same  incorrect  CRC  for  their  own  copy
(1-6BD88363 instead of the expected  1-E1845D2D). It seems thus extremely
likely that PSUVM got a corrupted  copy, which it just distributed to the
downstream servers.
 
Another piece of information is that OHSTPHRM (a LISTSERV node downstream
OHSTVMA) got CRC  errors for 2 out  of the 6 UPD17A files.  When I resent
the files manually, it got CRC errors again. I had to resend them 2 files
to get a "clean" copy through. Here are the release levels of RSCS at the
sites in question (I was unable to get that information for CSUOHIO):
 
FROM OHSTVMA: DMTCMQ690I RSCS Networking Version 2, Release 3.00
FROM OHSTPHRM: DMTCMQ690I RSCS NETWORKING VERSION 2, RELEASE 2.00
 
Of course, since IBM forgets to update DMTCVT half of the time, this does
NOT mean that they are running the base level.
 
Finally, the way the files are corrupted is that a single letter here and
there  is uppercased.  I am  including a  copy of  the corrupted  message
below; does anyone know of an APAR that addresses this problem?
 
  Eric
-------------------------------------------------------------------------
Date:         Tue, 9 Jul 1991 08:11:39 EDT
Reply-To:     Banyan Networks Discussion List <[log in to unmask]>
Sender:       Banyan Networks Discussion List <[log in to unmask]>
From:         Brian Sullivan <[log in to unmask]>
Subject:      Re: EISA ethernet Card
X-To:         [log in to unmask]
To:           Multiple recipients of list BANYAN-L <BANYAN-L@AKRONVM>
In-Reply-To:  <[log in to unmask]>
 
I'm not sure about the performance of the 32 bit cards, but
it should improve the performance on the server. But the real
bottleneck in a server should be getTing the information from
the disk to memory and not from main memory to ethernet board.
I would take a look at the cashE hit rate (Netman/IO/File stats),
if it was below 90% and you Haven't already got the max mem in
the sErver I would increaSe the memory.
 
A note on putting 32bit boards in client PC's. I don't know if this
applies and it's just a theory some of us have batted around ...
If the network is busy, and you go to 32 bit cards, you allow user
applications to put an increased load on the network. Traffic
to the point where collisions increase, at which point the
whole thing snowballs. And response time drops exponentially???
Just a theory ...