The XISCONA exit
The purpose of XISCONA is to help you prevent the performance problems that can occur when function shipping or DPL requests awaiting free sessions for a non-IPIC connection are queued in the issuing region. The exit permits you to control the number of outstanding ALLOCATE requests by allowing you to reject any function shipping or DPL request that would otherwise be queued.
If you already have an XISCONA exit program, you may be able to modify it for use at the XZIQUE exit point.
“Contention winner” is the terminology used for LU6.2 connections. The XISCONA exit applies also to MRO and LU6.1 connections: in these, the SEND sessions (defined in the session definitions) are used first for ALLOCATE requests; when all SEND sessions are in use, queuing starts.
Function shipping and DPL requests for a resource-owning region are queued by default if all bound contention winner sessions are busy, so that no sessions are immediately available. If the resource-owning region is unresponsive (for example, if it is a file-owning region, it may be waiting for a system journal to be archived), the queue can become so long that the performance of the issuing region is severely impaired. Further, if the issuing region is an application-owning region, its impaired performance can spread back to the terminal-owning region.
- If the XISCONA exit program is not active, CICS queues the request when necessary.
- If the exit program is active, it is invoked only if all bound contention winner sessions are in use. For other failures (for example, ‘Mode name not found' or ‘Out of service'), CICS bypasses the exit and returns to the application.
- If it is invoked, your exit program must decide whether or not
to queue the request by analyzing the statistics provided through
the user exit parameter list. Your exit program could:
- Stipulate that queuing is never to be used. This is the simplest
way to code the exit, and avoids complexities of tuning. It should
be effective if you define enough contention winner sessions to handle
the peak transaction load for the connection. If you suppress all
queuing, you must specify AUTOCONNECT(YES) on the SESSIONS definition,
because the queuing mechanism no longer binds sessions for you.
With this approach, a danger arises if you base your estimate of required sessions on average conditions and the transaction load subsequently varies widely; when CICS cannot use queuing to cope with the variation, users may suffer transaction abends when there is no significant problem in the resource-owning region.
- Examine the number of requests currently in the queue. The program
could, for example, stop queuing when the number exceeds 120% of the
maximum number of sessions. You could use this approach to cope with
intermittent stoppages in the resource-owning region.
You could use a table of thresholds for the connections in your system, with values determined from previous experience of queuing problems. Alternatively, you could use the EXEC CICS interface in a separate program to inquire about the state of the connection, and pass the information in a work area to the XISCONA exit program.
- Examine the type of request and the resource being accessed (which can be discovered by examining the request parameter list). The program could, for example, reject file read requests but queue file updates.
Note: Because a failure of the exit program could affect system availability, it is recommended that you make the logic of your program as simple as possible, thus reducing the possibility of errors. - Stipulate that queuing is never to be used. This is the simplest
way to code the exit, and avoids complexities of tuning. It should
be effective if you define enough contention winner sessions to handle
the peak transaction load for the connection. If you suppress all
queuing, you must specify AUTOCONNECT(YES) on the SESSIONS definition,
because the queuing mechanism no longer binds sessions for you.
There are some problems that XISCONA cannot solve. For example, if you have specified both a large number of sessions and a large value for MXT, CICS may develop the short-on-storage (SOS) condition before XISCONA is invoked because there are no further sessions available.