What is the use of keyword SCAN ABAP-SOURCE

Question

Hello experts,
what is the use of scan abap-source. please explain. what is tokens, statements, levels in that.

Answer 1

Hi
<b>SCAN</b>
This statement is for internal use only.
It cannot be used in application programs.
<b>SCAN ABAP-SOURCE itab1 ...TOKENS INTO itab2
                       ...STATEMENTS INTO itab3.</b>
Parts marked with " ..." are interchangeable
<b>Addition 1</b>
... FROM n1
<b>Addition 2</b>
... TO   n2
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.
When using the start specification n1, use the addition WITHOUT TRMAC to ensure that there are no unnecessary database accesses to the table TRMAC.
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.
Negative line specifications are not allowed and result in a runtime error.
A line specification of 0 amounts essentially to no specification.
If n1 number of lines in source code table, the scanner is not called (SY-SUBRC = 2).
If n1 > n2 and n2 > 0, the scanner is not called (SY-SUBRC = 2).
<b>
Addition 3</b>
... KEYWORDS FROM itab4
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.
<b>Addition 4</b>
... LEVELS INTO itab5
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.
<b>Addition 5</b>
...  STRUCTURES INTO itab6
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).
<b>Addition 6</b>
... OVERFLOW INTO c1
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.
<b>Addition 7</b>
... WITH ANALYSIS
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.
<b>Addition 8</b>
... WITH COMMENTS
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.
<b>Example</b>
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
If the addition ... WITH COMMENTS is used, the table itab2 must have the line type STOKES or STOKESX.
<b>Addition 9</b>
... WITH INCLUDES
Also breaks down subordinate source code units (included programs, called macros) into tokens.
You should normally combine the addition WITH INCLUDES with the addition LEVELS INTO itab5.
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.
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.
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.
<b>Addition 10</b>
... WITH TYPE-POOLS
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.
<b>Addition 11</b>
.. WITH LIST TOKENIZATION
Tokens of the form (a1, a2, a3) are not returned as tokens but broken down into the elementary components.
<b>Addition 12</b>
... WITHOUT TRMAC
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.
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.
<b>Addition 13</b>
... PROGRAM FROM c2
<b>Addition 14</b>
... INCLUDE INTO c3
<b>Addition 15</b>
... MESSAGE INTO c4
<b>Addition 16</b>
... WORD    INTO c5
<b>Addition 17</b>
... LINE    INTO n3
<b>Addition 18</b>
... OFFSET  INTO n4
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.
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.
<b>Variant 2</b>
SCAN AND CHECK ABAP-SOURCE itab1 ...RESULT INTO itab2.
Parts marked with " ..." are interchangeable
<b>Extras:</b>
1. ... PROGRAM FROM c1 2. ... INCLUDE INTO c2
3. ... MESSAGE INTO c3
4. ... WORD    INTO c4
5. ... LINE    INTO n1
6. ... OFFSET  INTO n2
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
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.
<b>Reward if usefull</b>