JULY 26

Example programs to understand and implement the concepts of move statement.

Using move with Field Strings:

With move, a field string name specified without a component name is treated as if it were a variable of type c. 

Example:

The MOVE Statement Treats a Field String Name without a Component Name like a Variable of Type C 

 1 report ztx0908.
 2 data: f1(4) value 'ABCD',
 3       begin of s1,
 4           c1(1),
 5           c2(2),
 6           c3(1),
 7           end of s1.
 8 s1 = f1.                         "s1 is treated as a char 4 variable
 9 write: / s1,                     "writes ABCD
10        / s1-c1, s1-c2, s1-c3.    "writes A BC D

Output:

ABCD 

A BC D
Description:

• Line 2 defines f1 as a four-byte variable of type c.
• Lines 3 through 7 define s1 as a field string having three components: f1, f2, and f3. The total length of s1 is calculated by totaling the lengths of its components: 1+2+1=4.
• Line 8 moves the value from f1 to s1 byte by byte, as if they were both variables of type c.
• Line 9 writes s1 out as a four-character variable.
• Line 10 writes out the contents of the components of s1.

Field String Moves Involving Numeric Fields

If the sending field is category character (types c, n, d, t, or x) and the target is a field string containing a numeric field (types i, p, or f), no data conversion is performed. The move proceeds as if both were purely character. The reverse is also true. No conversions are performed when moving a numeric to a field string containing a character field. In both cases, the results are invalid and are undefined.

Following shows a sample program that make an invalid conversion of a numeric field to a character field string.

 Example:
Moving a Numeric Field to a Character Field String Is Invalid

 1 report ztx0909.
 2 data: fc(5) type c,
 3       begin of s,
 4            fi type i,
 5            end of s.
 6
 7 fc = '1234'.
 8 s = fc.           "c<-c, no conversion performed
 9 write s-fi.       "writes junk
10
11 s-fi = 1234.      "assign a valid value
12 fc = s.           "c<-c, no conversion performed
13 write / fc.       "writes junk
14
15 s-fi = 1234.      "assign a valid value
16 fc = s-fi.        "c<-i conversion performed
17 write / fc.       "writes 1234

Output:

875770,417
"### 

1234
Description:

• On line 2, f1 is defined as an integer having a value of 1234.
• On lines 3 through 5, s1 is defined as a single component c1 type c length 12.
• On line 6, f1 is moved to s1. No conversion is performed because s1 is a field string, so it is treated like type c.
• On line 7, s1-c1 is written out and the results are garbage.
• On line 8, s1-c1 is assigned a valid character string '1234'.
• On line 9, s1 is moved to f1. No conversion is performed.
• Line 10 writes out f1, and again, the results are garbage.
• On Line 11, f1 is assigned a valid value of 1234.
• On line 12, f1 is assigned to s1-c1. Because the assignment is to the component and not to the field string, conversion is performed and line 13 writes out a valid value.

Moving from One Field String to Another Using Character Data Types

 We can use the move statement on two field strings if both strings contain components of only character data types (c, n, d, t, and x). The following program illustrates this concept.

Example-1:
Using MOVE with Two Field Strings Composed Entirely of Valid Character Data Types

 1 report ztx0910.
 2 data: begin of s1,
 3           d1     type d value '19980217',   "8 bytes
 4           n1(4)  type n value '1234',       "4 bytes
 5           c1            value 'A',          "1 byte
 6           c2            value 'B',          "1 byte
 7           end of s1,
 8       begin of s2,
 9           y1(4)  type n,                    "4 bytes
10           m1(2)  type c,                    "2 bytes
11           d1(2)  type n,                    "2 bytes
12           n1(2)  type c,                    "2 bytes
13           c1(4)  type c,                    "4 bytes
14           end of s2.
15  s2 = s1.
16  write: / s1,
17         / s2,
18         / s1-d1, s1-n1, s1-c1, s1-c2,
19         / s2-y1, s2-m1, s2-d1, s2-n1, s2-c1.

Output:

199802171234AB
199802171234AB
19980217 1234 A B 

1998 02 17 12 34AB
Description:

• Lines 2 through 14 define two field strings composed entirely of character type fields. Each field string is 14 bytes long in total.
• On line 15, s1 is moved to s2, treating each field string as if it is a single type c field 14 bytes long.
• On lines 16 and 17, both are written out as character fields.
• On lines 18 and 19, the components of each field string are written out. s1-d1 has been split across s2-y1, m1, and d1. The first two bytes of s1-n1 went into s2-n1. The remaining bytes from s1 went to s2-c1.

Moving from One Field String to Another with Numeric Data Types

Most operating systems require the machine address of numeric fields to conform to specific rules. For example, the address of a four-byte integer might be required to be divisible by two. That rule is often stated as "a four-byte integer must be aligned on an even byte boundary." Thus, the rule to which the address of a field conforms is called the alignment.

In order to satisfy alignment requirements, a typical compiler will insert padding bytes before a field that requires alignment. For example, if our four-byte integer begins at offset 0003 from the beginning of a program, a padding byte is necessary to align it on a two-byte boundary. The compiler will place an unused byte at offset 0003 so that the integer begins at offset 0004, causing it to be properly aligned. Padding bytes are invisible to the programmer, but their effects can be seen at times.

If we create a field string having a mixture of character and numeric fields, padding bytes are sometimes inserted by the system to bring numeric fields into alignment. If we attempt to use a move statement on such a field string to move its contents to another, these padding bytes can cause unexpected results.

Therefore, we can only use move if one of the following is true:

• Both field strings consist entirely of character fields (types c, n, d, t, and x).
• The data types, lengths, and position of all components in both field strings match exactly (the names of the components do not have to match).

If both the sending and receiving fields are entirely composed of character fields, no padding bytes will exist and the result of using move is predictable. If there is a mixture of character and numeric types, padding bytes might exist and the result of using move can be unexpected.

An example is shown below:

Example:
Padding Bytes Can Cause Unexpected Results When Moving Data Between Field Strings

 1 report ztx0911.
 2 data: begin of s1,
 3           c1 value 'A',             "one byte

 4           c2 type i value 1234,     "four bytes, usually needs padding
 5           c3 value 'B',             "one byte
 6           end of s1,

 7       begin of s2,
 8           c1,                       "one byte
 9           c2(4),                    "four bytes, no padding
10           c3,                       "one byte
11           end of s2,
12       begin of s3,                  "s3 matches s1 exactly:
13           x1,                       "- data types the same
14           x2 type i,                "- number of fields the same
15           x3,                       "- fields in the same order
16           end of s3.                "(names don't have to match)
17 s2 = s1.
18 write: / s2-c1, s2-c2, s2-c3.
19 s3 = s1. 

20 write: / s3-x1, s3-x2, s3-x3
Output:

A ###" # 

A 1,234 B.
Description:
s1-c1 is only one byte long, so c2 has an uneven offset from the beginning of the field string and requires padding on most systems, which makes s1 longer than s2. When s1 is assigned to s2, c3 does not line up and some of s1-c2 ends up at the beginning of s2-c3. However, s3 matches s1 exactly, so the move on line 14 works perfectly.

.