Roberto, When the condition occurs what does a 'd tcpip,,n,sock' show ? It should show the status of you client, I have seen finwt2 a lot with our Java client talking to our STC rubbing ezasoket interface written in COBOL..
Scott IDMWORKS On Friday, October 14, 2016, Roberto Halais <[email protected]> wrote: > Same here. Non-blocking. > > On Fri, Oct 14, 2016 at 11:44 AM, Ward, Mike S <[email protected] > <javascript:;>> 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:[email protected] > <javascript:;>] On > > Behalf Of Cannaerts, Jan > > Sent: Friday, October 14, 2016 7:52 AM > > To: [email protected] <javascript:;> > > 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] <javascript:;> 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] <javascript:;> 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 [email protected] <javascript:;> with the message: > INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
