James wrote:
> #3. Corruption in the data portion of a TCP packet.

[snip]

> Case #3 - This sounds like your problem, especially since this problem is
> seen 3000 to 3000.  Solution:  1. Fix the quality of the network links,
> and more importantly 2. Turn on TCP Checksum (don't pass go) Turn on TCP
> Checksum (don't collect $200 dollars) Turn on TCP Checksum...

As he said, do not pass go, do not stop to eat lunch, do not put it off
for the weekend, do not wait a while to see what happens.

Without the TCP level checksum enabled, *NO* *OTHER* *VALIDATION* on
inbound network data will be performed.  Historically, HP's LAN hardware
generally does not detect or report problems of this type.  A very
common failure mode of MAUs is to start quietly trashing the data that
passes through them.  There have also been one or two cases of bugs in
the MPE Lan Driver software that resulted in corrupted packets.  Again,
without the TCP checksum enabled, it is quite possible that nothing will
detect the corruption when it occurs only in the "data" (as opposed to
"header") portion of the IP packets.

If all you are doing over the network is Virtual Terminal connections,
then your exposure to serious problems is relatively limited.

But, if you do any kind of remote data access (and especially updating)
over your network (ODBC, RFA, RDBA, NetBase, NFS, Samba, any kind of
network backup, etc.) then it is quite possible that data is quietly
being corrupted.  In a worst case scenario, your databases silently turn
to mush over hours, days, or weeks, at which point recovery is difficult
to nearly impossible.

As James says, go forth and set:

> Path:  NETXPORT.GPROT.TCP
> [Y]       Checksum Enabled (Y For Yes, N For No)

> Expect to see TCP CHECKSUM PACKET DISCARDS logged to the console, this
> is a good thing and TCP will retransmit the packet.  This error tells you
> that you have a network link problem and that TCP is identifying corruption
> somewhere in the packet and a discard is taking place at this level rather
> then at the NS-SERVICES level detecting the problem in the NS-HEADER
> (8 bytes) or not detecting the problem in the data portion of the NS-MESSAGE
> - "AKA Data corruption"!

If you do start seeing these messages after turning on the TCP checksum,
then you should take the appropriate measures to deal with the potential
damage that may have already occurred.

G.