Same here. Non-blocking. On Fri, Oct 14, 2016 at 11:44 AM, Ward, Mike S <mw...@ssfcu.org> 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 > To: IBM-MAIN@LISTSERV.UA.EDU > 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 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 > -- “Live as if you were to die tomorrow. Learn as if you were to live forever.” – Mahatma Gandhi ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
