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

Don't know how many shops are using. The bottom line is not complex.
You have a single program that gets called when any trigger fires. It
then looks up the service program is attached to that table and
executes it.

The reason for using the mediator is simple. You can turn a trigger on
or off instantly or move a new version in and instantly have everyone
using the new version. There is no locks on the service program and
the performance is excellent.

To do that, there are a few pieces. You have a mediator, a service
program to implement the business logic and a maintenance screen to
maintain the table and trigger relations. The only part that changes
is the service program that implements the business logic.

As I said, if I was doing something like an ETL I would use a data
queue or a RCVJRNE. At my company, we needed real time updates so the
trigger mediator was the only way to go.

On Tue, Jun 12, 2012 at 10:15 AM, Stone, Joel <Joel.Stone@xxxxxxxxxx> wrote:

I found your "Trigger Mediator Documentation" from a google search.

This looks complex. Is this common to use in iseries shops?

What are the big advantages?

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Alan Campin
Sent: Tuesday, June 12, 2012 10:32 AM
To: Midrange Systems Technical Discussion
Subject: Re: multiple trigger programs for many data files - is there a better methodology?

Think about a data queue server. Just have one trigger program that
receives the buffer and writes a record to a data queue. The data
queue picks it up and does the transformation and sends it over to be
updated.

You could also use the RCVJRNE running in a batch job to receive the
journal entries, do the transformation and send over. There are some
tricks to this. I have code that I have used in the past.

Again my warning. Do not put any substantive logic in a trigger
program without the use of a trigger mediator. Using triggers without
a mediator is scraree to me no matter what.

On Tue, Jun 12, 2012 at 8:53 AM, Chris Bipes
<chris.bipes@xxxxxxxxxxxxxxx> wrote:

I would take a closer look at journaling the files. If the remote system is also an iSeries, you can set up remote journaling.

Daily you can detach the current journal receive and attach a new one. You can then have one program process the journal receiver you just detached and perform the updates. What is the external system? Another application on the same server or a different server / platform? Answers here will drive the recommendations in the correct direction.

--
Chris Bipes
Director of Information Services
CrossCheck, Inc.

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

--
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 inbound email has been scanned for all viruses by the MessageLabs SkyScan
service.
________________________________________________________________________

______________________________________________________________________
This outbound email has been scanned for all viruses by the MessageLabs Skyscan service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
--
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.