It really is a matter of taste which way you go.
Some prefer service programs, some prefer bound-in modules, while others
perfer both.
If you're looking for a solution to the situation where you have one
module bound into more than one *PGM, the solution is a service program.
If you say "so what", then I suppose you don't think you have an issue--so
there's nothing else to say about it.
Certainly if you have a subprocedure used by multiple objects (programs,
service programs, modules, whatever) placing it into a service program has
its benefits--one location, one copy of code loaded, one place to go to
update the object code, etc.
A bound-in *MODULE also has its benefits. One "thing" is put into
production, changing the code in that module only impacts the programs you
update.
If you don't like having to update dozens or hundreds of programs or you
want the ability to add to a parameter list of a subprocedure, then
service programs are you only choice.
This stuff isn't intuitive, but it is easy once you learn the basics.
Someone who doesn't understand that once a *MODULE is bound into a *PGM
that, that module is no longer needed and can be deleted, certainly
doesn't understand how things work. So I can see how service programs
might be a bit too complicated.
But I think if you read some of the on-line materials available like the
ILE Concepts manual from IBM, you'll get a much more clear understanding
of how *MODULEs, *PGMs, and *SRVPGMs work together. And that may be give
you a better understanding of how to move forward and resolve these
questiosn that you have.
But don't get caught up in a "black and white" way of doing things with
this stuff. That is the lazy way out and is almost always wrong. Only use
*SRVPGM's isn't correct, only using bound-in *MODULEs isn't correct
either. They both exist for specific needs. It sounds like your needs have
changed and *SRVPGMs would resolve the challenges created by those
changes.
-Bob
-------- Original Message --------
Subject: RE: ILE question : parmameters, modules and service programs
From: "Jim Wiant" <Jim.Wiant@xxxxxxxxxxxxxxxx>
Date: Sun, May 06, 2007 4:56 pm
To: "RPG programming on the AS400 / iSeries" <rpg400-l@xxxxxxxxxxxx>
There is another way to look at it....
For service programs, the service program itself needs to be in the
production environment along with the application. For bound modules,
only the application needs to be in production (it carries the code with
it). This can have maintenance considerations (we like to change the
production environment as little as possible).
Also, if I'm not mistaken you don't need to recompile programs if you're
making a module change. You can implement the module into production and
do a UPDPGM. As long as the module has not changed it's procedural
interfaces that is all you have to do. I'm not sure if the module needs
to stay in the production environment after a UPDPGM - haven't tried
that yet.
That's a couple reasons why I tend to use modules instead of service
programs in general.
Jim
Taking your module and creating a service program from it eliminates the
need to recompile (rebind) all the programs that use the module whenever
your making changes to your service program. Using binder source, you
can formally define the interface structures used to access the service
program, and maintain compatibility for prior generations of
applications that consume your service program.
There could be runtime improvements for your applications as well, if
this module is used in a large number of programs. When you bind a
module, you are copying that code into the new program object. Each
program in the call stack could be loading the same code (module) into
memory, wasting resources and time. Your program object sizes will be
smaller overall when using service programs.
Eric
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[
mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of David Foxwell
Sent: Friday, May 04, 2007 10:04 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: ILE question : parmameters, modules and service programs
Hello all,
After about 5 years since switching from RPGIII to free form, I fear
that we still have a lot to learn when about ILE.
We do not have a single service program. Instead, we use an ordinary
module containing all the exported procedures. I understand that means
the code is duplicated by each program that uses the module. My question
is, so what? What are we missing.
Another problem is when we need to add a parameter to an exported
procedure. In RPGIII. How do we do this when the procedure is called
from a hundred others?
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/rpg400-l.
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/rpg400-l.
######################################################################
This message was scanned for compliance with Foodstuffs email policies
######################################################################
This message has been sent from Foodstuffs (Auckland) Limited
("Foodstuffs").
The information contained in this message and or attachments
is intended only for the person or entity to which it is
addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other
use of, or taking of any action in reliance upon, this
information by persons or entities other than the intended
recipient is prohibited. If you received this in error,
please contact the sender and delete the material from any
system and destroy any copies.
The views and opinions expressed in this message may be those
of the individual and not necessarily those of Foodstuffs,
and are not given or endorsed by it.
Please note that this communication does not designate an
information system for the purposes of the Electronic
Transactions Act 2002.
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/rpg400-l.
midrange.com
