Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Flat structures

Former Member
0 Kudos

Hi everyone,

How to move data between flat structures in unicode .

Thanks in advance

Shalu

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Hi,

For conversions between structured fields or a structured field and a single field, flat structures were previously treated like C fields. With the implementation of Unicode, this approach has become too error-prone since it is not clear if programs can be executed with platform-independent semantics.

Two fields are compatible if they have the same type and length. If deep structures are assigned, the fragment views must therefore be identical. One requirement in connection with the assignment and comparison of deep structures has been that type compatibility must exist between the operands which requires both operands to have the same structure. This requirement will continue to apply for Unicode systems.

To check whether conversion is permitted at all, the Unicode fragment view of the structures is set up initially by combining character and byte type groups and alignment gaps as well as any other components. If the type and length of the fragments of the source structure are identical in the length of the shorter structure, conversion is permitted. Assignment is allowed subject to the fulfillment of the following conditions:

The fragments of both structures up to the second-last fragment of the shorter structure are identical.

The last fragment of the shorter structure is a character or byte type group.

The corresponding fragment of the longer structure is a character or byte type group with a greater length.

If the target structure is longer than the source structure, the character-type components of the remaining length are filled with blank characters. All other components of the remaining length are filled with the type-adequate initial value, and alignment gaps are filled with zero bytes. Since longer structures were previously filled with blanks by default, using initial values for non-character-type component types is incompatible. This incompatible change is, however, rather an error correction. For reasons of compatibility, character-type components are not filled with initial values.

BEGIN OF struc1,

a(1) TYPE C,

x(1) TYPE X,

END OF struc1.

BEGIN OF struc2,

a(1) TYPE C,

b(1) TYPE C,

END OF struc2.

The assignment struc1 = struc2 is not allowed under Unicode since struc1-x in contrast to struc2-b occupies only one byte.

BEGIN OF struc3,

a(2) TYPE C,

n(6) TYPE N,

i TYPE I,

END OF struc3.

BEGIN OF struc4,

a(8) TYPE C,

i TYPE I,

f TYPE F,

END OF struc4.

The assignment struc3 = struc4 is allowed since the fragment views of the character-type fields and the integer are identical.

BEGIN OF struc5,

a(1) TYPE X,

b(1) TYPE X,

c(1) TYPE C,

END OF struc5.

BEGIN OF struc6,

a(1) TYPE X,

BEGIN OF STRUC3,

b(1) TYPE X,

c(1) TYPE C,

END OF struc3,

END OF struc6.

struc5 = struc6 is again not permitted since the fragment views of both structures are not identical due to the alignment gaps before struc3 and struc3-c.

BEGIN OF struc7,

p(8) TYPE P,

c(1) TYPE C,

END OF struc7.

BEGIN OF struc8,

p(8) TYPE P,

c(5) TYPE C,

o(8) TYPE P,

END OF struc8.

The assignment struc7 = struc8 works since the Unicode fragment views are identical with regard to the length of structure struc1.

For deep structures, the operand types must be compatible as usual. As an enhancement measure, we slightly generalized the convertibility in case of object references and table components.

reward if useful

2 REPLIES 2

Former Member
0 Kudos

Use Offset operation with length specification. Eg:

<wa>-fld1 = <wa_file>+0(10).
<wa>-fld2 = <wa_file>+10(6).
....

Former Member
0 Kudos

Hi,

For conversions between structured fields or a structured field and a single field, flat structures were previously treated like C fields. With the implementation of Unicode, this approach has become too error-prone since it is not clear if programs can be executed with platform-independent semantics.

Two fields are compatible if they have the same type and length. If deep structures are assigned, the fragment views must therefore be identical. One requirement in connection with the assignment and comparison of deep structures has been that type compatibility must exist between the operands which requires both operands to have the same structure. This requirement will continue to apply for Unicode systems.

To check whether conversion is permitted at all, the Unicode fragment view of the structures is set up initially by combining character and byte type groups and alignment gaps as well as any other components. If the type and length of the fragments of the source structure are identical in the length of the shorter structure, conversion is permitted. Assignment is allowed subject to the fulfillment of the following conditions:

The fragments of both structures up to the second-last fragment of the shorter structure are identical.

The last fragment of the shorter structure is a character or byte type group.

The corresponding fragment of the longer structure is a character or byte type group with a greater length.

If the target structure is longer than the source structure, the character-type components of the remaining length are filled with blank characters. All other components of the remaining length are filled with the type-adequate initial value, and alignment gaps are filled with zero bytes. Since longer structures were previously filled with blanks by default, using initial values for non-character-type component types is incompatible. This incompatible change is, however, rather an error correction. For reasons of compatibility, character-type components are not filled with initial values.

BEGIN OF struc1,

a(1) TYPE C,

x(1) TYPE X,

END OF struc1.

BEGIN OF struc2,

a(1) TYPE C,

b(1) TYPE C,

END OF struc2.

The assignment struc1 = struc2 is not allowed under Unicode since struc1-x in contrast to struc2-b occupies only one byte.

BEGIN OF struc3,

a(2) TYPE C,

n(6) TYPE N,

i TYPE I,

END OF struc3.

BEGIN OF struc4,

a(8) TYPE C,

i TYPE I,

f TYPE F,

END OF struc4.

The assignment struc3 = struc4 is allowed since the fragment views of the character-type fields and the integer are identical.

BEGIN OF struc5,

a(1) TYPE X,

b(1) TYPE X,

c(1) TYPE C,

END OF struc5.

BEGIN OF struc6,

a(1) TYPE X,

BEGIN OF STRUC3,

b(1) TYPE X,

c(1) TYPE C,

END OF struc3,

END OF struc6.

struc5 = struc6 is again not permitted since the fragment views of both structures are not identical due to the alignment gaps before struc3 and struc3-c.

BEGIN OF struc7,

p(8) TYPE P,

c(1) TYPE C,

END OF struc7.

BEGIN OF struc8,

p(8) TYPE P,

c(5) TYPE C,

o(8) TYPE P,

END OF struc8.

The assignment struc7 = struc8 works since the Unicode fragment views are identical with regard to the length of structure struc1.

For deep structures, the operand types must be compatible as usual. As an enhancement measure, we slightly generalized the convertibility in case of object references and table components.

reward if useful