Re: ILE Concepts -- RPG400-L

I wasn't trying to convince you. You asked for reasons - I gave mine. They were not specific to your customer as I have no knowledge of their situation - but as you'll have seen by now others have agreed with my basic reasoning and put their own additions and qualifications to it. Further comments below.

On Nov 1, 2022, at 1:44 PM, Birgitta Hauser <Hauser@xxxxxxxxxxxxxxx> wrote:

Sorry Jon, I'm not convinced.

@1: There are almost no global variables used. Exception is if they have to hold/save on an activation group or job level (kind of replacement for the LDA but more powerful) and this information is SET and retrieved GET via functions.

This is customer specific - how are the rules enforced? Code review? My view is simply that it is easy to break the rules by "accident" with one huge lump of code. Many shops pay lip service to code review but don't do or do it infrequently. I've seen many cases of GOTO being used in shops that theoretically ban it.

@2: Modifications can be easily merged together because each programmer will work on his own copy of the member. New procedures are always added at the end of the source. If 2 programmers build new functions the first who returns his functions will be then embeeded at first and the other after.
... only problem might be if 2 programmers have to modify the same procedure (which happens very rarely).

"easily" ? If they are using (say) git to achieve this I would not argue the point. But if they are using traditional RPG tooling ...

@3: All functions belonging to a single functionality are in the same source/module ... no need to search multiple sources.
With RDi or other development tools you will have a list of exported and internal procedures on which can be ordered in either incoming sequence or alphabethical sequence.
... and old/unused functions should not be removed
... so they stay where they are and the content gets commented out and just in case they are called an escape message is sent.
... with multiple modules we still have the same situation (or are you finally removing a complete module).

Again you're missing the point. I was not critiquing a piece of software that I know nothing about - merely giving you my take on the question you posed. Disputing what I said by quoting application/company specifics has no impact on what I believe to be good or bad.

@4: I do not see why 2 functions should be merged together, instead of creating a 3rd one which calls both of them.
... but still IMHO it makes no difference whether these encapsulated procedures are in a single source or in multiple sources.

Then we agree to disagree.

I was simply stating the general rules as I see them and based on seeing many, many messed up applications because people build their new "modular" applications out of monoliths.

Jon P

Mit freundlichen Grüßen / Best regards

Birgitta Hauser
Modernization – Education – Consulting on IBM i

"Shoot for the moon, even if you miss, you'll land among the stars." (Les Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them and keeping them!"
„Train people well enough so they can leave, treat them well enough so they don't want to.“ (Richard Branson)

-----Original Message-----
From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Jon Paris
Sent: Dienstag, 1. November 2022 18:22
To: RPG programming on IBM i <rpg400-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: ILE Concepts

There is no absolute reason - but here are a few things to consider:

1) The larger the single module (i.e. source) the greater the temptation to use globals. <<There are almost no global variables used. Exception is if they have to hold/save on an activation group or job level (kind of replacement for the LDA but more powerful) and this information is SET and retrieved GET via functions.>>.

2) One source = (generally) one programmer working on it at a time. This losses the opportunity (among other things) to have juniors work on simple fixes in source A while the senior programmers wrestle with the big problems in sources B and C. <<Modifications can be easily merged together ... only problem might be if 2 programmers have to modify the same procedure>>

3) Large sources present the same old problem that our monolithic RPG/400 programs presented - sorting out the wheat from the chaff. Which bit belongs with/is used by which etc. It is easy to get overwhelmed by volume. When you can see the whole thing in a few pages things get simpler. <<All functions belonging to a single functionality are in the same source/module ... no need to search multiple sources.

4) Placing all functionality in a single source tends to lead to the same old problems that subroutines encouraged. i.e. "Well X gets called in the same timeframe as Y so lets just mush the code together."

There are more but ...

Jon P.

On Nov 1, 2022, at 1:03 PM, Birgitta Hauser <Hauser@xxxxxxxxxxxxxxx> wrote:

Thanks for the answers about my ILE questions ... you mostly confirmed
what I already told them (but ... as said the new guy knows everything better).

... but I have another may be silly question ... but until now nobody
could answer it in a way that I'm satisfied:

Why to bind multiple modules in a single service program?

If the functions/procedures are grouped depending on their
functionality into a source member and almost all functions are
exported and the exported ones are strongly encapsulated and only RPG is used.
Why would we need multiple modules with functions which can be grouped
together in a service program?
If the modules include functions with different functionality why we
should bind them into a single service program?
And if we are working with different programming languages, why not
using a service program for each language.

... activation time cannot be the reason, because the service programs
are bound with deferred. Also before we had deferred the activation
time was very fast, at least at this customer (and he currently has
around 120 service programs with around 8000 exported functions in total).
... working with different activation groups may also cause the same
service program to be activated multiple times in the same job. The
bigger the service program the more must be loaded (multiple times)
into memory

Mit freundlichen Grüßen / Best regards

Birgitta Hauser
Modernization – Education – Consulting on IBM i

"Shoot for the moon, even if you miss, you'll land among the stars."
(Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training
them and keeping them!"
„Train people well enough so they can leave, treat them well enough so
they don't want to.“ (Richard Branson)

-----Original Message-----
From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of
Charles Wilt
Sent: Dienstag, 1. November 2022 16:50
To: RPG programming on IBM i <rpg400-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: ILE Concepts

On Tue, Nov 1, 2022 at 9:36 AM Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:

I would also add that I find their current method of one source one
object also rather dated and pointless. But is is sadly a quite
widely used approach.

Agreed, it makes no sense to limit yourself to 1 module per service program.
I've been asking for our home-grown build process to be enhanced for
5+ years now... :(

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

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