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