Re: Benefits of Sub-procedures

[G Armour <garmour400r@xxxxxxxxx>]

Interesting & educational thread.

Bob, I see that you're the IT Manager.  Use your muscle, man!  ;-)

I'm somewhat in a hole as our shop supports clients that use another company's
software package.  Of course, it is written in RPG-III.  However, all new
applications that we develop, what few there are, are written in RPG-IV.  That
aside, however...

Could we get a definition of terms that seem to be used extensively in this 
thread?

What is a procedure?  Do we differentiate between procedures that are coded in 
the
same source member as the main program that calls it vs. those in a service 
program?

In a previous life, I was successful in writing in-line sub-procedures, that is,
procedures that were in the same source member as the main program calling it.  
This
shop used modules (i.e., *MODULE) extensively, and it seemed I was spitting 
into the
wind trying to adopt sub-procedures.  The argument was that there wasn't enough
benefit over a subroutine (this shop had good standards for naming conventions,
modular programs, documentation, and QA testing, so the benefit of local 
variables
was minimized, at least in their eyes).  I used in-line sub-procs as what I
perceived to be a stepping stone to service programs, which was really my goal, 
but
was not allowed to pursue that line further.  ("Modules can basically do the 
same
thing as service programs, and we already do modules, but no one here knows 
service
programs, so that's why we'll just keep doing modules.")

TIA, GA


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com