Re: binder language, binding directories, bind by copy/reference

Scott,

go to bed!  it's late!  ;)

> *CURRENT is used to signify that this list is the "latest edition" (most
> recent version) of your service program's interface.   *PRV says that
> it's not the most current, but rather an old version of it.

> Why does that matter?   Well, when you compile a new program that uses
the
> service program, which set of routines do you want it to use?!
Obviously,
> the "current" version.   So, you need a way to tell the compiler which
one
> is "current".

> Just, every time you add a subprocedure, or a group of them, to your
> service program, go into the binding source, and change the old interface
> to *PRV, and add a new group where the new subprocs are added, making
that
> new one the *CURRENT.

Ok, I think i've got it.  stop me when I'm wrong..

Does this means you can have multiple *PRV export symbol lists?

The combination of the exports in each list creates the signature that a
previously compiled SP uses.

Programs that use the SP and are (re)compiled will always use the *current.

As long as that signature doesn't change (by keeping an *prv export list in
the binder source when recompiling the SP), the programs that use the old
version of the SP don't need to be recompiled.

So, what happens if you change an existing subproc?  If you change the
prototype, then obviously you'd need to recompile all programs that use
that subproc.

at that point, what do you do to your binder source?  Since all
'signatures' with that proc listed will have changed, do you need to
recompile all programs that use the SP?

What if you don't change the prototype, only the calcs of the subproc, do
you still need to recompile?  do you change the binder source?

> > I've tried reading the ILE concepts guide, but i'm still fuzzy on these
> > topics.  Everytime I look at that thing, my eyes start to gloss over.

> That's unfortunate.   These things are, IMHO, rather simple things.  Too
> many people are afraid of them..   If IBM would write manuals that are
> easier to read, it would sure help!!

They are simple for those with exposure to more oo type languages, but us
old strait line procedural rpg hacks, it's not very intuitive.

IBM does a great job with reference manuals, but when they start to talk
about concepts, they fall a little short.

This has helped a bunch.

Thanks again,

Rick