The commands described in this chapter apply only to the principal facility of the task issuing them, where that facility is one of the following:
Terminal control commands fall into four groups:
The terminals and logical units covered in this chapter all operate in "half-duplex, flip-flop" mode. This means, essentially, that at any given moment, one partner in a conversation is in send mode (allowed to send data or control commands) and the other is in receive mode (restricted to receiving). This protocol is formally defined and enforced under VTAM. CICS® observes the same conventions for terminals attached under other access methods, but both the hardware and the access methods work differently, so that not all operations are identical.
When a terminal is the principal facility of a task, its conversation partner is the task. When it is not associated with a task, its conversation partner is the terminal control component of CICS. Between tasks, under VTAM, the conversation is left in a neutral state where either partner can send first. Ordinarily the terminal goes first, sending the unsolicited input that initiates a task (see How tasks are started).
This transmission also reverses the send/receive roles; thereafter the terminal is in receive mode and CICS, represented by the task that was attached, is in send mode. The task starts and remains in send mode, no matter how many SENDs it executes, until it explicitly changes the direction of the conversation. One way in which you can put the task in receive mode is by specifying the INVITE option on a SEND command. After SEND with INVITE, the task is in receive mode and must issue a RECEIVE before sending to the terminal again. You can also put the task in receive mode simply by issuing a RECEIVE, without a preceding INVITE; INVITE simply optimizes transmissions.
Note that the first RECEIVE command in a task initiated by unsolicited input does not count in terms of send/receive mode, because the input message involved has long since transmitted (it started the task). This RECEIVE just makes the message accessible to the task, and sets the related EIB fields.
ATI tasks--those initiated automatically by CICS--also start out in send mode, just like tasks started by unsolicited input.
Note that if a task is executing normally and performing non-terminal operations when a VTAM/network error occurs, the task is unaware of the error and continues processing until it attempts the next terminal control request. It is at this point that the task receives the TERMERR. If the task does not issue any further terminal control request, it will not receive the TERMERR or ABEND.
CICS satisfies requests for automatic task initiation (ATI) as soon as the terminal required as principal facility is available. When a task ends at a terminal, and CICS has an ATI request for that terminal, there may be contention between CICS, which wants to initiate the ATI task, and the terminal user, who wants to initiate a certain task by unsolicited input. In this situation, CICS always sets itself up as contention loser. That is, if the terminal sends unsolicited input quickly enough after the end of the previous transaction, CICS creates a task to process it and delay fulfilling the ATI request. This is intentional--it gives the user priority in contention situations.
However, you sometimes need to execute a sequence of particular tasks in succession at a terminal without allowing the user to intervene. CICS provides a way for you to do this, with the IMMEDIATE option on the RETURN command that ends the task. With RETURN IMMEDIATE, CICS initiates a task to execute the transaction named in the TRANSID option immediately, before honoring any other waiting requests for tasks at that terminal and without accepting input from the terminal. The old task can even pass data to the new one. The new task accesses this data with a RECEIVE, as if the user had initiated the task with unsolicited input, but no input/output occurs. This RECEIVE, like the first one in a task initiated by unsolicited input, has no effect on send/receive status; it just makes the passed data available to the new task. If the terminal is using bracket protocol (explained in Preventing interruptions (bracket protocol)), CICS does not end the bracket at the end of the first task, as it ordinarily does, but instead continues the bracket to include the following task. Consequently, the automatic opening of the keyboard at the end of bracket between tasks does not occur.
It is usually clear to users when they are supposed to "talk" (key and transmit), and when they are supposed to "listen" (wait for output), because the application makes this clear. On 3270 displays and many other terminals, the keyboard locks after the user has transmitted to reinforce this convention. It remains locked until the task unlocks it, which it usually does on a SEND before a RECEIVE, or on the last SEND in the task. This means the user has to do something particular (press the keyboard reset key) in order to break protocol.
What happens
if the user does this? For terminals connected under VTAM, violating this
protocol causes the task to abend (code ATCV) unless read-ahead queueing is
in force. Read-ahead queueing allows the logical unit and the task to send
and receive at any time; CICS saves input messages in temporary storage until
the task needs them. Inputs not read by task end are discarded. Read-ahead
queueing is applied at the transaction level (it is specified in the RAQ option
of the PROFILE under which the transaction runs). Read-ahead queueing
applies only to LU type 4 devices, and was originally provided for compatibility
reasons, to allow a transaction to support both BTAM-connected and VTAM-connected
terminals in the same way. As BTAM is no longer supported, read-ahead queueing
should no longer be used.
Sequential terminals differ from others in send/receive rules. Because the input is a pre-prepared file, CICS simply provides input messages whenever the task requests them, and it is impossible to break protocol. If the input is improperly prepared, or is not what the task is programmed to handle, it is possible for the task to get out of synchronization with its inputs, to exhaust them prematurely, or to fail to read some of them.
VTAM provides
a mechanism for a terminal in receive mode to tell its partner that
it would like to send. This is the "signal" data flow in VTAM, which
is detected on the next SEND, RECEIVE or ISSUE DISCONNECT command from the
task. When a
signal flow occurs, CICS raises the SIGNAL condition and sets EIBSIG in the
EIB. CICS default action for the SIGNAL condition is to ignore it. For the signal to have any effect, the task
must first detect the signal and then honor it by changing the direction of
the conversation.
On a 3270 display terminal and some others, the ATTENTION key is the one that generates the interrupt. Not all terminals have this feature, however, and in VTAM, the bind image must indicate support for it as well, or VTAM ignores the interrupts.
When a task issues a SEND command without specifying WAIT, CICS can defer transmission of the output to optimize either its overall terminal handling or the transmissions for your task. When it does this, CICS saves the output message and makes your task dispatchable, so that it can continue executing. The ISSUE COPY and ISSUE ERASE commands, which also transmit output, work similarly without WAIT.
If you use the WAIT option, CICS does not return control to your task until the output operation is complete. This wait lengthens the elapsed time of your task, with attendant effects on response time and memory occupancy, but it ensures that your task knows whether there has been an error on the SEND before continuing. You can avoid some of this wait and still check the completion of the operation if you have processing to do after your SEND. You issue the SEND without WAIT, continue processing, and then issue a WAIT TERMINAL command at the point where you need to know the results of your SEND.
When you issue a RECEIVE command that requires transmission of input, your task always waits, because the transmission must occur before the RECEIVE can be completed. However, there are cases where a RECEIVE does not correspond to terminal input/output. The first RECEIVE in a task initiated by unsolicited terminal input is the most frequent example of this, but there are others, as explained in the next section.
Also, when you issue any command involving your terminal, CICS ensures that the previous command is complete (this includes any deferred transmissions), before processing the new one.
[[ Contents Previous Page | Next Page Index ]]