Re: Trigger Question

Is the 30 seconds itself a vital interest? It would sound like they really just want to catch the ones that fall through the cracks. If so, once every 11 minutes or so would seem adequate and would not be a drain on resources, if the resource drain is a concern.

It also sounds like this is a back door way of finding out if the server has stopped serving. This leads to the obvious question: Why not monitor the server directly, and get a notice that the server has failed at the time it fails, instead of waiting for a message from the data file fail??






On 4/4/2011 5:03 PM, Albert York wrote:

Since you are only interested in making sure the update job is
running, you don't need to check every record.

Keep a data area with the time that a job was last sumitted. Only
submit a new one every 30 seconds.

Albert

On Mon, Apr 4, 2011 at 1:44 PM, Bradley Stone<bvstone@xxxxxxxxx> wrote:

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.

--
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.