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

To do a retry you need to be able to "rerun" the failing command. I looked
into this years ago and could not find anything within the exception
handling APIs which would do this. What I ended up doing was issuing a C
function set "setjmp" and "longjmp". Before each file I/O I would call the
setjmp and if a record lock occured (CPF5027) the condition handler for the
procedure would catch that error, wait 10 seconds and issue a longjmp. If
this occured on the same statement 3 times I would send a break message to
both the locker and locked users. This is not very elegant IMO but I have
never found anything better and I assume that IBM uses something similar to
do the retry.

The other choice would be to change the default reply to RNX1218 "R" and let
the system automatically retry. I would NOT recommend this as it would retry
on all RNX1218 messages and probably lock your jobs in a loop.

Duane Christen

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Larry Ducie
Sent: Tuesday, June 20, 2006 1:34 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Condition handler and lock waits - Retry! Retry!


Hi chaps,

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.

Cheers

Larry Ducie

P.S. As an incentive, once my work on this is complete and in production I 
will post the code of my program which writes a (semi) formatted dump of any

module located within the call-stack. no need for the DUMP opcode. Pass it 
the name of ANY module in ANY of your programs/service programs and it will 
format a dump for you.