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.


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

Reply via email to