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

Hi Duane,
 
<snip>
My Solution:
1. setjmp
1A. Read a record
2. CPF5027 exception produced by DB
3. CPF5027 caught by user condition handler. Message sent on 3rd retry
otherwise longjmp issued to return to step 1.
..
</snip>
 
This solution will work, but with this solution you have to "invade" the
code where the read is. If I am going to do that then it would be easier to
just put a loop around the read - to allow retry that way. The condition
handler can be many levels away in the call stack and will have no idea
about this particular read in this particular program.    
 
<snip>
If anyone has a better process I would like to know what it is.
</snip>
 
OK, a better process:
(This is tested and works)
 
-- your code --
1. Register condition handler.
2. Call code as normal - go many levels deep and call lots of programs.
3. Within a program allocate a locked record. 
-- condition manager --
4. Condition manager signals a CPF5027 twice, but issues the default reply.
5. Condition manager issues a RNX1218 *ESCAPE message and calls the
condition handler passing the condition token. 
-- within condition handler --
6. Create a copy of QRNXMSG in QTEMP - CRTMSGF MSGF(QTEMP/QRNXMSG)
7. Put a copy of the RNQ1218 message description into the QTEMP version -
MRGMSGF FROMMSGF(QSYS/QRNXMSG) TOMSGF(QTEMP/QRNXMSG) SELECT(RNQ1218)
8. Override to the QTEMP version - OVRMSGF MSGF(QRNXMSG)
TOMSGF(QTEMP/QRNXMSG)
9. Change the default value for the message to 'R' for retry - CHGMSGD
MSGID(RNQ1218) MSGF(QTEMP/QRNXMSG) DFT(R)
10. Change the job to reply to *INQ messages with the default value - CHGJOB
INQMSGRPY(*DFT)
11. Allow the exception to percolate - action code 20. This will cause the
system to handle the RNX1218 *ESCAPE message and issue a RNQ1218 *INQ
message. 
-- back to system --
12. When the RNQ1218 message is issued the new default reply of R is sent as
the reply. No screen pops up and we get our retry.
13. If retry fails go back to 4. If retry succeeds resume after 3.
 
Better still - the DFT value can be retrieved from a file. This allows the
value to be set from anywhere, such as a screen used by a helpdesk operator.
This allows you to put a nice pretty screen up to the user with only two
options - Retry or call helpdesk. Helpdesk can then attempt to get the
locking user to unlock the record and instruct the user to retry.  
 
Once the lock succeeds the problem is then to reset the job to use *RQD for
INQMSGRPY and remove the overridden MSGF. One way is to use a user exit
program set on the reply to the *INQ message. Another way is to simply wait
for another unhandled exception to occur. Leaving INQMSGRPY as *DFT can be
dangerous, but when another *INQ message is issued you (should) have been
sent a warning *ESCAPE message first. This would certainly occur if the
subsequent retry fails - another RNX1218 message is issued prior to the new
RNQ1218 message.
 
Cheers
 
Larry Ducie