Thank you Mike, Roberto, and David for the unanimous advice.
I guess we will have to re-implement!

Kind regards,

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

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

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

Reply via email to