SCAN
ABAP_VARIANTS:
1 SCAN ABAP-SOURCE itab1 ...TOKENS INTO itab2
...STATEMENTS INTO itab3.
2 SCAN AND CHECK ABAP-SOURCE itab1 ...RESULT INTO itab2.
ABAP_VARIANT_1 SCAN ABAP-SOURCE itab1 ...TOKENS INTO itab2
...STATEMENTS INTO itab3.
ABAP_ANY_SEQUENCE
ABAP_ADDITIONS:
1 ... FROM n1
2 ... TO n2
3 ... KEYWORDS FROM itab
4 ... LEVELS INTO itab
5 ... STRUCTURES INTO itab
6 ... OVERFLOW INTO c1
7 ... WITH ANALYSIS
8 ... WITH DECLARATIONS
9 ... WITH BLOCKS
10 ... WITH COMMENTS
11 ... WITH PRAGMAS pragmas
12 ... WITH INCLUDES [IMPLEMENTATIONS FROM itab]
13 ... WITH TYPE-POOLS
14 ... WITH LIST TOKENIZATION
15 ... PRESERVING IDENTIFIER ESCAPING
16 ... WITHOUT TRMAC
17 ... [INCLUDE] PROGRAM FROM c2
18 ... INCLUDE INTO c3
19 ... MESSAGE INTO c4
20 ... WORD INTO c5
21 ... LINE INTO n3
22 ... OFFSET INTO n4
23 ... WITH EXPLICIT ENHANCEMENTS [IMPLEMENTATIONS FROM itab]
24 ... WITH IMPLICIT ENHANCEMENTS [IMPLEMENTATIONS FROM itab]
25 ... ENHANCEMENT OPTIONS INTO itab
26 ... ENHANCEMENTS INTO itab
27 ... WITH INACTIVE ENHANCEMENTS
28 ... FRAME PROGRAM FROM c2
29 ... REPLACING itab
What does it do? 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 row � 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, fields of the type
STRING
can be used. However, this variant only makes sense if the program
to be broken down does not contain any comments. When an internal table
is specified, itab1 must be a standard table without secondary
keys.
The token table itab2 must be a standard table without secondary
keys and have the structure STOKES . If the addition WITH
ANALYSIS is specified, 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 (
include programs , called
macros ) are ignored. These semantics can be
modified by using 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 chained statements) and the statement table itab3
contains a statement description on each row. Here, a three-part
chained statement "a: b, c1 c2,
d." produces three entries "a b," , "a c1 c2," , and
"a d." in the statement table itab3 .
The statement table itab3 must be a standard table without
secondary keys and 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.
System Fields
sy-subrc Meaning
0Source code table is not empty, contains no errors, and is broken
down into tokens.
1Source code table is not empty and is broken down into tokens, but
at least one include program does not exist (can occur only in co
nnection with the addition WITH INCLUDES ).
2Source code table itab1 is empty or a blank row range was
selected (applies to the additions FROM and TO ).
4Scanner detects error in source code.
8Other error or runtime error in scanner.
If a runtime error occurs in the scanner ( sy-subrc has the
value 8), a database rollback is executed as usual.
Components of the Structure STOKES
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 (divider) between list elements)
E (end of a list)
Types B, D, and E can only appear if the addition WITH
LIST TOKENIZATION is specified.
ROW Number of row where token occurs or where it begins ( = 1)
COL Offset of first character of token relative to start of row
(>= 0)
STR Character string forming the token.
If the structure STOKEN is specified, three more fields are
filled and the following must be noted:
STR The character string forming the token contains only the
first part if the character string is longer than 30.
LEN Length of the 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 .
Components of the Structure SSTMNT
The fields of the structure SSTMNT , and thus the columns of the
statement table itab3 , have the following meaning:
TYPE Type of statement with 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 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 itab
specified after LEVELS INTO ( = 1, if level table specified,
otherwise 0).
STRUC Index of the statement in the structure table itab
specified after STRUCTURES INTO (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 itab is specified after KEYWORDS FROM )
PREFIXLEN Number of tokens before the colon (with chained
statements >= 1, otherwise 0)
COLONROW Row number of colon (with chained statements = 1,
otherwise 0)
COLONCOL Column number of colon (with chained statements = 0,
otherwise 0)
TERMINATOR End marker of a statement (normally a period
or a comma, but SPACE in the case of embedded Native SQL
statements and internal macro definitions)
TROW Row number of the end marker ( = 1, if
TERMINATOR SPACE , otherwise 0)
TCOL Column position of the end marker ( = 0, if
TERMINATOR SPACE , otherwise 0)
ENHMT Index in the enhancement 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.
Latest notes: When macro calls are expanded, no position specifications
are available. The corresponding fields in the token table itab2
and in the statement table itab3 are then set to 0.
Unlike in the usual syntax check, the following are not treated
as errors:
Comma without preceding colon (the comma then acts as an end marker),
Open chained statement sequence at end of source code, i.e. the last
statement is closed by a comma, not by a period,
Open statement at end of source code, i.e. the last statement is
closed neither by a period nor by a comma.
To enable errors to be analyzed without the program being modified,
the additions INCLUDE , MESSAGE , WORD , LINE ,
and OFFSET must be specified to gather information about the
error in question.
ABAP_ADDITION_1 ... FROM n1
ABAP_ADDITION_2 ... TO n2
What does it do? Breaks down the source code table itab1 into
tokens not from start to finish, but only from row n1 to row
n2 .
The additions FROM n1 and TO n2 must, in this order,
follow the specification of the source code table itab1 .
Latest notes: 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 splits a
chained statement , only the split
part up to the next comma is returned completely, not the entire chained
statement up to the next period.
Negative line specifications are not allowed and produce a runtime
error.
A line specification of 0 amounts essentially to no specification.
If n1 number of rows 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).
ABAP_ADDITION_3 ... KEYWORDS FROM itab
What does it do? Does not return all statements, only those specified in
the key word table itab .
If the key word table is empty (i.e. it contains 0 rows), all the
statements are selected.
The rows of the key word table are treated as a character field .
It must be a standard table without secondary keys.
To select a Native SQL statement or
a macro definition, the pseudo key words EXEC_SQL or
DEFINE_MACRO can be specified. It makes no difference whether the
statements EXEC or DEFINE occur as well. NativeSQL
statements and macro definitions are returned as one statement (of type
E or M even if the expansion of a macro definition produces more than
one statement.
If the key word table contains a blank row, blank statements are also
selected.
ABAP_ADDITION_4 ... LEVELS INTO itab
What does it do? Stores details about each edited source code unit (source
code table itab1 itself, expanded
include programs , expanded macro
definitions) in the level table itab .
Specify a level table only with the additions WITH INCLUDES or
WITH IMPLICIT ENHANCEMENTS .
The level table itab must have the structure SLEVEL . It
must be a standard table without secondary keys.
The fields of the structure SLEVEL (and consequently the
columns of the level table itab ) have the following meaning:
TYPE Type of source code unit with 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
row range [ FROM, TO ] in the statement table also covers the
statements in subordinate source code units.
Latest notes: Enhancements of type E are saved as normal includes
in the level table .
ABAP_ADDITION_5 ... STRUCTURES INTO itab
What does it do? Details of the construction of the source code table
itab1 are written to the structure table itab .
The structure table itab must have the structure SSTRUC
. It must be a standard table without secondary keys.
The fields in SSTRUC (which are also the columns of structure
table itab ) have the following meanings:
TYPE Type of 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 (jump command)
D (structured declaration)
E (event)
S (sequence of statements with simple structures)
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
' ' ).
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 .
STRUC_FROM Index of the first substructure of the structure in
structure table itab .
STRUC_TO Index of the last substructure of the structure in
structure table itab .
BACK Index of the structure in the structure table itab
that contains the structure as a substructure (0 if the structure is the
root structure of a structure tree).
ABAP_ADDITION_6 ... OVERFLOW INTO c1
What does it do? This 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 .
ABAP_ADDITION_7 ... WITH ANALYSIS
What does it do? Breaks down each token t = a+b(c) according to the logic
of the RSYN key word ANALYSIS 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 the addition WITH ANALYSIS is specified, 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 , the following must
be noted:
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.
ABAP_ADDITION_8 ... WITH DECLARATIONS
What does it do? Returns all declarative statements and all statements
with inline declarations .
ABAP_ADDITION_9 ... WITH BLOCKS
What does it do? Returns all statements that define a processing block or
a statement block.
ABAP_ADDITION_10 ... WITH COMMENTS
What does it do? Also returns comments, with each individual comment
representing a token. Also writes entries for each cohesive block to the
table itab3 . Here, a distinction is made between comments within
statements and comments at program level. In itab3 , an entry for
a comment within a statement always comes before the statement
containing the comment.
Example ABAP Coding
Look at the following program fragment. The prefixed 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'12
'S'35
'K'69
Latest notes: If the addition WITH COMMENTS is used, the table
itab2 must have the row type STOKES or STOKESX .
ABAP_ADDITION_11 ... WITH PRAGMAS pragmas
What does it do? This addition returns all relevant pragmas for each
statement before the first correct token of the statement but after a
block of comments collected with the WITH COMMENTS addition.
pragmas expects a data object of the type c with length 1,
usually containing the value "*". Other values are intended for and
recognized by special test tools.
A block of pragmas is combined in the statement table under the
statement type "G". In this way, the block sequence is for a statement
which contains comments and matching pragmas " S-G-K ".
Pragmas which are not determined for ABAP Compiler are searched for in
the TRPRAGMA database table.
Illegal (for example, unknown or lexically incorrect) pragmas are
processed in the same way as legal pragmas, that is, they are summarized
in a block preceding the actual statement (ID " G "). This
corresponds to the behavior of the scanner in the compiler.
ABAP_ADDITION_12 ... WITH INCLUDES [IMPLEMENTATIONS FROM itab]
What does it do? Also breaks down subordinate source code units (include
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, any
enhancements are ignored. itab must be a standard table without
secondary keys.
Latest notes: The addition WITH INCLUDES is normally combined
with the addition LEVELS INTO itab .
If (at least) one include 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 itab contains no
entry for include programs that do
not exist.
If WITH INCLUDES is combined with the addition 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
in the statement table itab3 are then set to 0.
The additions FRAME PROGRAM FROM and INCLUDE PROGRAM FROM
are required to correctly solve the source code enhancements.
ABAP_ADDITION_13 ... WITH TYPE-POOLS
What does it do? 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.
ABAP_ADDITION_14 ... WITH LIST TOKENIZATION
What does it do? Tokens of the form (a1, a2, a3) are not returned
as tokens but broken down into the elementary components.
ABAP_ADDITION_15 ... PRESERVING IDENTIFIER ESCAPING
What does it do? 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.
ABAP_ADDITION_16 ... WITHOUT TRMAC
What does it do? If a statement begins neither with an ABAP 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 , the
addition WITHOUT TRMAC should be used whenever it is assumed that
the source code being scanned contains unknown statements. Unknown
statements are particularly likely to occur if the addition FROM n1
is used, because the scanner does not start at the beginning of the
source code, but from a specified point.
Latest notes: If WITHOUT TRMAC is used with WITH INCLUDES ,
TRMAC macros are not expanded because the system does not
recognize them as subordinate source code units.
ABAP_ADDITION_17 ... [INCLUDE] PROGRAM FROM c2
ABAP_ADDITION_18 ... INCLUDE INTO c3
ABAP_ADDITION_19 ... MESSAGE INTO c4
ABAP_ADDITION_20 ... WORD INTO c5
ABAP_ADDITION_21 ... LINE INTO n3
ABAP_ADDITION_22 ... OFFSET INTO n4
What does it do? The above additions have the same effect as the
corresponding additions in the statement
SYNTAX-CHECK : 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 as
INCLUDE PROGRAM FROM to clarify the difference between the master
program and the split source code unit. If the addition is used in its
previous form PROGRAM FROM , it sets the master 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.
Laufzeitfehler
SCAN_AS_FROM_NEGATIVE :
SCAN_AS_INVALID_STRUCTURE :
SCAN_AS_LEVEL_NOT_ALIGNED :
SCAN_AS_LEVEL_TAB_DESTROYED :
SCAN_AS_LEVEL_TOO_SHORT :
SCAN_AS_NO_ROLL :
SCAN_AS_RABAX_ERROR :
SCAN_AS_STMNT_NOT_ALIGNED :
SCAN_AS_STMNT_TAB_DESTROYED :
SCAN_AS_STMNT_TOO_SHORT :
SCAN_AS_STRUCTURE_TOO_SHORT :
SCAN_AS_TOKEN_NOT_ALIGNED :
SCAN_AS_TOKEN_TOO_SHORT :
SCAN_AS_TO_NEGATIVE :
ABAP_ADDITION_23 ... WITH EXPLICIT ENHANCEMENTS [IMPLEMENTATIONS
FROM itab]
What does it do? When WITH EXPLICIT ENHANCEMENTS is specified, the
existing source code plug-ins for
explicit enhancement points are
automatically inserted into the split source code.
The optional addition IMPLEMENTATIONS FROM can limit the number
of inserted enhancements to the number specified in itab . If
itab is empty, any enhancements are ignored.
ABAP_ADDITION_24 ... WITH IMPLICIT ENHANCEMENTS [IMPLEMENTATIONS
FROM itab]
What does it do? When WITH IMPLICIT ENHANCEMENTS is specified, the
existing source code plug-ins for
implicit enhancement points are
automatically inserted into the split source code.
The optional addition IMPLEMENTATIONS FROM can limit the number
of inserted enhancements to the number specified in itab . If
itab is empty, any enhancements are ignored.
ABAP_ADDITION_25 ... ENHANCEMENT OPTIONS INTO itab
What does it do? Specifications about the enhancement points that exist in
the source code unit that is being processed are stored in the itab
description table. It therefore only makes sense to specify an
enhancement table together with additions WITH INCLUDES , WITH
EXPLICIT ENHANCEMENTS , or WITH IMPLICIT ENHANCEMENTS .
The level table itab must be a standard table without a
secondary key and must have the row structure SEOPTN whose fields
have the following meaning:
LEVEL Index of the relevant entry in the level table . If
this information is required, the LEVELS INTO addition must be
specified at the same time in order to fill the level table .
ROW , COL Position of the enhancement point in the source
code. This position is not unique, since enhancements can be inserted to
all blanks around the position specified by ROW and COLUMN
.
FULL_NAME Full name of the enhancement point. This name uniquely
identifies an implicit enhancement point.
TYPE The type of enhancement point. I is for an implicit
enhancement point and E is for an explicit enhancement point.
MODE The mode of the enhancement point. Type S is for static,
type D is for dynamic, and type A is for any enhancement point.
ENHMT Index of the first relevant enhancement implementation in
the enhancement table or 0 if the enhancement point is not implemented.
If this information is required, the ENHANCEMENTS INTO addition
must be specified at the same time in order to fill the enhancement
table.
Latest notes: The additions FRAME PROGRAM FROM and INCLUDE
PROGRAM FROM are used, especially for explicit enhancement points, to
find out the name of the master program or the name of the current
include program. These names are used to determine the full names of
explicit enhancement points.
The ENHANCEMENT OPTIONS INTO addition is independent of the
ENHANCEMENTS INTO addition and they can be used at the same time.
ABAP_ADDITION_26 ... ENHANCEMENTS INTO itab
What does it do? 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 , WITH
EXPLICIT ENHANCEMENTS , or WITH IMPLICIT ENHANCEMENTS .
The enhancement table itab must be a standard table without
secondary keys and have the row structure SENHMT , whose fields
have the following meaning:
ENHMT The index of the superior enhancement.
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 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.
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 the 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 Mode of the enhancement: "D" (dynamic) or "S"
(static).
Latest notes: For enhancements to be identified correctly, it is
imperative that the additions FRAME PROGRAM FROM and INCLUDE
PROGRAM FROM are specified correctly.
Multiple fragmentary enhancements can exist for a statement. In this
case, the statement table refers to the entry in the first enhancement
in the enhancement table; all other enhancements are connected directly
to this and can be identified uniquely using the STMNT field.
The ENHANCEMENT INTO addition is independent of the
ENHANCEMENTS OPTIONS INTO addition and they can be used at the same
time.
ABAP_ADDITION_27 ... WITH INACTIVE ENHANCEMENTS
What does it do? This addition is only possible with ENHANCEMENTS INTO
. If WITH INACTIVE ENHANCEMENTS is specified as well,
deactivated or overwritten enhancement implementations are respected.
For these, the values "e" and "f" are stored instead of "E" and "F" in
the TYPE column of the itab enhancement table.
ABAP_ADDITION_28 ... FRAME PROGRAM FROM c2
What does it do? Using this addition, the master program is specified to
the source code unit to be split. This is necessary, especially for
inserting source code plug-ins
correctly.
Latest notes: For the master program, remember that even when this
addition from the SCAN statement is specified, processing does
not occur at the same time. The SCAN statement always processes
only the passed source code and possibly the included type groups or
include programs. In order to process an include program in its context,
the master program must be passed itself, whereby non-relevant include
programs with the REPLACING addition can be hidden. As an
alternative to the use of REPLACING , a mock master
program, which constructs the correct context for include programs to be
processed but remains empty the rest of the time, is also possible.
ABAP_ADDITION_29 ... REPLACING itab
What does it do? Individual INCLUDE statements can be overridden by
specifying an internal table of type SREPTAB . If itab
contains an entry "INCL" in column name , with the
statement INCLUDE incl not the include INCL is read but
the source code from column itab-source is inserted.
It has the same effect as the addition REPLACING of the
internal statement SYNTAX-CHECK
FOR PROGRAM . However, the entry itab-trdir is ignored.
itab must be a standard table without secondary keys.
ABAP_VARIANT_2 SCAN AND CHECK ABAP-SOURCE itab1 ...RESULT INTO
itab2.
ABAP_ANY_SEQUENCE
ABAP_ADDITIONS:
1 ... PROGRAM FROM c1
2 ... INCLUDE INTO c2
3 ... MESSAGE INTO c3
4 ... WORD INTO c4
5 ... LINE INTO n1
6 ... OFFSET INTO n2
What does it do?
Checks the syntax of the program in table itab1 . This check
writes all information collected about the program, such as statement
structures, statements, tokens, data objects, or types, to the variable
result . Here, result must have the type SYSCH_RESULT
, defined in the type group
SYSCH .
ABAP_ADDITION_1 ... PROGRAM FROM c1
ABAP_ADDITION_2 ... INCLUDE INTO c2
ABAP_ADDITION_3 ... MESSAGE INTO c3
ABAP_ADDITION_4 ... WORD INTO c4
ABAP_ADDITION_5 ... LINE INTO n1
ABAP_ADDITION_6 ... OFFSET INTO n2
What does it do? 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 errors to be analyzed without the program being modified, the
additions INCLUDE , MESSAGE , WORD , LINE , and
OFFSET must be specified to gather information about the error in
question.
Runtime Exceptions
Catchable Exceptions
CX_SY_SCAN_SOURCE_TOO_WIDE
Reason for error: A string was passed that is longer than 32767
characters, or a string table that contains a row with more than 32767
characters.
Runtime error: SCAN_SOURCE_TOO_WIDE
Documentation extract taken from SAP system, � Copyright SAP AG. All rights reserved