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
> 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 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 with the message: INFO IBM-MAIN

“Live as if you were to die tomorrow. Learn as if you were to live
– Mahatma Gandhi

For IBM-MAIN subscribe / signoff / archive access instructions,
send email to with the message: INFO IBM-MAIN

Reply via email to