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 ...