Re: Diff between static binding and dynamic binding

My comments are in-line.

Buck Calabro <mcalabro@commsoft.net> wrote:
> > Scott,
> >
> Here are all the bits that needed clarification/discussion.  Some of
>  this
> stuff is hard to distill into a few words!  :-)  Help!
>
> > ==========
> Needs discussion:
>
> > > Q. What is binding?
> > > A. In an ILE language, when you compile your source code, you ma
> > >      a *MODULE object.  Binding is the act of combining one or
>  more
> > >      modules into a callable *PGM object.  This allows you to
>  write
> > >      your source code in smaller, more modular, chunks and combi
> > >      them to make your program.  The different modules can even
> > >      written in different languages.
> > >
> > > Q. What is the difference between Static and Dynamic binding?
> > > A. Dynamic binding is the "traditional" way for one program
> > >     to call another.  Static binding is the "ILE" way.  Static
> > >     binding is much faster at run time than dynamic binding.
> > >
> > >I'm not sure that "dynamic binding" is the correct term...  Is it
> > >A dynamic program call is NOT BOUND, is it?  I suppose you could
> > >refer to calling a procedure in a service program "dynamic
>  binding",
> > >but it gets a bit confusing if you refer to "dynamic calls",
> > >"bound calls" and "dynamic binding."
> >
> > Good question.  What does binding mean, anyway?  I tend to think o
>  it as
> > "parameter binding."  Since OPM parms are passed by reference, tha
>  means
> > that the called program needs to know the addresses that the calle
>  uses
> > to
> > store the parm values.  In essence, the called program modifies
>  memory
> > within the calling program's address space.  Getting a good
>  definition of
> > "binding" might be very useful for this mini-FAQ!
> >

I think its more than just parameters...   Like maybe the addresses
of the procedures themselves...   I don't know this for certain, but
it seems logical to me that this would be the way you'd want to do it.

Most parameters in ILE are also passed by reference.  Unless the
"value" keyword is used...  Essentially all this entails is passing
a pointer to the variable for the parameter -- to the called program.

The called program then puts its variable in the same area of memory,
which means that anything thats changed is changed for both programs.

When called by value, the programs each have different areas of memory
for their variables, but the byte values are copied from the caller's
area of memory to the called's area.

In my current understanding, binding is the act of finding all of
the procedures that are called (except for dynamic calls, of course)
and putting either a copy of the called module into the program
(i.e. bound by copy) or by placing a the address of the routines
to be called from their service programs into the program being
created (bound by reference)

Perhaps other people on the list would be able to give more input on
this?

> ==========
> To be added:
>
> > > Q. What is the difference between a dynamic program
> > >     call and a static procedure call?
> > > A. With dynamic binding, the "connection" between the
> -snip-
> > >
> > > You should also probably differentiate between calling a procedu
> > > in a bound module vs. calling a procedure in a service program.
> >
> Q. What is the performance difference between bind by copy
>     and a service program (bind by reference)?
> A. Simplistically, calling a "bind by copy" procedure is about
>     as fast as a traditional EXSR call, because the called code
>     is embedded right there in the program object.  A call to a
>     procedure in a service program is a bit more complex to
>     explain because the performance relates to the number of
>     procedures bound in the service program.  When you call
>     the main program, the service program is activated at the
>     same time.  The activation takes more time for each
>     procedure bound into the service program.  This "hit"
>     happens once, when the main program is called.  Actual
>     CALLPs to the service program's procedures take about
>     the same amount of time as an EXSR.  For details on
>     service program activation, see the ILE Concepts manual.
>
> ==========
> Needs discussion:
> >
> > Q. What difference does it make to the programmer?
> > A. If you currently program using many CALL operations,
> >     you can transition pretty quickly to CALLP because
> >     you're used to dealing with parameters.  Service programs
> >     are very much like a library of commonly used
> >     procedures.
> >     If you don't currently program with many CALLs, you'll
> >     need to get used to the idea of local variables, and
> >     accessing them via parameters.
> >
> > >CALLP can do both static and dynamic calls, which
> > >makes its use here sort of misleading.
> >
> > Agreed, but where do we draw the line on how complex to make an
> > introduction
> > to ILE and procedures?

True.  To my thinking, the question is asking "Whats the difference
when programming to use bound calls instead of dynamic calls?"
Then the answer is telling you how easy or hard the transition will
be.  Perhaps the question should be something like "How difficult
is it for a programmer to make the transition from dynamic calls to
bound calls?"

And perhaps another question should ask "What do I do differently in
my program to make bound calls instead of dynamic calls?"

That question can say very shortly "Use the CALLB command, or better
yet, create a prototype and use the CALLP command."  And then later
questions can outline the difference between the different call
commands, as you suggested below...

> > >Perhaps you meant to use CALLB, which only does
> > >static calls -- and is also much more similar to CALL
> > >in syntax -- rather than CALLP.
> >
> > I deliberately used CALLP because I'd probably never advise the us
>  of
> > CALLB
> > - there's way too much value in a prototyped CALLP than the clunky
>  CALLB.
> > Perhaps that needs explanation:
> >
> > Q. What is the difference between CALLB and CALLP?
> > A. CALLB follows the more traditional format of the CALL
> >     op-code, but is limited to calling procedures that are
> >     bound by reference.  The limitation is that it is easy
> >     to mis-match the parameter definitions between the
> >     caller and the called procedure.
> >     CALLP requires a prototype definition, much like C.
> >     This helps to enforce parameter matching.  It also
> >     allows you to use a procedure as a function, on
> >     the right side of an EVAL statement, like
> >     EVAL Title = GetTitle(EmployeeNum).
> >

Perhaps add in a line about "with the EXTPGM keyword on your prototype
you can even use CALLP to do dynamic calls!  See 'How do I prototype
calls to OPM programs...' below."

> ==========
> To be added:
>
> > > Otherwise, you should explain the differences btw EXTPGM, EXTPRO
>  and
> > > local procedure calls. :)
> >
> Q. How do I prototype calls to OPM programs like
>     QCMDEXC?
> A. Use the EXTPGM keyword on the prototype; you
>     won't need to have an actual procedure interface:
>     DQCmdExc          pr                  extpgm('QCMDEXC')
>     D Command                       80a   const
>     D Length                        15p 5 const
>
> Q. How do I prototype calls to a procedure in a
>     service program?
> A. No special coding is required.  Simply copy the
>     procedure prototype definition from the called
>     procedure into the calling program.  By far, the
>     easiest way to do this is to put the definition
>     in a /COPY member, and /COPY it into every
>     program that needs it, including the module that
>     ends up in the service program.
>
> Q. What is EXTPROC used for?
> A. EXTPROC is the way to utilize the bindable APIs
>     like CEEDOD or the C library functions.  You can
>     create your own bindable procedures by creating
>     a binding directory and adding the modules or
>     service programs to it.  When you use EXTPROC
>     you are doing a bind by copy.  You specify
>     BNDDIR on the CRTRPGMOD command, and
>     that's how the system knows where the executable
>     code is to be found.  Like EXTPGM, you only need
>     a procedure prototype, not the procedure interface.
>

Perhaps say something like "EXTPROC allows you to have a different
internal name for a procedure than its external name, much the way
the RENAME keyword on the F-specs lets you use a different record
format name"  Then, use the bindable APIs and C-functions as examples
of when the use EXTPROC.


You're doing a great job on this Buck!   This thing will be much
easier to understand than IBM's docs! :)

+---
| 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
+---