Filter
Top Products
Intersystem communication program exits XISCONA and XISLCLQ
The two exits in the intersystem communication program allow you to control the
length of intersystem queues.
Note: There are several methods that you can use to control the length of
intersystem queues. For a description of the available methods, see the
CICS Intercommunication Guide
.
The XISCONA exit
Important
It is recommended that you use the XZIQUE exit, in the VTAM working-set
module, to control the length of intersystem queues, rather than XISCONA.
(XZIQUE is described on page 237.) XZIQUE provides more functions, and is
of more general use than XISCONA (it is driven for function shipping, DPL,
transaction routing, and distributed transaction processing requests, whereas
XISCONA is driven only for function shipping and DPL). If you enable both
exits, XZIQUE and XISCONA could both be driven for function shipping and
DPL requests, which is not recommended.
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
4
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.
4. “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.
intersystem communication program exits
Chapter 1. Global user exit programs 127
|
|
|
|
|
|
|
|
|
|
|
|