× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.