ACCEPT

Receive a character from a specified channel

WSupported on Windows
USupported on Unix
VSupported on OpenVMS
NSupported in Synergy .NET
ACCEPT(channel, variable[, label][, WAIT:wait_spec]) [[error_list]]

channel

The open channel from which to obtain the character. (n)

variable

The variable that will contain the received character. (a or n)

label

(optional) The label to which to transfer control if variable is an alpha variable and an end-of-file character is received.

WAIT

(optional) Specifies how long to wait for terminal input. See WAIT for more information.

error_list

(optional) An I/O error list. If any one of the specified errors occurs as part of the ACCEPT, control is transferred to the associated label.

The ACCEPT statement receives the next sequential character from the specified channel and loads it, or its numeric value, into variable.

If variable is alpha, the input character is loaded into the first byte of variable, leaving the remaining positions unchanged. If an end-of-file character is encountered and label is specified, control immediately transfers to label. If an end-of-file character is encountered and label is not specified, an “End of file” error ($ERR_EOF) is generated.

If variable is numeric, the input character’s corresponding value is loaded. Appendix B: ASCII Character Set lists all the ASCII characters and their corresponding integer codes. If an end-of-file character is encountered, the optional label specification does not apply; instead, the integer value is loaded (for example, 004 for Ctrl+D on Unix).

The ACCEPT statement is often used to get a character from a terminal device. To accommodate all operating systems on which Synergy DBL runs, a carriage return character and a line feed character are both generated when you press Enter. Your program must account for both the carriage return and the additional line feed.

On Unix, ACCEPT maps a line feed character to a carriage return and line feed when input is redirected. Most input files on Unix are composed of lines containing characters followed by a line feed. To properly handle this lack of a carriage return, one is added when ACCEPT encounters a line feed.

In Synergy .NET, the ACCEPT statement is for console applications only and is not intended to be used in low-level windowing applications (i.e., those that use the Synergy windowing API). WD_ACCEPT should be used instead of ACCEPT in this scenario.

For Windows non-interactive and .NET runtimes, ACCEPT does not honor the WAIT qualifier and will wait forever for a terminating condition. (However, WAIT does work when running a .NET application on Linux.)

On Windows, because the F10 key is a reserved key that activates the system menu, it will not be returned to your application when using ACCEPT (although it will be returned in a UI Toolkit application).

If you have a telnet terminal connection, see $ERR_IOFAIL for more information.

Tip

Because ACCEPT is a character-level input operation, no special handling of record terminators occurs (as normally occurs in record-oriented operations such as READS); therefore, your program must handle such characters. Thus, it is more efficient to use GETS with the MASK qualifier and wait for serial I/O. For more information about serial ports on Unix, see INITPORT.

The examples below use the following data division.

.define TTCHN           ,1
record
    afld        ,a5
    dfld1       ,d1
    dfld2       ,d5

The following example receives the next character from the terminal. If the character is an end-of-file marker, the program terminates with an “End of file” error ($ERR_EOF).

accept(TTCHN, afld)

The following example also receives the next character from the terminal. If the character is an end-of-file marker, control transfers to the statement labeled done.

accept(TTCHN, afld, done)

The following example is functionally identical to the previous example, but it uses the I/O error list construct.

accept(TTCHN, afld) [eof=done]

The following example receives the next character from the terminal and load the corresponding value of that character into dfld2. The end label is ignored because dfld2 is a numeric variable. If the received character is an end-of-file marker, no special error handling occurs.

accept(TTCHN, dfld2, end)

In the following example, dfld1 is only one character long; therefore, only the low-order digit of the ASCII character integer code is loaded into dfld1.

accept(TTCHN, dfld1)