|
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 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.