One of the many types of terminal that CICS® supports is not really a terminal at all, but a pair of sequential devices or files simulating a terminal. One of the pair represents the input side of the terminal, and might be a card reader, a spool file or a SAM file on tape or DASD. The other represents the output, and might be a printer, a punch, spool or SAM file. Many device-type combinations are allowed, and either of the pair can be missing; that is, you can have an input-only or output-only sequential terminal.
You read from and write to the devices or files that constitute a sequential terminal with terminal control commands, specifically RECEIVE, SEND, and CONVERSE. (BMS supports sequential terminals too; see Special options for non-3270 terminals.)
The original purpose of sequential terminal support was to permit application developers to test online code before they had access to real terminals. This requirement rarely occurs any more, but sequential terminals are still useful for:
The input data submitted from a sequential terminal must be in the form in which it would come from a telecommunication device. For example, the first record usually starts with a transaction code, to tell CICS what transaction to execute. The transaction code must start in the first position of the input, just as it must on a real terminal. Note that this limits the ability to test applications that require input in complex formats. For example, there is no provision for expressing a formatted 3270 input stream as a sequential file, because of all the complex control sequences. However, you can use an unformatted 3270 data stream (or any other similar stream) for input, and you can still use BMS to format your output.
When you build the input file, you place an end-of-data indicator (EODI) character after each of your input records. The EODI character is defined in the system initialization table; the default value is a backslash (‘\’, X'E0'), but your installation may have defined some other value.
When processing the input stream,
CICS observes EODI characters only. CICS does not analyze the record structure
of the input file or device, which means that each input can span records
in the input file. However, you must start each input on a new physical record
to ensure each input is correctly processed.
The length of an input record (the number of characters between EODIs) should not exceed the size of the input buffer (the INAREAL value in the LINE component of the sequential terminal definition). If it does, the transaction that attempts to RECEIVE the long record abends, and CICS positions the input file after the next EODI before resuming input processing.
An end-of-file marker in the input also acts as an EODI indicator. Any RECEIVE command issued after end-of-file is detected also causes an abend.
If the definition of a sequential terminal indicates that the output half is a line printer, you can write multiple lines of output with a single SEND. For this type of device, CICS breaks your output message into lines after each new line character (X'15') or after the number of characters defined as the line length, whichever occurs first. Line length is defined by the LPLEN value in the terminal definition. Each SEND begins a new line.
CICS continues to initiate transactions from a sequential terminal until it (or the transactions themselves) have exhausted all the input or until the terminal goes out of service. To prevent CICS from attempting to read beyond the end of the input file (which causes a transaction abend), the last transaction executed can put the terminal out of service after its final output. Alternatively (and this is usually easier), the last input can be a CESF GOODNIGHT transaction, which signs the terminal off and puts it out of service. You cannot normally enter further input from a sequential terminal once CICS has processed its original input, without putting it out of service.
[[ Contents Previous Page | Next Page Index ]]