Re: Trigger Question

[Charles Wilt <charles.wilt@xxxxxxxxx>]

Bad idea...

Triggers are synchronous...the program that fired the trigger won't
get control back till the trigger completes.

Your trigger should write to another table or better yet a *DTAQ or
*MSGQ for which there's another never ending job running processing
the records.  This job can check to see if the record status has
changed within 30 seconds..

Also,  it would seem to me, that you might simple be able to add a
"last changed" timestamp to the records, and have a process that
asynchronously looks for records with a stuck with a certain status.

Having said that, I have to wonder...is this really a good idea in the
first place?   It seems to me to be a band-aid workaround for some
problem with the process that should be processing the records and
changing the status in the first place.

Rather than building some additionally monitor, why not just fix the
problem you're trying to watch out for?

Charles

On Mon, Apr 4, 2011 at 12:27 PM, Bradley Stone <bvstone@xxxxxxxxx> wrote:
> Ok, before I get too deep into this, I've had a request to make this change:
>
> 1.  Add a trigger to a file for when records are added.
> 2.  If after 30 seconds, the record isn't updated (a status type
> field), send a message to QSYSOPR
>
> Now, sounds easy enough, but I'm wondering if that 30 second delay
> that I'd put in would hold a lock or anything on that record, or cause
> any other problems?  It's been a while since I did a trigger.  :)
>
> What I would do is:
>
> Trigger PGM
>
> store original value from ADD to file
> pause(30)
> Chain to the file and check that original value <> new value
>
> Thanks!
>
> Brad
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.