HTTP Persistent connection request limit in CICS

This RFE is satisfied by CICS TS 5.3 which is generally available from December 11th 2015.

The new SOTUNING SIT parameter specifies whether performance tuning for HTTP connections occur to protect CICS from unconstrained resource demand. If the SOTUNING SIT parameter is set to the default value of YES, if the region becomes overloaded CICS temporarily stops listening for new HTTP connection requests. If overloading continues, CICS closes existing HTTP persistent connections and marks all new HTTP connections as non-persistent. These actions prevent oversupply of new HTTP work from being received and queued within CICS, allowing feedback to TCP/IP port sharing and Sysplex Distributor, promoting a balanced sharing of workload with other regions that are sharing the same IP endpoint and allowing the CICS region to recover more quickly.If SOTUNING is set to YES, CICS periodically closes persistent connections to allow more efficient sharing of workload across regions that share IP endpoints, using technologies such as TCP/IP shared ports and Sysplex distributor.

This RFE is satisfied by CICS TS 5.3 which was announced on October 5th 2015 with a planned general availability date of December 11th 2015.
For more information see the announcement letter http://www.ibm.com/common/ssi/cgi-bin/ssialias?infotype=an&subtype=ca&supplier=897&letternum=ENUS215-363

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - Transaction Processing
Product - CICS Transaction Server

For recording keeping, the previous attributes were:
Brand - WebSphere
Product family - Transaction Processing
Product - CICS Transaction Server

This is something we would like to address. The RFE is being moved into 'Planned for Future release' status. Please note:
IBM’s statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM’s sole discretion. Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision. The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code or functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any future features or functionality described for our products remains at our sole discretion.

This is becoming a more serious problem when you are running a CICSPlex environment with 2 or more TOR's and using webservices with high transaction rates. If TOR 1 goes down all the connections go to TOR 2 and stay there even when TOR 1 is restarted leading to an unbalanced workload. So please implement this RFE asap.

This is becoming more of a requirement as more and more customers implement ip based access to CICS, especially web services. I believe that a request count is better than a timeout.

Not exactly. The TCPIPService idle timeout (SOCKETCLOSE) should close an open connection if the required number of requests do not arrive on that connection. Having a number of requests is better because during spikes of workload, a singe CICS region does not get the bulk of the requests but forces Sysplex Distributor to route across the Sysplex. Currently, we have a home grown solution for this which is to add a Connection: Close HTTP header after a defined count is reached for a connection and with this we have achieved near equal distribution of the workload across the Sysplex under normal CPU usage. When CPU saturation occurs of course some LPARs get more work than others but the workload balances much quicker with a "count' than "time".

In the description you mention "...limit the number of requests to be accepted on a persistent connection from a client.".  As the arrival rate of workloads will vary (sometime greatly) over time and for different web services end points, would having a maximum reuse based on a time limit rather than count limit be more predictable and meaningful ?

This is a candidate for inclusion in a future release.