RE: Function Opinion

Aaron,

On Wed, 2003-10-15 at 16:43, Bartell, Aaron L. (TC) wrote:
> In our shop we do the one module to one service program way with potentially
> many sub procs in each module.  Not that we think multiple modules in a
> service program is bad, it has just worked out this way for us so far.  It
> really comes down to having somebody oversee all development and then make
> sure all related modules get bound together in a appropriately named service
> program.

I think this can be a good approach and I use this approach for file
access service programs (and display file stuff too).  One module,
multiple procedures, one service program.  I then put all of the
application wide service programs in one binding directory.

> How would it work if you were binding many modules in one service program
> and you only needed to change one module in a service program?  Would you
> use the update service program command, create the entire service program
> over?

No big deal, you just update the service program.  In the case of
additions you recreate the service program (this is where binder source
becomes so cool).  At that point you no longer need the *MODULE objects,
so as long as you are shipping the updated service program you are good
to go.

> This is where one module to one service program benefits my shop I think.
> We have to distribute our software to our remote companies once a month (at
> least) and if we bundled many modules in one service program we might be
> sending unchanged code.

Again, you only need the *SRVPGM object, so you don't need the multiple
*MODULE objects.  Grouping multiple modules into a single service
program is therefore easier to distribute.

Also, if you are using binder source and multiple signatures, then older
programs will still run without changing a thing.

> Just some thoughts,
> 
> Aaron Bartell

Always glad to hear from you!

Joel
http://www.rpgnext.com