Re: Service Programs 101

> This should be a quick one for most of you.  What exactly is a service
> program, or rather, how are they implemented?  Is a service program like a
> compiled, standalone subroutine or module of multiple subroutines?

A *SRVPGM is just like a *PGM, except for two things:

a) You can export subprocedures so that they can be called individually.

b) You can't call a SRVPGM directly with the CALL command, it must be
called from a *PGM object.

Usually, yes, a service program is used as a library of subprocedures that
can be called from programs.

It's similar to a *MODULE (it's actually made of modules, like a *PGM is)
except that when you bind modules together, copies of those modules are
included in the *PGM.  When you bind to a *SRVPGM, there's only one copy
of the *SRVPGM that gets shared by all of the programs that use it.

The nice thing about having one copy, instead of a separate copy for each
program, is that when you want to make a change, you only have to
re-create one object, rather than many.  Saves a lot of time & headaches
on the maintenance side.

> I've read the comments people have made in reference to them but haven't
> had a need for them so far.

I think it's more likely that you do have a need for them, and you just
don't know it yet.  :)


> I'm still getting my feet wet with procedures and procedure interfaces.
> (I've used them for CALLP's and for replacing *ENTRY PLIST).  This may
> or may not be applicable but I am familiar with creating RPG modules and
> then binding them into a executable program.

You can't use procedures or procedure interfaces with CALLP or *ENTRY
LIST.  You're confusing procedures with prototypes. They're related, but
they're not the same thing.

Learning procedures is probably the best place to start, I think you're on
the right track.  Once you use subprocedures all the time, you'll find
yourself saying "I wish I could put this subprocedure somewhere and call
it from all of my programs!".  And then the light goes on and you say
"service programs are great!"

And then you start saying "I'm tired of having to remember to use
BNDSRVPGM() every time I compile this program."  and then the light goes
on about binding directories...


> Specifically, I've been adapting some of Scott Klement's code for reading
> and writing to the IFS in preparation for a project that's coming up.  It's
> been going good so far but one of the examples creates a service program
> and uses it in later programs.  I want to try to use it in my program but
> I'm not sure if I understand the implementation.
> 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?

That would work.  An alternative is to create a binding directory, and
include that binding directory on the H-spec of the program you're calling
it from.

There's instructions for building a binding directory for the IFSTEXTR4
service program at the bottom of the following page:
  http://scottklement.com/rpg/ifs_ebook/textreading.html

(The same instructions are in the .PDF copy of the document as well, but I
don't know the page number off the top of my head)

Once you've got a binding directory, you just need an H-spec like this:

   H DFTACTGRP(*NO) BNDDIR('MYLIB/MYBNDDIR')

Plus, you have to copy the prototypes in with:

    /copy mylib/qrpglesrc,ifstext_h

Those two lines of code are all it takes.  You can now access all of the
routines.  Presto! :)


> MY ERROR MESSAGE:
> Message . . . . :   Definition not found for symbol 'READLINE'.

Library list is irrelevant...  *SRVPGM's are either explcitly included
with the BNDSRVPGM() parameter of the CRTPGM command, or by putting them
in a binding directory and including it on the H-spec or on the CRTBNDRPG
BNDDIR() parameter, or the CRTPGM BNDDIR() parameter.

What a lot of people will do to make things even simpler is put *ALL*
service programs in a single binding directory, and include that BNDDIR()
in every program that they write.  Then you never have to worry about it.