Re: multiple trigger programs for many data files - is there a better methodology?

Here is a copy & paste that would be a good mediator. This comes from Pete Hall, and is a few years old. It may do exactly what you'd like, but you would need one for each file.

http://www.martinvt.com/Code_Samples/Trigger/trigger.html

What is significant though is that the trigger program does not have an F-spec for the trigger file. The record is passed as a before image and an after image. That gives you choices, but the significant point is to make the trigger program simple. Don't do any processing in it beyond the trigger itself. Put all of the complexity in non-trigger programs that are easily changeable.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:

midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Stone, Joel

Sent: Tuesday, June 12, 2012 7:45 AM
To: 'Midrange Systems Technical Discussion'
Subject: multiple trigger programs for many data files - is there a

better methodology?

I have been tasked with copying records from several files to an

external system when data in records change.

So a series of trigger programs seems like a good solution.

I will have a pile of20 files, but lets say there are 3 files for

simplification.

I need a different trigger pgm for each file:

File Program
------- -------------------
Cust pgmA

Product pgmB

Order pgmC




Would it be possible and worthwhile to build only one trigger pgm? I

was thinking that maybe there is a way to capture ONLY the file-name and
the primary key values into a new file.

Then later when the data transfer to the external system occurs, an SQL

command would take the file name& keys and get the actual full data record
to transfer.

Would this be worth the extra work to make one flexible pgm to handle

all data files?

I could possibly make use of the system files QADBKFLD and QADBIFLD to

construct keys and files to identify changed records.

Can this be done?? Or not worth it??

Has anyone done this? Can you share some code??

--