RE: Subroutines vs Subprocedures was RE: Indicators

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.