ch09.htm

这个是sap开发语言abap的教育文档

<PRE>
199802171234AB
199802171234AB
19980217 1234 A B
1998 02 17 12 34AB<BR>
</PRE>
</BLOCKQUOTE>
<P>
<IMG SRC="../button/analysis.gif" tppabs="http://pbs.mcp.com/ebooks/0672312174/button/analysis.gif">
<UL>
<LI>Lines 2 through 14 define two field strings composed entirely
of character type fields. Each field string is 14 bytes long in
total.
<LI>On line 15, <TT>s1</TT> is moved to <TT>s2</TT>, treating
each field string as if it is a single type <TT>c</TT> field 14
bytes long.
<LI>On lines 16 and 17, both are written out as character fields.
<LI>On lines 18 and 19, the components of each field string are
written out. <TT>s1-d1</TT> has been split across <TT>s2-y1</TT>,
<TT>m1</TT>, and <TT>d1</TT>. The first two bytes of <TT>s1-n1</TT>
went into <TT>s2-n1</TT>. The remaining bytes from <TT>s1</TT>
went to <TT>s2-c1</TT>.
</UL>
<H5>Moving from One Field String to Another with Numeric Data
Types</H5>

<IMG SRC="../button/newterm.gif" tppabs="http://pbs.mcp.com/ebooks/0672312174/button/newterm.gif">

<BLOCKQUOTE>
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 &quot;a four-byte integer must be
aligned on an even byte boundary.&quot; Thus, the rule to which
the address of a field conforms is called the <I>alignment</I>.
</BLOCKQUOTE>

<IMG SRC="../button/newterm.gif" tppabs="http://pbs.mcp.com/ebooks/0672312174/button/newterm.gif">

<BLOCKQUOTE>
In order to satisfy alignment requirements, a typical compiler
will insert <I>padding bytes</I> before a field that requires
alignment. For example, if your four-byte integer begins at offset
<TT>0003</TT> 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 <TT>0003</TT> so that the
integer begins at offset <TT>0004</TT>, causing it to be properly
aligned. Padding bytes are invisible to the programmer, but their
effects can be seen at times.
</BLOCKQUOTE>
<BLOCKQUOTE>
If you 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 you attempt to use
a <TT>move</TT> statement on such a field string to move its contents
to another, these padding bytes can cause unexpected results.
</BLOCKQUOTE>
<BLOCKQUOTE>
Therefore, you can only use <TT>move</TT> if one of the following
is true:

<UL>
<LI>Both field strings consist entirely of character fields (types
<TT>c</TT>, <TT>n</TT>, <TT>d</TT>, <TT>t</TT>, and <TT>x</TT>).
<LI>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).
</UL>

If both the sending and receiving fields are entirely composed
of character fields, no padding bytes will exist and the result
of using <TT>move</TT> is predictable. If there is a mixture of
character and numeric types, padding bytes might exist and the
result of using <TT>move</TT> can be unexpected. An example is
shown in Listing 9.11.<BR>
</BLOCKQUOTE>
<CENTER>
<TABLE BORDERCOLOR=#000000 BORDER=1>
<TR VALIGN=TOP><TD WIDTH=600><B>NOTE</B></TD></TR>
<TR VALIGN=TOP><TD WIDTH=600>
<BLOCKQUOTE>
The <TT>move-corresponding </TT>statement can be used to move field strings that have a mixture of character and numeric data types. It is described in the following section.
</BLOCKQUOTE>

</TD></TR>
</TABLE></center>

<p>
<img src="../button/input.gif" tppabs="http://pbs.mcp.com/ebooks/0672312174/button/input.gif">

<HR>
<P>
<B>Listing 9.11&nbsp;&nbsp;Padding Bytes Can Cause Unexpected
Results When Moving Data Between Field Strings<BR>
</B>
<BLOCKQUOTE>
<PRE>
 1 report ztx0911.
 2 data: begin of s1,
 3           c1 value 'A',             &quot;one byte

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

 7       begin of s2,
 8           c1,                       &quot;one byte
 9           c2(4),                    &quot;four bytes, no padding
10           c3,                       &quot;one byte
11           end of s2,
12       begin of s3,                  &quot;s3 matches s1 exactly:
13           x1,                       &quot;- data types the same
14           x2 type i,                &quot;- number of fields the same
15           x3,                       &quot;- fields in the same order
16           end of s3.                &quot;(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.
</PRE>
</BLOCKQUOTE>
<HR>
<P>
<IMG SRC="../button/output.gif" tppabs="http://pbs.mcp.com/ebooks/0672312174/button/output.gif">
<P>
On my system, the code in Listing 9.11 produces the following
output. In your system, results might vary for fields with invalid
assignments.
<BLOCKQUOTE>
<PRE>
A ###&quot; #
A      1,234  B
</PRE>
</BLOCKQUOTE>
<P>
<TT>s1-c1</TT> is only one byte long, so <TT>c2</TT> has an uneven
offset from the beginning of the field string and requires padding
on most systems, which makes <TT>s1</TT> longer than <TT>s2</TT>.
When <TT>s1</TT> is assigned to <TT>s2</TT>, <TT>c3</TT> does
not line up and some of <TT>s1-c2</TT> ends up at the beginning
of <TT>s2-c3</TT>. However, <TT>s3</TT> matches <TT>s1</TT> exactly,
so the move on line 14 works perfectly.
<P>
This example shows that you can't ignore the effects of having
numeric fields within a structure. The fact that each receiving
field has the same number of bytes as each sending field is not
enough to guarantee that the components will line up.
<P>
Alignment rules vary with the operating system, so the number
of padding bytes and their positions vary. The results of a <TT>move</TT>
on one operating system might be different on another. Therefore,
to ensure that your programs are portable, never rely on padding
bytes and don't consider them during moves. Each field string
must be composed entirely of character data types or all components
of each field string must match exactly (except for the name).
<H3><A NAME="UsingtheTTFONTSIZEmovecorrespondingFONTTTFONTSIZEStatementFONT">
Using the <TT><FONT SIZE=4>move-corresponding</FONT></TT><FONT SIZE=4>
Statement</FONT></A></H3>
<P>
To perform a move from one field string to another where the data
types and/or lengths do not match, use the <TT>move-corresponding</TT>
statement. It generates individual <TT>move</TT> statements for
components with matching names. Components in the receiving field
string that do not have a matching name in the sending field string
are not changed. Listing 9.12 illustrates.
<H4>Syntax for the <TT>move-corresponding</TT> Statement</H4>
<P>
The following is the syntax for the <TT>move</TT> statement. Operators
and operands must be separated by spaces. Multiple assignment
occurs from right to left.
<BLOCKQUOTE>
<PRE>
move-corresponding <I>v1</I> to <I>v2</I>.
</PRE>
</BLOCKQUOTE>
<P>
where:
<UL>
<LI><TT><I>v1</I></TT> is the
sending variable or field string.
<LI><TT><I>v2</I></TT> is the
receiving variable or field string.
</UL>
<P>
<P>
<IMG SRC="../button/input.gif" tppabs="http://pbs.mcp.com/ebooks/0672312174/button/input.gif">
<HR>
<P>
<B>Listing 9.12&nbsp;&nbsp;The </B><TT><B>MOVE-CORRESPONDING</B></TT><B>
Statement Generates Individual </B><TT><B>MOVE</B></TT><B>
Statements and Thus Performs Data Conversion<BR>
</B>
<BLOCKQUOTE>
<PRE>
 1 report ztx0912.
 2 data: begin of s1,
 3           c1    type p decimals 2 value '1234.56',
 4           c2(3)                   value 'ABC',
 5           c3(4)                   value '1234',
 6           end of s1,
 7       begin of s2,
 8           c1(8),
 9           x2(3)                   value 'XYZ',
10           c3    type i,
11           end of s2.
12 write: / 's1                          :', s1-c1, s1-c2, s1-c3.
13 write: / 's2 before move-corresponding:', s2-c1, s2-x2, s2-c3.
14 move-corresponding s1 to s2. &quot;same as coding the following two statements
15 * move s1-c1 to s2-c1.       &quot;performs conversion
16 * move s1-c3 to s2-c3.       &quot;performs conversion
17 write: / 's2 after  move-corresponding:', s2-c1, s2-x2, s2-c3.
</PRE>
</BLOCKQUOTE>
<HR>
<P>
<IMG SRC="../button/output.gif" tppabs="http://pbs.mcp.com/ebooks/0672312174/button/output.gif">
<P>
The code in Listing 9.12 produces this output:
<BLOCKQUOTE>
<PRE>
s1                          :         1,234.56  ABC 1234
s2 before move-corresponding:          XYZ          0
s2 after  move-corresponding: 1234.56  XYZ      1,234
</PRE>
</BLOCKQUOTE>
<P>
<IMG SRC="../button/analysis.gif" tppabs="http://pbs.mcp.com/ebooks/0672312174/button/analysis.gif">
<P>
Line 14 generates two <TT>move</TT> statements; for sake of clarity,
they are shown within comments on lines 15 and 16. Normally, you
cannot see these <TT>move</TT> statements; the system generates
and executes them automatically &quot;behind the scenes.&quot;
One <TT>move</TT> is generated for each component of the receiving
field string that has the same name as a component in the sending
field string. In this case, <TT>c1</TT> and <TT>c3</TT> have the
same names, so two <TT>move</TT>s are generated. Data conversions
are performed as they would be if you had coded these statements
yourself. The contents of <TT>c2</TT> are unchanged after the
<TT>move-corresponding</TT> completes.
<H3><A NAME="PerformingCalculations">
Performing Calculations</A></H3>
<P>
You can perform calculations using the following statements:
<UL>
<LI><TT>compute</TT>
<LI><TT>add</TT> or <TT>add-corresponding</TT>
<LI><TT>subtract</TT> or <TT>subtract-corresponding</TT>
<LI><TT>multiply</TT> or <TT>multiply-corresponding</TT>
<LI><TT>divide</TT> or <TT>divide-corresponding</TT>
</UL>
<H4>Using the <TT>compute</TT> Statement</H4>
<P>
<TT>Compute</TT> is the statement most commonly used to perform
calculations.<P>
<CENTER>
<TABLE BORDERCOLOR=#000000 BORDER=1>
<TR VALIGN=TOP><TD WIDTH=600><B>TIP</B></TD></TR>
<TR VALIGN=TOP><TD WIDTH=600>
<BLOCKQUOTE>
If two field strings match exactly, don't use <TT>move-corresponding </TT>to move the data from one to another. Use <TT>move</TT>, it's more efficient.
</BLOCKQUOTE>

</TD></TR>
</TABLE>
</CENTER>
<P>
<H5>Syntax for the compute Statement</H5>
<BLOCKQUOTE>
The following is the syntax for the <TT>compute</TT> statement.
Operators and operands must be separated by spaces. More than
one operator per statement is permitted.
</BLOCKQUOTE>
<BLOCKQUOTE>
<PRE>
compute <I>v3</I> = <I>v1</I> op <I>v2</I> [op <I>vn</I> ...].
</PRE>
</BLOCKQUOTE>
<BLOCKQUOTE>
or
</BLOCKQUOTE>
<BLOCKQUOTE>
<PRE>
<I>v3</I> = <I>v2</I> op <I>v2</I> [op <I>vn</I> ...].
</PRE>
</BLOCKQUOTE>

<P>
<blockquote>
where:
<UL>
<LI><TT><I>v3</I></TT> is the
receiving variable for the result of the computation.
<LI><TT><I>v1</I></TT>, <TT><I>v2</I></TT>,
and <TT><I>vn</I></TT> are the
operands.
<LI><TT><I>op</I></TT> is a mathematical
operator.
</UL>

Table 9.5 contains a list of the valid operators.<BR>
</BLOCKQUOTE>
<P>
<CENTER><B>Table 9.5&nbsp;&nbsp;Valid Operators for the </B><TT><B>COMPUTE</B></TT><B>
Statement</B></CENTER><CENTER>
<TABLE BORDERCOLOR=#000000 BORDER=1>
<TR VALIGN=TOP><TD WIDTH=96><CENTER><B>Operator</B></CENTER></TD><TD WIDTH=192><CENTER><B>Operation</B></CENTER>
</TD></TR>
<TR VALIGN=TOP><TD WIDTH=96><CENTER><TT>+</TT></CENTER></TD><TD WIDTH=192>Addition
</TD></TR>
<TR VALIGN=TOP><TD WIDTH=96><CENTER><TT>-</TT></CENTER></TD><TD WIDTH=192>Subtraction
</TD></TR>
<TR VALIGN=TOP><TD WIDTH=96><CENTER><TT>*</TT></CENTER></TD><TD WIDTH=192>Multiplication
</TD></TR>
<TR VALIGN=TOP><TD WIDTH=96><CENTER><TT>/</TT></CENTER></TD><TD WIDTH=192>Division
</TD></TR>
<TR VALIGN=TOP><TD WIDTH=96><CENTER><TT>**</TT></CENTER></TD><TD WIDTH=192>Exponentiation
</TD></TR>
<TR VALIGN=TOP><TD WIDTH=96><CENTER><TT>DIV</TT></CENTER></TD><TD WIDTH=192>Integer division
</TD></TR>
<TR VALIGN=TOP><TD WIDTH=96><CENTER><TT>MOD</TT></CENTER></TD><TD WIDTH=192>Remainder of integer division
</TD></TR>
</TABLE>
</CENTER>
<P>
<BLOCKQUOTE>
There are also built-in functions. For a list, obtain F1 help
for the keyword <TT>compute</TT>.
</BLOCKQU