Filter
Top Products
If you already have an XISCONA exit program, you may be able to modify it for use
at the XZIQUE exit point.
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
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.
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.
To control the queuing of function shipping and DPL requests, use the XISCONA
exit to tell CICS, whenever a session cannot be allocated immediately, whether to
queue the request, or to return ‘SYSIDERR’ to the application. The exit works like
this:
1. If the XISCONA exit program is not active, CICS queues the request when
necessary.
2. 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.
3. 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:
v 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.
v 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.
1. “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.
Chapter 1. Global user exit programs
139