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 <roberto.hal...@gmail.com>
wrote:

> Same here. Non-blocking.
>
> On Fri, Oct 14, 2016 at 11:44 AM, Ward, Mike S <mw...@ssfcu.org
> <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:IBM-MAIN@LISTSERV.UA.EDU
> <javascript:;>] On
> > Behalf Of Cannaerts, Jan
> > Sent: Friday, October 14, 2016 7:52 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU <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 lists...@listserv.ua.edu <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 lists...@listserv.ua.edu <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 lists...@listserv.ua.edu <javascript:;> 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