RE: Trigger Question

["Morgan, Paul" <Paul.Morgan@xxxxxxxxxxx>]

Bradley,

How many jobs could you have running?  If the jobs get backed up would that be a problem?

How about an *AFTER *UPDATE trigger?  Then you have a monitor job looking for *AFTER *ADD events without an *AFTER *UPDATE event in 30 seconds.

Paul Morgan

Principal Programmer Analyst
IT Supply Chain/Replenishment

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Bradley Stone
Sent: Monday, April 04, 2011 4:44 PM
To: Midrange Systems Technical Discussion
Subject: Re: Trigger Question

There could be quite a few actually.

So, record gets written to the file.  The *AFTER *ADD trigger fires
and it submits a job to run in 30 seconds to chain to that record and
see if the value of the status has changed.  If not, it sends a
QSYSOPR message.  All I would really need to pass to the submitted job
is the RRN and the old status.

That's really all they want.  Sounds doable.  But it also sounds like
it would chew a few resources.

Just want to see if I'm missing something.

Brad

On Mon, Apr 4, 2011 at 2:04 PM,  <rob@xxxxxxxxx> wrote:
> Are there low quantities of inserts?  For example, I insert a row that
> says go print a PO.  And they only print 50 PO's a day.  When I print a PO
> then some other stuff should occur and you do not want to modify the PO
> print because it is vendor supplied.  You could trigger on the PO,
> actually perform the side work and modify the status flag.  There's a
> value on ADDPFTRG to ALWREPCHG(*YES).  If you use this you can actually
> modify that status flag yourself.
>
> If they do not trust the server app to be running then they probably might
> not trust the data queue concept to be running either.
>
> Another option, if the row operation is an "insert" then fire off the
> process.  If the row operation is a change then do not fire off the
> operation.  Can't do that?  Then check before/after images on the
> 'change'.  If the only thing on the change (by checking the before/after
> images) was the status column then do not fire off the ancillary process.
>
>
> Rob Berendt
> --
> Group Dekko
> Dept 1600
> Mail to:  2505 Dekko Drive
>          Garrett, IN 46738
> Ship to:  Dock 108
>          6928N 400E
>          Kendallville, IN 46755
> http://www.dekko.com
>
>
>
>
>
> From:   Bradley Stone <bvstone@xxxxxxxxx>
> To:     Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
> Date:   04/04/2011 01:20 PM
> Subject:        Re: Trigger Question
> Sent by:        midrange-l-bounces@xxxxxxxxxxxx
>
>
>
> For clarification, the reason they want to do this is because there is
> a server job running (or should be) that when a record is written, it
> does some stuff to it and changes the status.
>
> They were thinking a trigger would work in this case to know if the
> server job is running or not.
>
> I asked if they had any ROBOT type programs that can check, but they
> weren't interested in that solution.  They wanted this one.
> --
> 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.
>
>
> --
> 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.