That is not so. "bbbbbb-79349" is recognized as 79349 when assigned to a
packed field.
Even though the debugger shows the "-" sign, it doesn't actually convert
the value to a negative number when used in any calculation.
What Barbara said was also "interesting". Since the hex value was X'60',
the zone-to-packed conversion ignored the x'6' portion and only looked
at the second number (X'#0" where the # is ignored). This is what I
found in my testing when I the hex values where X'40', which also passed
a decimal assignment to packed from zoned.
My suggestion assumes the field is an actual character field being
converted to numeric. It won't work if the field in the data structure
is left as Zoned.
Chris Hiebert
Programmer/Analyst
Disclaimer: Any views or opinions presented are solely those of the
author and do not necessarily represent those of the company.
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Monday, May 13, 2013 8:48 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Eval-corr
On 13 May 2013 06:23, Florin Todor wrote:
<<SNIP>> my work-around was this:
if DS_HRESD01.D1CHGAMT < 0;
DS_DETD01 *= (-1);
endif;
and it worked. So, the subfield DS_HRESD01.D1CHGAMT is recognized as a
negative value;
While I was originally going to describe the effect for the
presentation by debug as "disturbing" [the term /interesting/ is far too
complacent sounding toward the debugger; just look at the confusion it
caused], I would find the above claim for the effects from the RPG
comparison to be even more disturbing... if I understand correctly.
Does that claim imply that the 12 byte string [with character b
representing blanks] 'bbbbbb-79349', when stored in a zoned decimal
variable, will compare as less than a zero value? Please tell me that
is not so!
Regards, Chuck
midrange.com
