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:[email protected]] On Behalf Of Cannaerts, Jan Sent: Friday, October 14, 2016 7:52 AM To: [email protected] 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 [email protected] 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 [email protected] with the message: INFO IBM-MAIN
