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
