On 09-Nov-2014 10:54 -0600, DrFranken wrote:
On 11/7/2014 2:24 PM, CRPence wrote:
On 07-Nov-2014 11:55 -0600, Mohan Eashver wrote:
I have a character variable with numeric data. This holds number
of copies that will be used on the OVRPRTF command.
DCL VAR(©CHR) TYPE(*CHAR) LEN(1) VALUE('3')
DCL VAR(&COPIES) TYPE(*DEC) LEN(1 0) VALUE(1)
CHGVAR VAR(&COPIES) VALUE(©CHR)
OVRPRTF FILE(WGTMNFP) MAXRCDS(*NOMAX) HOLD(*YES) COPIES(&COPIES)
<<SNIP>>
There is no reason to perform that conversion; thus no reason
also, for the Decimal variable. Just use the Character variable as
the value specified on the COPIES() parameter:
DCL VAR(©CHR) TYPE(*CHAR) LEN(1) VALUE('3')
OVRPRTF FILE(WGTMNFP) MAXRCDS(*NOMAX) HOLD(*YES) COPIES(©CHR)
<<SNIP>>
If you DO want to convert a variable in that manner however the
correct method is
CHGVAR &COPIES %DEC(©CHR 1 0)
Here the 1 indicates total number of places and 0 indicates number
of decimal places.
At first glance, that seemed to muddle RPG built-in function syntax
with what is available with the CL. But I see the above syntax is new
with v7r2.
The CL Change Variable (CHGVAR) has always enabled implicit
conversion from character into the numeric data types; the precision and
scale of the target variable named in the VAR() parameter determines the
decimal result precision, but the decimal separator in the character
string determine original precision before the assignment. Thus, the
implicit data conversion is also "correct":
<
http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_71/cl/chgvar.htm>
_Change Variable_ (CHGVAR)
"... implicit conversion between decimal and character values is
performed by the rules given in the VALUE parameter description.
...
_Coding Character Values for Decimal Variables_
When a character value is specified for a decimal variable:
• Only the digits 0 through 9, a decimal point (specified as either
a period or a comma), and a plus sign (+) or minus sign (-) can be used.
• If a plus sign or minus sign is specified, it must be placed
immediately in front of (no blanks between) the first digit in the
character value. If no sign character is specified, the value is
converted as a positive value.
• The number of decimal positions in the converted result is
determined by the decimal point specified in the character value. If no
decimal point is specified, it is assumed to be to the right of the last
digit in the converted value.
• Decimal alignment occurs in the converted result. The number of
decimal positions in the converted result is determined by the number
declared for the variable. If the specified character value has more
decimal positions than the declared variable, the extra positions on the
right are truncated. If the integer portion of the character value has
more digits than that declared for the variable, an error message is
sent to the user.
..."
With IBM i 7.2 the CL is apparently extended with the %DEC built-in
function (BIF):
<
http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_72/rbam6/rbam6decbif.htm>
%DEC _built-in function_
"%DEC converts character, logical, decimal, integer, or unsigned integer
data to packed decimal format. ...
...
If the convert-argument parameter is a character variable, the following
rules apply:
• The sign is optional. It can be '+' or '-'. It can precede or
follow the numeric data.
• The decimal point is optional. It can be either a period or a comma.
• Leading and trailing blanks are allowed in the data.
For example, ' +3 ' is a valid parameter.
• All-blank value will return a zero value.
• If invalid numeric data is found, an exception occurs with CPF0818.
..."
The above /enhanced/ capabilities from the BIF should be examined for
benefits or potentially detrimental effects as compared\contrasted with
what the implicit conversion offers; i.e. do not just blindly change to
use %DEC [for existing or new CHGVAR], with an expectation the results
of the BIF will mimic the effect with implicit conversion from *CHAR to
numeric.
midrange.com
