Jon can answer this better than I can, but here's some additional insight
I got from various COMMON sessions and other research.
The OPM COBOL compiler hasn't been modified or enhanced since V3R0 of
OS/400. (It may even have been "stabilized" before that. Only bug fixes
have been applied since this time. Note the date on the most recent OPM
COBOL manual, the best I can find is "June 1994.") The optimization
techniques used by the compiler were limited and obviously haven't been
updated. The compiler basically generated MI code. (I don't my notes at
hand right now so I could be a little off on this.) The MI code was then
compiled into a program object.
ILE is considered a much more modern compiler. It generates intermediate
code (p-code, if i recall correctly--again I don't have my notes at hand).
This can have some heavy duty optimization applied. One COMMON session I
attended claimed that simply recompiling a program in ILE could result in
a 20-30% performance gain.
Again, Jon will be much better equipped to answer the question. I
treated is very simplified. The dynamic call is resolved on the first
call. Then on subsequent calls, it basically uses the pointer which was
resolved on the first call. ILE uses the same technique for dynamic
calls. I have notes somewhere on procedure calls in ILE, but as I recall
there are some differences in the way they are handled. You'll see a
definite difference on the first call. But the down side is program
activation for your initial program can take a little longer. But it will
be almost negligible when you call the procedure. (Okay, again I better
defer to Jon--I know this is true for procedures in a service program, but
I don't recall if it applies to programs with procedures in multiple
modules all bound into the same program.)
Make the jump to ILE--It can take some effort to learn the nuances, but
you'll be glad you did. Here's a *short* list of benefits:
--better compiler optimization
--bound procedure calls (the procedures can be written in whatever
language is best suited to the task at hand.)
--more API choices
--intrinsic functions
--Service Entry Point (SEP) debugging with RDP. (This one alone is almost
enough to be worth the price of admission.) You can even take advantage
of this in the green screen. See Susan Gantner's article at:
http://www.itjungle.com/fhg/fhg100312-story01.html
--recent documentation. (See my note above about the "June 1994" manual.)
If you get a chance, post what kind of results you see to the list here.
Michael Quigley
Computer Services
The Way International
www.TheWay.org
cobol400-l-bounces@xxxxxxxxxxxx wrote on 10/03/2012 06:00:50 PM:
----- Message from "Stone, Joel" <Joel.Stone@xxxxxxxxxx> on Wed, 3
Oct 2012 20:07:21 +0000 -----
To:
"'COBOL Programming on the iSeries/AS400'" <cobol400-l@xxxxxxxxxxxx>
Subject:
Re: [COBOL400-L] COBOL400-L Digest, Vol 10, Issue 27
Im confused:
I am calling data scrubbing routines Zillions of times (one for each
field in millions of records) in OPM.
I thought that a big reason to move to ILE was to improve
performance of CALLing separate modules and binding them together.
This should reduce the overhead of the 2nd thru Nth call to the same
routine.
But you are stating that OPM is pseudo-doing this time-reduction-
efficiency of CALLs anyways??
So - if I break these into modules and bind them a certain way in
ILE - the time reduction will be negligible??
midrange.com
