Overview
1. Accessing single fields
2. Accessing structures
3. Passing parameters to subroutines
4.
Accessing field symbols using offset and length addressing
5. Accessing field symbols using offset addressing without specifying length
Offset and length specifications are generally critical, since the length of each character is platform-specific.
Thus it is not immediately clear, particularly in a mixed structure, whether the unit being addressed
is a byte or a character. This forced us to impose several serious restrictions, outlined below. However,
subject to these restrictions, you can still use offset and length addressing. The statements affected
are those used to: access single fields; access structures; pass parameters to subroutines; and work with field symbols.
The system supports offset and length access for character-type single fields, strings, and single fields of types X and XSTRING. For character-type fields and fields of type STRING, offset and length are interpreted on a character-by-character basis. For types X and XSTRING, the values for offset and length are interpreted in bytes.
Offset and length access to structured fields is a programming technique that should be avoided. This access type results in errors if both character and non-character type components exist in the area identified by offset and length.
Offset and length access to structures is only permitted in a Unicode program if the structures are flat and the offset/length specification includes only character-type fields from the beginning of the structure. The example below shows a structure with character-type and non-character type fields. Its definition in the ABAP program and the resulting assignment in the main memory is as follows:
BEGIN OF STRUC,
a(3) TYPE
C, "length 3 characters
b(4) TYPE
N, "length 4 characters
c
TYPE D, "length 8 characters
d
TYPE T, "length 6 characters
e
TYPE F, "length 8 bytes
f(28)
TYPE C, "length 28 characters
g(2) TYPE
X, "length 2 bytes
END OF STRUC.
The Unicode fragment view splits the structure into four fragments, F1 to F5:
[ aaa | bbbb | cccccccc | ddd | AAA | eeee
| fffffffffffff | gg ]
[
F1
| F2 | F3 | F4 | F5 ]
In this case, you can only use offset and length access in the first fragment, F1. Accesses like struc(21) or struc+7(14) are accepted by the ABAP interpreter and treated like a single field of type C. By contrast, struc+57(2) access is now only allowed in a non-Unicode program.
If offset/length access to a structure is permitted, both the offset and length specifications are generally interpreted as characters, in a Unicode program.
Hinweis
C fields or structures are frequently used as containers for storing structures of different types,
which are often not known until runtime. Subcomponents of the structure are then selected in offset/length
accesses to the container. This technique no longer works with Unicode. Instead you can create suitable
containers at runtime using CREATE
DATA
. Alternatively, you can use ASSIGN
... CASTING with a field symbol to view an existing memory area as a container with the
appropriate type. You can edit it using ASSIGN COMPONENT ... with index or field name.
Until now, passing parameters using PERFORM has allowed you to use offset and length addressing beyond field boundaries. In future, this will no longer be allowed in Unicode programs. In Unicode programs, offset and length-based access beyond field boundaries returns a syntax or runtime error. For example, access types c+15 or c+5(10) would trigger such an error for a ten-digit C field c.
Previously, if you specified an offset but no length for a parameter, the entire length of the field was accessed, instead of the remaining length. Now if you attempt to do this in a Unicode program, the system wil return a syntax error - since the parameter crosses the field boundary if you only use an offset. Thus you cannot use PERFORM test USING c+5.
Also in Unicode programs, you can continue to specify the remaining length starting from the offset off for parameters using the form field+off(*).
InUnicode programs, you can only use offset and length access in an ASSIGN statement within a predefined range. Normally, this range corresponds to the field boundaries in case of elementary fields or, in flat structures, to the purely character-type starting fragment. Using a special RANGE addition for ASSIGN, you can expand the range beyond these boundaries. For more information, see Assignments to Field Symbols
Field symbols are assigned a range allowed for offset/length specifications. If the source of an ASSIGN statement is specified using a field symbol, the target field symbol adopts the range of the source. If not explicitly specified otherwise, the RANGE is determined as follows:
If the assignment to the field symbol is not possible because the offset or length specification exceeds
the range permitted, the field symbol is set to UNASSIGNED in
a Unicode program. Other checks such as type or alignment checks return a runtime error in a Unicode
program. As a rule, offset and length specifications are counted in characters for data types C, N, D, and T as well as for flat structures, and in bytes in all other cases.
Until now, the behavior of the ASSIGN feld+off TO<fs> variant was unusual, in that the field length was used to address the field or field symbol, not the remaining length - if you specified an offset but not length. Since an ASSIGN statement with a cross-field offset causes problems in Unicode, you must observe the following rules:
As previously, the field length of field is used as the length. Using ASSIGN field+off(*)... you can explicitly specify the remaining length .
You can only use ASSIGN
Generally, you cannot generally use the syntax ASSIGN field+off TO
These rules will also enable you, in Unicode programs, to pass a field symbol through an elementary
field using ASSIGN <fs>+n TO <fs>, as in a loop, for example.
Note
In the context of Structure Enhancements you should be aware of the categories used in the Dictionary.