Hi David,
I once was so dismayed I asked why am I binding at all? Why not just do
dynamic calls as without service programs it isn't really ILE, it's RPGIII
with all the advantages of RPGIV code. The answer I got that it was much
faster to call the program that was bound. I wonder. If that program is
bound to everything and the system has to deal with all programs that are
just as fat, doesn't that slow it down?
--
that's a vald point!!!
From the technical perspective, there is no need for static binding, any
diffrences in performance can be neglected. If you have a look from the
design perspective, you have two possibilities only: you could call a
programm or a procedure and if you are calling a procedure, sitting alone in
a module, you could replace this procedure with a programm. If the procedure
has no return value and you use prototypes for the call, you could even make
this change altering the prototype only and recompile the application.
Thinking about what a procedure could and a program can't, in other words:
what's the diffrence between a programm and a module?
program:
- a programm has an external program entry point (AKA main) and you can call
it from within another programm and from a command line.
- a programm has only one entry point
procedure:
- a module could have many entry points, every procedure within the same
module could be an entry point, if you specify the keyword export for the
procedure.
- a procedure could have a return value
- a procedure could have a selfdeclaring name
Lets discuss this with a data access module:
you have a table order and you want to centralize all database operations
with the order table.
you would need:
- readByKey
- update
- delete
- setOrderBy
- setWhere
- readNext
and maybe some other functions. The main advantage compared to operate with
the table in every program is, you could centralize all checking logic at
one place.
Putting all this in diffrent programms or modules, wouldn't work, because
some functions have to be in the same programm/module, (setOrderBy, setWhere
and readNext for instance), because they share statefull information.
Easiest way is, to write a procedure for each of these functions and put
them into the same module, so they can share their statefull data. (putting
it to one programm and branching to the appropriate subroutine by an
ActionCode, you will get a very broad parameter structure, changing with
every change of one function)
That's the reason, why a module mostly has more than one procedure!
How many procedures should a module have?
Easiest way: only as much as it needs, that would minimize change
problematic and is best for readability. The most important criterion what
to put in the same module is sharing statefull information and the easiest
way to make your design desicions is giving a module a selfdeclaring name
and it should be a noun.
The most important advantage from ILE compared to OPM, is the possibilty to
write readable code not speed!!! a well designed application using ILE,
would be slightly slower from the machine perspective, but much better from
the perspective of programmer performance!!!
Just to complete the recomendations for easy ILE:
- don't use bind by copy
- one module one Service programm
- automate your compile and bind process
D*B
midrange.com
