Re: IN operator with array doesn't always work?

Hi Vern,

well the compiler follows the operator precedence rules quite strict:

https://www.ibm.com/docs/en/i/7.5?topic=expressions-operation-precedence

And the NOT operator has a much higher precedence than the IN operator - so it will try to bind to the next expression term (in this case your variable inCtFcr.MKTSG#).

So you have to place parentheses around the term, that you want to negate.

The compiler is simply following it’s rules - even if I wish, that they would have created an extra rule for

if something not in ….

because

if not (something in …..)

really looks a bit strange to me - and also to many others.

HTH

Kind regards,
Daniel

P.S.: “We” already tried to convince the “Compiler Queen” (Barbara Morris) to change that - but I don’t think that it will happen.

Am 09.06.2022 um 20:34 schrieb Vern Hamberg via RPG400-L <rpg400-l@xxxxxxxxxxxxxxxxxx>:
Hi Mark

Yeah, that might be the case, except that this is an RPG operator, no SQL involved. And except that the example in the documentation should probably raise a compile error, too, as it is the same syntax as my first attempt.

Regards
Vern

On 6/9/2022 12:00 PM, Mark Waterbury wrote:

Vern,
The SQL preprocessor probably follows the operator "precedence" rules of SQL -- for better or worse (in this case).
When there is any doubt at all, I always use parentheses. IMHO, it never hurts to use extra parentheses to "document" what you really want, as far as the "evaluation order" of an expression is concerned, for the benefit of the compiler, and for anyone in the future who may need to maintain the code.
All the best,
Mark S. Waterbury
On Thursday, June 9, 2022, 12:50:21 PM EDT, Vern Hamberg via RPG400-L <rpg400-l@xxxxxxxxxxxxxxxxxx> wrote:
Y'all

I just tried the fairly new IN operator, to see if a value is in a list
of items. The list has to be in an array, it seems, at 7.3, anyhow, that
%LIST() is basically hard-coded thing.

Anyhow, I have an 99-element zoned(2:0) array, segXcpt. I also have a
data structure element, inCtFcr.MKTSG#, that is zoned(2:0).

blox is a count of how many elements I loaded into segXcpt.

So this statement compiles fine -
if inCtFcr.MKTSG# in %subarr(segXcpt : 1 : blox);

The following statement gives me an RNF7421 compile error (Operands are
not compatible with the type of operator) -
if not inCtFcr.MKTSG# in %subarr(segXcpt : 1 : blox);

This is identical, syntactically, to the example in the documentation -
In the following example, the IF statement is true if item is not in the
array availableItems. %SUBARR is used to limit the number of array
elements checked.
IF NOT item IN %SUBARR(availableItems : 1 : numAvailabeItems);

What DID work is this statement, where I used parentheses - there is no
hint of the need for the parentheses, even in the 7.5 documentation, IIRC.
if not (inCtFcr.MKTSG# in %subarr(segXcpt : 1 : blox));

It looks like the RPG parser is tying the NOT to the subfield after it
and treating it all as an indicator type. Something like that.

BTW, I had tried this, which I think should be allowed, and it was a
different syntax error -
if inCtFcr.MKTSG# not in %subarr(segXcpt : 1 : blox);

So I probably need to submit a case but wanted to run it by y'all first.

Regards
Vern

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

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com