The MOVE opcode was great for converting numeric data into character. That is, it was great at moving numeric data to a character field. MOVE does something that isn't directly supported by the EVAL opcode; it allows you to move the data and zero-fill the result. EVAL can't do this.
The EVAL opcode does not allow you to copy numeric fields to character fields, nor does it allow you to copy character fields containing numbers into numeric fields. MOVE always supported this capability.
Many people use the %CHAR built-in function to circumvent this shortcoming, as follows:
D nItem S 5P 0 Inz(208)
C eval szText = %char(nItem)
The code above results in szText containing '208 ' (the number 208 left-justified in the szText field and followed by two blank characters).
Since V5R2, you can copy the value in szText to nItem using the %DEC or %INT built-in functions, as follows:
D nItem S 5P 0
C eval nItem = %Dec(szText)
But how do you replace the MOVE feature that would produce '00208' when copying nItem to szText?
The answer is %EDITC(). This built-in function applies the indicated edit code to the numeric value and then copies the result as text to the target field. Here's an example:
D nItem S 5P 0 Inz(208)
C eval szText = %EditC(nItem:'X')
The above example results in szText containing '00208'.
(Note: The 'X' edit code is an RPG-specific edit code and is not available if you're using DDS or other editing tools, such as the "Edit" APIs.)
If you want to ensure that the result is right-justified and zero-filled, use the EVALR opcode, as follows:
D nItem S 5P 0 Inz(208)
C evalR szText = %EditC(nItem:'X')
The EVALR opcode was introduced in V4R2, so it is virtually available on all iSeries systems today.
What about negative numbers? What happens in the following example code?
D szText5 S 5A
D szText6 S 6A
D szText7 S 7A
D nItem S 5P 0 Inz(-208)
C eval szText4 = %EditC(nItem:'X')
C eval szText5 = %EditC(nItem:'X')
C eval szText6 = %EditC(nItem:'X')
C eval szText7 = %EditC(nItem:'X')
The results from the above example would set the fields szText4 to szText7 to the following values:
Field | Value |
szText4 | 0020 |
szText5 | 0020Q |
szText6 | 0020Q_ |
szText7 | 0020Q__ |
Note that in szText4, the minus sign and the low-order digit are truncated, but in all other fields, the letter "Q" is used as the minus sign. This is a shortcoming in the 'X' edit code; there really isn't a way to have it embed a minus sign. But you can do it manually, as follows:
D nItem S 5P 0 Inz(-208)
D szSign S 1A Inz Varying
C if nItem < 0
C eval nItem = %abs(nItem)
C eval szMinus = '-'
C endif
C eval szText = szSign + %EditC(nItem:'X')
This example causes szText to contain '-00208' left-justified.
The last problem is when the numeric value contains decimal digits. The 'X' edit code ignores decimal positions, so you again have to do it yourself. Here's one technique that I came up with:
D nSales S 7P 2 Inz(-208.50)
D szMinus S 1A Inz Varying
C if nSales< 0
C eval nSales= %abs(nSales)
C eval szMinus = '-'
C endif
C eval szText = szMinus +
C %EditC(nSales:'X')
C eval szText = %subst(szText:1:
C %Len(%trimR(szText)) -
C %DecPos(nSales))
C + '.' +
C %subst(szText:
C %Len(%trimR(szText)) -
C %DecPos(nSales)+1)
This may not be elegant, but it works. The result is '-00208.50' left-justified in the szText field. The technique incorporates the %DECPOS built-in function that extracts the number of decimal positions for the corresponding field.
You can move numeric to character fields and get the data in just about any format you want. You just have to work at it a little.
Bob Cozzi is a programmer/consultant, writer/author, and software developer of the RPG xTools, a popular add-on subprocedure library for RPG IV. His book The Modern RPG Language has been the most widely used RPG programming book for nearly two decades. He, along with others, speaks at and runs the highly-popular RPG World conference for RPG programmers.
LATEST COMMENTS
MC Press Online