Trigger performance not good

I second the idea of a DataQueue that gets loaded with Triggered Data - it is the way to go.

And while you are writing your DataQueue pgm, insert a little logic for "a mediator" - You will want to skip the trigger operation if a data-area is turned off.
This occasional "skip the trigger" is needed when refreshing test environments, or when clearing and restoring data the file in production.
Also, one Data Queue can be fed different formats from different files, but read by a single MEDIATOR program, and your MEDIATOR Logic is contained in one place.
(Typical setup is one Data Queue per Module - one for Recievables processes, one for Manufacturing processes, one for EDI processes )

And in fact, Data Queues sit in EVENT-WAIT and their processing pgms do not wake up and get called until data is placed in the data-queue. This makes data queue processes supremely efficient.

More details here and here
http://archive.midrange.com/midrange-l/201409/msg00603.html
http://archive.midrange.com/midrange-l/200506/msg01053.html

- John Voris

date: Tue, 28 Apr 2015 09:20:54 -0500
from: "Englander, Douglas"
subject: RE: Trigger performance not good

Another scenario you could try is: Instead of the trigger passing the data to an RPG program for processing, have the data sent to a data queue. Then have an RPG program read the data queue, and
process it that way in batch. That way the trigger is sending the data quite quickly, and RPG program could process the data queue quicker also, and check it every one or 2 minutes or so to see if there
is data for processing.