Re: confusing coding?

Hi Greg

I agree that it is more helpful to be explicit with conditional statements. The precedence rules, however, do make it clear enough - and OR always starts an new set of conditions, untill the next OR.

Still, having to wade through the predicates can be painful. Same as the precedence rules for arithmetic between multiplicative operations and additive ones.

*Regards*

*Vern Hamberg*

IBM Champion 2025 <cid:part1.qlWxkVAG.ZXeGyYSs@centurylink.net> CAAC (COMMON Americas Advisory Council) IBM Influencer 2023


On 8/5/2025 8:43 AM, Greg Wilburn wrote:

Daniel,

You are correct. The keys to ARCMA1 are
ACCOM#
ACENT#
ACSSF#

This line of code:

c if %eof
c or wsprms>0
c and (accom#<>p1com# or acent#<>p1ent#)
c leave
c endif

My only confusion was the "OR" followed by an "AND" that was not in parenthesis... I wasn't sure what the "AND" applied to
1. just back to the prior "OR"
-or-
2. all the way back to the condition prior to the "OR" (which was %eof)

** I never code like this BECAUSE it's confusing **

To me, this is more readable:

c if %eof or
c (wsprms>0 and (accom#<>p1com# or acent#<>p1ent#))
c leave
c endif

I'm sure it has something to do with my education (Physics/Math)

Personally, I prefer my loops to be more explicit:

setll (key1:key2) recordformat;
dou %eof(myfilename);
reade (key1:key2) recordformat;
if not %eof(myfilename);

...STUFF...

endif;
enddo;

In this case, the program is a Re-Aging customer receivables. It's designed to run for One customer (ACCOM#, ACENT#) or for the entire DB File of customers.

The problem I have is that they used this method of reading records ALL THROUGH THE PROGRAM. It got stuck again last night, so I've reverted to the older version (that works).

I will find the culprit eventually... I think I know what subroutine it is stuck in based on viewing the call stack before ending the program this morning.






-----Original Message-----
From: RPG400-L<rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Daniel Gross
Sent: Tuesday, August 5, 2025 5:36 AM
To:rpg400-l@xxxxxxxxxxxxxxxxxx
Subject: Re: confusing coding?

So let's go through the code, to end all confusion:

n Mon, Aug 4, 2025 at 10:46 AM Greg Wilburn<gwilburn@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

1. WSPRMS is assigned *PARMS
2. P1COM# & P1ENT# are the possible parameters

c*
c *entry plist
c parm p1com# 3
c parm p1ent# 8
c parm p1wx
c*

I think there is no explanation needed. Only that all parameters, including P1COM# and P1ENT#, seem to be optional - otherwise wsprms = *PARMS might not be needed.

c*
c if wsprms>0
c move p1com# accom#
c move p1ent# acent#
c ackey setll arcma1
c endif
c*

The SETLL positions the file to (right in front of) the first record, that matches p1com# and p1ent# - as I can't see the definition of the ackey KLIST I assume, that those fields are "leading keys" of the file arcma1.

The positioning is only done, if at least 1 parameter was gives to the program - which is odd, because if only 1 parameter is given, it would result in a MCH3601 message for p1ent#.

c dow '1'
c read arcma1

An infinite loop reading arcma1

c if %eof
c or wsprms>0
c and (accom#<>p1com# or acent#<>p1ent#)
c leave
c endif

The loop ending conditions are defined in an IF with LEAVE - a typical construct. The LEAVE-conditions are:

a) if %EOF() is reached
OR
b) if pgm parameters are given and accom# or acent# differ from that pgm parameters

If accom# and acent# are leading keys of the file arcma1 a loop with READE might have worked - but for this we would have to see the LF definition and the KLIST.

But as I already said - anytime I find such a construct, I would always refactor and use SQL - instead of "negative" logic (for LEAVE) a SQL SELECT uses "positive" logic (which records are needed).

Am 05.08.2025 um 09:13 schrieb Patrik Schindler<poc@xxxxxxxxxx>:
Honestly, even I avoid using implicit cycling, because it's function not represented by code, which confuses me.

I have to disagree Patrik ;-) the cycle is of course explicitly coded by coding the file as a primary (or secondary) by that single "P" (or "S") in position 19 (ILE) of the traditional file specification. That might not be so obvious - but it is explicitly coded.

Of course I know - the compiler is doing a lot implicitly and under the covers - but that's not really a bad thing - Python, Perl, Java, C# - all modern languages do something "under the hood" - even if it's only implicit type conversion.

The problem with the cycle is that one really has to learn how it works - including L1 to L9 and MR. That means some (like a lot of) reading, some testing - and that kind of "slow learning" isn't en-vogue since the early 2000's - Learn-XYZ-in-21-days books and 5-15 minute YouTube videos have done a lot of harm.

In Japan they say that you need 7 years to learn something well - and another 7 years to master it. In our world today any 3-years-out-of-college is called a "Senior Software Architect".

That said - as always - the answer (again) is most probably SQL.

Kind regards,
Daniel


--
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
athttps://archive.midrange.com/rpg400-l.

Please contactsupport@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.

Greg Wilburn
Director of IT
301.895.3792 ext. 1231