Filter
Top Products
permanently locked.
TCAM queues
Because a queue is a sequential data set, the second message on the queue
cannot be retrieved until the first message has been processed. To keep messages
flowing smoothly through the queue, it is essential that each message be processed
as soon as it arrives. In the CICS-TCAM interface, “processing the message”
means detaching the message from the special input TCTTE and attaching it to the
individual TCTTE correlated to the actual physical terminal or logical unit. Each
individual TCTTE may be considered to be a “destination” for the purpose of this
discussion.
If a particular destination (TCTTE) is not ready to accept the current message on
the queue, the queue locks until the destination can accept the message. Queue
locks are only a problem when a queue is serving more than one destination. In this
case, if a queue locks, any new transaction on the queue, or messages queued for
existing tasks, are not processed until the required destination has accepted the
current message.
Because queue locks can adversely affect system performance, it is important that
you understand their cause and effect, as described below. Proper configuration of
the TCAM process queue and CICS terminal control tables reduces the occurrence
and duration of queue locks to a minimum.
The maximum number of terminals that can be attached to one queue is governed
by the amount of activity expected, and by the response time required from the
system. For high activity and low response times, you should not exceed 25
terminals. Note that only a real performance test can verify whether this figure is
acceptable.
Because TCAM can read ahead from the terminals, it is possible for TCAM to
present to CICS a new transaction message destined for a TCTTE that is already
processing a task. Also, TCAM can present a message for an existing task before
that task issues a READ request. In either case, CICS cannot process the message
(as described above) until the TCTTE is ready to accept the new TIOA. Such input
is called “unsolicited input”.
These conditions can produce unsolicited input:
1. The CICS TCTTE for which the data is destined is out of service.
2. The CICS TCTTE for which the data is destined is in RECEIVE status.
3. The CICS TCTTE for which the data is destined has an associated task that
has not issued a READ, and for which the period of time indicated by the
NPDELAY specification has expired.
4. A terminal in a pool has entered data and is unable to find an available TCTTE.
In all cases, the action taken by the CICS-TCAM interface is to place the input line
out of service, and attach DFHTACP to process the error condition.
The default action taken by DFHTACP (which can be altered by a user-written
DFHTEP) for conditions 1 and 2 is to discard the data and place the input line in
service. No default action is taken by DFHTACP for condition 3 or 4; therefore, the
input line is placed in service, but with the same message still to be processed,
thereby preventing CICS from reading any subsequent messages from the input
queue.
the CICS-TCAM interface
Chapter 26. Using TCAM with CICS 703