Re: Recursion in RPG

[Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>]

Hi Phil,

The authors statement that you cite (about RETURN) doesn't make any 
sense. Just because you write it in an article doesn't mean you're 
right!  (Lord knows I've made mistakes in articles!)

Anyway, whether or not he has a RETURN statement there will not make any 
difference at all.  It will still go to the ENDIF line of the preceding 
call stack entry after the RETURN.  And yes, that's the expected 
behavior.  If it didn't work that way, I wouldn't call it recursive!

As for system limits -- the big one I've run into is the maximum amount 
of automatic storage allowed in the single-level storage model. You can 
only (approx) 16 mb of automatic storage for the entire call stack -- 
that's all procedures added together!   This can be "solved" by using 
STGMDL(*TERASPACE)

I'm not aware of any other limits.

In my opinion, the article you cite does not provide a good example of 
recursion, or explain why you'd want to use it.  Seems to me his example 
would make more sense if it was just run in a loop instead of run 
recursively.  Recursion only comes up occasionally in business 
programming.  Something like a bill of materials is an example where 
recursion makes sense...  but aside from that, recursion is pretty rare 
in business programming.


On 2/14/2013 12:50 PM, ssc1478 wrote:
> I recently read this article:
> http://ibmsystemsmag.com/ibmi/developer/rpg/rpgle_recursion/
>
> and was interested in this comment:
> "Even though this procedure doesn’t return a value, it’s a good idea to
> have a return statement on the end so the program can exit right away after
> it reaches the end of MGACCM. Otherwise, it will unwind itself by going
> from the Endif line to the end of the procedure for as many records as were
> written."
>
> What I've noticed is that each recursive call puts an entry on the call
> stack, and at the end it "unwinds" down the call stack until it can exit
> the subprocedure.  I thought the author's comment above was addressing
> that, but it made no impact on my test pgm.
>
> Is that the expected behavior?  I'm worried about a long-running job
> running into a system limit.  Does anyone know?
>
> Thanks,
> Phil