Have you thought of:

Using record timestamps and having a single NEP job that either processes a record added by your trigger or uses SQL to read the table by timestamp and status and avoids triggers altogether.

Seems easy enough.

Regards,
Richard Schoen
RJS Software Systems Inc.
Where Information Meets Innovation
Document Management, Workflow, Report Delivery, Forms and Business Intelligence
Email: richard@xxxxxxxxxxxxxxx
Web Site: http://www.rjssoftware.com
Tel: (952) 736-5800
Fax: (952) 736-5801
Toll Free: (888) RJSSOFT
----------------------------------------------------------------------

message: 1
date: Mon, 4 Apr 2011 15:44:12 -0500
from: Bradley Stone <bvstone@xxxxxxxxx>
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.



This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].