Re: The value of ILE

Dieter,

I appreciate your response. Still, I disagree, a little bit:

On Sun, Jul 20, 2014 at 2:36 AM, D*B <dieter.bender@xxxxxxxxxxxx> wrote:

The very diffrence between a PGM and an ILE SRVPGM is, that a SRVPGM has
multiple entry points: a SRVPGM is a collection of exported procedures with
shared memory. Each procedure could have private variables too.
One of the patterns, often used in Business applications are (for example)
DataAccess Modules providing readNext() read(key), update(), insert(),
delete() setOrderBy(), newCursor().... If you would try this with OPM and
programm call, you would end up with unreadable and unusable code.

I understand what you are saying here, and I think a service program
is *nicer* than a corresponding OPM program, but you can do this
pattern using OPM without making it unreadable and unusable. I guess
that depends on what you consider "readable". ;) But you can take the
system API approach and have, say, one parameter which tells you which
function to use and then either a bunch of small, sometimes optional
parameters if they can be the same types among the different
functions, or a big parameter that you need to chop up with different
data structures depending on the function. Everybody keeps saying
that the way to handle ILE prototypes is to put them in /COPY members.
Well, just have the corresponding data structures in /COPY members
instead.

Second point for ILE is, that the compiler does more work for the
programmer, compared to OPM.

I can't disagree with that.

Compared to C/C++/Java/C# on other platforms,
the ILE compiler does this job not very well and the IDEs and Editors are
even worse.

OK, this doesn't sound like it's discussing the relative merits of ILE
versus OPM anymore. ;) (But I will say that I have personally found
ILE a pain to use with just PDM, SEU, and the command line.)

John