Re: Lost datagrams on z/OS 1.12?
Charles Mills wrote: And the answer is ... And I hear a drrum ro! ;-D A bug in my code was causing my software to *very occasionally* send out a message in which the initial part of the message was malformed for the protocol it implements. (Syslog, in the UNIX/RFC 3164 sense of the word, not in the MVS SYSLOG sense of the word.) Ouch... An Intrusion Protection System was then shutting down the path on the theory that this was some sort of malware attack. Very interesting, so it was indeed an external issue triggered by your bug. (First post: It is definitely not a firewall or other external issue because Version x.1 works fine.) Working on a fix ... Good luck! I hope you can get it sorted out! Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Lost datagrams on z/OS 1.12?
It is definitely not a firewall or other external issue I guess all debugging consists of finding out where you wuz wrong. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Tuesday, April 02, 2013 3:14 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Lost datagrams on z/OS 1.12? Charles Mills wrote: And the answer is ... And I hear a drrum ro! ;-D A bug in my code was causing my software to *very occasionally* send out a message in which the initial part of the message was malformed for the protocol it implements. (Syslog, in the UNIX/RFC 3164 sense of the word, not in the MVS SYSLOG sense of the word.) Ouch... An Intrusion Protection System was then shutting down the path on the theory that this was some sort of malware attack. Very interesting, so it was indeed an external issue triggered by your bug. (First post: It is definitely not a firewall or other external issue because Version x.1 works fine.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Lost datagrams on z/OS 1.12?
And the answer is ... A bug in my code was causing my software to *very occasionally* send out a message in which the initial part of the message was malformed for the protocol it implements. (Syslog, in the UNIX/RFC 3164 sense of the word, not in the MVS SYSLOG sense of the word.) An Intrusion Protection System was then shutting down the path on the theory that this was some sort of malware attack. So all of a sudden data, including subsequent correctly-formed messages, would stop arriving at the destination for some period of time. (Exactly what the reset trigger was is not clear to me.) Working on a fix ... Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Friday, March 22, 2013 7:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Lost datagrams on z/OS 1.12? Charles Mills wrote: Good question. The big problem is at one customer. Thanks. That could helps you to narrow your search to a solution. So the answer to your question is a little unclear. 1 or 2 customers out of 3. Ok. Then I'm out of ideas and any possible contributions to your problem solving. I was hoping you have 3 million customers and you have problem with this ONE customer... ;-) Good luck and all of the very best for you! Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Lost datagrams on z/OS 1.12?
Charles Mills wrote: I have told the customer that it may be our problem In all your posts, you're speaking of one? customer. Do this problem appears at your other customers? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Lost datagrams on z/OS 1.12?
Good question. The big problem is at one customer. We have another customer -- z/OS release number question still pending -- that is running the possibly problematic code with no issue. There was one POC where the prospect installed the product, which supports the use of TCP or UDP. The prospect wanted to use TCP but there was an unrelated issue with TCP so they tried UDP. I *think* they *may* have seen this problem, but they had no interest in exploring the UDP issue since what they really wanted was TCP. Perhaps it was something else -- some unrelated firewall configuration issue or something. For obvious reasons we have not shipped this code to anyone else. We have 1.11, 1.12, and 1.13 test LPARs and have never seen a hint of anything like this in testing. So the answer to your question is a little unclear. 1 or 2 customers out of 3. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Friday, March 22, 2013 2:14 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Lost datagrams on z/OS 1.12? Charles Mills wrote: I have told the customer that it may be our problem In all your posts, you're speaking of one? customer. Do this problem appears at your other customers? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Lost datagrams on z/OS 1.12?
Charles Mills wrote: Good question. The big problem is at one customer. Thanks. That could helps you to narrow your search to a solution. So the answer to your question is a little unclear. 1 or 2 customers out of 3. Ok. Then I'm out of ideas and any possible contributions to your problem solving. I was hoping you have 3 million customers and you have problem with this ONE customer... ;-) Good luck and all of the very best for you! Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Lost datagrams on z/OS 1.12?
Some of you asked for updates. Update: the problem has reappeared after a while in the version 1.3 code. I got a packet trace and it seems to me to show everything exactly as I would expect. I have told the customer that it may be our problem but someone on the network side or in IBM is going to have to look at the packet trace and tell me what we're doing wrong. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Wednesday, March 20, 2013 2:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Lost datagrams on z/OS 1.12? And the answer is ... that I am not a very happy camper here. I sent version 1.3 off to the customer. The only changes are diagnostic, not functional. And guess what -- the problem has gone away. So either - the customer is confused and/or was also making firewall or router changes at the same time. I don't think that is the case. - moving variables around has obscured the problem. That's the one that worries me. Very little variable movement so hopefully not. - perhaps compiler/library maintenance? Thank you Lloyd I am looking into that. Not much time between versions. Version 1.2 was compiled on Feb. 25 and Version 1.3 yesterday. Otherwise I just don't know. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Wednesday, March 20, 2013 8:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Lost datagrams on z/OS 1.12? 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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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. Yes, obviously it could be your basic program bug and I am of course working the heck out of that angle. I'm not asking this list to debug code it has not seen. The code is way too complex to post here meaningfully. But does this problem ring a bell with anyone? I am not the most skilled in the world at searching for APARs. Does anyone else want to spend 5 minutes and see if you can find anything? Thanks much, Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Kind regards, / Mit freundlichen Grüßen Miklos Szigetvari Research Development ISIS Papyrus Europe AG Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria T: +43(2236) 27551 333, F: +43(2236)21081 E-mail: miklos.szigetv...@isis-papyrus.com Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 Visit our brand new extended Website at www.isis-papyrus.com --- This e-mail is only intended for the recipient and not legally binding. Unauthorised use, publication, reproduction or disclosure of the content of this e-mail is not permitted. This email has been checked for known viruses, but ISIS Papyrus accepts no responsibility for malicious or inappropriate content. --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Lost datagrams on z/OS 1.12?
Miklos Szigetvari wrote: 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 . Hmmm, which leads me to some things: Charles: In TCP/IP, do you collect SMF records 119 for UDPTERM? Do you have UDPCHKSUM defined for your TCP/IP Stack? Is the datagram traffic the same on both your product version? I doubt if it is useful, but can you use CTIEZBxx parmlib member to do traces for TCP/IP? About OMVS, I wonder whether some settings can be too small for your product? For example in RACF, the OMVS segment there are some settings which may be enlarged? Just wondering of course. (Disclaimer, It was a very long time ago that I helped to do TCP/IP traces and even that was for specific ports) Good luck and please tell us if you got a solution. (perhaps by writing version x.3? ;-D ) Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Lost datagrams on z/OS 1.12?
It was the UDPQUEUELIMIT we have set. On 20.03.2013 09:33, Elardus Engelbrecht wrote: Miklos Szigetvari wrote: 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 . Hmmm, which leads me to some things: Charles: In TCP/IP, do you collect SMF records 119 for UDPTERM? Do you have UDPCHKSUM defined for your TCP/IP Stack? Is the datagram traffic the same on both your product version? I doubt if it is useful, but can you use CTIEZBxx parmlib member to do traces for TCP/IP? About OMVS, I wonder whether some settings can be too small for your product? For example in RACF, the OMVS segment there are some settings which may be enlarged? Just wondering of course. (Disclaimer, It was a very long time ago that I helped to do TCP/IP traces and even that was for specific ports) Good luck and please tell us if you got a solution. (perhaps by writing version x.3? ;-D ) Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Kind regards, / Mit freundlichen Grüßen Miklos Szigetvari Research Development ISIS Papyrus Europe AG Alter Wienerweg 12, A-2344 Maria Enzersdorf, Austria T: +43(2236) 27551 333, F: +43(2236)21081 E-mail: miklos.szigetv...@isis-papyrus.com Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 Visit our brand new extended Website at www.isis-papyrus.com --- This e-mail is only intended for the recipient and not legally binding. Unauthorised use, publication, reproduction or disclosure of the content of this e-mail is not permitted. This email has been checked for known viruses, but ISIS Papyrus accepts no responsibility for malicious or inappropriate content. --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Lost datagrams on z/OS 1.12?
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
Re: Lost datagrams on z/OS 1.12?
Charles, Where was the routine compiled? Under which version of z/OS? If z/OS 1.12 or newer, make sure that you check the updates to the compiler and the library. They were significant. Lloyd - Original Message From: Charles Mills charl...@mcn.org To: IBM-MAIN@LISTSERV.UA.EDU Sent: Wed, March 20, 2013 11:09:07 AM Subject: Re: Lost datagrams on z/OS 1.12? 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Lost datagrams on z/OS 1.12?
Interesting. Thanks. I will look into that. I don't own that part of things. Compiling and linking on 1.13. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lloyd Fuller Sent: Wednesday, March 20, 2013 10:33 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Lost datagrams on z/OS 1.12? Charles, Where was the routine compiled? Under which version of z/OS? If z/OS 1.12 or newer, make sure that you check the updates to the compiler and the library. They were significant. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Lost datagrams on z/OS 1.12?
And the answer is ... that I am not a very happy camper here. I sent version 1.3 off to the customer. The only changes are diagnostic, not functional. And guess what -- the problem has gone away. So either - the customer is confused and/or was also making firewall or router changes at the same time. I don't think that is the case. - moving variables around has obscured the problem. That's the one that worries me. Very little variable movement so hopefully not. - perhaps compiler/library maintenance? Thank you Lloyd I am looking into that. Not much time between versions. Version 1.2 was compiled on Feb. 25 and Version 1.3 yesterday. Otherwise I just don't know. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Wednesday, March 20, 2013 8:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Lost datagrams on z/OS 1.12? 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Lost datagrams on z/OS 1.12?
Someone privately suggests that the diagnostic code may have slowed things down *just* enough to make it work. Good thought, but when we turn the diagnostics off it still works. My trace code is pretty good if I do say so myself. IIRC the path is only about four machine instructions if the option is off. Not much I'm sure compared to a sendto(). Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Wednesday, March 20, 2013 2:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Lost datagrams on z/OS 1.12? And the answer is ... that I am not a very happy camper here. I sent version 1.3 off to the customer. The only changes are diagnostic, not functional. And guess what -- the problem has gone away. So either - the customer is confused and/or was also making firewall or router changes at the same time. I don't think that is the case. - moving variables around has obscured the problem. That's the one that worries me. Very little variable movement so hopefully not. - perhaps compiler/library maintenance? Thank you Lloyd I am looking into that. Not much time between versions. Version 1.2 was compiled on Feb. 25 and Version 1.3 yesterday. Otherwise I just don't know. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Wednesday, March 20, 2013 8:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Lost datagrams on z/OS 1.12? 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
Re: Lost datagrams on z/OS 1.12?
Charles, My instinct would be to run a packet trace. Use PROT=UDP,PORTNUM=port and DISCARD=ALL. (DISCARD is a newish feature that will trace packets that are about to be dropped by the stack.) Good luck, Steven St.Jean -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Tuesday, March 19, 2013 3:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Lost datagrams on z/OS 1.12? 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. Yes, obviously it could be your basic program bug and I am of course working the heck out of that angle. I'm not asking this list to debug code it has not seen. The code is way too complex to post here meaningfully. But does this problem ring a bell with anyone? I am not the most skilled in the world at searching for APARs. Does anyone else want to spend 5 minutes and see if you can find anything? Thanks much, Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Lost datagrams on z/OS 1.12?
On Tue, Mar 19, 2013 at 12:16 PM, Charles Mills charl...@mcn.org 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.) UDP does not guarantee delivery of packets or the order in which packets are received. It is up to the application to manage those issues. 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. Yes, obviously it could be your basic program bug and I am of course working the heck out of that angle. I'm not asking this list to debug code it has not seen. The code is way too complex to post here meaningfully. But does this problem ring a bell with anyone? I am not the most skilled in the world at searching for APARs. Does anyone else want to spend 5 minutes and see if you can find anything? Thanks much, Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
