Re: Wrapping API in service program

I've considered this approach myself, but I haven't found a particularly
good approach.  Here are some thoughts, mostly disorganized :)

I already create RPG prototypes for the APIs before calling them.

A simple wrapper usually doesn't significantly improve the interface of
the API any more than just prototyping it would.  I've found that in
order to support all of the functions of any given API, my parameters end
up being very nearly the same as the ones IBM provides.

Even if I can simplify them a little bit, when I upgrade my system and
get newer versions of the APIs, I'll have to go through the extra work of
upgrading my wrappers.

When the next programmer looks at my programs, he's got to figure out what
the heck I'm doing.   If I use IBM's APIs directly, he'll be able to
perform a search of the info center and find documentation explaining the
API.  If he gets especially stuck, he could post a message to a list like
this one, or ask a collegue, with a good chance that they'll be able to
help him.    If he's using my wrapper program, however, this will be a
little more difficult.

So, after all of this, I came to the conclusion that this probably would
create more of a maintenance nightmare than it would solve.

However, if I don't try to provide every capability that a given API is
capable of, it works out better.

For example, Let's say I wanted to write a routine that just sends a
status message to the display, I could make a generic routine that uses
the QMHSNDPM API.  It could be set to always use CPF9897 from
*LIBL/QCPFMSG, and always send to the same call stack entry.
Consequently, the only parm it would need is the actual message data...
Calling this from all over saves a lot of coding.

Another example might be a routine to retrieve the IP address of the
current job.   It wouldn't need any parms, just a return value of the
IP itself.   This would be signficantly easier than calling QDCRDEVD
directly...

So, to conclude, I think that when you have specific details that you
want to get from an API, and you do it the same way frequently, it's
easier to have a procedure in a service program with a very simple
interface.   But, if you intend on supporting all functions of an API,
by using a simple wrapper around that API, you'll probably just complicate
things without saving much work.

That's my opinion, anyway.

On Wed, 12 Sep 2001, Buck Calabro wrote:
>
> As I work with more and more APIs, I want to wrap them in my own procedures.
> I want to make these procedures available to others in my shop; service
> programs seem just the ticket.  My first thought was to wrap each API
> "family" in it's own service program, so I'd have one service program for
> user spaces, one for retrieving program information, etc.  This seems a fair
> balance because a single program will only need to bind to a few service
> programs in order to work.
>
> 1) Any contrary ideas?
> 2) Any practical experience to support/refute this plan?
>