Re: Service program

Keshav,

As you already know, you can make modules, usually NOMAIN modules,
that contain lots of useful procedures that you can call from your
RPG program.

To make these "utility procedures" very useful, you need to be able
to bind them to many different programs.   This becomes cumbersome,
because now when you make a change to your utility module, you have
to first search out all programs that use your module, then you have
to recreate all of these programs.

Another problem with this approach is that when you bind modules
with the CRTPGM command, you're "binding by copy" which means that
each program has a complete copy of the module in it.   Thats not
a very efficient use of disk space!

So this is where service programs come in.   You can take one or more
modules and create a service program.   Then, you can bind this
service program to the programs that you want to call its utility
functions from.  When this happens, you are "binding by reference",
which means that your program only stores "references" to the service
program, rather than an entire copy of the module.  And because its
stored in a seperate object on the disk, you don't have to re-create
all of the programs -- unless the "interface" has changed.

The "interface" for a service program tells the system which
procedures are available for other programs to call, and what order
they are listed in the service program.   This is important because
it determines how the operating system creates "references" when you
bind your programs to a service program.   By creating some source
code for your "interface" you can allow the service program to
have previous interfaces as well as the current interface.  This
is useful if you want to avoid recompiling your existing programs
when you change your service program's interface.

So thats what service programs are...

The RPG code for a service program, instead of a bound module is
identical, so I won't try to show you a code difference.

However, to make a program from two modules, you do this:

CRTPGM PGM(mypgmname) MODULE(module1 module2) actgrp(myactgrp)

To do the same thing, but have module2 be a service program, you'd
do:

crtsrvpgm srvpgm(mylib/mysrvpgm) module(module2) export(*all) +
     text('my service program') actgrp(*caller)

crtpgm pgm(mypgmname) module(module1) bndsrvpgm(mylib/mysrvpgm) +
       actgrp(myactgrp)


and, if (and you SHOULD do this!) you needed to specify your srvpgm's
interface, you'd make a source member like this:

(for example, this might be in MYLIB/QSRVSRC in the MYSRVPGM member)

STRPGMEXP PGMLVL(*CURRENT)
     EXPORT SYMBOL(FirstProc)
     EXPORT SYMBOL(SecondProc)
     EXPORT SYMBOL(ThirdProc)
ENDPGMEXP

And then you'd compile it with:

crtsrvpgm srvpgm(mylib/mysrvpgm) module(module2) export(*srcfile) +
     srcfile(mylib/qsrvsrc) srcmbr(mysrvpgm) text('my service +
     program') actgrp(*caller)

crtpgm pgm(mypgmname) module(module1) bndsrvpgm(mylib/mysrvpgm) +
       actgrp(myactgrp)



Thats really all there is to service programs...   They're not very
different from calling other modules from your RPG programs.

If you need more info, theres details and some good examples in
the "AS/400 ILE Concepts" book which is available in your softcopy
library or in ibm's on-line library at:
http://as400bks.rochester.ibm.com/pubs/html/as400/onlinelib.htm

Good luck!




"keshava narasimha" <anandthirta@hotmail.com> wrote:
> Hi !
>
> Yes I am familiar with the sub-procedures & NOMAIN modules
> Thanks again.
>
> Keshav
>
> >"keshava narasimha" <anandthirta@hotmail.com> wrote:
> > >
> > > Hi everybody!
> > >
> > > I have just started with ILE RPG/400.I am not very clear in
> > >  understanding
> > > Service programs.Could someone from the list  discuss  it with
> > > examples(source).
> > >
> > > Thanks,
> > >
> > > Keshav
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---