Overview
1. Field symbols
2. STRUCTURE
3. LIKE
4. INCLUDES
If you define the types of field symbols using
FIELD-SYMBOLS <f>STRUCTURE s DEFAULT wa and
they are later assigned a data object
wa using ASSIGN wa TO <f>
...
, in non-Unicode programs both statements are checked to see that wa
is at least as long as
s and wa satisfies the alignment requirements of s at runtime.
If parameter types in function modules or subroutines are defined using FORM form1USING/CHANGING arg STRUCTURE s ... or FORM form2 TABLES itab_a STRUCTURE s ...and the parameters are passed actual parameters with PERFORM form1 USING/CHANGING wa or PERFORM form2 USING/CHANGING itab_b, the non-Unicode program also only checks that wa (or the line type of itab_b) is at least as long as s, and that wa (or the line type of itab_b) satisfies the alignment requirements of s. The same is true for function module parameters whose types are defined with STRUCTURE.
The following extra rules are checked in a Unicode program after defining the type with STRUCTURE when assigning data objects, i.e. for the DEFAULT addition in the FIELD-SYMBOLS statement, for ASSIGN and when passing actual parameters.
If the type of an argument in a function module was defined using ... LIKE struc, where struc is a flat structure, the non-Unicode program only checks that the argument is a flat structure with the same length when the parameters are passed. In the Unicode program, it also checks that the fragment views of the current and formal parameters are the same.
Furthermore, two structures of which one or both contain Includes, are only compatible if the alignment gaps caused by the Include are the same on all platforms. In the following example, struc1 and struc2 are not compatible because a further alignment gap occurs in the Unicode system before the INCLUDE:
BEGIN OF struc1, BEGIN
OF struc2, BEGIN OF struc3,
a(1) TYPE X, a(1)
TYPE X., b(1) TYPE X,
b(1) TYPE X, INCLUDE
struc3. c(1) TYPE C,
c(1) TYPE C,
END OF struc2. END OF struc3.
END OF struc1.
Since the type compatibility can differ in a Unicode program and an non-Unicode program, the type compatibility
rules of the calling program are valid in an non-Unicode system for checking the parameters. This means
that if an non-Unicode program calls a Unicode program, the type compatibility is defined as in the
non-Unicode program. Vice versa, the Unicode check is activated if a Unicode program calls a non-Unicode program.
Note
In the context of Structure Enhancements you should be aware of the categories used in the Dictionary.