RE: Eval with two equals? -- RPG400-L

Hi Jon -

It has been available forever - or at least as long as RPG IV has existed.
It was in the very first release.

Since you mention it's ability to turn the indicator off if it is already
on, it is probably worth extending your example to _preserve_ the current
state of the indicator. e.g.

*In50 = (RRN1 > *Zero) or *In50

Of course we shouldn't be using nasty numbers anyway now should we <grin> -
so a better example might be:


Where SubfileDisplay is a named constant with a value of 50.  If we have
used the INDDS keyword to name our indicators, then it becomes even cleaner
because it could read like this:

SubfileDisplay = (RRN1 > *Zero) or SubfileDisplay

You're dealing with a very bad example of preserving the prior state. Having SFLDSP indicator on even though the subfile is now empty, just because it previously had data, is NOT a good idea.

Speaking in general terms, I really like that the evaluated value replaces the current value. I use that kind of assignment statement a lot. I *always* code it with parenthesis around the comparison so that it is clear what is happening. Likewise, if I have an IF with multiple conditions, I always put the parenthesis around the various conditions to indicate the way the testing should be done, even if that is exactly the same as the what the compiler's built-in hierarchy would do. E.g. I code if (a = b) or (c = d) even though if a = b or c = d would give exactly the same results.

Since RPGIV understands that an indicator is a boolean
true/false you don't need the "= *On" or "= '1'" <shudder!>.  So "If
*In(SubfileDisplay)" is equivalent to "If *In(SubfileDisplay) = *On" - and
"If Not *In(SubfileDisplay)" is equivalent to "If *In(SubfileDisplay) =
*Off"

I'm with you there. And to expand what I know you know, but others may not realize, this applies to any logical expression, including named indicators and BIFs. E.g. dow not %eof rather than dow %eof = *off if %found rather than if %found = *on

The shorter source code MAY even generate shorter compiled code, depending on how smart the compiler is, particularly on the second line.

Without any special checking if %found would test the %found flag for a on status, then if true, execute the code inside the IF, whereas if %found = *on would compare the %found flag to a true value, then test the result of that comparison to see if it is true, then if that is true, execute the code inside the IF.

Maybe Barbara or Hans will chime in and let us know how smart the compiler is at eliminating redundant checking.

-- Ken http://www.ke9nr.net/ Opinions expressed are my own and do not necessarily represent the views of my employer or anyone in their right mind.