Re: Conditional Processing with NoPass Parameters

jrc@xxxxxxxxxx wrote:
> 
> This is a little too pocket protector-ish for me ... how do I fix it?  Use 
> procedure variables instead of paramaters and populate the variables based on 
> the parms sent?
> 

That's the usual way.  I like to initialize the procedure variable with
the default value, and then update it with the parm if the parm was
passed.

D CalcDat         pr                  
ExtPgm('CALCDAT')           
D  inpDat                       10                 
D  inpDatFmt                    10                 
D  inpDays                       4  0              
D  outDat                       10                 
D  outDatFmtP                   10   Value
Options(*nopass)               

D outDatFmt       s                  Inz(myDefaultValue)
 /free
    If %parms() > 4 ;
      outDatFmt = outDatFmtP;       // add this
      If outDatFmt = *Blanks ;          
        outDatFmt = inpDatFmt ;         
      EndIf ;     
 // Else ;                          // don't need this
 //   outDatFmt = myDefaultValue ;  // don't need this
    Endif ;                    

> I don't claim to understand all this memory management type stuff, but if 
> this is a potential problem then why allow it?  Doesn't the procedure 
> allocate all the storage it needs?  The procedure knows the parm is used as a 
> local variable and space is allocated for the variable, so why wouldn't there 
> be storage allocated for it, passed or not?
> 

The space for a parameter is allocated on the parameter stack by the
caller, so it's only enough space for the parameters that are actually
passed.