ILE doesn't enforce structured and modular programming. And I was doing
that before ILE.
I'd fail assignments if they ever found a GOTO! As soon as I got a job,
I kept up those good techniques. (Plus, I am far too lazy to write the same
piece of code twice.)
That's exactly what I thought we went from RPGIII to RPGIV and started with
ILE concepts!
We were as modular as we could be for RPGIII, but that's NOT really modular!
You'll never write a program for a single or only for a few statement, but
you'll write a function or procedure.
... and a program can only have output parameters, but never a return value.
In an really modular world you won't need subroutines any more, instead you
write procedures, ideally small encapsulated black boxes that can be used
everywhere.
Those functions/procedures are grouped based on the functionality into
source members (--> Modules --> service programs). For example all date/time
procedures, all string procedures, all procedures to check an item no, all
procedures to, all procdedures to calculate and compare your stocks, all
procedures to write an invoice etc.
If you need a procedure you simple have to look into the appropriate service
program, if it exists call it, if it does not exist add the new procedure to
the appropriate service program. If your co-programner looks for a similar
procedure he'll find it the next time.
If a procedure must be changed it can be done and tested without touching
any programs or service programs (i.e. without modifying any code or
recompiling those objects).
If a variant of the procedure is needed just write it an use it where it is
needed.
In this way program code will be reduced to a minimum. My programs consists
only of a few IFs and Loops and procedure or function calls. My procedures
can be accessed from everywhere and rarely have more than 100 statements,
most are much smaller. There are only a few internal procedures (for example
for initializing global variables).
Learning to think modular is an ongoing process. ... Most of the first ILE
procedures I ever wrote were not modular, at least from my current
understanding. And I had to restructure them again later.
Mit freundlichen Grüßen / Best regards
Birgitta Hauser
"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"
-----Ursprüngliche Nachricht-----
Von: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] Im Auftrag von w 4038
Gesendet: Monday, 04.2 2013 05:36
An: Midrange Use this to send questions
Betreff: What good is ILE?
Hi VernThank you for your reply. Also, thank you for your replies to the
multitude of questions that have been posted to these forums over the years.
I have learned a lot from the wise council that you and others freely give.
(Public display of sincere gratitude is now over, so I'll get back to the
business at hand.) What good is ILE?ILE doesn't enforce structured and
modular programming. And I was doing that before ILE. I was taught
structured technique in universtiy back in the 80's and the professors
enforced it. I'd fail assignments if they ever found a GOTO! As soon as I
got a job, I kept up those good techniques. (Plus, I am far too lazy to
write the same piece of code twice.) You are correct that I intentionally
mentioned all those terms as a type of "FUD". But that was the point. All
that "FUD" (or more complexity as I prefer to call it) and I still don't see
any great benefit. You wrote that ILE gives a smaller object size. Is
that a great benefit? Perhaps it was in the 80's, but is that still true
today? I didn't realize that compiling CL as ILE improves performance. So
I concede, that could be a benefit. How much does it improve performance
though? Enough to justify more
complicated programs and compiles? I don't know, but I am asking. Which
brings me to the question of anonymity. I apologize for that. I don't have
the confidence that others have and so I prefer not to have my name public.
I do hope you'll still consider my questions valid though.Thank you
Date: Sun, 3 Feb 2013 21:59:42 -0600
From: vhamberg@xxxxxxxxxxxxxxx
To: midrange-l@xxxxxxxxxxxx
Subject: Re: What good is ILE?
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.
--
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.
midrange.com
