Hi Alan,
I thought I sent this out last night but it does not look like it went so I am sending it again. If for some reason you did get this I apologize for sending it again. Not to belabor the subject I just want to make sure I understand. Here is what my issue was. I processed many SQL queries of DB2 tables via DB2 connect running on a z/OS LPAR down to a Linux server running on the same machine but a different z/VM LPAR without any issues. Until, we ran across some queries that were larger than all of the others. These queries failed (timed out). We saw in the DB2 connect trace that the size of the queries was about 2.3K. We knew it was a size issue because when we did a 'SELECT *' on the tables, basically reducing the size it worked. After a lot of effort we found that there was an extra route in the Linux routing table that sent the data bound for one of the z/OS LPARS over to our z/VM where it then was routed by the TCP/IP stack on z/VM to the z/OS LPAR over the HiperSockets LINK. This LINK happened to have a MTU size of 1500. When we removed the bogus route from the Linux routing table causing the SQL queries in question to travel over a HiperSockets LINK with a MTU size of 16348 they were successful. It appears that the difference in the MTU sizes was the problem. My question is does the MTU size mismatch cause the problem? I thought that even if the packets were fragmented they would still get over in full. Sorry for being so wordy but I thought I would present to try to help you help me and to also help others that may be just getting into this as I am. Thanks again for all of your help!! Terry Thank You, Terry Martin Lockheed Martin - Information Technology z/OS & z/VM Systems - Performance and Tuning Cell - 443 632-4191 Work - 410 786-0386 [EMAIL PROTECTED]
