It sounds like you are capturing and handling the recursive calls, it is just that the recursive calls are creating entries in the job logs?
If this is the case you might want to have a program that retrieves and removes these messages from the joblog as they occur.
Paul
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of James H. H. Lampert
Sent: Thursday, May 16, 2013 12:43 PM
To: Midrange Systems Technical Discussion
Subject: Re: Preventing recursive call exceptions on triggers, or at least keeping them out of the joblog?
On 5/16/13 10:23 AM, rob@xxxxxxxxx wrote:
Let me ask this, if some action updates FILEA, and there's a trigger
on FILEA it does not attempt to update that same row in FILEA by
either an SQL update or an rla update, does it? Because it's better
to do that by
ALWRPTCHG(*YES) and modifying the trigger buffer.
Or is it more of a case where row A gets triggered and that trigger
updates row B and the trigger on row B attempts to update row A again?
Actually, neither: as I said, the trigger program in question executes workflow scripts, and it's mostly ILE RPG, with nothing done to enable recursion, so it (by design) rejects recursive calls. And it's the "after" trigger for insert, update, and delete on every file that supports workflow scripting.
My workflow scripting language has no provision for modifying or deleting existing records, other than by making an external call to a program that does so. It can create new records in certain files, and therein lies the failed (by design) recursion, since it's creating new records in files for which it is the after-insert trigger.
We want it to continue to reject recursive triggering; otherwise, it would be very easy to write some combination of workflow scripts (or even a single workflow script) that would throw the job into a recursive tightloop until it blew up (or took the system down).
--
JHHL
midrange.com
