Other Changes Relating to Unicode

Overview

1. Bit statements
2. Adding field strings
3. Loops with the VARY and VARYING additions
4. Generating subroutines
5. Saving programs
6. Types and GET/SET PARAMETER ...



1. Bit statements

SET BIT i OF f [TO g].
GET BIT i OF f [INTO g].

Until now, there was a check in these statements to see if field f is character-type, where normally X fields, X strings, and flat structures were also seen as character-type. This is no longer meaningful in a Unicode program because, on the one hand, the types X and XSTRING are no longer regarded as character-type, and, on the other hand, bit-by-bit access to character-type fields or structures is no longer platform-independent. In a Unicode program, field f must therefore be of type X or XSTRING for these operations.

f O x, f Z x, and f M x

Until now, all number-type and thus all character-type types were permitted in the bit mask operations f O x , f Z x, and f M x for the left operand f. Operand f must now be type X or XSTRING in a Unicode program.



2. Adding field strings

ADD n1 THEN n2 UNTIL nz [ ACCORDING TO sel ] GIVING m [RANGE str ]
ADD n1 THEN n2 UNTIL nz TO m [ RANGE str ].

When adding field strings, there are certain restrictions in Unicode programs for the following statements:

ADD n1 FROM i1 GIVING m [ RANGE str ].

The field n1 must be within a structure. If this is not statically recognizable, the structure must be explicitly defined with the RANGE addition.

At runtime, the system also checks for this variant whether n1 and the addressed values are within the structure.



3. Loops with the VARY and VARYING additions

Loops with the VARY or VARYING addition can also cause problems in Unicode, because, on the one hand, you cannot be sure that you are accessing memory contents with the correct type and, on the other hand, memory could be inadvertently overwritten.

DO ... VARYING f FROM f1 NEXT f2 [ RANGE f3 ].
WHILE ... VARY f FROM f1 NEXT f2 [ RANGE f3 ].

With these statements, the fields f, f1, and f2 must be type-compatible with one another.

To avoid overwriting memory contents, a RANGE for valid accesses is implicitly or explicitly implemented for these statements

If the RANGE f3 addition is specified, a syntax or runtime error is triggered, should f1 or f2 not be included in f3. For f3, only structures and elementary fields of the types C, N, or X are permitted.

If the RANGE addition is not specified, it is implicitly defined with FROM f1 NEXT f2 as follows:

If a deep structure is defined as a RANGE addition, the system checks for every loop pass that there are no field references, object references, tables, or strings within the accessed range.



4. Generating subroutines

When subroutines are generated automatically using the GENERATE SUBROUTINE POOL itab NAME name statement, the generated program inherits the contents of the Unicode flag of the generating program.



5. Saving programs

When programs are generated automatically using the INSERT REPORT prog FROM itab ... statement, default values are set for the TRDIR entry as usual. However, this statement now includes (among others) a new addition, UNICODE ENABLING uc, with which the Unicode flag of the inserted report is given the value of uc. If this addition is not specified, the following applies:

  1. A Unicode program creates another Unicode program
  2. A non-Unicode program in turn creates another non-Unicode program
  3. A non-Unicode program becomes a Unicode program if it is overwritten by a Unicode program
  4. A Unicode program stays a Unicode program if it is overwritten by a non-Unicode program



6. Types and GET/SET PARAMETER ...

With the statements GET PARAMETER ID pid FIELD f and SET PARAMETER ID pid FIELD f f must be character-type. Use the EXPORT and IMPORT statements to store non-character-type fields and structures.