RE: dRE: No Subroutines (was Re: Debugging many subprocedures)

 
> Okay, but in this case a subprocedure call would've been 
> better if it weren't for a flaw in that particular API that 
> prevents you from specifying where the message is coming from.
> 
> For example, the following code would've been better:
> 
>       if field1 = 'bad';
>          diag('Field 1 must not be bad');
>       endif;
> 
>       if field2 = 'bad';
>          diag('Field 2 must not be bad');
>       endif;
> 
> The only reason you can't use it is because there's no way to 
> tell that API that diag() is a wrapper procedure and that the 
> "real" originator is the proc before it.  So you use a 
> subroutine purely because it doesn't create a different call 
> stack level.


You're right, but it's little comfort to know why it's not possible. I still
have to deal with the fact that it can't be done. Fortunately, I'm still
able to make use of the subroutine to achieve my objective without
cluttering the code.

> There's another situation where subroutines make sense as 
> well...  the situation of wanting to have a *PSSR that 
> catches any errors in a subproc.
> 
> But other than those two situations, I can't envision why 
> you'd ever want to use a subroutine in RPG.


So you can't envision it. Ok. Go in peace brother... 

Human diversity is such that there are sure to be others who can:

someUsefulProc  b
                        pr
 * required parms
  iParm1                         1a     const
 * optional group 1 parms
  iParm2                         1a     const options(*nopass: *omit)
  iParm3                         1a     const options(*nopass: *omit)
  iParm4                         1a     const options(*nopass: *omit)
 * optional group 2 parms
  iParm5                         1a     const options(*nopass: *omit)
  iParm6                         1a     const options(*nopass: *omit)


        exsr initialize;
        
        // do some real work

        return;
 
  //**********************************************
  // Subroutine: Procedure Initialization
  //**********************************************
  begsr initialize;
        
        // test input parms for validity
        // iParm 1 must always be passed
        // iParms 2,3,4 must be passed as a group
        // iParms 5,6 must be passed as a group
        // if validation fails, throw an escape message to caller
        
  endsr;


someUsefulProc  e


The validation logic on the input parms can become pretty wordy when you're
testing a number of different conditions. With a procedure interface, I
write the initialization code once and can safely forget about it. I really
don't want this "housekeeping" code distracting me at the start of every
procedure. 

In any event, this discussion --while fun-- is not very productive for
either one of us. Subroutines exist in RPG, and each programmer is free to
use them where and when they determine it's appropriate. I was just rankled
into responding by the predictable crying of the purists (silly me).
Fortunately, they're a minority -- albeit a rather vocal one.


Regards,


John Taylor