RE: Subroutines vs Subprocedures was RE: Indicators

1) Yes you can code it as a subproc and callp, but then you either pass
in all the global variables, or raise the question in all subprocs as to
whether a given variable is local or global.

2) Since these subroutines are only there to allow you to break up your
code into more manageable sections. There is no difference between using
them and having the code within the mainline of the program, other than
to make it easier to read.

3) In this case you would either need to copy the subroutine into the
subproc, or see if you can modify the subroutine so that it can be made
into a subproc without creating problems such as accessing global
variables from within a subprocedure. If the subroutine for example
cleared the variables for a file, it would probably make sense to change
it into a subproc even though the field variables are global, since file
field variables are about the only global variables that should be used
in a subproc, even then you should probably limit their use to a single
input and output and refrain from using them as work variables. If on
the other hand the subroutine really needed to be used with in the
subproc, you might need to look at the subproc and see if it should
really be a subproc, or if maybe it should be a subroutine.

4) Changing the subroutine into a subproc will not necessarily make
that section of code less readable, but if it does things like mixing
local and global variables in the subproc, so that you can no longer be
certain that a variable within a subproc is and always will be local, it
can make the entire program or even a large number of programs less
readable. 

Let me try to explain it this way. A subprocedure is a section of code
that can, with extremely minor modifications, be it's own program. It
doesn't have to be a very capable program, but it should be self
contained. A subroutine is part of a program that cannot stand on its
own and is only separated for organizational purposes.

Joe Lee

>>> Lim.Hock-Chai@xxxxxxxx 08/23/2004 15:09:09 >>>
1) You can do this in sub-procedure by simply change the exsr to callp
and change all those subroutines to sub-proc (Once again, this doesn't
means that you should code sub-proc like sub-routine).

2) What if some business rules change and you find out that you now
need to loop thru some global arrays in sub-routine handle_x, y and z.

A typical array looping code is the following:
        for ix = 1 to %elem(myArray)
        ...
        endfor
In this case you will need to declare ix in global section.  However,
if they are sub-proc, you can safely declare it as local variable.

3) What if you happened to create a sub-proc and it happen to make
sense for it to execute handle_x, how should you do that?

4) I don't see how changing them to sub-proc will make it less
readable.

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx 
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Joe Lee
Sent: Monday, August 23, 2004 4:07 PM
To: rpg400-l@xxxxxxxxxxxx 
Subject: RE: Subroutines vs Subprocedures was RE: Indicators


 I find it easier to read
something like this:

if condition x
exsr  handle_x
else
select
when condition y
exsr  handle_y
when condition z
exsr  handle_z
endsl
endif
where each of the "handle" subroutines is several pages of code. 

Than I find reading the same code with the subroutines inline. True
you
may be able to do some of this via subprocedures, and if you can you
probably should. But if the code in question gains no advantage from
being in a subprocedure other than being split up into more manageable
chunks, then I believe that a subroutine is the better solution. 


--
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.