RE: Interesting Situation

Good points, all, Buck.  The one modification I would make is to replace the
CL driver with an RPG driver program that can be left active. This
eliminates the overhead of starting and ending the CL program, particularly
in a batch environment where many thousands of records may be firing the
trigger repeatedly.

I use a generic RPG program as the driver on all files, which calls a
generic procedure, that checks a control file to determine the name of the
real procedure and service program for the actual trigger functions, then
activates that service program and calls the procedure.  The control file is
keyed by filename and library so that when someone creates a duplicate of a
production file and thereby duplicates the trigger call, the control file
will find no valid record and the generic procedure will just log a message
saying there was no valid trigger found and end harmlessly.  This prevents
someone's testfile programs from accidentally calling the production trigger
and causing all sorts of havoc.  By passing the buffer pointer down the
line, the whole process is completely generic until it gets to the final
"real" procedure that really cares what is in the buffer.  That procedure,
of course, is file specific.

The best uses for a trigger, IMHO, is to protect files from unauthorized or
outside programs, to head off hard crashes due to ref.constraint violations,
and to do background work like writing audit records.  Field editing is ok,
but sometimes causes more problems than just keeping it in the maintenance
programs. Special situations, like working around a vendor's software is
also a good candidate.

I've also found that having one and only one version of a trigger anywhere
on the system, will save endless problems.

> -----Original Message-----
> From: Buck Calabro [SMTP:buck.calabro@aptissoftware.com]
> Sent: Wednesday, March 28, 2001 11:59 AM
> To:   RPG400-L@midrange.com
> Subject:      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
> +---


************************************************************************************************************************************************************************************************************
This message originates from Lincare Holdings Inc. It contains information 
which maybe confidential or privileged and is intended only for the individual 
or entity named above.
It is prohibited for anyone else to disclose, copy, distribute or use the 
contents of this message. 
All personal messages express views solely of the sender, which are not to be 
attributed to Lincare Holdings Inc., and may not be copied or distributed 
without this disclaimer. 
If you received this message in error, please notify us immediately at 
MailAdmin@lincare.com or (800) 284-2006.
************************************************************************************************************************************************************************************************************
+---
| 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
+---