RE: Wrapping API in service program

On Wed, 12 Sep 2001 lisa.thomas@Hayssen.com wrote:

> Unless the majority of the functions in each program would be used in most
> programs, most programs will be bigger than required.

This isn't true.   You appear to be confusing *SRVPGM's with *MODULEs.
If you bind your programs directly to the module, then your statement
above is true.   But when binding to a service program, the number of
procedures in the service program does not affect the size of the original
*PGM object.

> Also if you need to
> change the parameters on a function with or without binding language, it
> would seem you would be rebinding many more objects.  This would hold
> especially true for APIs that may add functionality requiring different
> parameters.

Creating a service program and not using binding language is always a bad
idea.   Since the binding language is little more than a list of the
procedures that you want to export, it takes virtually no time at all to
write.   (Even for VERY large service programs, I've done my binding
language in under 10 minutes)

>
> I have used the single function service program model along with a binding
> directory for several years and have been satisfied with it.
>

For each service program, you need  (1) a source member with the code for
each module (though in your scenario, it's probably a 1:1 relationship)
(2) a source member containing prototypes (you ARE using prototypes aren't
you?) and (3) a source member containing the binding source.   If you do
this for every API on the system, just keeping track of all the source
members seems like it would be a nightmare.

And -- although this isn't particularly important to me -- you're using
more disk space this way.  Putting multiple procedures in the same *SRVPGM
would reduce the amount of disk space the compiled objects are taking up.

I agree with Buck's approach.   Use one service program for each group of
related procedures...