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 
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 
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 
successful continue. If the connection is still pending, we'd issue a select 
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.


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

Reply via email to