Re: Convert character to decimal

Thanks to everyone who responded.
The field in question came from a database file and was a character
representation of a 10.5 numeric field.
The decision to make the field a character was to avoid having to recompile
all of the programs that may write to the file if the field changed.
I have spoken with the designer and we agreed that by making this a signed
field, that the issue can be avoided and any program needing the field will
always have it in the proper format.

I recall that I had a similar issue in the past, but with a field that was
passed from a web application that had to be converted and I used the DS
overlay method to resolve it.

Again, thanks for all of the suggestions.



On Mon, Mar 18, 2013 at 7:30 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

On 18 Mar 2013 14:30, Jeff Young wrote:

I have a character representation of a numeric field whose value
is '0009671180'. This represents 96.71180.

FWiW, IMO far too little is known about the alpha variable and how
that value is set\obtained. Most responses given in this thread seem to
presume that the specific example given, which alludes but does not
explain explicitly, that the character variable will always and only
contain 10 zoned _digits_ of the EBCDIC values x'F0' through x'F9'.
While Henrik gave an example that is an apparent exception to that
presumption, there is no explanation as to why one should expect other
possible values to be functional, and what are the bounds for its
remaining functional.

Because the builtin shown being used [i.e. %DEC()] supports
conversion from a character-string representing a decimal value [which
could include sign and decimal point], values other than those like the
one provided as an example could be expected to be supported... but how
would we know? If for example the value of the character variable was
'0096.71180', ¿one might expect that? the division by 100000 might be
inappropriate, yet the code could produce a [likely unexpected] result
with no error.

If the value is alpha representation of zoned decimal data [e.g. from
a DS], then a more appropriate resolution is an [effective] overlay of
that data with a zoned decimal variable. That would also ensure that
negative values were handled properly. But then, as Gary alludes, the
division is unwanted because the type\length attributes of the variable
defined in the overlay can implicitly resolve the precision\scale of the
data.

--
Regards, Chuck
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.