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



Hi

The CL boost was something I remember from some time ago - I don't know why it is so, however. I did just google the topic and found a couple things -

http://search400.techtarget.com/tip/ILE-CL-can-boost-productivity-and-performance

That article mentions a 5% benefit when calling an OPM program. That might not seem worth it, and probably does not make it worthwhile to recompile just to recompile. When making a bound call to another ILE procedure, it was markedly better. Ron Turull wrote this in 2004, it says.

The original ILE Application Development Example manual

http://publib.boulder.ibm.com/iseries/v5r2/ic2924/books/c4156020.pdf

has lots of statements about the benefits of ILE - they do seem to center on more effort for the developer with the end of better performance for the process or user - that's a trade-off I often am willing to take - and necessary much of the time.

As I said in the other reply, YMMV - code re-use, however, is one of the main reasons I hold for going with ILE.

As a counter, I did find a position page from TAA Tools - at the time, they have not converted to ILE, using it only for certain things that require it. That makes an interesting counter to what I've heard elsewhere. Even they thought that ILE should run better. They also have a simplicity approach, and they see ILE as more complicated - hence something similar to the OP.

So the performance thing might be a wash.

Vern

On 2/3/2013 10:19 PM, rpglist@xxxxxxxxxxx wrote:
Vernon,
I am not the original poster on this, but I have a follow up question, you mentioned that compiling a CL as CLLE gives you a performance boost..... Can you explain this further?

On Feb 3, 2013, at 9:59 PM, Vernon Hamberg wrote:

I don't see your name, so this essentially anonymous -but I'll mention
one thing

Maintenance. How many places do you have the same code in many of them?
Of course, we shouldn't do that, but we probably do. When a change is
needed, there is just one place - the service program - that needs changing.

Now YMMV - depends on a number of things, one of which I hinted at above.

The other answers to this have been around the world many times -
anything related to more structured, modular programming techniques,
applies to this question.

You mention all these "binding" things - I find that it is a bit of FUD
just to list them. Once you've set up bindery language, you're done, and
additions are easy to do. Statid vs dynamic vs by reference - you
basically choose one, and you're done again.

Another one? Object size.

Another one? Just compiling CL programs as ILE gives you a great
performance boost with almost no effort - great ROI. Why NOT take the
low-hanging fruit?

Others will have more to add.

<not-letting-you-know-this-is-vern>

:)

On 2/3/2013 7:17 PM, w 4038 wrote:
What good is ILE??

Before ILE, if you needed to call program B from program A, a simple CALL statement did the job.
All you had to worry about was the library list and it was up to you to pass parameters correctly.

Then IBM introduced ILE.
Now you can worry about, Activation Groups,Binding Directories, Binder Language, subprocedures, service programs, Static Binding, Dynamic Binding, Bind by Reference and some I can't recall right now.

Sure, it's nice that the compile checks to ensure that passed parameters match, but what other benefits are there? The benefit isn't speed. Newer hardware resolves that.
All the complexity just increases the potential for coding errors.

So I ask great minds of the Midrange List, what good is ILE?
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



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.