Read position

At a read position, the content of an operand is only read, and not changed, when the statement is executed. Data objects can be specified as followed at read positions:

• Specification of a literal (text field literal, string literal, numeric literal).
  

• Specification of a data object visible at this point using a label dobj, a field symbol <fs> or a data reference dref->* dereferenced using the dereferencing operator ->* (as of release 6.10, and providing dref is typed). The names of data objects here include the specification of a text symbol using text-###, where ### is the three-character code of the text symbols, or concatenations of reference variables. If a field symbol or data reference is used, it cannot be initial.
  
  As an alternative to specifying a text symbol using text-###, you can append the three-character code of a text symbol to the literal in parentheses:
  
  ... 'Literal'(###) ...
  
  If the text symbol exists in the currently loaded text pool, the corresponding content of the text symbol is used in place of the literal. If it does not exist there, the literal is used.

• If the data object is an internal table, the expressions dobj[], <fs>[] and dref->*[] can also be used, which guarantees that the table body is addressed, and not any header line which may exist. If an internal table does not have a header line, its simple name (without []) is interpreted as the table body at all operand positions. However, if an internal table does have a header line, its simple name (without []) is interpreted as a header line, and not a table body, at almost all operand positions. The name of an internal table is only interpreted as a table body at operand positions at which an internal table is expected (in particular in the statements for processing internal tables), when data clusters are stored and read with EXPORT and IMPORT, for statements FREE and SEARCH, and all dynamic specifications of statement parts in Open SQL (except the specification of database tables).

• Specification of a subarea of a character-like or byte-like data object (or a character-like initial part of a structure) by specifying an offset/length.

Specification of a predefined function. Predefined functions can be used as source fields for statement MOVE, as operands in arithmetic expressions of statement COMPUTE, as operands in logical expressions, and as operands of statements CASE and WHEN. The result of the predefined function is used as the operand.

Before release 6.10, predefined functions could only be specified in statement COMPUTE.

• Specification of a functional method. Functional methods can be specified as operands at the same places as predefined functions and in bit expressions. The syntax for no, one, or several input parameters of the method is as follows:
  
  meth( )
  meth( a )
  meth( p1 = a1 p2 = a2 ... )
  
  Here, meth is the label of a method and can be specified as for CALL METHOD. The return value of the functional method is used as the operand. The syntax corresponds to the short forms of statement CALL METHOD. If a functional method has the same name as a predefined function, the functional method is always called with expression meth( a ).

Notes

• Text symbols must not be listed at all read positions. For example, they are not permitted for specifying the target of dynamic executions.

• A system field should only be specified as an operand at a read position if its content is not set by the same statement, as otherwise undefined behavior may occur.