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


  1.  Home
  2. RPG400-L
  3. August 2021

Re: large difference in job run times between bound procedure call, and procedure call from within program.

My opinion only but a very bad thing to do.

Think of what happens over time. You write the procedure and then bind it
into 25 programs. You then modify it and you recompile one of your programs
but don't for the others. Easy to do. Now you have two versions floating
around. That's why service programs are the best technology.

As far as LR, again it means nothing in a procedure in a module and
performance wise if you are binding in program there is absolutely no
difference between having in one module vs another module unless you pass
or returning large parameters.

The way the module works in a program or a service program is that each
module has its own static memory. That static memory is not initialized
until you enter one of the procedures in the module. Once you call one of
these procedures in a module, that storage stays. It is never released
until the activation group ends so if you entered a procedure and set the
value of a global variable to say one, the next time you called the
procedure or any other procedure the value would still be one until you
changed it.

The trick with static storage is to use as little as possible.

If you declare a variable within a procedure, that is called automatic
storage and each time that you call the procedure the storage is
re-allocated and when you exit it is released, ie local variables.




On Wed, Aug 25, 2021 at 1:04 PM Gerald Magnuson <gmagqcy.midrange@xxxxxxxxx>
wrote:

I am not using a service program, I have compiled this up as a *module,
and put in a binding directory entry to point to it.


On Wed, Aug 25, 2021 at 2:21 PM Alan Campin <alan0307d@xxxxxxxxx> wrote:

As I indicated above, LR means nothing in a service program. There is no
RPG runtime bound into a service program.

Just a note also, you do not have to type the name the procedure three
times. You only need to type once.
dcl-proc MyProc Extport;
dcl-pi *N;
Parms
end-pi;

end-proc;



On Wed, Aug 25, 2021 at 12:15 PM Gerald Magnuson <
gmagqcy.midrange@xxxxxxxxx>
wrote:

here is my source of module
https://code.midrange.com/10a0227a02.html



On Wed, Aug 25, 2021 at 2:07 PM Ali Ekinci via RPG400-L <
rpg400-l@xxxxxxxxxxxxxxxxxx> wrote:

here is my 2 cents:

* do not turn on LR in the procedure, have an initialization
logic
that is processed only at the first call
* make sure your utility program is not using *NEW activation
group.

________________________________
From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> on behalf of
Gerald
Magnuson <gmagqcy.midrange@xxxxxxxxx>
Sent: Wednesday, August 25, 2021 2:59 PM
To: rpg400-l@xxxxxxxxxxxxxxxxxx <rpg400-l@xxxxxxxxxxxxxxxxxx>
Subject: large difference in job run times between bound procedure
call,
and procedure call from within program.

Sent by an external sender
------------------------------

I don't have my terms correct, sorry.

we have many programs that have a sub-routine, called "get
allocations".
This routine is found in over a dozen of our programs, and trying to
simplify things, I made it a
procedure, and even migrated from f specs to complete SQL.

However, in a program that invokes this routine 300k times, the run
time
went from 25 seconds, to
350 seconds to sometimes over 400 seconds.

If I put the procedure in the bottom of the program I call it, it
runs
as
fast as the sub-routine call.

maybe this is normal for the overhead of having a bound procedure
call,
or
maybe I just don't know what i need to do.
--
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

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