Thanks again to all who responded to my query. Jay's pointer at buffersizes resulted in our problem being solved. Great to have it sorted so promptly. My colleague John Rattray's note below might just help somebody else.
Regards, Eric Lawler. -----Original Message----- From: Rattray, John : SP-SI Sent: 11 December 2001 10:51 To: '[EMAIL PROTECTED]' Cc: Lawler, Eric : SP-SI Subject: FW: Problem with Virtual CTCs between VM Linux guests and OS/390 2.10 IP Stack. Jay, Thanks for this pointer, I couldn't find the CTC entries in the /proc filesystem, should we have them ??? What it did make me do was look at manual LNUX-1003-02 LINUX for S/390 Device Drivers and Installation Commands and I found a section on page 23 which states that the IOBUFFERSIZE on the remote side of the CTC to your Linux system should be set to 65535 as the Linux for S/390 CTC driver has 64k internally coded. We then found the TCP/IP IOBUFFERSIZE definition on our OS/390 stack which was defaulting to 32K. We amended this to 64k and we can now FTP using an MTU of 1492 with the transfer stalling. I would be interested to know where the CTC parameter definitions would be held on the Linux machines if not in /proc Regards, John -----Original Message----- From: Lawler, Eric : SP-SI Sent: 10 December 2001 16:18 To: Rattray, John : SP-SI Cc: Zarzeck, John : SP-SI Subject: FW: Problem with Virtual CTCs between VM Linux guests and OS/390 2.10 IP Stack. John, as agreed, Eric. -----Original Message----- From: Robert J Brenneman [mailto:[EMAIL PROTECTED]] Sent: 10 December 2001 15:34 To: [EMAIL PROTECTED] Subject: Re: Problem with Virtual CTCs between VM Linux guests and OS/390 2.10 IP Stack. Make sure the MTUs match **exactly** on each side of the CTC. Also check the CTC driver's buffersize on Linux - like so: alps4188:~ # cat /proc/net/ctc/ctc0/buffersize 32768 the following will change it if it is smaller than the MTU. I believe the buffer should be large enough to hold an entire frame, which is MTU + header size. alps4188:~ # echo "<buffersize>" > proc/net/ctc/ctc0/buffersize Jay Brenneman Eric Lawler <eric.lawler@barc To: [EMAIL PROTECTED] lays.co.uk> cc: Sent by: Linux on Subject: Re: Problem with Virtual CTCs between VM Linux guests and OS/390 390 Port 2.10 IP Stack. <[EMAIL PROTECTED] IST.EDU> 12/10/01 06:49 AM Please respond to Linux on 390 Port Many thanks for your replies regarding MTU size. We had MTU at 1492 and the ftp still failed. Then, we tried 65527 and it worked. So, we set about tracking the break figure and found that :- at MTU = 32767 the ftp failed. MTU = 32768 it worked the first time and then failed at the second and third attempts to send the same file. The failure sees the Linux guest 'stalling' with the msgs below issued at the OS/390 end. I must say the Linux VM ctc connection to OS/390 does not seem very robust. We have no problem sending data from OS/390 to Linux at any matching MTU value eg 1492. Any further suggestions eg Linux buffers ? We are new to Linux and could be missing something basic. Thanks again for replies so far. Eric Lawler. -----Original Message----- From: Robert J Brenneman [mailto:[EMAIL PROTECTED]] Sent: 30 November 2001 15:06 To: [EMAIL PROTECTED] Subject: Re: Problem with Virtual CTCs between VM Linux guests and OS/390 2.10 IP Stack. Check your MTU sizes on both sides of the CTC connection. On OS/390 do tso netstat gate - this will give you the MTU on that side of the CTC. It should be the 4th column, with a heading of Pkt Sz ( at least on z/OS R2 it is.) Set the MTU on Linux to be the same with a ifconfig ctc0 mtu 32760 (32760 is the MTU on my system. ) Jay Brenneman z/OS System Build and Installation Dept. C90A 1A26/710 T/L: 295 - 7745 Extern: 845 - 435 - 7745 [EMAIL PROTECTED] Eric Lawler <eric.lawler@barc To: [EMAIL PROTECTED] lays.co.uk> cc: Sent by: Linux on Subject: Problem with Virtual CTCs between VM Linux guests and OS/390 2.10 390 Port IP Stack. <[EMAIL PROTECTED] IST.EDU> 11/29/01 02:01 PM Please respond to Linux on 390 Port Hello, Our setup is under VM/ESA 2.4.0. without TCP/IP for VM. We have :- Linux virtual machines (Suse 7.0 kernel 2.2.16) connected via vctcs (r/w pair) to IP stack on OS/390 2.10 MVS guest. MVS guest has onward connection to outside world via CIP routers. Problem occurs with large volumes of data being sent from Linux thru MVS. No problem other way eg. FTP or NFS from LINUX to MVS fails while from MVS to Linux works ok. FTP showed no definitive error msgs but log listed a 'stall' situation. OS/390 showed following error msgs :- EZZ4310I ERROR: code=80100044 reported on device DEVB26. diagnostic code: 03 EZZ4309I Attempting to recover device DEVB26 IST1578I SOFT INOP detected for IUTX0B26 by ISTTCCTE code = 102 This problem when using NFS causes sending Linux guest to lock out needing reipl to recover. Very small files (eg. 1K ) can be sent successfully from Linux to MVS. We have not yet discovered how large a file is needed to actually make the failure occur. Has any one experienced this problem. Thanks in advance, Eric Lawler. Eric Lawler, Infrastructure Support (Platforms), Barclays Service Provision, Ground Floor (A7), Block 10, Radbroke Hall, WA16 9EU (M). Phone: 7-2000-3729 (Internal) +44 (0)1565 613729 (External) Email: [EMAIL PROTECTED] Internet communications are not secure and therefore the Barclays Group does not accept legal responsibility for the contents of this message. Although the Barclays Group operates anti-virus programmes, it does not accept responsibility for any damage whatsoever that is caused by viruses being passed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Barclays Group. Replies to this email may be monitored by the Barclays Group for operational or business reasons. Internet communications are not secure and therefore the Barclays Group does not accept legal responsibility for the contents of this message. Although the Barclays Group operates anti-virus programmes, it does not accept responsibility for any damage whatsoever that is caused by viruses being passed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Barclays Group. Replies to this email may be monitored by the Barclays Group for operational or business reasons. Internet communications are not secure and therefore the Barclays Group does not accept legal responsibility for the contents of this message. Although the Barclays Group operates anti-virus programmes, it does not accept responsibility for any damage whatsoever that is caused by viruses being passed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Barclays Group. Replies to this email may be monitored by the Barclays Group for operational or business reasons.
