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

We are using a mediator program to point to the correct trigger programs.
It has worked well, and makes it easier to make changes while the file is
in use. Ours is not as complex as Alan has outlined, just a mediator that
fires as the trigger program. The mediator program then calls the insert,
change or delete programs as is appropriate. If a change needs to be made
to one of the programs, the changes can be made and put into place quickly.

Jim

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.