RE: ILE Propoganda

[Buck Calabro <Buck.Calabro@xxxxxxxxxxxx>]

> His comment, "It sounds awfully complicated, so why not just create
> a program and call the program?

In a word, Performance.

It is much more expensive to CALL a program than to CALLP a procedure.  Look
at all the cool stuff OS/400 does when you CALL a program (I'll probably
miss some stuff):

o If CALL *LIBL/PGM, search each library in the library list for PGM
o Validate authority to PGM
o Page PGM into main store
o Create static storage areas if they don't exist yet
o Create automatic storage areas
o Open files
  o Search *LIBL/OVRDBF for each file
  o Validate authority to each file
o Begin execution

The S/38 performance whizzes used to eliminate the time to
find/open/validate each file by using shared ODPs.  The "main" program would
open every file used in the application and specified OVRDBF xxx
SHARE(*YES).  The cost to open the file became a one time affair, because
every subsequent open became a "pseudo open."  

Another performance kick was to RETURN instead of SETON LR.  By leaving the
program in the invocation stack, subsequent CALLs didn't have to initialise
the various buffers and variables; the values are left over from the
previous CALL.

These techniques were not widely used; probably the majority of programmers
thought them too complicated because the code to do this work is scattered
among the various programs in the application; you can't see all the logic
in one source member.  As if I could understand my RPG program without
looking at the CL and OVRxxx anyway.  Oops.  Sorry for the rant.

Since every other platform had static binding, IBM added that to our bag of
tools: ILE.  If your man wants to use dynamic CALLs, have him do a benchmark
and see the reason ILE is superior, performance-wise.

We could always have "libraries" of programs to do work for us; INTCALC to
do interest calculations, DATEPGM to handle dates, STRINGPGM to manipulate
strings, etc.  Because of performance issues, we simply haven't.  That means
the darned code is scattered among the various "mainline" programs instead
of reused from a central repository.  With good performance, we'll finally
start building up reusable service programs that the other programmers can
use without having to worry about integrating and testing the function every
time it's reused.

Buck 
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---