× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: *PSSR subroutine and the call stack
  • From: "York, Albert" <albert.york@xxxxxxxxxxxxxx>
  • Date: Sun, 9 May 1999 10:07:42 -0700

Doug, 

Thanks for your reply. What you discuss in your answer is exactly what I was
concerned about. 

Now I'm curious. In my experience, a subroutine call involved saving the
current address (usually on a stack), branching to the subroutine, and
branching back to the saved address ( plus 1 instruction) at the end of the
subroutine. If RPG doesn't do it this way, how does it do it?


Thanks,

Albert.

> ----------
> From:         dhandy@isgroup.net[SMTP:dhandy@isgroup.net]
> Sent:         Saturday, May 08, 1999 12:31 PM
> To:   MIDRANGE-L@midrange.com
> Subject:      Re: *PSSR subroutine and the call stack
> 
> Albert,
> 
> >When you use the *PSSR subroutine and specify *DETC on the ENDSR line,
> does
> >the internal call stack get reset?
> 
> If I infer correctly what you are asking, you are expecting RPG to
> push/pop instruction addresses on/off a call stack when executing
> subroutines.  While most languages do so, RPG does not.  That is one
> reason RPG actually lets you directly branch out of a subroutine to
> detail calcs using GOTO/TAG.  It does not leave an unbalanced call
> stack because nothing was pushed when the subroutine was called.
> (This is also another reason subroutines can't support recursion.)
> 
> So if your concern is whether an unbalanced call stack condition
> happens with *PSSR, the answer is no.  It should be noted that
> subprocedures are different than subroutines -- subprocedures do use a
> call stack and they support recursion.  But they have their own *PSSR
> handling.  And the subprocedure's *PSSR needs to either do a RETURN or
> brach back into the subprocedure where it will eventually do a RETURN.
> Therefore, the call stack remains balanced here too. (Without a *PSSR,
> a subprocedure percolates the exception to a condition handler, not
> the mainline *PSSR.)
> 
> But maybe this isn't what you were asking, in which case never mind...
> 
> Doug
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
> MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
> david@midrange.com
> +---
> 
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.