Re: Diff between static binding and dynamic binding

> 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 make
> >      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 combine
> >      them to make your program.  The different modules can even be
> >      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 of it as
> "parameter binding."  Since OPM parms are passed by reference, that means
> that the called program needs to know the addresses that the caller 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!
> 
==========
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 procedure
> > 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?
> 
> >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 use 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).  
> 
==========
To be added:

> > Otherwise, you should explain the differences btw EXTPGM, EXTPROC 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.


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