Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!decvax!decwrl!amdcad!lll-crg!ucdavis!ucbvax!apollo
From: Mark_Giuffrida@UMICH-MTS.MAILNET
Newsgroups: mod.computers.apollo
Subject: File corruption.
Message-ID: <1130749@UMich-MTS.Mailnet>
Date: Tue, 11-Feb-86 08:37:48 EST
Article-I.D.: UMich-MT.1130749
Posted: Tue Feb 11 08:37:48 1986
Date-Received: Wed, 12-Feb-86 02:40:24 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 19
Approved: apollo@yale-comix.arpa

We have noticed that same problem on occasion on just one of
our machines.   When it happens, no matter where you are in the
network, you always get the "remote node failed to respond..." msg.
As I said, it happens to just *one* of our machines, and no others.
I haven't seen the problem in a month or so.  I can only recommend
2 things which helped us:

1) Use DMPF on the corrupted file and see if the header (the first
   32 bytes) have been corrupted -- i.e., all zeros.  If so, then the
   file should be "recreated".
2) Use the NETSTAT command during these times when the files aren't
   accessible and check to see if the "Last ring hardware failure..."
   message has the current time.  We had a temperature sensitive
   board (when the temp got above 75, it would act up) on one of our
   DN660's.  It caused subtle network problems and sometimes heavy
   network problems.  We traced one instance of the "remote node failed..."
   msg to this when the network was fine for all other nodes.
                                 Mark Giuffrida
                                 CAEN - University of Michigan