RE: Wrapping API in service program

[Scott Klement <klemscot@xxxxxxxxxxxx>]

It has to resolve the references for each procedure at compile time,
anyway.  It doesn't matter if they're in one service program or 10
service programs, it still has to resolve them....

Binding language is EXTREMELY simple.  I strongly encourage you to take
an hour or so (actually, I'm not sure that it took me that long) to learn
it.   Without using binding language, you'll have to recompile all the
programs that use a given service program each time you change the service
program!   It'll save you many, many, many hours to use binding source.

Really, making service programs without binding source should ONLY be done
in a classroom/experimental scenario.   Once you're using this stuff in
production, it should ALWAYS have binding source.


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

> Your correct that since it is a service program the size would not be
> affected but it would need to resolve the references.  I am using the
> prototypes but not putting them in a separate source member.  Also at this
> point using very little binding language so no binding source either.
>
> -----Original Message-----
> From: Scott Klement [mailto:klemscot@klements.com]
> Sent: Wednesday, September 12, 2001 2:04 PM
> To: midrange-l@midrange.com
> Subject: 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...
>