Re: Condition handler and lock waits - Retry! Retry!

Larry,

IIRC (and memory lane goes back to the last century), there is an API to
convert Escape MSGs into Diagnostic messages, to prevent the message
screen. It should be called directly after the error fires your error
trapping routine. Then you can retrieve the last diagnostic messages and
deal with it the way you want to.

You can try this API (if you did not already), but as memory serves me
well, it did not work all the time (meaning an escape message would still
display the message screen one time, and the next time did not),

Regards,
Carel Teijgeler

*********** REPLY SEPARATOR  ***********

On 20-6-2006 at 6:33 Larry Ducie wrote:

I have a condition handler program written in RPG. This program is

supposed 

to allow us to gracefully handle exceptions as they occur. In most cases 
(such as batch jobs) we simply log the exception, send an email to the 
helpdesk (with the call stack, various module dumps, and job info as 
attachments) and end the job.

Now, in the case of a file locking problem (CPF5027 followed by RNX1218) 
within an interactive job I have a problem:

In normal circumstances (no condition handlers, direct monitors, or *PSSR

at 

higher level) the system would issue CPF5027 twice, and then issue RNX1218

as a *ESCAPE message to the program attempting to allocate the record.

This 

would be unhandled in this situation so another RNX1218 would be sent as a

*INQ to the user. The user would get a Retry option and all would be cool.

I want to be able to handle this exception without displaying the 
black-n-white InqMsg screen to the user. I also don't want the user to be 
able to cancel out by pressing Enter accidentally. I thought I'd be able

to 

receive the message and reply to it without displaying the black 
screen-of-death. Now, when using the condition handler I don't get to see 
the CPF5027 messages as the system automatically replies to them. I do get

the RNX1218 *ESCAPE message. I want to handle this and force a retry, but

I 

don't know if this allows a retry - no replies listed. If I don't handle 
this message and simply issue a resume then a RNX1218 *INQ message is 
subsequently issued - to the workstation. I don't get to see that one

within 

my program - but it has the retry option!

How can I handle the RNX1218 *ESCAPE message to force a retry of the

record 

lock without simply ignoring it and causing the standard black-n-white 
screen to appear - forcing the user to decide?

Your help in this matter is most welcome.