My setup is as follows: Java clients, using Java sockets, dial to a CICS 5.2 Application (the program addressed is written in COBOL). The Java clients are careless: If they have a job for CICS, they will send a transaction request.
The problem is that when too many of them send a request, the CICS hardware can't process it fast enough.
What happens is that the CICS Sockets listener doesn't care about how overloaded CICS is in general. So, it tries to create concurrent servers for all incoming transaction requests. However, there is no room for the new concurrent servers (see added info in * below) because CICS is busy with what it already has. So, these tries hang in there for a while and then report a GIVESOCKET TIMEOUT.
Using Micro Focus Enterprise Server 2.2 on Windows 7.
How do professional implementations handle this? I know my hardware to be fast enough, it's just that it has no nice way of handling a queue.
I was thinking maybe a semaphore, to indicate to the clients not to send a request to the listener if there's a queue already? Maybe allow a super-large timeout for GIVESOKET?
BTW, are concurrent servers handled fairly in CICS 5.2? I mean, the first concurrent server to be denied processing and put in a queue is the first to execute when there's room?
Thanks.
- Micro Focus ES has these things called SEPs. They are like cores. You define, for example, 10 SEPs per CICS application and every program running in parallel on that application holds a SEP until it is done. If you have 10 SEPs and 10 running programs, the 11'th program will stand in a queue until a SEP becomes free. CICS TCP/IP concurrent servers need their own SEP for each one. So, by "no room", I mean that all SEPs are loaded with instances of concurrent servers and new concurrent servers cannot be created by the EZASOKET listener (CSKL) and produce a GIVESOKET timeout (which is the first call the listener does on a newly made concurrent server but because there isn't such - it times out)
