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