× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



The project consists of multiple modules which are bound into one service program. There are f. e. the following modules:

- frame builder
- frame parser
- commands
- main module

Again why should I bind multiple modules instead of having a service program for each functionality (independent of the object/program or not)
Procedures (IHMO) must be encapsulated and callable from everywhere just to make the development very flexible.

... in either way I didn't want to open a can of worms

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 Mihael
Sent: Dienstag, 1. November 2022 18:23
To: rpg400-l@xxxxxxxxxxxxxxxxxx
Subject: Re: ILE Concepts

I try to keep my code organized. If we take for example my STOMP client (which is a client for communicating with a message queue system like Apache Artemis and probably also IBM MQ).

The project consists of multiple modules which are bound into one service program. There are f. e. the following modules:

- frame builder
- frame parser
- commands
- main module
- ...

The user uses at least the main module and the commands module but never needs to call anything from the frame parser because this is called internally.

Could I have munched all together in one source/module ... yes. But I don't like source members with tens of thousands of code lines. This become very quickly unwieldy. It is much harder to maintain than multiple source members with only some hundreds or at least less than
2000 lines of code.

My 2 cents.

Mihael

On 01.11.22 18:03, Birgitta Hauser 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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.