RE: Changing triggers -- RPG400-L

Thanks to all who replied.

We use something similar to this for our replication piece - except the
files are journalled.  We have a program sitting on the journal receiver to
move the data into a file for a different program to replicate.  This way we
do not get 'backed up' on reading the journal - makes ending and re-starting
much cleaner.

Sounds like having the trigger call a front-end CL program, and maintain
that program, will work.

We'll proceed with the plan.

Thanks again,
JN

> -----Original Message-----
> From: Schlemme, Michael C. [SMTP:mschlemme@frpaper.com]
> Sent: Monday, March 27, 2000 2:17 PM
> To:   'RPG400-L@midrange.com'
> Subject:      RE: Changing triggers
> 
> Jim, 
> 
> We use several methods for handling triggers.  One method uses a trigger
> on FILEA (not it's real name, HA HA).  The trigger program (RPGLE)
> receives the trigger buffer and sends the data to a data queue.  PGMA
> (RPGLE, not it's real name) is a never ending program waiting for an entry
> to arrive on the data queue.  One advantage to this method is you can
> start multiple PGMA's waiting on the same data queue.  
> 
> Another method sends the trigger buffer data to a data queue being
> monitored by a never ending CLLE program.  The CLLE program receives the
> entry, looks in the trigger buffer information area, and calls the
> appropriate program to process the buffer based on the file name.
> 
> Still another method places the trigger buffer data from multiple files
> files into a single, keyed data queue.  Many different programs are
> waiting to receive data from this data queue.  The key to the data queue
> entry is the program name to process the entry.   
> 
>       -----Original Message----- 
> From:   Scott Mildenberger [SMTP:Smildenber@Washcorp.com] 
> Sent:   Monday, March 27, 2000 11:23 AM 
> To:     'RPG400-L@midrange.com' 
> Subject:        RE: Changing triggers 
> 
>       Jim, 
> 
>       To accomplish this we made the trigger programs do nothing but call
> another 
> program passing the parms to it.  This additional layer allows us to
> change 
> the programs that are actually doing the work whenever we want. 
> 
>       Scott Mildenberger 
> 
>       > -----Original Message----- 
> > From: Nelson, Jim   (RCIS) [SMTP:Jim.Nelson@RCIS-NET.COM] 
> > Sent: Monday, March 27, 2000 8:20 AM 
> > To:   'MIDRANGE-L@midrange.com' 
> > Subject:      Changing triggers 
> > 
> > In our development environment, we are changing SOME trigger on SOME
> file 
> > almost daily.  To make such a change, the file that trigger is based on 
> > must 
> > not have any locks.  This has become unworkable with the number of 
> > developers and functional test people involved. 
> > 
> > We are talking about creating completely generic triggers to call a
> stored 
> > procedure which will either run the activity intended or call one or
> more 
> > other stored procedures.  When a change was needed it would be made to 
> > that 
> > front-end stored procedure. 
> > 
> > Before we get too deep into this, it would be nice to know if there are 
> > any 
> > 'gotchas'.  
> > 
> > Has anybody else gone down this road?  Has it worked?  Anything we
> should 
> > keep in mind? 
> > 
> > Thanks, 
> > JN 
> > 
> +--- 
> | 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 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
+---