Re: What good is ILE? -- MIDRANGE-L

I had to take a second look at this, too. We do have public and private declarations in VB, for example. Privacy is about scope or visibility, I think. Global vs local, perhaps.

Programs and their parameters are basically global. Anything can call them. Procedures can be made local to a program or service program.

So although you can have only programs, which may seem simpler, the ability to hide some of those in an ILE module has potential benefit in terms of maintenance, which is a matter of future cost to a company.

In all this discussion, I have had an idea forming - benefits of ILE can be examined in different aspects - final performance (probably not the main benefit), development effort (this is probably future benefit, might seem more work at the start). And other categories.

JMHO early in the morning!
Vern

On 2/5/2013 3:04 AM, whatt sson wrote:

For me, a big advantage of ILE is the ability to have multiple levels of

privacy.

Privacy?

Is that a correct term in this context? Never heard or read about it using
the term "privacy".

Public/private, encapsulation, information hiding, etc, but privacy is
something that applies to something like facebook (or rather not).

On Tue, Feb 5, 2013 at 1:10 AM, Barbara Morris <bmorris@xxxxxxxxxx> wrote:

On 2013/2/3 8:17 PM, w 4038 wrote:

What good is ILE??
...
All the complexity just increases the potential for coding errors.

For me, a big advantage of ILE is the ability to have multiple levels of
privacy. Increased privacy tends to decrease the potential for coding
errors.

Say A calls B to do some subtask, and you want to change the first
parameter for B to be bigger.

If B is a separate *PGM, then B is public to the entire system. You now
have to do some analysis to determine who is calling B, so you can
increase the size of the variable that is being passed to B by all
callers. If you miss one of the callers of B, you might not find out
about the error until years later, if the storage corruption caused by
the parameter mismatch doesn't cause an exception.

If B is a _non-exported_ procedure in the same module as A, then B is
private to the module containing A and B. You don't have to do any
analysis at all. It is impossible to miss compiling one of the callers
of B. And even if you miss one of the callers of B so you don't change
the length of its parameter, the compiler will tell you immediately.

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