Re: TCP/IP ezasoket call interface - connection timeout parameter.
Thank you Mike, Roberto, and David for the unanimous advice. I guess we will have to re-implement! Kind regards, Jan -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: maandag 17 oktober 2016 6:20 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TCP/IP ezasoket call interface - connection timeout parameter. I'm not familiar with EZASOCKET but I assume it supports the usual set of socket API calls. To set a connection timeout put the socket into non-blocking mode and then call connect(). Check the return code, it's probably EINPROGRESS otherwise an error has occured. Call select() with a timeout value to wait until the socket is connected or a timeout occurs. Put the socket back into blocking mode and send/receive some data. I also use setsockopt() to set send/receive timeouts as well. On 14/10/2016 8:52 PM, Cannaerts, Jan wrote: > Hello list, > > > We have a situation where we have a CICS transaction which exchanges > information > With another company over TCP/IP, using the ezasoket call interface. > We are the client, while they are the server. > > Through experience we have learned that "because reasons", the server does not > always accept our connections, but our connection attempts are not being > actively refused. Instead, the connection attempt waits until its timeout > value > is met and then returns with the appropriate error code. For every pending > connection that will never succeed, a transaction sits there waiting for its > timeout. Those queue up, we reach MaxTasks, and other work gets disrupted. > > So the question is then; how and/or where we can set this timeout value > for a connection attempt? From what I gather, it's not possible to set this > value > on a per-socket basis, as some digging through the IP Sockets Application > Programming Interface Guide and Reference has left me wanting. From the > z/OS Communications Server: IP Configuration Reference, I find that I can set > the > CONNECTTIMEOUT parameter in the TCPCONFIG statement of our TCP/IP profile, but > this value will then be enforced on every connection made through that IP > stack. > From what I gather, we don't set CONNECTTIMEOUT, and as such are subject to > the > 75 second default, which is definitely too long for what we're doing. > > We could set up an entirely different IP stack with a lower CONNECTTIMEOUT for > just this application, but that seems a bit much. Especially if we can set the > connection timeout on a per-socket basis instead. > > Another idea is to make the sockets that perform the connection attempts > non-blocking. We would check the return code after the connection attempt, > and if > successful continue. If the connection is still pending, we'd issue a select > with > an appropriate timeout parameter. At this point this seems the most logical > way > to continue. But I know I might be missing something, otherwise I wouldn't be > consulting the list. > > Any ideas, or comments about my assumptions are kindly appreciated. > > > Regards, > Jan > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TCP/IP ezasoket call interface - connection timeout parameter.
I'm not familiar with EZASOCKET but I assume it supports the usual set of socket API calls. To set a connection timeout put the socket into non-blocking mode and then call connect(). Check the return code, it's probably EINPROGRESS otherwise an error has occured. Call select() with a timeout value to wait until the socket is connected or a timeout occurs. Put the socket back into blocking mode and send/receive some data. I also use setsockopt() to set send/receive timeouts as well. On 14/10/2016 8:52 PM, Cannaerts, Jan wrote: Hello list, We have a situation where we have a CICS transaction which exchanges information With another company over TCP/IP, using the ezasoket call interface. We are the client, while they are the server. Through experience we have learned that "because reasons", the server does not always accept our connections, but our connection attempts are not being actively refused. Instead, the connection attempt waits until its timeout value is met and then returns with the appropriate error code. For every pending connection that will never succeed, a transaction sits there waiting for its timeout. Those queue up, we reach MaxTasks, and other work gets disrupted. So the question is then; how and/or where we can set this timeout value for a connection attempt? From what I gather, it's not possible to set this value on a per-socket basis, as some digging through the IP Sockets Application Programming Interface Guide and Reference has left me wanting. From the z/OS Communications Server: IP Configuration Reference, I find that I can set the CONNECTTIMEOUT parameter in the TCPCONFIG statement of our TCP/IP profile, but this value will then be enforced on every connection made through that IP stack. From what I gather, we don't set CONNECTTIMEOUT, and as such are subject to the 75 second default, which is definitely too long for what we're doing. We could set up an entirely different IP stack with a lower CONNECTTIMEOUT for just this application, but that seems a bit much. Especially if we can set the connection timeout on a per-socket basis instead. Another idea is to make the sockets that perform the connection attempts non-blocking. We would check the return code after the connection attempt, and if successful continue. If the connection is still pending, we'd issue a select with an appropriate timeout parameter. At this point this seems the most logical way to continue. But I know I might be missing something, otherwise I wouldn't be consulting the list. Any ideas, or comments about my assumptions are kindly appreciated. Regards, Jan -- 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: TCP/IP ezasoket call interface - connection timeout parameter.
Roberto, When the condition occurs what does a 'd tcpip,,n,sock' show ? It should show the status of you client, I have seen finwt2 a lot with our Java client talking to our STC rubbing ezasoket interface written in COBOL.. Scott IDMWORKS On Friday, October 14, 2016, Roberto Halais wrote: > Same here. Non-blocking. > > On Fri, Oct 14, 2016 at 11:44 AM, Ward, Mike S > wrote: > > > We always use non-blocking, it seems to perform better. We had the same > > issue's here that you experienced. That's why we went the non-blocking > way. > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU > ] On > > Behalf Of Cannaerts, Jan > > Sent: Friday, October 14, 2016 7:52 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: TCP/IP ezasoket call interface - connection timeout parameter. > > > > Hello list, > > > > > > We have a situation where we have a CICS transaction which exchanges > > information With another company over TCP/IP, using the ezasoket call > > interface. > > We are the client, while they are the server. > > > > Through experience we have learned that "because reasons", the server > does > > not always accept our connections, but our connection attempts are not > > being actively refused. Instead, the connection attempt waits until its > > timeout value is met and then returns with the appropriate error code. > For > > every pending connection that will never succeed, a transaction sits > there > > waiting for its timeout. Those queue up, we reach MaxTasks, and other > work > > gets disrupted. > > > > So the question is then; how and/or where we can set this timeout value > > for a connection attempt? From what I gather, it's not possible to set > this > > value on a per-socket basis, as some digging through the IP Sockets > > Application Programming Interface Guide and Reference has left me > wanting. > > From the z/OS Communications Server: IP Configuration Reference, I find > > that I can set the CONNECTTIMEOUT parameter in the TCPCONFIG statement of > > our TCP/IP profile, but this value will then be enforced on every > > connection made through that IP stack. > > From what I gather, we don't set CONNECTTIMEOUT, and as such are subject > > to the > > 75 second default, which is definitely too long for what we're doing. > > > > We could set up an entirely different IP stack with a lower > CONNECTTIMEOUT > > for just this application, but that seems a bit much. Especially if we > can > > set the connection timeout on a per-socket basis instead. > > > > Another idea is to make the sockets that perform the connection attempts > > non-blocking. We would check the return code after the connection > attempt, > > and if successful continue. If the connection is still pending, we'd > issue > > a select with an appropriate timeout parameter. At this point this seems > > the most logical way to continue. But I know I might be missing > something, > > otherwise I wouldn't be consulting the list. > > > > Any ideas, or comments about my assumptions are kindly appreciated. > > > > > > Regards, > > Jan > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > email > > to lists...@listserv.ua.edu with the message: INFO > IBM-MAIN > > > > == > > This email, and any files transmitted with it, is confidential and > > intended solely for the use of the individual or entity to which it is > > addressed. If you have received this email in error, please notify the > > system manager. This message contains confidential information and is > > intended only for the individual named. If you are not the named > addressee, > > you should not disseminate, distribute or copy this e-mail. Please notify > > the sender immediately by e-mail if you have received this message by > > mistake and delete this e-mail from your system. If you are not the > > intended recipient, you are notified that disclosing, copying, > distributing > > or taking any action in reliance on the contents of this information is > > strictly prohibited. > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: > INFO IBM-MAIN > > > > > > -- > “Live as if you were to die tomorrow. Learn as if you were to live > forever.” > – Mahatma Gandhi > > -- > 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: TCP/IP ezasoket call interface - connection timeout parameter.
Same here. Non-blocking. On Fri, Oct 14, 2016 at 11:44 AM, Ward, Mike S wrote: > We always use non-blocking, it seems to perform better. We had the same > issue's here that you experienced. That's why we went the non-blocking way. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Cannaerts, Jan > Sent: Friday, October 14, 2016 7:52 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: TCP/IP ezasoket call interface - connection timeout parameter. > > Hello list, > > > We have a situation where we have a CICS transaction which exchanges > information With another company over TCP/IP, using the ezasoket call > interface. > We are the client, while they are the server. > > Through experience we have learned that "because reasons", the server does > not always accept our connections, but our connection attempts are not > being actively refused. Instead, the connection attempt waits until its > timeout value is met and then returns with the appropriate error code. For > every pending connection that will never succeed, a transaction sits there > waiting for its timeout. Those queue up, we reach MaxTasks, and other work > gets disrupted. > > So the question is then; how and/or where we can set this timeout value > for a connection attempt? From what I gather, it's not possible to set this > value on a per-socket basis, as some digging through the IP Sockets > Application Programming Interface Guide and Reference has left me wanting. > From the z/OS Communications Server: IP Configuration Reference, I find > that I can set the CONNECTTIMEOUT parameter in the TCPCONFIG statement of > our TCP/IP profile, but this value will then be enforced on every > connection made through that IP stack. > From what I gather, we don't set CONNECTTIMEOUT, and as such are subject > to the > 75 second default, which is definitely too long for what we're doing. > > We could set up an entirely different IP stack with a lower CONNECTTIMEOUT > for just this application, but that seems a bit much. Especially if we can > set the connection timeout on a per-socket basis instead. > > Another idea is to make the sockets that perform the connection attempts > non-blocking. We would check the return code after the connection attempt, > and if successful continue. If the connection is still pending, we'd issue > a select with an appropriate timeout parameter. At this point this seems > the most logical way to continue. But I know I might be missing something, > otherwise I wouldn't be consulting the list. > > Any ideas, or comments about my assumptions are kindly appreciated. > > > Regards, > Jan > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > == > This email, and any files transmitted with it, is confidential and > intended solely for the use of the individual or entity to which it is > addressed. If you have received this email in error, please notify the > system manager. This message contains confidential information and is > intended only for the individual named. If you are not the named addressee, > you should not disseminate, distribute or copy this e-mail. Please notify > the sender immediately by e-mail if you have received this message by > mistake and delete this e-mail from your system. If you are not the > intended recipient, you are notified that disclosing, copying, distributing > or taking any action in reliance on the contents of this information is > strictly prohibited. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- “Live as if you were to die tomorrow. Learn as if you were to live forever.” – Mahatma Gandhi -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TCP/IP ezasoket call interface - connection timeout parameter.
We always use non-blocking, it seems to perform better. We had the same issue's here that you experienced. That's why we went the non-blocking way. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Cannaerts, Jan Sent: Friday, October 14, 2016 7:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: TCP/IP ezasoket call interface - connection timeout parameter. Hello list, We have a situation where we have a CICS transaction which exchanges information With another company over TCP/IP, using the ezasoket call interface. We are the client, while they are the server. Through experience we have learned that "because reasons", the server does not always accept our connections, but our connection attempts are not being actively refused. Instead, the connection attempt waits until its timeout value is met and then returns with the appropriate error code. For every pending connection that will never succeed, a transaction sits there waiting for its timeout. Those queue up, we reach MaxTasks, and other work gets disrupted. So the question is then; how and/or where we can set this timeout value for a connection attempt? From what I gather, it's not possible to set this value on a per-socket basis, as some digging through the IP Sockets Application Programming Interface Guide and Reference has left me wanting. From the z/OS Communications Server: IP Configuration Reference, I find that I can set the CONNECTTIMEOUT parameter in the TCPCONFIG statement of our TCP/IP profile, but this value will then be enforced on every connection made through that IP stack. >From what I gather, we don't set CONNECTTIMEOUT, and as such are subject to the 75 second default, which is definitely too long for what we're doing. We could set up an entirely different IP stack with a lower CONNECTTIMEOUT for just this application, but that seems a bit much. Especially if we can set the connection timeout on a per-socket basis instead. Another idea is to make the sockets that perform the connection attempts non-blocking. We would check the return code after the connection attempt, and if successful continue. If the connection is still pending, we'd issue a select with an appropriate timeout parameter. At this point this seems the most logical way to continue. But I know I might be missing something, otherwise I wouldn't be consulting the list. Any ideas, or comments about my assumptions are kindly appreciated. Regards, Jan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN == This email, and any files transmitted with it, is confidential and intended solely for the use of the individual or entity to which it is addressed. If you have received this email in error, please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this message by mistake and delete this e-mail from your system. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
TCP/IP ezasoket call interface - connection timeout parameter.
Hello list, We have a situation where we have a CICS transaction which exchanges information With another company over TCP/IP, using the ezasoket call interface. We are the client, while they are the server. Through experience we have learned that "because reasons", the server does not always accept our connections, but our connection attempts are not being actively refused. Instead, the connection attempt waits until its timeout value is met and then returns with the appropriate error code. For every pending connection that will never succeed, a transaction sits there waiting for its timeout. Those queue up, we reach MaxTasks, and other work gets disrupted. So the question is then; how and/or where we can set this timeout value for a connection attempt? From what I gather, it's not possible to set this value on a per-socket basis, as some digging through the IP Sockets Application Programming Interface Guide and Reference has left me wanting. From the z/OS Communications Server: IP Configuration Reference, I find that I can set the CONNECTTIMEOUT parameter in the TCPCONFIG statement of our TCP/IP profile, but this value will then be enforced on every connection made through that IP stack. >From what I gather, we don't set CONNECTTIMEOUT, and as such are subject to >the 75 second default, which is definitely too long for what we're doing. We could set up an entirely different IP stack with a lower CONNECTTIMEOUT for just this application, but that seems a bit much. Especially if we can set the connection timeout on a per-socket basis instead. Another idea is to make the sockets that perform the connection attempts non-blocking. We would check the return code after the connection attempt, and if successful continue. If the connection is still pending, we'd issue a select with an appropriate timeout parameter. At this point this seems the most logical way to continue. But I know I might be missing something, otherwise I wouldn't be consulting the list. Any ideas, or comments about my assumptions are kindly appreciated. Regards, Jan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
