SAP's ABAP/4 Tips and Tricks

SAP's ABAP/4 Tips and Tricks

These are straight from SAP, in a slightly more pleasing HTML format.

SQL Interface
/ Select ... Where vs. Select + Check / / Select with index support
/ Select Single vs. Select-Endselect / / Select ... into Table t
/ Select aggregates / / Select-Endselect vs. Array-Select
/ Select with view / / Select with select list
/ Select with buffer support / / Array Insert vs. Single-row Insert
/ Column Update
String manipulation
/ Special operators in IF (CA, ...) / / String concatenation
/ String concatenation II / / String split
/ Deleting leading spaces / / String length
/ Initializing strings
Internal Tables
/ Building sorted tables / / Building condensed tables
/ Building tables without duplicates / / Linear vs. binary search
/ Different forms of key access / / Secondary indices
/ Key access to multiple lines / / Using explicit work areas
/ Copying internal tables / / Comparing internal tables
/ Sorting internal tables / / Joining internal tables
/ Nested loops / / Appending a table
/ Inserting a table / / Deleting duplicates
/ Deleting a sequence of lines / / Deleting a set of lines
/ Modifying an internal table / / Modifying a set of lines
Typing
/ Typed vs. untyped Parameters / / Typed vs. untyped Field-Symbols
If, Case, ...
/ If vs. Case / / While vs. Do
/ Case vs. Perform i Of ...
Field Conversion
/ Field Types I and P / / Literals Type C and Type I
/ Constants Type F / / Arithmetic
/ Mixed Types
SQL Interface
Select...Where vs. Select + Check
Select + Check Statement. / Select with Where condition.
SELECT * FROM SBOOK. / SELECT * FROM SBOOK
CHECK: SBOOK-CARRID = 'LH' AND / WHERE CARRID = 'LH' AND
SBOOK-CONNID = '0400'. / CONNID = '0400'.
ENDSELECT. / ENDSELECT.
microsec: 5,044 / microsec: 3,886

• Always specify your conditions in the Where-clause instead of checking them yourself with Check statements.
• The database system can then use an index [if possible] and the network load is considerably less.

Select single vs. Select-Endselect
Select ... Endselect. / Select Single.
SELECT * FROM SCARR / SELECT SINGLE * FROM SCARR
WHERE CARRID = 'LH'. / WHERE CARRID ='LH'.
ENDSELECT.
microsec: 2,895 / microsec: 2,636

• If you are interested in exactly one row of a database table or view, use the Select Single statement instead of a Select-Endselect loop.
• Select Single requires one communication with the database system, whereas Select-Endselect needs two.

Select aggregates
Select ... Where + Check. / Select using an aggregate function.
C4A = '000'. / SELECT MAX( MSGNR ) FROM T100 INTO C4A
SELECT * FROM T100 / WHERE SPRSL = 'D' AND
WHERE SPRSL = 'D' AND / ARBGB = '00'.
ARBGB = '00'.
CHECK: T100-MSGNR > C4A.
C4A = T100-MSGNR.
ENDSELECT.
microsec: 94,287 / microsec: 11,498

• If you want to find the maximum, minimum, sum and average value or the count of a database column, use a select list with aggregate functions instead of computing the aggregates yourself.
• Network load is considerably less.

Select with view
Nested Select statements. / Select with view.
SELECT * FROM DD01L / SELECT * FROM DD01V
WHERE DOMNAME LIKE 'CHAR%' / WHERE DOMNAME LIKE 'CHAR%'
AND AS4LOCAL = 'A'. / AND DDLANGUAGE = SY-LANGU.
SELECT SINGLE * FROM DD01T / ENDSELECT.
WHERE DOMNAME =
DD01L-DOMNAME
AND AS4LOCAL = 'A'
AND AS4VERS =
DD01L-AS4VERS
AND DDLANGUAGE =
SY-LANGU.
ENDSELECT.
microsec: 950,404 / microsec: 195,175

• To process a join, use a view instead of nested Select statements.
• Network load is considerably less.

Select with buffer support
Select without buffer support. / Select with buffer support.
SELECT SINGLE * FROM T100 / SELECT SINGLE * FROM T100
BYPASSING BUFFER / WHERE SPRSL = 'D'
WHERE SPRSL = 'D' / AND ARBGB = '00'
AND ARBGB = '00' / AND MSGNR = '999'.
AND MSGNR = '999'.
microsec: 2,764 / microsec: 99

• For all frequently used, read-only tables, try to use SAP buffering.
• Network load is considerably less.

Column Update
Single-line Updates. / Column Update.
SELECT * FROM SFLIGHT. / UPDATE SFLIGHT.
SFLIGHT-SEATSOCC = / SET SEATSOCC = SEATSOCC - 1.
SFLIGHT-SEATSOCC - 1.
UPDATE SFLIGHT.
ENDSELECT.
microsec: 22,041 / microsec: 4,563

• Whenever possible, use column updates instead of single-row updates to update your database tables.
• Network load is considerably less.

Select with index support
Select without index support. / Select with primary index support.
SELECT * FROM T100. / SELECT * FROM T002.
WHERE ARBGB = '00' / SELECT * FROM T100
AND MSGNR = '999'. / WHERE SPRSL = T002-SPRAS
ENDSELECT. / AND ARBGB = '00'
AND MSGNR = '999'.
ENDSELECT.
ENDSELECT.
microsec: 1,495,282 / microsec: 84,080

• For all frequently used Select statements, try to use an index.
• You always use an index if you specify [a generic part of] the index fields concatenated with logical Ands in the Select statement's Where clause.
• Note that complex Where clauses are poison for the statement optimizer in any database system.

Select...Into Table t
Select + Append Statement. / Select Into Table.
REFRESH X006. / SELECT * FROM T006 INTO TABLE X006.
SELECT * FROM T006 INTO X006.
APPEND X006.
ENDSELECT.
microsec: 1,847 / microsec: 919

• It is always faster to use the Into Table version of a Select statement than to use Append statements

Select-Endselect vs. Array-Select
Select Into Table t + Loop at t. / Select ... Endselect.
SELECT * FROM T006 / SELECT * FROM T006.
INTO TABLE X006. / ENDSELECT.
LOOP AT X006.
ENDLOOP.
microsec: 1,080 / microsec: 1,427

• If you process your data only once, use a Select-Endselect loop instead of collecting data in an internal table with Select Into Table.
• Internal table handling takes up much more space.

Select with select list
Select *. / Select with select list.
SELECT * FROM DD01L. / SELECT DOMNAME FROM DD01L
WHERE DOMNAME LIKE 'CHAR%' / INTO DD01L-DOMNAME
AND AS4LOCAL = 'A'. / WHERE DOMNAME LIKE 'CHAR%'
ENDSELECT. / AND AS4LOCAL = 'A'.
ENDSELECT.
microsec: 66,472 / microsec: 205,433

• Use a select list or a view instead of Select *, if you are only interested in specific columns of the table.
• Network load is considerably less.

Array Insert vs. Single-row Insert
Single-line inserts. / Array Insert.
LOOP AT TAB. / INSERT CUSTOMERS FROM TABLE
INSERT INTO CUSTOMERS / TAB.
VALUES TAB.
ENDLOOP.
microsec: 37 / microsec: 24

• Whenever possible, use array operations instead of single-row operations to modify your database tables.
• Frequent communication between the application program and database system produces considerable overhead.

String manipulation
Special operators in IF (CA, ...)
DO-Loop with Field Symbols. / Using the CA operator.
ASSIGN CHA(1) TO <C>. / IF CHA(200) CA '()'.
"...any actions
DO 200 TIMES. / ENDIF.
IF <C> = '(' OR <C> = ')'.
"...any actions
EXIT.
ENDIF.
ASSIGN <C> + 1 TO <C>.
ENDDO.
microsec: 327 / microsec: 11

• Use the special operators CO, CA, CS, instead of programming the operations yourself.
• If ABAP/4 statements are executed per character on long strings, CPU consumption can rise substantially.

String concatenation II
Moving with offset. / Use of the CONCATENATE statement.
" MOVE 'Jane' TO CMA. / " MOVE 'Jane' TO CMA.
" MOVE 'Miller' TO CMB. / " MOVE 'Miller' TO CMB.
" MOVE 'New York City' TO CMC. / " MOVE 'New York City' TO CMC.
I1 = STRLEN( CMA ). / CONCATENATE
I2 = STRLEN( CMB ). / 'Mrs.' CMA CMB 'from' CMC
MOVE 'Mrs. ' TO CHA. / INTO CHA
MOVE CMA TO CHA + 5.I1 = I1 + 6. / SEPARATED BY SPACE.
MOVE CMB TO CHA + I1.I1 = I1 + I2 + 1.
MOVE 'from' TO CHA + I1.I1 = I1 + 5.
MOVE CMC TO CHA + I1.
"Mrs. Jane Miller from New York City" is the final value of CHA. / "Mrs. Jane Miller from New York City" is the final value of CHA.
microsec: 40 / microsec: 9

• Use the CONCATENATE statement instead of programming a string concatenation of your own.

Deleting leading spaces
Shifting by SY-FDPOS places. / Using SHIFT...LEFT DELETING LEADING...
" CLA contains the string / " CLA contains the string
" '"Editor line n'. / " '"Editor line n'.
IF CLA CN SPACE. ENDIF.
SHIFT CLA BY SY-FDPOS PLACES LEFT. / SHIFT CLA LEFT DELETING LEADING SPACE.
microsec: 4 / microsec: 2

• If you want to delete the leading spaces in a string, use the ABAP/4 statement SHIFT...LEFT DELETING LEADING...
• Other constructions (with CN and SHIFT...BY SY-FDPOS PLACES, with CONDENSE if possible, with CN and ASSIGN CLA + SY-FDPOS(LEN)...) are not as fast.
• In any case, avoid using SHIFT inside a WHILE-loop!

Initializing strings: CLEAR/TRANSLATE vs. CLEAR WITH val
Initializing with CLEAR/TRANSLATE. / Initializing with CLEAR WITH val.
* STRING is a 255 byte character field / * STRING is a 255 byte character field
CLEAR STRING. / CLEAR STRING WITH '*'.
TRANSLATE STRING USING '*'.
microsec: 20 / microsec: 2

• Use "CLEAR f WITH val" whenever you want to initialize a field with a value different from the field's type-specific initial value.

String concatenation
Use of a CONCATENATE function module. / Use of the CONCATENATE statement.
CALL FUNCTION 'STRING_CONCATENATE_3' / CONCATENATE T100-ARBGB
EXPORTING / T100-MSGNR
STRING1 = T100-ARBGB / T100-TEXT INTO CLA.
STRING2 = T100-MSGNR
STRING3 = T100-TEXT
IMPORTING
STRING = CLA
EXCEPTIONS
TOO_SMALL = 01.
microsec: 67 / microsec: 3

• Some function modules for string manipulation have become obsolete and should be replaced by ABAP/4 statements or functions:
• STRING_CONCATENATE...->CONCATENATE
• STRING_SPLIT...->SPLIT
• STRING_LENGTH...->strlen()
• STRING_CENTER...->WRITE...TO...CENTERED
• STRING_MOVE_RIGHT...->WRITE...TO...RIGHT-JUSTIFIED

String split
Use of SEARCH and MOVE with Offset. / Use of the SPLIT statement.
" CMA contains '(410)-45174-66354312' and / " CMA contains '(410)-45174-66354312' and
" shall be split into AREA_CODE, / " shall be split into AREA_CODE,
"TEL_NO1, / "TEL_NO1,
"TEL_NO2. / "TEL_NO2.
SEARCH CMA FOR '-'.
MOVE CMA(SY-FDPOS) TO / SPLIT CMA AT '-' INTO AREA_CODE
AREA_CODE. / TEL_NO1
I1 = SY-FDPOS + 2. / TEL_NO2.
SEARCH CMA FOR '-' STARTING AT I1.
I1 = I1 - 1.
MOVE CMA + I1(SY-FDPOS) TO
TEL_NO1.
I1 = I1 + SY-FDPOS + 1.
MOVE CMA + I1 TO TEL_NO2.
microsec: 28 / microsec: 4

• Use the SPLIT statement instead of programming a string split yourself.

String length
Get a check-sum with length / Get a check-sum with strlen()
" DATA: BEGIN OF STR, LINE TYPE X, END OF STR. / " DATA: BEGIN OF STR, LINE TYPE X, END OF STR.
" 'CHECK_SUM TYPE I. / " 'CHECK_SUM TYPE I.
" MOVE 'KALEBVPQDSCFG' TO CLA. / " MOVE 'KALEBVPQDSCFG' TO CLA.
I1 = STRLEN( CLA ).
DO 64 TIMES VARYING STR FROM CLA NEXT CLA+1. / DO I1 TIMES VARYING STR FROM CLA NEXT CLA+1.
CHECK STR NE SPACE. / CHECK STR NE SPACE.
ADD STR-LINE TO CHECK_SUM. / ADD STR-LINE TO CHECK_SUM.
ENDDO. / ENDDO.
microsec: 178 / microsec: 55

• Use the strlen() function to restrict the DO loop to the relevant part of the field, eg. when determining a check-sum.

Internal Tables
Building a sorted internal table: READ/INSERT vs. APPEND/SORT
One-step approach: READ/INSERT. / Two-step approach: APPEND, then SORT.
* TAB_DEST is filled with 1000 entries / * TAB_DEST is filled with 1000 entries
REFRESH TAB_DEST. / REFRESH TAB_DEST.
LOOP AT TAB_SRC. / LOOP AT TAB_SRC.
READ TABLE TAB_DEST / APPEND TAB_SRC TO TAB_DEST.
WITH KEY K = TAB_SRC-K / ENDLOOP.
BINARY SEARCH. / SORT TAB_DEST BY K.
INSERT TAB_SRC INTO TAB_DEST
INDEX SY-TABIX.
ENDLOOP.
microsec: 22,223 / microsec: 10,745

• If the amount of data is small (<20 entries), or if you need read-access to the internal table while it is being filled, the one-step approach using READ/INSERT is the right choice.
• If, however, the data amount is larger and you need read-access only to the completely-filled table, the two-step algorithm is preferable

Building unique sorted tables: READ/INSERT vs. APPEND/SORT/DELETE
One step approach / Three-steps: copy, sort, delete duplicates.
* TAB_SRC contains 1000 entries, of which / * TAB_SRC contains 1000 entries, of which
* 500 are different. / * 500 are different.
REFRESH TAB_DEST. / REFRESH TAB_DEST.
LOOP AT TAB_SRC. / LOOP AT TAB_SRC.
READ TABLE TAB_DEST / APPEND TAB_SRC TO TAB_DEST.
WITH KEY K = TAB_SRC / ENDLOOP.
BINARY SEARCH. / SORT TAB_DEST BY K.
IF SY-SUBRC > 0. / DELETE ADJACENT DUPLICATES FROM
INSERT TAB_SRC INTO TAB_DEST / TAB_DEST COMPARING K.
INDEX SY-TABIX.
ENDIF.
ENDLOOP.
microsec: 13,393 / microsec: 12,806

• If the data amount is small (<20 entries), or if you need read-access to the internal table while it is being filled, the one-step approach using READ/INSERT is the right choice.
• If, however, the data amount is larger and you need read-access only to the completely-filled table, the three-step algorithm is preferable.

Key access: implicit versus explicit key field specification
Access via implicit default key. / Access via key specified explicitly.
* Table TAB is filled with 30 entries of / * Table TAB is filled with 30 entries of
* 500 bytes each. / * 500 bytes each.
* The READ ends with SY-SUBRC = 4 / * The READ ends with SY-SUBRC = 4
MOVE SPACE TO TAB. / READ TABLE TAB WITH KEY K = 'X'
TAB-K = 'X'. / BINARY SEARCH.
READ TABLE TAB BINARY SEARCH.
microsec: 14 / microsec: 4

• If possible, specify the key fields for read access explicitly.
• Otherwise, the key fields have to be computed dynamically by the run-time system.

Key access to multiple lines: LOOP/CHECK versus LOOP...WHERE
Key access with LOOP/CHECK. / Key access with LOOP...WHERE.
* Table TAB is filled with 100 entries / * Table TAB is filled with 100 entries
* of 500 bytes each, / * of 500 bytes each,
* 5 entries of which match the key conditions / * 5 entries of which match the key conditions
LOOP AT TAB. / LOOP AT TAB WHERE K = KVAL.
CHECK TAB-K = KVAL. / " ...
" ... / ENDLOOP.
ENDLOOP.
microsec: 697 / microsec: 123

• LOOP...WHERE is faster than LOOP/CHECK because LOOP...WHERE evaluates the specified condition internally.
• As with any logical expressions, the performance is better if the operands of a comparison share a common type.
• The performance can be further enhanced if LOOP...WHERE is combined with FROM i1 and/or TO i2, if possible

Copying internal tables
Pedestrian way to copy internal tables. / Let the kernel do the work...
* Table TAB_SRC is filled with 100 entries / * Table TAB_SRC is filled with 100 entries
* of 100 bytes each. / * of 100 bytes each.
REFRESH TAB_DEST. / TAB_DEST[] = TAB_SRC[].
LOOP AT TAB_SRC INTO TAB_DEST.
APPEND TAB_DEST.
ENDLOOP.
microsec: 370 / microsec: 119

• Internal tables can be copied by MOVE just like any other data object.
• If an internal table itab has a header line, the table itself is accessed by itab[].

Sorting internal tables
Sort internal table with default sort key. / Sort with sort key specified explicitly.
* Table TAB is filled with 100 entries / * Table TAB is filled with 100 entries
* of 500 bytes each. / * of 500 bytes each.
SORT TAB. / SORT TAB BY K.
microsec: 1,318 / microsec: 417

• The more restrictively you specify the sort key, the faster the program will run.
• Therefore, specify the sort key as restrictively as possible.

Nested loops at two sorted tables
Straightforward nested loop. / More sophisticated loop: parallel cursors.
* Table TAB1 is filled with 100 entries / * Table TAB1 is filled with 100 entries
* of 100 bytes each. / * of 100 bytes each.
* Table TAB2 is filled with / * Table TAB2 is filled with
* 10 * 100 = 1000 entries of 100 bytes each. / * 10 * 100 = 1000 entries of 100 bytes each.
* Tables TAB1 and TAB2 are assumed to be
* sorted by K in ascending order.
LOOP AT TAB1. / I2 = 1.
LOOP AT TAB2 WHERE K = TAB1-K. / LOOP AT TAB1.
" ... / LOOP AT TAB2 FROM I2.
ENDLOOP. / IF TAB2-K > TAB1-K.
ENDLOOP. / I2 = SY-TABIX.
EXIT.
ENDIF.
" ...
ENDLOOP.
ENDLOOP.
microsec: 139,964 / microsec: 3,915

• If TAB1 has n1 entries and TAB2 has n2 entries, the time needed for the nested loop with the straightforward algorithm is O(n1 * n2), whereas the parallel cursor approach takes only O(n1 + n2) time.
• The above parallel cursor algorithm assumes that TAB2 contains only entries also contained in TAB1.
• If this assumption does not hold, the parallel cursor algorithm gets slightly more complicated, but its performance characteristics remain the same.

Inserting an internal table into another internal table
Pedestrian way to insert a table. / Let the kernel do the work...
* Table TAB_SRC and TAB_DEST are both / * Table TAB_SRC and TAB_DEST are both
* filled with 500 entries of 100 bytes each. / * filled with 500 entries of 100 bytes each.
* TAB_SRC is inserted in a single step into / * TAB_SRC is inserted in a single step into
* TAB_DEST at index IDX. / * TAB_DEST at index IDX.
IDX = 250. / IDX = 250.
LOOP AT TAB_SRC. / INSERT LINES OF TAB_SRC INTO
INSERT TAB_SRC INTO TAB_DEST / TAB_DEST INDEX IDX.
INDEX IDX.
ADD 1 TO IDX.
ENDLOOP.
microsec: 5,802 / microsec: 1,194

• With the new INSERT variant INSERT LINES OF itab1 TO itab2 INDEX idx, the task of inserting a table into another table can be transferred to the kernel.

Deleting a sequence of lines from an internal table
Pedestrian way to delete a sequence of lines. / Let the kernel do the work...
* Table TAB_DEST is filled with 1000 entries / * Table TAB_DEST is filled with 1000 entries
* of 500 bytes each, and lines 450 to 550 are / * of 500 bytes each, and lines 450 to 550 are
* to be deleted / * to be deleted
DO 101 TIMES. / DELETE TAB_DEST FROM 450 TO 550.
DELETE TAB_DEST INDEX 450.
ENDDO.
microsec: 1,301 / microsec: 77

• With the new DELETE variant DELETE itab FROM...TO..., the task of deleting a sequence of lines can be transferred to the kernel.

Modifying selected components of an internal table
Modifying all components. / Modifying selected components only.
* Table TAB is filled with 5000 entries of 500 / * Table TAB is filled with 5000 entries of 500
* bytes each. Actually, only the 8 bytes of the / * bytes each. Only the 8 bytes of the selected
* component DATE are modified. / * component DATE are modified.
LOOP AT TAB. / WA-DATE = SY-DATUM.
TAB-DATE = SY-DATUM. / LOOP AT TAB.
MODIFY TAB. / MODIFY TAB FROM WA
ENDLOOP. / TRANSPORTING DATE.
ENDLOOP.
microsec: 6,919 / microsec: 2,717

• With the MODIFY variant MODIFY itab...TRANSPORTING f1 f2... the task of updating a line of an internal table can be accelerated.
• The longer the table line is, the larger the speed-up is. The effect increases for tables with complex structured line types.

Building a condensed, sorted table: READ/INSERT vs. COLLECT/SORT
COLLECT semantics using READ BINARY. / Collect via COLLECT.
* Table TAB_SRC is filled with 10,000 entries, / * Table TAB_SRC is filled with 10,000 entries
* 5,000 of which have different keys / * 5,000 of which have different keys
LOOP AT TAB_SRC. / LOOP AT TAB_SRC.
READ TABLE TAB_DEST / COLLECT TAB_SRC INTO TAB_DEST.
WITH KEY K = TAB_SRC-K / ENDLOOP.
BINARY SEARCH. / SORT TAB_DEST BY K.
IF SY-SUBRC = 0.
ADD: TAB_SRC-VAL1 TO
TAB_DEST-VAL1,
TAB_SRC-VAL2 TO
TAB_DEST-VAL2.
MODIFY TAB_DEST INDEX
SY-TABIX.
ELSE.
INSERT TAB_SRC INTO TAB_DEST
INDEX SY-TABIX.
ENDIF.
ENDLOOP.
microsec: 299,948 / microsec: 132,617

• If you need the COLLECT semantics, DO use COLLECT!
• READ BINARY runs in O(log²(n)) time, and the internal table's index must be adjusted with each INSERT.
• COLLECT, however, uses a hash algorithm and is therefore independent of the number of entries (ie. O(1)) and does not need to maintain a table index. If you need the final data sorted, sort it after all data has been collected.
• If the amount of data is small, the READ/INSERT approach isn't bad, but for larger amounts of data (>1000), COLLECT is much faster.
• Caution: When you fill an internal table, do not use COLLECT in combination with any other table-filling statements (APPEND, INSERT, MODIFY, SELECT * INTO TABLE and/or SELECT * APPENDING TABLE). If you mix COLLECT with the other statements, COLLECT cannot use its hash algorithm. In this case, COLLECT resorts to a normal linear search, which is dramatically slower: O(n).

Linear search vs. binary search
Linear search of an internal table. / Binary search of an internal table.
* Table TAB is filled with 1000 entries / * Table TAB is filled with 1000 entries
* of 100 bytes each. / * of 100 bytes each.
* The READ ends with SY-SUBRC = 4 / * The READ ends with SY-SUBRC = 4
READ TABLE TAB WITH KEY K = 'X'. / READ TABLE TAB WITH KEY K = 'X'
BINARY SEARCH.
microsec: 545 / microsec: 7

• If internal tables are assumed to have many (>20) entries, a linear search through all entries is very time-consuming.
• Try to keep the table ordered and use binary search.
• If TAB has n entries, linear search runs in O(n) time, whereas binary search takes only O(log²(n)).

Creating a secondary index to avoid linear search
No secondary index => linear search. / Binary search using secondary index.
* Table TAB is filled with 1000 entries. / * Table TAB is filled with 1000 entries.
* The READ locates the 500th entry. / * The READ locates the 500th entry.
READ TABLE TAB WITH KEY DATE = / READ TABLE TAB_INDEX
SY-DATUM. / WITH KEY DATE = SY-DATUM
IF SY-SUBRC = 0. / BINARY SEARCH.
" ... / IF SY-SUBRC = 0.
ENDIF. / READ TABLE TAB INDEX
TAB_INDEX-INDX.
" ...
ENDIF.
microsec: 268 / microsec: 10

• If you need access an internal table with different keys repeatedly, keep your own secondary indices.
• With a secondary index, you can replace a linear search with a binary search plus an index access.

Using an explicit work area instead of filling the header line
Table operation via header line. / Table operation via explicit work area.
* The line width of table TAB is 500 bytes. / * The line width of table TAB is 500 bytes.
TAB = TAB_WA. / APPEND TAB_WA TO TAB.
APPEND TAB.
microsec: 7 / microsec: 3

• Avoid unnecessary MOVEs by using the explicit work area operations
• APPEND wa TO tab.
• INSERT wa INTO tab.
• COLLECT wa INTO tab.
• MODIFY tab FROM wa.
• READ TABLE tab INTO wa.
• LOOP AT tab INTO wa.

where appropriate.