Open topic with navigation
WTSupported in traditional Synergy on Windows
WNSupported in Synergy .NET on Windows
USupported on UNIX
VSupported on OpenVMS
ACCEPT(channel, variable[, label][, WAIT:wait_spec]) [[error_list]]
The open channel from which to obtain the character. (n)
The variable that will contain the received character. (a or n)
(optional) The label to which to transfer control if variable is an alpha variable and an end‑of‑file character is received.
(optional) Specifies how long to wait for terminal input. See WAIT for more information.
(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.
In Synergy .NET, the ACCEPT statement is for console applications only. ACCEPT won’t accept characters from a low‑level windowing application (i.e., one that uses the Synergy windowing API), so use WD_ACCEPT for all characters in this scenario.
For Windows service runtimes and all .NET runtimes, ACCEPT does not honor the WAIT qualifier and will wait forever for a terminating condition.
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 (see GETS for more information). 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
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).
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.