× 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: "Simon Coulter" <shc@xxxxxxxxxxxxxxxxx>
  • Date: Sun, 09 May 99 10:57:15 +1000


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