Thanks all. Filling in some gaps and answering some questions.
I've added additional trace code within the product to make certain that the socket, sockaddr, and record length are as expected. (I already know that the sendto() is getting issued with the correct record.) I changed the error check from if ( returnvalue < length ) to if (returnvalue != length ) to help avoid any possibility of signed/unsigned or similar issues. Running a test at the customer today with a packet trace also. Environment is z/OS started task. Source language is IBM XL C++. Record length varies but is typically a few hundred bytes and never exceeds 1024 bytes. Ditto for the old version that works, so maximum datagram and MTU size issues seem unlikely. Don't know any of the customer's TCP/IP configuration but the message traffic should be 99.9% the same for both versions -- they are in theory both sending the same "stuff." More to follow ... Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Miklos Szigetvari Sent: Wednesday, March 20, 2013 12:10 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Lost datagrams on z/OS 1.12? Not really rings the bell, but we have here some UDP applications, and the TCP/IP UDP settings maybe different, We had to change some "maxudp..." values in the TCP/IP or OMVS definition . On 19.03.2013 20:16, Charles Mills wrote: > I've got a problem that is defying my ability to find it. I have a > product that uses sendto() to send UDP messages (datagrams). At one > and perhaps two z/OS 1.12 customers I have seen a problem in which > what appear to be perfectly good sendto()'s send a datagram that never > arrives at its destination. (Of course, the lack of error feedback is > a known characteristic of UDP.) > > Version x.1 of my product does not exhibit this behavior. Version x.2 does. > There is relatively little difference between how the two issue > sendto(). I have never seen the problem on my development machine, > including under z/OS 1.12. > > It is definitely not a firewall or other external issue because > Version x.1 works fine. You bring it down and bring Version x.2 up > with the same parameters and it works for a little while and then 100% > of the messages start disappearing. You bring it down and bring x.1 back up and all is well. > Similar TCP/IP code does not seem to have the same problem. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
