RE: Benefits of Sub-procedures -- RPG400-L

Bob:

The discussion needs to begin with the concept of Modularity. I've yet
to meet a programmer who doesn't agree that a modular approach to
application programming is a good thing. It simplifies development,
testing, and maintenance.

Obviously, the programmers you refer to have some understanding and
acceptance of this principle , since they're advocating the use of
program call's. Within those programs, I wouldn't be surprised to find
sub-routines, which is further evidence of their acceptance and
application of modularization.

Once you've established that everyone agrees modularity is a Good Thing,
it's time to ask them why they bother writing sub-routines, when they
can encapsulate that logic in an external program instead. They'll have
no trouble coming up with a list of reasons why sub-routines are useful
sub-divisions of a single program. Then use their own list of reasons as
the starting point for why procedures are useful.

I believe that it's easier for them to initially think of procedures as
an alternative to sub-routines, rather than programs. 

Their next question is likely to then be, "so why not just continue
using a sub-routine?". Well, basically, it's easier to implement a
modular programming approach with procedures than it is with
sub-routines. Why? Because, among other benefits, procedures provide us
with local variables and an argument list (parameters). 

Since sub-routines offer neither of these useful features, they often
end up having to reference and/or manipulate global variables. Now,
which one of those programmers hasn't had the painful experience of
jumping around a source member trying to track down various references
to a global variable referenced in a sub-routine? And how many times
have they had to come up with names like WKN001, WKN002, and so on, for
temporary numeric variables used within a calculation? Maybe they'd
appreciate the ability to take that CALCTX sub-routine they currently
have, change the name to "calculateTax()", and use variable names like
"taxableAmount", "taxAmount", "totalAmount", without worrying about
where else those names might have been defined within the same source
member.

In my opinion, it's best to leave service programs, AG's, bindable
modules, and the like, off the table in the beginning. Just get them to
start using a procedure here and there where they might otherwise have
used a sub-routine. Before long, they'll have come up with this great
new procedure which will inevitably end up being /copy'd into their
programs. That's when you start approaching the subject of bindable
modules, and service programs.

On the other hand, if you find yourself in the company of those who
don't even see the point of modularity, then it's time to call in Scott
and his .30-06. 

Good luck,

John Taylor

> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx 
> [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Bob Cagle
> Sent: Wednesday, October 22, 2003 3:05 PM
> To: RPG400-l@xxxxxxxxxxxx
> Subject: Benefits of Sub-procedures
> 
> 
> I'm looking for some ammo, guys!
> 
> I personally have been using RPGIV and sub-procedures, 
> service programs, etc. since '96.  But I am running into an 
> ever increasing number of programmers that ask the basic 
> question "Why use a sub-procedure when it does the same thing 
> as a program call?"
> 
> I always spout the performance benefits, plus the ability to 
> call a procedure from within an expression and return a 
> value.  But even then it sometimes isn't enough to convince them.
> 
> Can anyone give me some more compelling reasons for switching 
> completely to ILE RPGIV?  Remember, these are typical 
> business programmers and statements like "it's cool/fun/looks 
> & works like java/etc." is just even more of a turnoff for 
> them.  I'm looking to give some sound business reasons for the change.
> 
> 
> p.s. And I have tried arguing easier maintenance - which they 
> will always argue that pure ILE RPGIV is harder to maintain 
> because of the increased number of objects and source members 
> to keep track of!
> 
> Bob Cagle
> IT Manager
> Lynk, Inc.
> 913-492-9202 x41