Receiving

You can choose whether to process data in small segments or all at once. Your choice depends upon various factors including:

The data is a standard inbound data stream, exactly as is sent to the simulated terminal from VTAM®. It is quite possible that there will be occasions on which you will receive no data; for example, when the back-end system needs to set a protocol indicator.

Command completion

FEPI RECEIVE can be specified, or defaulted, to end in one of the following ways:

RU
On the first to occur of:
CHAIN
On the first to occur of:
UNTILCDEB
On the first to occur of:
Note:
Using UNTILCDEB is not recommended, because you may have the difficult task of splitting data back into its constituent chains in order to process it.

In all cases, the ENDSTATUS option is set to indicate what the completion conditions were. Where several conditions occur together, ENDSTATUS shows the most significant one. The values of ENDSTATUS and their associated meanings are shown in Table 12.

Table 12. ENDSTATUS values and associated meanings for data stream
ENDSTATUS Command options End bracket Change direction End chain End RU INTO area full Next command expected
EB RU, CHAIN, UNTILCDEB Y - Y Y - Any
CD RU, CHAIN, UNTILCDEB - Y Y Y - FEPI SEND or CONVERSE
LIC RU, CHAIN, UNTILCDEB - - Y Y - FEPI RECEIVE
RU RU - - - Y - FEPI RECEIVE
MORE RU, CHAIN, UNTILCDEB - - - - Y FEPI RECEIVE
Note:
Y=Condition indicated.

FEPI RECEIVE commands must continue to be issued until ‘change direction’ or ‘end bracket’ is indicated. You cannot start sending data until all inbound data has been received. If an ENDSTATUS of MORE is indicated, the data stream is not necessarily self-contained and should not be processed until the remainder of the information is received. The value returned for REMFLENGTH may indicate how much more information is to come.

When ‘end bracket’ is received, the session is in contention state, and either end may try to transmit data next. Some back-end systems use ‘end bracket’ in the middle of a series of transmissions to allow the terminal to break in if it wants, and they may use ‘end bracket’ instead of ‘change direction’ at the end of the flow. This is particularly true of IMS™. CICS® usually sends ‘change direction’ eventually, although it may send ‘end bracket’ indicators intermediately.

Using your knowledge of the back-end application and system, you must check the data that you have already received, to find out whether more data is to be expected or the transmission is complete. If more data is expected, you should issue another FEPI RECEIVE command; if the transmission is complete, it is the front-end application’s turn to send data.

A problem arises where the application is the pass-through type, because it does not look at the received data. There are various ways of handling this:

  1. Request data conditionally from both ends-which cannot generally be done, and particularly not in the most typical case where the pass-through is directly to a front-end terminal.
  2. Wait for data from both ends at once. This can be done where the pass-through is directly to a front-end terminal and the transaction is pseudoconversational for both CICS and FEPI. See Started tasks.
  3. Ask each end at intervals if there is data waiting (for the back-end system by using FEPI RECEIVE with TIMEOUT); this is often not possible, as in the case where the pass-through is directly to a front-end terminal.
  4. Forego a strict pass-through technique and check the data.
  5. Assume that a transmission with ‘end bracket’ and no data means that more data is to come.
  6. Issue another FEPI RECEIVE with TIMEOUT in case more data is to come, which has the disadvantage of introducing a delay.
Note:
The last two cases involve an element of risk because the wrong assumptions can be made.

You should always use the TIMEOUT option on a FEPI RECEIVE command; see Time-outs.

[[ Contents Previous Page | Next Page Index ]]