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

Reply via email to