SCAN

Note

This statement is for internal use only.
It cannot be used in application programs.

Variants:

1. SCAN ABAP-SOURCE itab1 ...TOKENS INTO itab2
                       ...STATEMENTS INTO itab3.

2. SCAN AND CHECK ABAP-SOURCE itab1 ...RESULT INTO itab2.

Variant 1

SCAN ABAP-SOURCE itab1 ...TOKENS INTO itab2
                       ...STATEMENTS INTO itab3.


Parts marked with " ..." are interchangeable

Extras:

1. ... FROM n1

2. ... TO   n2

3. ... KEYWORDS   FROM itab4

4. ... LEVELS     INTO itab5

5. ... STRUCTURES INTO itab6

6. ... OVERFLOW INTO c1

7. ... WITH ANALYSIS

8. ... WITH COMMENTS

9. ... WITH INCLUDES [IMPLEMENTATIONS FROM itab]

10. ... WITH TYPE-POOLS

11. ... WITH LIST TOKENIZATION

12. ... PRESERVING IDENTIFIER ESCAPING

13. ... WITHOUT TRMAC

14. ... [INCLUDE] PROGRAM FROM c2

15. ... INCLUDE INTO c3

16. ... MESSAGE INTO c4

17. ... WORD    INTO c5

18. ... LINE    INTO n3

19. ... OFFSET  INTO n4

20. ... WITH EXPLICIT ENHANCEMENTS [IMPLEMENTATIONS FROM itab]

21. ... FRAME PROGRAM FROM c2

22. ... ENHANCEMENTS INTO itab

Effect

Breaks down the ABAP source code in the source code table itab1 into tokens according to the rules of the ABAP scanner. The tokens are written - one per line - to the token table itab2. The source code to be broken down need not necessarily be contained in an internal table. It can be specified in any character-like field. In particular, you can use fields of the type STRING. However, this variant only makes sense if the program to be broken down does not contain any comments.

The token table itab2 must have the structure STOKES. If you specify the addition WITH ANALYSIS, the token table must have the extended structure STOKESX.
(For reasons of downward compatibility, STOKEN and STOKEX can still be used. The main difference is that in the new structures the character string which makes up the token is typed with reference to the data type STRING. With the structures STOKEN and STOKEX, a C field of length 30 and an OVERFLOW area are used instead.

Normally, comments are filtered out and subordinate source code units (included programs, called Macros) are ignored. If you want to include these items, use the additions WITH COMMENTS and WITH ANALYSIS.

In addition to classifying the source code by token, the scanner organizes the tokens themselves into statements - using the colon-comma logic to form chain records - and the statement table itab3 contains a statement description on each line. Here, a three-part chained statement "a: b, c1 c2, d." results in three entries "a b,", "a c1 c2," and "a d." in the statement table itab3.

The statement table itab3 must have the structure SSTMNT.

The statement classification characters colon, comma and period are not written to the token table itab2. Instead, the table itab3 contains details about the position of a colon or the type (comma or period) and position of the end marker in the statement description.

Return Value

SY-SUBRC = 0:
Source code table is not empty, contains no errors and is broken down into tokens.
SY-SUBRC = 1:
Source code table is not empty and is broken down into tokens, but at least one include program does not exist (can occur only in connection with the addition WITH INCLUDES).
SY-SUBRC = 2:
Source code table itab1 is empty or a blank line range was selected (applies to the additions FROM and TO).
SY-SUBRC = 4:
Scanner detects error in source code.
SY-SUBRC = 8:
Other error or RABAX in scanner.

The fields of the structure STOKES, and thus the columns of the token table itab2, have the following meaning:

TYPE
Type of token with possible values:

I (Identifier)
S (String, i.e. character literal)
L (List, enclosed in parentheses)
C (Comment)
B (Beginning of a list)
D (Separator between list elements)
E (End of a list)

Types B,D, and E can only appear if the WITH LIST TOKENIZATION addition is specified.
ROW
Number of line where token occurs or where it begins (>= 1)
COL
Offset of first character of token relative to start of line (>= 0)
STR
Character string forming the token. If you specify the

If you specify the structure STOKEN, 3 more fields are filled and you must consider the following:

STR
The character string forming the token contains only the first part if the character string is longer than 30.
LEN
Length of token
OVFL
Overflow flag for field STR with the following possible values:

SPACE (no overflow, token fits completely in field STR)
X (overflow, either not resolved (no overflow area specified) or token fits in overflow area c1))
O (overflow of token and overflow of overflow area c1)
OFF1
Offset in overflow area, if

token does not fit completely in field STR and
an overflow area c1 is specified and
token fits completely in overflow area c1.

The fields of structures SSTMNT, and thus the columns of the statement table itab3, have the following meaning:

TYPE
Type of statement with the following possible values:

E ( Native SQL statement between EXEC SQL and ENDEXEC)
I (INCLUDE prog)
J (INCLUDE prog, prog does not exist, can occur only in connection with the addition WITH INCLUDES)
T (TYPE-POOLS pool)
V (TYPE-POOLS pool, pool does not exist)
R (Call a macro from table TRMAC)
D (Call a macro internally defined with DEFINE)
M (Macro definition between DEFINE and END-OF-DEFINITION)
C (COMPUTE statement, sometimes without COMPUTE as first token)
A (Method call in short form)
K (Other ABAP/4 key word)
N (Blank statement)
P (Comment between statements)
S (Comment within statements)
U (Unknown, non-blank statement)
LEVEL
Index of source code unit in the level table itab5 (>= 1, if level table specified, otherwise 0).

STRUC
Index of the statement in the structure table itab6 (0 if the structure table is not specified or the structure in which the statement occurs could not be constructed).
FROM
Index of first token of statement in the token table itab2 (FROM = TO + 1, if the statement consists only of the end marker - comma or period)
TO
Index of last token of statement in the token table itab2 (the end marker of the statement no longer counts as a token)
NUMBER
Statement counter in a source code unit. Covers all statements, regardless of how many are actually selected - in cases where a key word table itab4 is specified
PREFIXLEN
Number of tokens before the colon (with chain statements >= 1, otherwise 0)
COLONROW
Line number of colon (with chain statements >= 1, otherwise 0)
COLONCOL
Column position of colon (with chain statements >= 0, otherwise 0)
TERMINATOR
End marker of a statement (normally a period or a comma, but SPACE in the case of native SQL statements and internal macro definitions)
TROW
Line number of end marker (>= 1, if TERMINATOR <> SPACE, otherwise 0)
TCOL
Column position of end marker (>= 0, if TERMINATOR <> SPACE, otherwise 0)
ENHMT
Index in the ehnancement table of type SENHMT, if the statement was enhanced or originates completely from an enhancement implementation. If addition ENHANCEMENTS INTO itab is not specified, this value is always 0.

Notes

  1. When expanding macro calls, no position specifications are available. The relevant fields in the token table itab2 and in the statement table itab3 are then set to 0.

  2. Unlike in the usual syntax check, the following are not treated as errors:

  1. To be able to analyze errors without modifying programs, use the additions INCLUDE, MESSAGE, WORD, LINE and OFFSET. These provide information about the errors which have occurred.

Addition 1

... FROM n1

Addition 2

... TO   n2

Effect

Breaks down the source code table itab1 into tokens not from start to finish, but only from line n1 to line n2.

The additions FROM n1 and TO n2 must, in this order, follow the specification of the source code table itab1.

Notes

  1. When using the start specification n1, use the addition WITHOUT TRMAC to ensure that there are no unnecessary database accesses to the table TRMAC.

  2. The end specification n2 is treated as "soft", i.e. a statement that begins on a line <= n2, but ends only on a line > n2, is returned completely.

    If the end specification n2 is split in a chain statement, only the split part up to the next comma is returned completely, not the entire chain statement up to the next period.

  3. Negative line specifications are not allowed and result in a runtime error.

  4. A line specification of 0 amounts essentially to no specification.

  5. If n1 number of lines in source code table, the scanner is not called (SY-SUBRC = 2).

  6. If n1 > n2 and n2 > 0, the scanner is not called (SY-SUBRC = 2).

Addition 3

... KEYWORDS FROM itab4

Effect

Does not return all statements, only those specified in the key word table itab4.

If the key word table is empty (i.e. it contains 0 lines), all the statements are selected.

The lines of the key word table are treated as a character field.

To select a Native-SQL statement or a macro definition, you can specify the pseudo key words EXEC_SQL or DEFINE_MACRO. It makes no difference whether the statements EXEC or DEFINE occur as well. Native SQL statements and macro definitions are returned as one statement (of type E or M even if the expansion of a macro definition results in more than one statement.

If the key word table contains a blank line, blank statements are also selected.

Addition 4

... LEVELS INTO itab5

Effect

Stores details about each edited source code unit (source code table itab1 itself, expanded include-programs, expanded macro definitions) in the level table itab5.

Specification of a level table makes sense only with the addition WITH INCLUDES.

The level table itab5 must have the structure SLEVEL.

The fields of the structure SLEVEL - and consequently the columns of the level table itab5 have the following meaning:

TYPE
Type of source code unit with the following possible values:

P (Program)
D (Internal DEFINE macro)
R (Macro from table TRMAC)
NAME
Name of source code unit (name of include program, macro name)
DEPTH
Current nesting depth of source code unit (>= 1)
LEVEL
Index of superior (i.e. including or calling) source code unit in the level table (>= 1, if DEPTH >= 2, otherwise 0)
STMNT
Index of superior (i.e. including or calling) statement in the statement table (>= 1, if DEPTH >= 2, otherwise 0)
FROM
Index of first statement of source code unit in the statement table (>= 1)
TO
Index of last statement of source code unit in the statement table (>= 1)

If the source code unit contains include programs or macro calls, the line range [FROM, TO] in the statement table also covers the statements in subordinate source code units.

Note

Enhancements of type E are saved as normal includes in the level table.

Addition 5

...  STRUCTURES INTO itab6

Effect

Details of the construction of the source text table are given in the structure table itab6.

The structure table itab6 must have the structure SSTRUC.

The fields in SSTRUC (which are also the columns of structure table itab6) have the following meanings:

TYPE
Type of the structure with possible values:
P (Beginning of the source code)
R (Subroutine)
M (Macro, EXEC SQL)
I (Loop)
A (Case distinction)
C (Condition in a case distinction)
J (Goto command)
D (Structured declaration)
E (Event)
S (Follow-on from simple structured statement)
STMNT_TYPE
The statement type of the beginning of the structure. The values are listed in the type pool SCAN in structure SCAN_STRUC_STMNT_TYPE.
KEY_START
Flags whether the start of the structure is described semantically ('X' if there is a special statement, otherwise ' ').

KEY_END

Flags whether the end of the structure is described semantically ('X' if there is a special statement, otherwise blank).

STMNT_FROM

Index of the first statement of the structure in the statement table itab3.

STMNT_TO

Index of the last statement of the structure in the statement table itab3.

Index of the first substructure of the structure in structure table itab6.

STRUC_TO

Index of the last substructure of the structure in structure table itab6.

BACK

Index of the structure in the structure table itab6 that contains the structure as a substructure (0 if the structure is the root structure of a structure tree).

Addition 6

... OVERFLOW INTO c1

Effect

The addition is only allowed and required if the token table itab2 has the structure STOKEN or STOKEX.
If a token is too large to be stored in the token table in the field STR, it is placed in the overflow area c1. The offset of the token in the overflow area then lies in the token table in the field OFF1.

Addition 7

... WITH ANALYSIS

Effect

Breaks down each token t = a+b(c) according to the logic of the RSYN key word >ANALY into its three components a, b and c.

Offset and length of components a, b and c are stored in the fields LEN1, OFF2, LEN2, OFF3, and LEN3 in the token table. (The offset of OFF1 is always 0 and therefore not required.)

If you specify the addition WITH ANALYSIS, the token table itab2 must have the structure STOKESX, so that the fields LEN1, OFF2, LEN2, OFF3 and LEN3 are available.

If the token table has the structure STOKEX, you must consider the following:
If the whole token exists in the token table, the offset specifications are relative to the token start. If the token is in the overflow area c1, the offset specifications are relative to the start of the overflow area.

Addition 8

... WITH COMMENTS

Effect

Returns comments also, with each individual comment representing a token. The system additionally stores entries for each full block of comments in the table itab3, differentiating between comments that occur within statements and those that occur at program level. In itab3, an entry for a comment within a statement always comes before the statement containing the comment.

Example

Look at the following program fragment. The preceding numbers are the indexes of the tokens.

1    * An example  *
2    * with scattered comments
6    MOVE
3    * Inserted comment 1
7    X
4    *  Inserted comment 2
8    TO
9    Y
5    * Inserted comment 3
.

SCAN then enters the following values for the components TYPE, FROM and TO (in this order from left to right) into itab3.

'P' 1 2
  'S' 3 5
  'K' 6 9

Note

If the addition ... WITH COMMENTS is used, the table itab2 must have the line type STOKES or STOKESX.


Addition 9

... WITH INCLUDES [IMPLEMENTATIONS FROM itab]

Effect

Also breaks down subordinate source code units (included programs, called macros) into tokens.

In addition, >source code plug-ins of explicit and implicit enhancement options which may exist are automatically inserted in the source code to be split. The optional addition IMPLEMENTATIONS FROM itab can be used to limit the number of inserted enhancements to the number specified in itab. If itab is empty, no enhancements are inserted. addition LEVELS INTO itab5.

Note

  1. The addition WITH INCLUDES is normally combined with the addition LEVELS INTO itab5.

  2. If (at least) one included program does not exist, SY-SUBRC is set to 1 and the relevant INCLUDE statement is flagged in the statement table itab3 by the statement type J (instead of I), but the breakdown process continues. The level table itab5 contains no entry for include-programs that do not exist.

  3. If you combine WITH INCLUDES with WITHOUT TRMAC, TRMAC- Macros are not expanded because the system does not recognize them as subordinate source code units.

  4. When macro calls are expanded, no position specifications are available. The corresponding fields in the token table itab2 and the statement table itab3 are then set to 0.

  1. The additions FRAME PROGRAM FROM and INCLUDE PROGRAM FROM are required to correctly solve the source code enhancements.


Addition 10

... WITH TYPE-POOLS

Effect

  1. This addition has the same effect as the WITH INCLUDES addition, except that with the former include programs belonging to type groups are broken down into tokens.

Addition 11

... WITH LIST TOKENIZATION

Effect

Tokens of the form (a1, a2, a3) are not returned as tokens but broken down into the elementary components.

Addition 12

... PRESERVING IDENTIFIER ESCAPING

Effect

By default, exclamation marks before labels are deleted. Exclamation marks can be used to distinguish between labels and key
words. This addition prevents their deletion.

Addition 13

... WITHOUT TRMAC

Effect

If a statement begins neither with an ABAP/4 key word nor with a DEFINE macro, the system does not check whether this is a TRMAC macro, but assumes an unknown statement. (Unknown statements are flagged in the statement table itab3 with a U in the field TYPE.)

To avoid unnecessary database accesses to the table TRMAC, you should use the addition WITHOUT TRMAC whenever you assume that the source code to be scanned contains unknown statements. Unknown statements are particularly likely to occur if you use the addition FROM n1, because the scanner does not start at the beginning of the source code, but from a specified point.

Note

If you use WITHOUT TRMAC with WITH INCLUDES, TRMAC macros are not expanded because the system does not recognize them as subordinate source code units.

Addition 14

... [INCLUDE] PROGRAM FROM c2

Addition 15

... INCLUDE INTO c3

Addition 16

... MESSAGE INTO c4

Addition 17

... WORD    INTO c5

Addition 18

... LINE    INTO n3

Addition 19

... OFFSET  INTO n4

Effect

The above additions have the same meaning as those for the SYNTAX-CHECK statement: c2 is an input field for a program name to be assigned to the source code, while the fields c3, c4, c5, n3, and n4 are output fields in case an error occurs.

In release 7.00, the addition PROGRAM FROM was renamed to INCLUDE PROGRAM FROM to clearify the difference between the main program and the source code unit to be broken down. If the addition is used in its previous form PROGRAM FROM, it sets the main program and the source code text unit to be scanned at the same time.

To be able to analyze errors without modifying programs, use the additions INCLUDE INTO, MESSAGE INTO, WORD INTO, LINE INTO and OFFSET INTO. These provide information about the errors which have occurred.

Addition 20

... WITH EXPLICIT ENHANCEMENTS [IMPLEMENTATIONS FROM itab]

Effect

When you specify WITH EXPLICIT ENHANCEMENTS, the existing source code plug-ins for explicit enhancement options are automatically inserted into the source code that has been broken down.

The optional addition IMPLEMENTATIONS FROM can limit the number of inserted enhancements to the number specified in itab. If itab is empty, no enhancement is inserted.

Addition 21

... FRAME PROGRAM FROM c2

Effect

This addition specifies the main program for the source code text to be broken down. This is required for the correct insertion of source code plug-ins.

Addition 22

... ENHANCEMENTS INTO itab

Effect

Specifications of the enhancement implementations available in the source code that is processed are saved in enhancement table itab. It therefore only makes sense to specify an enhancement table together with additions WITH INCLUDES or WITH EXPLICIT ENHANCEMENTS.

The level table itab has to have the line structure SENHMT, whose fields have the following meaning:

ENHMT
The index of the superior enhancement. As nested enhancements are not currently supported, this entry is always 0.
STMNT
The index of the statement in the statement table to which the enhancement is connected (such as ENHANCEMENT-POINT for explicit enhancements or METHOD for an implicit enhancement of a method implementation).
FROM
With regular enhancements (type E), this is the index of the first statement of the enhancement in the statement table. With fragmentary enhancements (type F), this is the index of the first token of the enhancement in the token table.
TO
With regular enhancements (type E), this is the index of the last statement in the enhancement in the statement table. With fragmentary enhancements (type F), this is the index of the first token of the enhancement in the token table.
NAME
Name of the enhancement
INCLUDE
Name of the include that contains the implementation of the enhancement.
ID
Internal ID of the enhancement implementation within the implementation include.
TYPE
Type of enhancement. Type E stands for a normal enhancement with one or more complete statements. Type F stands for a fragmentary enhancement of one or more tokens within an individual statement.
MODE
Enhancement mode: D (dynamic) or S (static).

Notes

Variant 2

SCAN AND CHECK ABAP-SOURCE itab1 ...RESULT INTO itab2.


Parts marked with " ..." are interchangeable

Extras:

1. ... PROGRAM FROM c1 2. ... INCLUDE INTO c2
3. ... MESSAGE INTO c3
4. ... WORD    INTO c4
5. ... LINE    INTO n1
6. ... OFFSET  INTO n2

Effect

The syntax of the program in table itab1 is checked. During the check, all of the information from the program, such as statement structures, statements, tokens, data objects, types and do on are placed into the result field. This field must have the type SYSCH_RESULT, which is defined in type group SYSCH. You must therefore declare type group SYSCH in your ABAP program using a TYPE-POOLS statement.

&ABAP_ADDITION _1&

... PROGRAM FROM c1

&ABAP_ADDITION _2&

... INCLUDE INTO c1

&ABAP_ADDITION _3&

... MESSAGE INTO c3

&ABAP_ADDITION _4&

... WORD    INTO c4

&ABAP_ADDITION _5&

... LINE    INTO n1

&ABAP_ADDITION _6&

... OFFSET  INTO n2

Effect

The above additions have the same effect as the corresponding additions in the statement SYNTAX-CHECK: c1 is an input field for a program name to be assigned to the source code, the fields c2, c3, c4, n1 and n2 are output fields, used when errors occur.

To enable you to analyze errors without having to modify the program, you should specify the INCLUDE, MESSAGE, WORD, LINE and OFFSET additions for the information about the error that occurred.

Exceptions

Catchable Exceptions

CX_SY_SCAN_SOURCE_TOO_WIDE