Re: Service Programs 101

["Buck Calabro" <buck.calabro@xxxxxxxxxxxx>]

Dave wrote:

> This should be a quick one for most of you.

On the contrary.  Often, the easiest questions to ask are the hardest
to answer.

> What exactly is a service program,

A service program is a collection of procedures intended to be used by
(mainline) programs.

> I am familiar with creating RPG modules
> and then binding them into a executable program.

That may be the same thing depending on how you then call the code in
the bound modules.  If you use eval [as in eval
myResult=someFunction(aParameter)] or callp [as in callp
someFunction(aParameter: aNotherParameter)], then changing the bound
module to a service program is a pretty easy step to take.

> The service program was successfully created in QGPL.
> I'm using a /COPY member of Scott's to define the procedure.
> I get the following error when I try to do a CRTBNDRPG
> on my program.  Do I need to create my program as a module
> and then bind it to the service program?
>
> MY ERROR MESSAGE:
> Message . . . . :   Definition not found for symbol 'READLINE'.

You're close...  Let me start at the error and work backwards.
"Definition not found' means that the binder (the BND part of
crtBNDrpg) cannot find any PI reference in your (single) module.  The
compiler part (CRTbndRPG) didn't have a problem because the /COPY
defined what the prototype looks like.  The reference to READLINE in
the mainline was understood by the compiler because it had seen a
prototype for READLINE.

Why did the binder not find the PI?  Because no where on CRTBNDRPG is
there a way to specify the location of the PI - the actual procedure
definition.  That's in the service program.  You should double check
that by doing a DSPSRVPGM and making sure the READLINE procedure is
exported.  You can tell the binder how to find the service program
(and therefore the PI) in several ways.

One way is to do a two-step compile & bind, similar to what you do
when you bind two modules together.  CRTRPGMOD on your mainline, and
then CRTPGM and instead of specifying the service program in the
MODULE parameter, you specify it in the BNDSRVPGM parameter.  This
will work for the moment, but I think that many people find it
inconvenient to do two steps to make a program.

Another way is to use an object called a binding directory.  If you go
back and look at the CRTBNDRPG command, you'll see that there's a
parameter called BNDDIR.  You specify the name of the binding
directory you're about to create on that parameter and you can compile
in one step - the familiar PDM option 14.

What's a binding directory?  Oops... guess I should detour a moment to
describe it.  A binding directory is a search path for procedures.
Like a library list or classpath or DOS PATH.  When the binder can't
find a PI (like READLINE) it looks at the first entry in the binding
directory.  Say the first entry is a service program: the binder looks
at all the exports for that service program and sees if any are
READLINE.  If so, it binds to that service program and goes on to the
next 'definition not found.'

Create a binding directory - as a beginner, may I suggest that you
create one single *BNDDIR for your whole company?  Let's call it
NISHIKAWA.  Put it in a library where every developer can use it, say
QGPL or QUSRSYS.  All you need to do now is to add a binding directory
entry, something like ADDBNDDIRE BNDDIR(NISHIKAWA) OBJ((SCOTTSRVPG
*SRVPGM))  Your needs may differ, but you probably want the service
program to be *LIBL and not qualified...  Now you have a way for the
binder to search for READLINE.

So you can now compile with option 14 and BNDDIR(NISHIKAWA), but
that's a pain, isn't it?  You can make it even easier, because the
compiler recognises the H specification keyword BNDDIR!  So you can
put H bnddir('NISHIKAWA') at the top of your program, compile with PDM
14 and never bother with prompting the command.

Give it a whirl, see how it feels and let us know if any of this
advice was worth reading.  We can try to make a FAQ entry out of it to
help others who are just starting out with this stuff.  In this
regard, your feedback is crucial, because you're just stepping on that
first stair.  Some of us are already standing on that stair and have
forgotten what was so new and different about service programs.
  --buck