Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

Statement syntax

&pagelevel(3)&pagelevel

This section explains the underlying concepts during the syntactic analysis of EDT statements.

Because the two types of input are handled differently, when ever input is received EDT must decide whether this is data input or an EDT statement (multiple EDT statements are also possible. In F mode, these are separated by semicolons (;),and in L mode by [LZE] characters provided that BLOCK mode has been activated).

In F mode, EDT makes this decision on the basis of the location of the input. EDT always interprets input in the statement line as an EDT statement and input in the data window as data input. It interprets input in the statement code column as statement codes. The same principle applies to the subroutine interface where EDT statements and data have to be entered in separate input areas provided for the purpose.

In contrast, in L mode all the input is made in a line. To make it possible to distinguish between data input and EDT statements in L mode, all EDT statements entered in L mode must start with the EDT statement symbol (default value: @).
In F mode and at the subroutine interface, the EDT statement symbol may be omitted since there is no danger of confusion with data input.

In L mode, the following special characteristics should also be noted.
If an entry starts with two EDT statement symbols (@@, where one or more blanks may be located before and after the first @), EDT interprets the input as data input and the second EDT statement symbol is considered to be the first character of the data input. EDT removes all the characters (first EDT statement symbol and all the blanks) which occur before the second EDT statement symbol. In L mode, it is therefore easy to write lines containing EDT statements in EDT procedures (if an input starts with a single EDT statement symbol then it is immediately executed as an EDT statement and is not written to a line). In L mode, therefore, data input is only interpreted as a statement if the first character which is not a blank is the EDT statement symbol and the first character that is not a blank following the EDT statement symbol is not the EDT statement symbol.

The above applies equally to user statement symbols. If input starts with two identical user statement symbols then this input is interpreted as data input and the second user statement symbol is considered to be the first character in the data input. In contrast, if the input starts with one user statement symbol or two different user statement symbols then everything after the first user statement symbol is interpreted and executed as a user statement (blanks are skipped).

Some EDT statements (e.g. @SET, format 6) possess the operand text (see section “Operand syntax”). This text operand which EDT handles as a separate input, may in turn take the form of either an EDT statement or a data input. EDT decides which interpretation is correct on the basis of the rules used in L mode.

If EDT identifies the input as an EDT statement then, in case the input consists of multiple EDT statements, it first isolates the first non-processed EDT statement in the input. In F mode, the semicolon is used as the separator and semicolons are not taken into account when literals are broken down. In L mode, the separator is the [LZE] character. The (separated) EDT statement is then copied to two internal buffers. One of the two buffers then contains the EDT statement as it was input while, in the other, it is converted into uppercase to simplify the recognition of the statement name and operands.

EDT then attempts to determine the statement name. If it is possible to identify the statement name and if it corresponds to an EDT statement with an indirect operand specification (see section “Indirect operand specification”) then the operands are now entered in the two internal buffers and in one of these, the input is again converted into uppercase.

A syntax check of the EDT statement is then performed.
During the analysis of EDT statements, EDT accesses the originally entered statement for those sections in which the distinction between uppercase and lowercase is relevant, e.g. literals.
Unicode substitute representations in EDT statements are only interpreted inside of literals (except in @DO and @PARAMS).
Furthermore, no tabulator expansion is performed in EDT statements. If there are no syntax errors, the EDT statement is now executed and the originally entered EDT statement is then written to the statement buffer (indirect operands are not resolved in this buffer).

An EDT statement begins with a statement name (e.g. @OPEN, @COPY, @WRITE) which may be followed by one or more operands. In the case of some EDT statements, a comment is permitted after the operands. One or more blanks are permitted (but not necessary) before the EDT statement symbol and between the EDT statement symbol and the statement name.

If an EDT statement possesses operands then these follow the statement name, possibly separated by one or more blanks. The operands must be entered in the predefined order. Any number of blanks may be entered before or after each operand. Some operands must always be specified whereas others are optional.

If optional operands are omitted then default values are assumed for these operands. The syntax description for each of the statements indicates which operands are optional and which are not and what the default values for omitted operands are.

The blanks between the statement name and the operands or between the individual operands themselves may be omitted. However, they must be entered if it would otherwise not be possible to distinguish between the statement name and the operand or between two successive operands.

Example

@SYMBOLS='?' is incorrect; the correct form is @SYMBOL S='?', since @SYMBOL is a legal abbreviation of the statement @SYMBOLS.

Users are generally not advised to omit the blanks between the statement name and the operands or between the individual operands since this may sometimes make statements very difficult to understand.

Alongside the direct entry of operands as described above, they can also be specified indirectly by means of string variables. This means that it is possible, for example, not to specify operands until runtime, thus permitting much greater flexibility, in particular in EDT procedures. This method of specifying operands is described in more detail in section “Indirect operand specification”.

In the case of some EDT statements, a comment is permitted after the operands if present. The syntax description of each statement indicates whether or not it may be accompanied by a comment.

Most EDT statements can be abbreviated. This is usually achieved by omitting one or more characters at the end of the statement name. In some cases, however, there are also abbreviations which do not result from the omission of characters. The @BLOCK statement, for example, can be abbreviated as @BK, the @QUOTE statement can be abbreviated as @QE and the @SETF statement in F mode can be reduced to the character #. In the @SEARCH-OPTIONS statement, it is also possible to omit certain characters in the middle of the statement name with the result, for example, that @SEA or @SEA-OPTIONS constitute valid abbreviations for these statements. The @SET statement, in which the statement name can be entirely omitted, is an exception here. However, if @SET (format 6) is used in F mode or at the subroutine interface then the statement symbol must be specified to remove ambiguity. The minimum portion of the statement name that must be present so that EDT can recognize the statement without ambiguity is indicated in bold print in the syntax diagrams.

Starting with the shortest possible abbreviation, EDT attempts to uniquely identify the statement name. If it is successful, any further characters in the statement name are skipped. This operation continues until EDT has processed the complete statement name or a character which does not correspond to the statement name is detected (this may also be a blank). The first character other than a blank that does not correspond to the statement name is interpreted as the first character of the operand section.

In the case of three pairs of statements (@DELETE/@DELIMIT, @PAR/@PARAMS and @UNSAVE/@UPDATE), the analysis of the statement name is not sufficient for a unique identification of the statement since the shortest possible abbreviations are identical (@D, @PAR and @U respectively). In these three cases, the first character of the operand section is used for differentiation. In the case of the @DELIMIT statement, for example, the operand section starts with the character =, whereas this character does not occur in the operand section of the @DELETE statement (in the case of the @PARAMS, statement & is the first character in the operand section and in the @UNSAVE statement, it is the character '. Neither of these characters occurs in the operand section of the other statement in the pair).

Example

Consider the input @DEL& (blanks between the statement name and the operand section can be omitted). The abbreviations @DIALOG, @DO and @DR (for @DROP) do not match. The only remaining abbreviation is @D which may stand for the statement @DELETE or for the statement @DELIMIT. However, the @DELIMIT statement can be excluded because the character = does not occur in the remainder of the statement. The statement name is therefore @DELETE. The characters E and L in the input are now skipped since they match the corresponding characters in the statement name. However, the character & does not match the corresponding character (E) in the statement name and is therefore the first (and in this case the only) character in the operand section.

The above description of the procedure employed when analyzing statements also makes it clear why error messages with no immediately obvious cause are sometimes output.
If no statement can be identified in the input, the message EDT3101 (illegal statement) is output (e.g. @XD). However, there are a large number of situations in which the message EDT3002 (operand error) is output even though the message EDT3101 would be expected. Let us assume that in the above example, @DDL& is accidentally entered instead of @DEL&. Exactly as in the above statement analysis, EDT would come to the conclusion that the intended statement is @DELETE (@DELIMIT is not possible because there is no =). However, the very next character after @D in the input differs from the corresponding character in the statement name @DELETE. Therefore, everything as of this character is considered to belong to the operand section (DL&). However, the string DL& cannot be interpreted as a permitted operand for any of the three formats of the @DELETE statement and the message EDT3002 is therefore output.

Notes

  • The delimiter characters for literals (by default, the characters ' and ") can be redefined using the @QUOTE statement. However, in the @DO and @PARAMS statements, the character ' is always used as the delimiter for literals irrespective of any redefinition performed using the @QUOTE statement.

  • In @DO procedures, statements are not analyzed until the procedure parameters have been substituted. Only then is any indirect operand specification resolved.

  • It is not permissible to include blanks in the keywords of statements or append comments at the end of statements (comments are only permitted at the end of a statement if this is explicitly indicated in the statement description).

  • The statement @SYNTAX TESTMODE=ON activates test mode. In this case, with only a few exceptions, EDT statements are not executed but simply subjected to a syntax check in L mode. This makes it possible, for example, to make sure that EDT procedures are suitable for execution before running them (for more detailed information, see the @SYNTAX statement, "@SYNTAX - Set test mode ").