Adding Field Sequences
Creating Subroutines
Saving Programs
Assigning Types for GET/SET PARAMETER
Unreachable Statements
Function Modules with Incorrect Parameter Names
Previously, the system checked for the bit statements SET BIT i OF f [TO g] and GET BIT i OF f [INTO g]whether the field f is character-type; X fields, X strings, and flat structures are usually regarded as character-type. For Unicode programs this is no longer useful, because the types X and XSTRING no longer count as character-type and the bit by bit access to character-type fields or structures is no longer platform-independent. Therefore, with these operations in Unicode programs, the field f must be type X or XSTRING.
For the bit mask operations f O x, f Z x, and f M x you could previously use all number-type and hence all character-type types for the left operand f. In Unicode programs, the f operand must now be type X or XSTRING.
When adding field sequences, restrictions apply to the following statements in Unicode:
ADD n1 THEN n2 UNTIL nz [ ACCORDING TO sel ] GIVING m ...
ADD n1 THEN n2 UNTIL nz TO m [ RANGE str ].
ADD n1 FROM i1 GIVING m [ RANGE str ].
Loops with the VARY or VARYING addition are also problematic in Unicode, since a type-a access to memory contents cannot be ensured and memory can be overwritten inadvertently.
DO ... VARYING f FROM f1 NEXTf2.
For this statement, the fields f, f1, and f2 must be type-compatible with each other. To prevent memory contents being overwritten, a RANGE for valid accesses is introduced implicitly or explicitly for the following statements:
DO ... TIMES VARYING f FROM f1 NEXT f2 [ RANGE f3 ].
WHILE ... VARY f FROM f1 NEXTf2 [ RANGE f3 ].
A syntax or runtime error is caused if f1 or f2 are not included in f3. If the RANGE addition is missing, it is defined implicitly from FROM f1 NEXT f2 as follows:
If you specify a deep structure as the RANGE addition, the system checks for every loop pass that there are no field references, object references, tables, or strings in the area read.
When automatically generating subroutines using the statement GENERATE SUBROUTINEPOOL itab NAME name, the generated program inherits the content of the Unicode flag of the generating program.
When automatically generating programs using the statement INSERT REPORT prog FROM itab, default values are set for the TRDIR entry as before. Amongst other things, this statement has the new addition UNICODE ENABLING uc, with which the Unicode flag of the inserted report receives the value of uc. If this addition is missing, the following applies:
A Unicode program creates a Unicode program.
A non-Unicode program in turn creates a non-Unicode program.
A non-Unicode program becomes a Unicode program if it is overwritten by a Unicode program.
A Unicode program remains a Unicode program if it is overwritten by a non-Unicode program.
For the statements GETPARAMETER ID pid FIELD f andGETPARAMETER ID pid FIELD f, f must be character-type. You can use the EXPORT and IMPORT statements for storing non-character-type fields and structures.
In Unicode programs, unreachable statements cause a syntax error. In non-Unicode programs, there was previously only a syntax warning.
In Unicode programs, calling a function module, whose parameter names are specified statically as a literal or constant, causes an exception that can be handled if an incorrect parameter name was specified. This only applies to function modules that are not called via Remote Function Call. In non-Unicode programs, an incorrect name was previously ignored.