Filter
Top Products
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.
v 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.
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.
The sample XISCONA global user exit program, DFHXIS
Note that there is a CICS-supplied sample exit program, DFHXIS, that shows one
way of limiting the queue of ALLOCATE requests, based on the information passed
to the program. For more information about the sample global user exit programs,
see “Sample global user exit programs” on page 14.
Exit XISCONA
When invoked
When a function shipping or DPL request is about to be queued because all
bound contention winner sessions to the remote region are in use.
Note: For DPL requests that are routed dynamically, the dynamic routing
program is invoked before XISCONA. If there are no free sessions
the routing program may choose not to queue a DPL request; in
these circumstances, XISCONA is not invoked. For information about
the dynamic routing of DPL requests, see the
CICS
Intercommunication Guide
.
intersystem communication program exits
128
CICS TS for OS/390: CICS Customization Guide
|
|
|
|
|
|
|
|