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



Nice catch Simon, you are correct.

Msg_Throw() was throwing the escape message back 2 entries:
         // Now Throw the escape Message
         SendProgramMessage( msgID
                           : msgf
                           : msgData
                           : %len(msgData)
                           : '*ESCAPE'
                           : CURRENT_CALL_STACK_ENTRY
                           : 2
                           : msgKey
                           : errorDS );

Given the way I normally use it, from a subprocedure to signal an error to the 
caller of the
subprocedure, it works fine.

This time, I'm trying to use it differently.  Obviously, it doesn't work. 

Looking back at Greg Helton's original Throw/Catch article, I see he was 
throwing back to the prior
call stack entry instead of the second prior.

I changed it for a reason, but I don't remember what that reason was now ;-)

On the other hand, I'm at a new employer.  So my Throw/Catch is brand new 
again.  If I want to change
how it works, now would be the time.  I'll run some tests with Msg_Throw() 
throwing back to the prior
call stack entry instead of the second prior.

Thanks again,
Charles


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On 
Behalf Of Simon Coulter
Sent: Tuesday, February 20, 2007 11:10 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: Can you have nested MONITOR statements?


On 21/02/2007, at 5:45 AM, Wilt, Charles wrote:

The lower level on-error works, but the higher level one doesn't get 
hit.  Instead, I get CEE9901

Without seeing exactly what your msg_throw function does it's a bit hard to 
tell. My GUESS is that
msg_throw sends an *ESCAPE message to a call message queue higher in the stack 
than the monitor
statements. If so it is entirely to be expected that the outer monitor does not 
get control.

The job log messages will tell you where the message was sent from and where it 
went to. It is
probably skipping the call level containing the monitor statements. Try sending 
the message to the
same call message queue as the one containing the monitor. Note that monitor 
only catches RPG program
error codes. That is, those errors for which a program status code can be found 
in the PSDS. You'll
need to ensure that whatever your msg_throw function does causes one of these 
status codes to be
set--in this case probably 00202 or 00211.

Regards,
Simon Coulter.



This e-mail transmission contains information that is intended to be 
confidential and privileged.  If you receive this e-mail and you are not a 
named addressee you are hereby notified that you are not authorized to read, 
print, retain, copy or disseminate this communication without the consent of 
the sender and that doing so is prohibited and may be unlawful.  Please reply 
to the message immediately by informing the sender that the message was 
misdirected.  After replying, please delete and otherwise erase it and any 
attachments from your computer system.  Your assistance in correcting this 
error is appreciated.


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.