RE: Service program

[Chris Bipes <ChrisB@xxxxxxxxxxxxxxx>]

Scott,

Thank You.  I new the differences between service programs and modules but
never how to create the service program.  Nor the way to create the
interface.  Your strait forward example is great.  Why can't IBM make their
manuals short, to the point and clear examples.  Please go to work for IBM
as a tech writer.  You would do the industry a great service.

again Thank You,

Christopher K. Bipes
CrossCheck, Inc.

-----Original Message-----
From: Scott Klement [mailto:infosys@klements.com]
Sent: Friday, September 03, 1999 12:53 PM
To: RPG400-L@midrange.com
Subject: 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!
+---
| 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
+---