RE: Interesting Situation

Christopher makes a very good point about minimising the work that the
trigger performs.  May I add another caveat along the same line?

Have the trigger do nothing except pass the buffer to the "real" processing
program.  The point is that there might come a time when you want to turn
the trigger off or recompile the trigger program.  You will need a *EXCL
lock on the file in order to do that.  In many businesses it is difficult to
get such a lock during business hours.

Code your trigger program to check a data area, user space, control file -
whatever.  If the "Trigger is running" flag is set, pass the buffer to the
real program and have him do the processing you need.  If there's a bug in
that processing, reset the "Trigger is running" flag in your data area and
you can recompile your real processing program all you want without having
to worry about getting a lock on the file. 

ADDPFTRG FILE(FILELIB/MASTERFILE)  
         TRGTIME(*AFTER)           
         TRGEVENT(*INSERT)         
         PGM(TRIGLIB/TRIGGERCL)    

TRIGGERCL - rtvdtaara  
                          If (&Flag *eq '1') (call TRIGGERRPG PARM(...))

TRIGGERRPG - the "real" work happens here.

If you want to get more exotic, you can create a _single_ program that you
specify on ADDPFTRG.  This program checks the "is running" flag, the file
name, before/after trigger, etc. and call the right processing program for
that file.  Basically a single trigger driver program.

Triggers are easy, but avoid the IBM example that hard codes the buffer.  An
externally described data structure is Much Better in my opinion.

Buck Calabro
Commsoft; Albany, NY
"Nothing is so firmly believed as
 that which we least know" -- Michel Montaigne
Visit the Midrange archives at http://www.midrange.com

> -----Original Message-----
> From: Chris Bipes 
> Sent: Wednesday, March 28, 2001 11:15 AM
> To:   'RPG400-L@midrange.com'
> Subject:      RE: Interesting Situation
> 
> The less the trigger does itself the better.  That is why we like to send
> the data somewhere else to be processed by a separate batch job, generally
> a
> data queue server job in our shop.
> 
> Christopher K. Bipes
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---