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

[Scott Klement <klemscot@xxxxxxxxxxxx>]

On Sat, 14 Jun 2003, Richard B Baird wrote:
>
> Does this means you can have multiple *PRV export symbol lists?
>

Yes.  One for each previous version of your service program.


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

I think you understand...   I would've said "a previously compiled PROGRAM
uses." instead of SP.  And, techincally we're talking about BINDING rather
than compiling...

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

Again, they'd have to be rebound, not recompiled.  But yes, unlike
basketball, the point is to avoid rebounds.

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

Using binding language doesn't protect you against parameter changes.
Parameters aren't part of the signature.

But, you're right, if you move the parameters around or change their
types or sizes, the calling program will pass the wrong values and
your service program will probably choke on that.

Instead, only add new parameters to the end of the parameter list, and
use options(*nopass) so that the parameters are optional.  Have code
that checks %parms to determine if the new parameters were passed, and
if not, use the old behavior.  That way, things stay backward-compatible

If you do need a completely different set of parameters, consider making
it a new subprocedure, and tack it on to the end of your service program.


For example, lets say you had a procedure that executed an OPNQRYF.  Maybe
it's parameters are like this:

    D do_OPNQRYF      PI             1N
    D    peFile                     21A   const
    D    peQrySlt                  256A   const
    D    peKeyFlds                 256A   const

But then you have a new project, and the QrySlt needs to be bigger... so
you want to expand it to 1024A.   Instead of changing this subprocedure,
which would break compatibility, add a new subprocedure like this:

    D do_big_OPNQRYF  PI             1N
    D    peFile                     21A   const
    D    peQrySlt                 1024A   const
    D    peKeyFlds                 256A   const

This subprocedure would contain the same (more-or-less) code, but it
would be a whole new subprocedure tacked on to the END of your service
program.

Then, you could change the code for the original do_OPNQRYF to just
call the new procedure, so that you didn't have to two sets of code
for OPNQRYF.

The point is, keep the original prototype intact, to preserve backward
compatibility!

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

As I mentioned above, parameters are not part of the signature.  You
can change the parameters without the binding source knowing that anything
has happened.

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

No, in that case you don't need to change the binder source or recompile
the calling programs.  In fact, that's what happens MOST of the time when
you change a service program.  usually you've found a simple bug somewhere
and you just need to fix the calcs.   Nothing that calls your SP needs to
change, because the external interface of your SP hasn't changed.

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

I don't think of this stuff as OO related.  It's more like shared object
libraries in Unix or DLLs in Windows.  Except, IMHO, it's better because
of signatures and binding language.

Really, though, all you're doing in binding language is making a list
of things that you want to export.

STRPGMEXP PGMLVL(*CURRENT)
   EXPORT SYMBOL(PROC1)
   EXPORT SYMBOL(PROC2)
ENDPGMEXP

That's it... just a list of things to be exported.  Everything else is
just syntax, and/or avoiding gothcas.

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

They do a great job with the RPG reference manuals.  IMHO,the more recent
stuff, like Digital Certificate Manager, QShell, etc are not well written.

My observation of IBM manuals is that they make a ton of sense after
you've already learned the material, and aren't very useful if you don't
already understand it.

People learning stuff don't need to be given every detail and every
possibility of the material thrown at them at once.  They need something
very simple, at first, so that they get the underlying concept.  Then, you
build upon that understanding... add new concepts as you go along.

But throwing a bunch of complicated terms at someone in the beginning
makes them stop, say "this is too complicated, I'll come back to it when I
have more time!"

and then they give up.

Thats just my observation.  Occasionally, I'm actually right.