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

True - this is a classic situation of SQL-vs-RPG - or maybe even SQL-vs-the-rest-of-the-world, because even in C you would have to write something like !(…) to negate a logic expression.

But of course SQL is a descriptive and not an imperative language like RPG.

And yes - I hate this too - especially because as an embedded SQL programmer I’m constantly switching between RPG and SQL - but slowly I get used to it.

Bye
Daniel

Von meinem iPhone gesendet

Am 09.06.2022 um 21:49 schrieb Vern Hamberg via RPG400-L <rpg400-l@xxxxxxxxxxxxxxxxxx>:

Thx, Daniel, that makes sense out of things, and goes along with Mark's comment.

Trouble is, __the documentation suggests the opposite__, so we shall see what IBM says.

An SQL example confuses things further for me - I believe these are equivalent - and I could completely mistaken -

where column not between lowval and highval

where not column between lowval and highval

Maybe there is a distinction in SQL over operators and predicates or some such - and is "not" and operator as such in SQL?

I'm just glad I got this working - much better than FOR-looping through array elements and needing to use LEAVE for an early exit.

Cheers
Vern

On 6/9/2022 2:03 PM, Daniel Gross wrote:
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

--
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