Adam,
I think you need to bone up on subprocedures, service programs and modules a bit
more.
Certainly by not comparing apples to apples, one can make an argument that one
type of development appears easier than another. I see this all the time in
arguments and debates.
Certainly learning *MODULEs and *SRVPGMs after using RPGIII or RPG IV and single
*PGM objects is not as intuitive as, for example, learning the syntax for the
READE opcode after having experienced READ and CHAIN for years.
I often find in shops I teach in, that there is that "one guy" who already knows
all this stuff. But except in very rare cases, it is that one guy who learns
that what he had been doing is all wrong.
Now why would that be? Why would it be wrong? Well, in word "busy".
The scenario often unrolls like this:
Hey Steve, go try some of that ILE stuff; modules and service programs, and see
if we can use it. And just like the first time someone builds their own house,
edits a movie, writes a book, buys a boat, they often make mistakes and have
assumptions based on prior experiences that may or may not necessarily apply to
(in this case) "ILE stuff".
So they do things a certain way and end up with stuff that mostly works.
The bad news is, this guy's stuff is then often used as standards for the
shop--so everyone else in the shop ends up clone the code that really is awful
to begin with.
Then, down the road, they run into trouble maintaining the modules, programs,
and subprocedures because they didn't set good standards--had a poor foundation
to begin with.
While ILE is not by any means Rocket Science, it is complex and needs to be
learned--it is, as I said, not intuitive. But like most things that are learned
correctly, ILE stuff can be easy, once you've learned enough of the vocabulary
and seen a few good examples.
-Bob Cozzi
www.i5PodCast.com
Ask your manager to watch i5 TV
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [
mailto:rpg400-l-bounces@xxxxxxxxxxxx] On
Behalf Of AGlauser@xxxxxxxxxxxx
Sent: Monday, May 07, 2007 8:34 AM
To: RPG programming on the AS400 / iSeries
Subject: RE: ILE question : parmameters, modules and service programs
bob@xxxxxxxxxxxx wrote on 06/05/2007 20:15:29:
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.
I (partly) disagree. It depends on the nature of the change to a *MODULE
object whether or not you need to "update dozens or hundreds of programs".
If need to make a bug fix to the operation of a subprocedure in a
*MODULE, and every program using that *MODULE needs to access the fix, you
need to recompile everything. I don't have a good idea of what percentage
of changes typically fall into this category, but I suspect it is fairly
large (> 50%)?
However, I can think of a couple of scenarios where making a change to a
*MODULE is as simple or even simpler than changing a *SRVPGM.
1. Adding a new procedure. Only the *PGM objects that need to use the new
procedure need to be updated. You are probably rebuilding these objects
due to other changes anyway if a new procedure is required.
2. Adding a parameter to a procedure. Again, only the *PGM objects that
need to use the new parameter need to be updated. You are probably
rebuilding these objects due to other changes anyway if a new procedure is
required. It is even a bit simpler than adding a parameter when using a
*SRVPGM, as you could get away with not using *NOPASS (though it is
probably not advisable to do so).
That said, having a bunch of *PGM objects which each contain a different
version of a particular *MODULE might be more of a pain than doing an
UPDPGM on all of them each time you change the *MODULE, so while you _can_
do it, it may not be wise depending on your environment.
HTH,
Adam
Attention:
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 message in error, please contact the sender and
delete the material from any system and destroy any copies. Thank you for your
time and consideration.
Attention:
Le contenu de ce message et(ou) les fichiers ci-joints sadressent
exclusivement ` la personne ou -entiti ` laquelle ils sont destinis. Ils peuvent
contenir de linformation confidentielle, protigie et(ou) classifiie. Il est
strictement interdit ` toute personne ou entiti autre que le(la) destinataire
privu(e) de ce message dexaminer, de riviser, de retransmettre ou de diffuser
cette information, de prendre une quelconque action en fonction ou sur la base
de celle-ci, ou den faire tout autre usage. Si vous avez regu ce message par
erreur, veuillez communiquer avec lexpiditeur(trice), supprimer ce message et
les fichiers ci-inclus de tout systhme, et en ditruire toutes copies, quelles
soient ilectroniques ou imprimies. Nous vous remercions de votre entihre
collaboration.
midrange.com
