XZIQUE exit for managing MRO and APPC intersystem queues
You can use the XZIQUE exit to control the number of queued requests for sessions on MRO and APPC connections.
- Queued requests for sessions are known as allocate queues.
- The equivalent global user exit to control the number of queued requests for sessions on IP interconnectivity connections is XISQUE. See XISQUE exit for managing IPIC intersystem queues.
- There are several methods that you can use to control the length of intersystem queues. For a description of the various methods, see Intersystem session queue management.
The XZIQUE exit enables you detect queuing problems (bottlenecks) early. It extends the function provided by the XISCONA global user exit, that is described in Intersystem communication program exits, XISCONA, XISLCLQ, and XISQLCL, which is invoked only for function shipping and DPL requests. XZIQUE is invoked for transaction routing, asynchronous processing, and distributed transaction processing requests, as well as for function shipping and DPL. Compared with XISCONA, it receives more detailed information on which to base its decisions.
XZIQUE enables allocate requests to be queued or rejected, depending on the length of the queue. It also allows a connection on which there is a bottleneck to be terminated and then re-established.
No interaction with the XISCONA exit
There is no interaction between the XZIQUE and XISCONA global user exits. If you enable both exits, XISCONA and XZIQUE could both be invoked for function shipping and DPL requests, although this is not recommended. Therefore, you should ensure that only one of these exits is enabled. Because of it provides more function and greater flexibility, it is recommended that you use XZIQUE rather than XISCONA.
If you already have an XISCONA global user exit program, you could possibly modify it for use at the XZIQUE exit point.
When the XZIQUE exit is invoked
- Whenever CICS®
tries to acquire a session with a remote system and there is no free session available. It is
invoked whether or not you have specified the QUEUELIMIT option on the CONNECTION definition, and
whether or not the limit has been exceeded. It is not invoked if the allocate request specifies
NOQUEUE or NOSUSPEND.
Requests for sessions can arise in a number of ways, such as explicit EXEC CICS ALLOCATE commands issued by DTP programs, or by transaction routing or function shipping requests.
- Whenever an allocate request succeeds in finding a free session, after the queue on the connection has been purged by a previous invocation of the exit program. In this case, your exit program can indicate that CICS is to continue processing normally, resuming queuing when necessary.
What statistics your XZIQUE program can use to control queues
There are some statistics fields that your XZIQUE global user exit program can use to control queues.
- Field A14EALRJ
-
Each time an XZIQUE global user exit program returns with a request to reject a request, CICS increments field A14EALRJ in the system entry connection statistics.
Field A14EALRJ (allocate rejected) is in DSECT DFHA14DS and is provided to help you to tune the queue limit. Normally, if the number of sessions and the queue limit defined for a link are correctly balanced, and there has been no abnormal congestion on the link, the A14EALRJ should be zero. If the rejected allocates field is non-zero it probably indicates that some action is needed.
- Fields A14EQPCT and A20EQPCT
-
Each time an XZIQUE global user exit program returns with a request to purge a queue, CICS increments a new field in either the system entry connection statistics (field A14EQPCT) or mode entry connection statistics (field A20EQPCT).
- A14EQPCT indicates the count of the number of times the queue has been purged for the connection as a whole.
- A20EQPCT indicates the count of the number of times the mode group queue has been purged.
For detailed information about statistics fields, what they contain and how they are updated, see ISC/IRC system entry: Resource statistics.