Intersystem session queue management
This section describes how to control the number of queued requests for sessions on intersystem links (allocate queues).
Overview of session queue management
In a perfect intercommunication environment, queues would never occur because work flow would be evenly distributed over time, and there would be enough intersystem sessions available to handle the maximum number of requests arriving at any one time.
However, in the real world this is not the case, and, with peaks and troughs in the workload, queues do occur: queues come and go in response to the workload. The situation to avoid is an unacceptably high level of queuing that causes a bottleneck in the work flow between interconnected CICS® regions, and which leads to performance problems for the terminal end-user as throughput slows down or stops. This abnormal and unexpected queuing should be prevented, or dealt with when it occurs: a “normal” or optimized level of queuing can be tolerated.
For example, function shipping requests between CICS application-owning regions and connected file-owning regions can be queued in the issuing region while waiting for free sessions. Provided a file-owning region deals with requests in a responsive manner, and outstanding requests are removed from the queue at an acceptable rate, then all is well. But if a file-owning region is unresponsive, the queue can become so long and occupy so much storage that the performance of connected application-owning regions is severely impaired. Further, the impaired performance of the application-owning region can spread to other regions. This condition is sometimes referred to as “sympathy sickness”, although it should more properly be described as intersystem queuing, which, if not controlled, can lead to performance degradation across more than one region.
How to manage allocate queues
- You can specify the QUEUELIMIT and MAXQTIME options on the CONNECTION and IPCONN resource definitions for intersystem links that have simple control requirements; for example, links that carry noncritical traffic. The QUEUELIMIT option defines the maximum number of allocate requests that CICS is to queue, while the MAXQTIME option defines the approximate time for which allocate requests will queue for free sessions on a connection that is unresponsive. For details, see Using resource definitions to manage allocate queues.
- A further method of controlling explicit allocate requests is to specify the NOQUEUE|NOSUSPEND option of the EXEC CICS ALLOCATE command. However, while this enables you to control specific requests, it takes no account of the state of the queue at the time the requests are issued. And it is of no use in controlling implicit allocate requests (where the session request is instigated by, for example, a function shipping request). For programming information about API options, see ALLOCATE (APPC).
- You can control the queuing of allocate requests through a global user exit program, which provides more flexibility than setting a queue limit on the connection. Use XISQUE to manage IPIC queues and XZIQUE to manage MRO and APPC queues. For details, see Using the XISQUE and XZIQUE global user exits to manage allocate queues.