I don't see your name, so this essentially anonymous -but I'll mention
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
Others will have more to add.
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?