Hi Michael,
I found that the unsigned PositiveValue was indeed causing issues.
Changing PositiveValue to 3i 0 (option 1)
That'd work, as long as you didn't need PositiveValue to store numbers
up to 255.
Alleviated the problem. Leaving PositiveValue at 3u 0 and using the
assignment " NegativeValue = %int(PositiveValue) - 21;" (2a)
Alright... this comment surprised me. So I tried it, I took your
example (which had several syntax errors in it) and fixed it up and
tried it... and it works just fine for me. No errors! Here's the code
I was running, copy/pasted verbatim:
D PositiveValue s 3u 0
D NegativeValue s 3i 0
/free
PositiveValue = 3;
NegativeValue = %int(PositiveValue) - 21;
*inlr = *on;
/end-free
Are you saying that on your box, this code crashes/halts?! It doesn't
for me. And it shouldn't, based on my understanding of intermediate
results.
The original issue is that you had nothing on the right-hand side to
make the intermediate result a signed result. You had this:
NegativeValue = PositiveValue - 21;
...which is....
NegativeValue = (Unsigned Int) - 21.
Since there's nothing to indicate a signed result on the right-hand side
of the equation, the intermediate result should be unsigned -- so it
crashes. That makes perfect sense.
Likewise, if you did this (as suggested by Alan):
NegativeValue = %int(PositiveValue - 21);
This actually doesn't change anything, and should report the same error,
because the phrase 'PositiveValue - 21' is STILL unsigned, and therefore
can't go negative. Granted, that unsigned value is now going to be
converted to a signed one -- but that won't happen until AFTER the
subtraction, and therefore it'll still fail. (And actually, the
original example also converted it to signed after the subtraction,
since the result field was signed, so... you've accomplished nothing by
wrapping the whole thing in an %int()!)
However, you just told me that this won't work:
NegativeValue = %int(PositiveValue) - 21;
That's a whole different story, since the unsigned field is converted to
signed BEFORE the subtraction takes place, and therefore has a signed
intermediate result. This _should_ work. And it does in my tests. But
you just posted that it doesn't??!
(You'd think a business language should be a bit more forgiving in
basic math functionality, but my expectations are often unrealistic)
It is... RPG's native numeric data types of packed and zoned both take
care of this for you, so you can't screw it up. This is only a problem
with the (rather unusual) unsigned data type that was, frankly, added
primarily for compatibility with other languages. Thus, RPG as a
business language _is_ more forgiving. What's not is the other
languages that the U data type was intended to achieve compatibility with.
midrange.com
