Re: Module source naming schemes

Hi Jim,

Service programs have a "signature" which is created by doing some sort of
a checksum on all the procedures that you're exporting.  When you add,
remove, or change the order, of the exports in your service program, the
signature changes.

Here's what that means:  When you change your service program, you'll need
to recompile the module, and then re-bind it with the CRTSRVPGM command to
make your service program.   

If the changes you made cause your signature to change, you'll also have
to re-bind all the programs that use the outdated signature.  If it didn't
change the signature, then they'll work without changes.

But wait -- there's more!   A service program can have more than one
signature for backwards compatability, AND you can control what the
signature is.  This allows you, with a little planning, to make sure that
you don't have to re-bind the programs that call your SRVPGM until you
need to use a new procedure.

Whew... I know that all sounds complicated, but it really isn't.  

First, to have any control, you need to create "Bindery Language" source
that describes your program's exports.  In your case, it would look like
this:

STRPGMEXP PGMLVL(*CURRENT)
     EXPORT SYMBOL(RNF_OPEN)
     EXPORT SYMBOL(RNF_READ)
     EXPORT SYMBOL(RNF_CLOSE)
ENDPGMEXP

That's it.   When the binder creates a signature for your service program,
it'll base its checksum on those 3 procedures, in the order specified with
the export statements.

If you decide to add another function, for example rnf_readp(), later on
you'd change your bindery source to look like this:

STRPGMEXP PGMLVL(*CURRENT)
     EXPORT SYMBOL(RNF_OPEN)
     EXPORT SYMBOL(RNF_READ)
     EXPORT SYMBOL(RNF_READP)
     EXPORT SYMBOL(RNF_CLOSE)
ENDPGMEXP
STRPGMEXP PGMLVL(*PRV)
     EXPORT SYMBOL(RNF_OPEN)
     EXPORT SYMBOL(RNF_READ)
     EXPORT SYMBOL(RNF_CLOSE)
ENDPGMEXP

The existing programs will have signatures that match the *PRV section,
and they'll use that interface.  The new programs that you bind will grab
the new signature, and use the *CURRENT section.  Very simple.

You can have more than one *PRV section, so you can keep supporting older
versions as long as you need to.  

Of course, when you do your CRTSRVPGM, you need to make sure you use the
bindery source...   Lets say you put it in SOURCE/QSRVSRC member RNF.

Your CRTSRVPGM just needs:
     EXPORT(*SRCFILE) SRCFILE(SOURCE/QSRVSRC) SRCMBR(RNF)

For more info, check out this link:
http://publib.boulder.ibm.com:80/cgi-bin/bookmgr/BOOKS/QBKAQ700/4.4



On Tue, 9 Jan 2001, Jim Langston wrote:

> Okay.  So now I am going to have four functions.
> RcvNetF(UserName, SysName) where UserName and SysName will be *NoPass
> RNF_Open(UserName, SysName) which will simply call RcvNetF passing the 
>parameters
> RNF_Read() which will simply all RcvNetF passing no parameters
> RNF_Close() which will, currently, do absolutely nothing.
> 
> I don't have to do this at this time, I could put the actual processing
> into the subroutines, but I'm used to doing things this way.  The theory
> being that RNF_Open, RNF_Read and RNF_Close will never change in the 
>parameters
> they are accepting, but RcvNetF may change at any given time depending on
> how I find the best way to do things in the future.
> 
> Which brings up a question.  I build this all into my modules.  I link my
> modules into my service program. I link my service programs into my Bound
> Library.  Then I go and change RcvNetF, and the way it interacts with my
> other calls in the same module.  When I recompile my module, do I have to
> relink it to my service program?  And then do I have to relink my service
> programs into my bound library?  And then do I have to recompile all the 
> programs that use the bound directory?
> 
> Regards,
> 
> Jim Langston
> 

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