|
Hello Albert, It sounds like you want to invoke the *PSSR manually rather than as the result of an unmonitored exception in the RPG program. In this case the GOTO is probably the simplest choice although you could probably consider using the ILE condition handlers to signal an exception (or a deliberate divide-by-zero error to cause the *PSSR to get control which then returnes control to the start of the detail calculations (*DETC) ). Education for those interested follows: The *PSSR behaves differently depending on how it is invoked. 1/ The usual way is to let the RPG error handler pass control to the *PSSR. This happens for any unmonitored program exception an control is passed to the *PSSR by an internal GOTO. An unmonitored exception is one where no error (LO) indicator is specified. For instance, a divide by zero operation is an error. If you code it as: C DIV 0 RESULT this is an unmonitored exception and the RPG error handler causes an inquiry message to be sent. If you code it as: C DIV 0 RESULT --99-- you are using indicator 99 in the LO column to monitor for exceptions on the DIV operation. You can of course use %ERROR in more recent dialects of RPG IV. If you code it as in the first example but also have a *PSSR in the program then you are performing a global exception monitor (like MONMSG CPF0000 in CL). Note that the *PSSR can also be used to handle file I/O errors by naming it as the INFSR on the F-spec. If control is passed to the *PSSR by the RPG exception handler then you must specify a return point in factor 2 of the ENDSR operation. If you don't then the RPG error handler sends the inquiry message. The choices of return point are CYCLE entry points: *DETC, *TOTC, *GETIN, *CANCL, and a few others I forget. *CANCL ends the program, all the others branch back to some point in the cycle EVEN IF YOU ARE NOT EXPLICITLY USING THE CYCLE. 2/ The second way is to invoke the *PSSR via EXSR. In this case it behaves just like an ordinary subroutine and the ENDSR operation will generally pass control back to the instruction immediately following the EXSR. Regards, Simon Coulter. «»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«» «» FlyByNight Software AS/400 Technical Specialists «» «» Eclipse the competition - run your business on an IBM AS/400. «» «» «» «» Phone: +61 3 9419 0175 Mobile: +61 0411 091 400 «» «» Fax: +61 3 9419 0175 mailto: shc@flybynight.com.au «» «» «» «» Windoze should not be open at Warp speed. «» «»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«» //--- forwarded letter ------------------------------------------------------- > X-Mailer: Internet Mail Service (5.5.2448.0) > Date: Sat, 08 May 99 12:06:59 -0700 > From: "York, Albert" <albert.york@nissan-usa.com> > To: "'MIDRANGE-L@midrange.com'" <MIDRANGE-L@midrange.com> > Reply-To: MIDRANGE-L@midrange.com > Subject: RE: *PSSR subroutine and the call stack > > Shanks for the response. > > I have a batch program which is processing requests from a data queue.There > is a driver routine which uses a series of CAS statements to determine how > to route the request. While processing the request, under certain > circumstances, I may want to abort processing and return to the driver > routine to get the next request. I could use a GOTO but I was hoping the > *PSSR subroutine would work better. > > The decision to abort is always done in the same subroutine which is called > from several places. > > > From: Simon Coulter[SMTP:shc@flybynight.com.au] > > Sent: Saturday, May 08, 1999 3:07 AM > > To: MIDRANGE-L@midrange.com > > Subject: Re: *PSSR subroutine and the call stack > > > > M > > Hello Albert, > > > > No. Control simply branches back to the start of the C-specs (a GOTO). > > > > Why do yo ask, Two Dogs? > > > > Regards, > > Simon Coulter. > > > > «»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«» > > «» FlyByNight Software AS/400 Technical Specialists «» > > «» Eclipse the competition - run your business on an IBM AS/400. «» > > «» «» > > «» Phone: +61 3 9419 0175 Mobile: +61 0411 091 400 «» > > «» Fax: +61 3 9419 0175 mailto: shc@flybynight.com.au «» > > «» «» > > «» Windoze should not be open at Warp speed. «» > > «»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«» > > //--- forwarded letter > > ------------------------------------------------------- > > > X-Mailer: Internet Mail Service (5.5.2448.0) > > > Date: Fri, 07 May 99 12:35:15 -0700 > > > From: "York, Albert" <albert.york@nissan-usa.com> > > > To: "'MIDRANGE-L@midrange.com'" <MIDRANGE-L@midrange.com> > > > Reply-To: MIDRANGE-L@midrange.com > > > Subject: *PSSR subroutine and the call stack > > > > > > > > When you use the *PSSR subroutine and specify *DETC on the ENDSR line, > > does > > > the internal call stack get reset? > > > > +--- > > | 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 > +--- > +--- | 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.