Note that the APAR addresses the case of datagrams which are
INCORRECTLY discarded. This is not Bill's case because there really
is an "Inv blk hdr" in the block. I also had this problem and when
I reported it IBM was told that a similar incident already existed
for which the responce was:
"The DTCCTC008E messages are explained by PQ34318. We made a change in
that apar to allow the the entire buffer to be used but it has been
reported that the message still is issued intermittantly. I did trace
the problem and the message is being issued validly the input from
Linux is not correct. If the message is being intermittantly issued it
should not cause the outage the data is just resent by the Linux host.
Linux support would have to address that issue."
Bob Matthews, University of Geneva.
----- Original Message -----
From: "Grimm Peter (KTPS 1)" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, February 14, 2002 8:10 AM
Subject: AW: TCP/IP and Linux
This is the Apar to fix the problem:
Abstract for VM TCP/IP APAR PQ34318
APAR PQ34318
CTC DRIVER MAY INCORRECTLY DISCARD DATAGRAMS WITH DTCCTC008E
If a datagram ends within 6 bytes of the end of the CTC write
buffer, it will be discarded by the read side and message
DTCCTC008E will be produced. Note: This problem is equivalent to
that reported by MVS CS/390 APAR PN80905.
mfG Peter Grimm
-----Urspr�ngliche Nachricht-----
Von: Scully, William [mailto:[EMAIL PROTECTED]]
Gesendet am: Mittwoch, 13. Februar 2002 17:49
An: [EMAIL PROTECTED]
Betreff: FW: TCP/IP and Linux
Thanks for the info Romney! On one of the Linux servers where I get the
error, I did an IFCONFIG and I find:
linux017:~ # ifconfig
ctc0 Link encap:Serial Line IP
inet addr:141.202.232.131 P-t-P:141.202.198.101
Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MTU:1500 Metric:1
RX packets:7407345 errors:0 dropped:0 overruns:0 frame:0
TX packets:13113625 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:3924 Metric:1
RX packets:2629004 errors:0 dropped:0 overruns:0 frame:0
TX packets:2629004 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
I see an MTU of 1500 on ctc0. So how did such a large packet end up on the
CTC between Linux and VM?
-----Original Message-----
From: Romney White [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 13, 2002 11:02 AM
To: [EMAIL PROTECTED]
Subject: Re: TCP/IP and Linux
Bill:
The message is documenting the fact that Linux sent a malformed block
of packets across the CTCA. The blocks may be up to 32K (32768 bytes)
long, so a packet starting at 33134 is clearly an error. The offending
packet is at offset 31628 in the buffer.
I presume that there is a mismatch in the buffer size between Linux
and VM TCP/IP and hope there is a control you can set on the Linux
side to use a buffer size of 32K.
Romney
On Wed, 13 Feb 2002 10:55:27 -0500 Scully, William said:
>(Cross-posted to the VM and Linux on 390 lists)
>
>We find a lot of the following messages on TCP/IP's console (FL 3A0)
>regarding the CTCs for Linux servers:
>
>22:50:10 DTCCTC008E CTCA device LINUX016: UnpackReads: 33134
>from input position 31628. Last blk hdr 0. Discarding remainder of block.
>
>
>Are others of you out there seeing this? The message doesn't seem to be
>documented. What does it mean? It appears that some (but not all) servers
>loose connectivity when this happens.
>
>William P. Scully
>Systems Programmer
>Computer Associates International, Inc
>[EMAIL PROTECTED]
