×

Good News Everybody!

The new search engine is LIVE!

Please report any problems to david (at) midrange.com.




It comes down to usage, need, and priorities. If it is only used
sparingly, I would not make it a service program. If it is used often, I
would make it a service program. Once loaded into memory, the efficiency
gain would be worth it; But you are right when you said that SQL is the
easiest and fastest to implement. Personally, with no more than it is
doing, I would embed the SQL statement. If used in multiple programs,
create the procedure (I included the code in a previous post) for ease and
consistency. Again, it depends on your needs.

On Wed, Sep 4, 2019 at 7:47 AM Robert Jacobs <robertjacobsit@xxxxxxxxx>
wrote:

Looking at my example, the copyCommon file can list all of the modules
within your service program individually. Then, in the calling rpg, you can
/define only the modules you want to load in memory, then /include the
copyCommon file (multiple can be defined before the /include statement, or
only one). The copyCommon file then checks which modules you've defined and
/includes only the prototypes desired.

On Wed, Sep 4, 2019, 3:34 AM Gad Miron <gadmiron@xxxxxxxxx> wrote:

Hello guys

Thanks to Robert, Carel, Dexter , Justin, Raul for your input.

To sum it:
1. This is a small exercise so I do not want to use SQL although it seems
the simplest way.
2. I thing I understand that creating a module/procedure and embed it in
a
SRVPGM is
the proper way to do it
but
3. I hazily recall from years back having read that upon the first call
of
a module/procedure
of a service program the entire SRVPGM is loaded into memory .
(and since we have several big SRVPGMs I don't want to add this
routine
to any of them)

Am I wrong about this loading of entire SRVPGM into memory?


TIA
Gad
--
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@xxxxxxxxxxxx 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@xxxxxxxxxxxx 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 ...

Replies:

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

This mailing list archive is Copyright 1997-2026 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.