Just an FYI - in recent versions of RPG IV, you don't need prototypes
for procedures in the same source unit. That's a nice enhancement, I think.
Prototypes for procedures in other modules, well, you do have to tell
the linker what to look for - as you know, that's one thing the
prototypes give you. They are only an entry of sorts in the module, anyhow.
Now an addition to RDP might help with this - to provide a means of
discovering the prototype for procedures you use. There is already
something similar for Java calls. Maybe that's already there - I've not
I compare this to C++, for example - you have to declare things - here
is a quote I just found -
"When you declare a variable, a function, or even a class all you are
doing is saying: there is something with this name, and it has this
type. The compiler can then handle most (but not all) uses of that name
without needing the full definition of that name. Declaring a
value--without defining it--allows you to write code that the compiler
can understand without having to put all of the details. This is
particularly useful if you are working with multiple source files, and
you need to use a function in multiple files. You don't want to put the
body of the function in multiple files, but you do need to provide a
declaration for it."
I guess I've understood this implicitly, but I like seeing it clearly
stated - the compiler of the module can finish the compilation, even
though it doesn't have the connection to the actual executable code in
On 2/4/2013 9:20 AM, Steve Richter wrote:
On Sun, Feb 3, 2013 at 8:17 PM, w 4038 <window4038@xxxxxxxx> wrote:
What good is ILE??
I agree with the complaint about the complexity of ILE. The compiler
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.
and OS should be able to abstract a lot of the complexity away. Should
not need procedure prototypes and binding source. Even binding
directories and the listing of service programs to bind to at create
time. Some sort of a system maintained directory of all the procedures
in all the service programs in a library could serve as the basis of a
way the system would find a procedure at run time.