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



There are roughly 12,500 lines of code in the start up of the RPG program
logic cycle.

Back when they were first doing ILE, they said that the dynamic call was
about 2500 lines of code.
The new bound call is about 250 lines of code.

So the procedure call is 10 times faster than the dynamic call (based on the
original implementation, but it is probably faster today).  Subsequent calls
to a bound procedure run a few dozen lines of code (faster than that first
bound call).

However, if you add the 12,500 lines of cycle code to the 2,500 lines of
dynamic call you end up with 15,000 lines of code for a dynamic call.
If you change the dynamic call to a bound call you end up with 12,750 lines
of code on that bound call to an RPG IV module.
A difference of less what 15 percent give or take?
In other words, unnoticeable by humans.
And that's just lines of code, not the speed in which those lines execute. I
would be the performance ratio of dynamic call to an RPG IV module version
bound call is narrower. 
In fact, I've heard some people say that CALLB to a module can be slower in
some situations than a regular old CALL.
-Bob Cozzi


-----Original Message-----
From: rpg400-l-bounces+cozzi=rpgiv.com@xxxxxxxxxxxx
[mailto:rpg400-l-bounces+cozzi=rpgiv.com@xxxxxxxxxxxx] On Behalf Of Krish
Thirumalai
Sent: Friday, January 07, 2005 2:03 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: General ILE question - *LR

I was following a thread based on an article you had written in 2003
CALL  or CALLB ?(http://tinyurl.com/3zjds) and agree that in some
instances it does not make sense or the time to convert and in most
instances the performance improvements are not noticeable.

Correct me if I am wrong but isn't a bound call faster than a dynamic
call?  Wouldn't you still get that benefit even if calling to a main
line as opposed to a procedure?

We need to keep this broken up code as fast as possible.  We wanted to
make the calls to the new programs faster by using bound calls instead
of dynamic calls.

One of my colleagues remembers that at a COMMON conference, in the
intro to ILE class, they stated that one of the easiest benefits you
can get from ILE is to change CALL to CALLB on programs that are not
called by many programs but called extensively by the ones that do
allowing for a faster call and thus better efficiency. Is that an
incorrect assumption
 

On Fri, 7 Jan 2005 11:27:49 -0600, Bob Cozzi <cozzi@xxxxxxxxx> wrote:
> Right, RPG IV sucks when it comes to file sharing between modules. It just
> really, really sucks.
> One way to work around this, and it is not by any means perfect, is to
> declare externally described data structures and then EXPORT/IMPORT the
> between the modules. These DS's would be EXTNAME(myfile) and the files in
> each module would then read into and from these data structure
automatically
> (the subfield names would match those of the input/output fields). Using
> PREFIX and QUALIFIED DS's would be even better.
> -Bob
> 
> 
> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
> On Behalf Of Krish Thirumalai
> Sent: Friday, January 07, 2005 10:53 AM
> To: RPG programming on the AS400 / iSeries
> Subject: Re: General ILE question - *LR
> 
> We have a mammoth RGPLE program that is currently using a very
> subprocedures, but the main line portion of the code is still pretty
> big and is getting to be a maintenance nightmare.
> 
> We want to rewrite this program into several modules based on
> different functionality, so that we can do some concurrent development
> and make development/maintenance easier. We have figured out which
> subroutines are common and which are not.
> 
> Not sure what the easiest way to break this down since the program
> currently uses around 100 files and we want to share the ODP and be
> able to share data between these modules without having to chain back
> to the same files in each module if we break these down.
> 
> On Fri, 7 Jan 2005 10:37:30 -0600, Bob Cozzi <cozzi@xxxxxxxxx> wrote:
> > I suppose the first question is why do you want to do this?
> > What can you possible gain from making a module that has the RPG logic
> cycle
> > in it a bound call?
> > Leave it a stand-alone program and dynamic call, you'll be better off.
> > The only time you use multiple modules is when the NOMAIN keyword is
> > specified on the header specification of the secondary modules.
> > If you haven't begun using subprocedures, don't move to multiple
modules.
> > The "correct" order (in my view) is to begin using subprocedures first,
> then
> > move to using multiple modules.  The capability to call a module by name
> > using CALLB or a prototype is an anomaly due to the way RPG is
structured
> > and should always be avoided.
> > -Bob Cozzi
> >
> >
> > -----Original Message-----
> > From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]
> > On Behalf Of Krish Thirumalai
> > Sent: Friday, January 07, 2005 10:24 AM
> > To: RPG programming on the AS400 / iSeries
> > Subject: General ILE question - *LR
> >
> > I have a general ILE question.  Say I am creating a module that is
> > bound by copy to the calling program.  The module has a mainline that
> > logic will flow through each time it is called.  Do I want to set
> > *INLR on each time when logic reaches the end of the mainline or
> > should I always just RETURN?  Does turning on *INLR really do anything
> > if the program is a module?
> >
> > Thanks
> >
> > Krish
> > --
> > This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list
> > To post a message email: RPG400-L@xxxxxxxxxxxx
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> > or email: RPG400-L-request@xxxxxxxxxxxx
> > Before posting, please take a moment to review the archives
> > at http://archive.midrange.com/rpg400-l.
> >
> > --
> > This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list
> > To post a message email: RPG400-L@xxxxxxxxxxxx
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> > or email: RPG400-L-request@xxxxxxxxxxxx
> > Before posting, please take a moment to review the archives
> > at http://archive.midrange.com/rpg400-l.
> >
> >
> --
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
> To post a message email: RPG400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.
> 
> --
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
> To post a message email: RPG400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: RPG400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/rpg400-l.
> 
>
-- 
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.





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.