I have done "retry" logic maybe 3 times in the last 10-15 years with a condition handler. The way I've done it is with the C functions setJmp, longJmp.
I have had no discernable problems, but if someone sees a flaw in my logic (below) I would appreciate a heads up.
When initializing the program/procedure
If setJmp(jumpPoint) = 1; // jump to this point, from the condition handler
// after the condition is handled and the exception
// message information is loaded into the error structure.
de-register condition handler
Return;
EndIf;
register condition handler
// Continue with program/procedure logic
...
// Location of retry logic within the program/procedure logic
Set up user condition handler exit procedure and data
// The implementation of my default condition handler has an exit point to
// allow non-default handling of the exception. The exit procedure would have logic
// to only execute the longJmp to jumpPoint2 for the appropriate exception message(s)
userCh.ExitProc = %Paddr('RECORDLOCKEDUSERCH001');
retryCount = 1;
If setJmp(jumpPoint2) = 1;
retryCount += 1;
If retryCount >= 3;
// Throw retried too many times exception
EndIf;
EndIf;
Read file; // If the appropriate message(s) is thrown we will execute the code
// in the "If setJmp(jumpPoint2)" code block
// If the read is successful, clean up the "Retry" logic
userCh.ExitProc = *NULL;
// Continue with normal program logic.
...
Duane Christen
--
Duane Christen
Senior Software Engineer
(319) 790-7162
Duane.Christen@xxxxxxxxxx
Visit PAETEC.COM
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Larry Ducie
Sent: Saturday, October 02, 2010 1:54 AM
To: RPG400
Subject: Re: Convert from free to fixed
Hi Barbara,
On 2010/9/29 8:55 AM, Larry Ducie wrote:
... The process
continues from the next line of code as if nothing went wrong. You
can't beat that!
<snip>
Larry, it can be dangerous to set the action parameter to resume at the next instruction. The process doesn't continue from the next line of high-level-language code, it continues from the next low-level machine instruction. Whatever low-level instruction that happens to be at that release and PTF level. There's no guaranteed upward compatibility for what the next machine instruction is.
</snip>
Your point is well taken, and this not not something we do often or lightly. Our support team don't even have the option to do this.
I understand that a single line of high level code can cause a stack of low level lines of code to run (such as during a chain or reade). I would not, for instance, even attempt to proceed to the next instruction if a call failed because the object could not be located. The call is already trashed as the object location is not set.
Would this level of caution extend to a simple a = b / c where c is zero? We have had examples where c came from a configuration file and a developer forgot to set the value when promoting the code. In that instance we can fix c in debug and do the math on a calculator and set a. Then let it run. Fixing the config file prevents re-occurances of course. Would this also not be a wise move?
Your thoughts, as always, are most welcome.
Cheers
Larry Ducie
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.
midrange.com
