Using data transmission commands

There are three commands that transmit data to and from the terminal or logical unit that is the principal facility of your task:

RECEIVE
reads data from the terminal.
SEND
writes data to the terminal.
CONVERSE
writes data to the terminal, waits for input, and reads the input.

CONVERSE is essentially a combination of SEND and RECEIVE and is usually the equivalent of SEND followed by RECEIVE. In certain cases you must use CONVERSE instead of SEND and RECEIVE, for example, sending structured-field data to certain 3270 devices. In other cases you must use SEND and RECEIVE, because CONVERSE is not provided; these are noted in Table 24.

The SEND, RECEIVE, and CONVERSE commands are fully described in the CICS® Application Programming Reference manual. They are broken down by device group, because the options for different devices and access methods vary considerably. Terminal device support tells you which device group to use for your particular device.

What you get on a RECEIVE

We use the terms "input message" and "transmission" to mean both what the terminal sent and what the application received. For the most common types of terminals, these are equivalent. A 3270 display, for example, sends whatever was changed in its buffer as a single entity, and the task associated with the terminal normally gets the entire message in response to a single RECEIVE command.

However, input messages and physical transmissions are not always equivalent, and there are several factors that can affect the one-to-one relationship of either to RECEIVE commands. These are:

Input chaining

Some SNA devices break up long input messages into multiple physical transmissions, a process called "chaining". CICS assembles the component transmissions into a single input message or present them individually, depending on how the terminal associated with the task has been defined. This affects how many RECEIVEs you need to read a chained input message. Details on inbound chaining are explained in Chaining input data.

Logical messages

Just as some devices break long inputs into multiple transmissions, others block short inputs and send them in a single transmission. Here again, CICS provides an option about who deblocks, CICS or the receiving program. This choice also affects how much data you get on a single RECEIVE. (See Handling logical records for more on this subject.)

NOTRUNCATE option

Still another exception to the one-input-message-per-RECEIVE rule occurs when the length of the input data is greater than the program expects. If this occurs and the RECEIVE command specifies NOTRUNCATE, CICS saves the excess data and uses it to satisfy subsequent RECEIVE commands from the program with no corresponding read to the terminal. If you are using NOTRUNCATE, you should issue RECEIVEs until the field EIBCOMPL in the EIB is set on (that is, set to X'FF'). CICS turns on EIBCOMPL when no more of the input message is available.

Without NOTRUNCATE, CICS discards the excess data, turns on EIBCOMPL, and raises the LENGERR condition. It reports the true length of the data, before truncation, in the data area named in the LENGTH option, if you provide one.

Print key

If your CICS system has a PA key defined as a "print" key, another exception to the normal send/receive sequence can occur. If the task issues a RECEIVE, and the user presses the "print" key in response, CICS intercepts this input, does the necessary processing to fulfil the request, and puts the terminal in receive mode again. The user must send another input to satisfy the original RECEIVE. (See CICS print key for more information about the "print" key.)

[[ Contents Previous Page | Next Page Index ]]