• Subject: RE: triggered file list problem
  • From: "David Morris" <dmorris@xxxxxxxxxxxxx>
  • Date: Fri, 29 Oct 1999 10:07:29 -0600


You are right about LR having a noticeable impact however CL and LR are 
not know to each other.  Using a CL main procedure does not cause an 
RPG sub-procedure to be deactivated.  I have done this both ways and 
did not see any performance difference.  It may be that this is the case 
because the call is always dynamic or perhaps disk access was acting 
as a governor.  If I get a chance I will do a more scientific test.  

In my case all the CL main procedure does is receive the trigger information 
and pass control to an RPG sub-procedure contained in a service program.  
There was only a one byte variable declared in the CL program so there was 
not a big startup hit.

David Morris

>>> Scott Mildenberger <Smildenber@Washcorp.com> 10/29/99 08:27AM >>>

        It just depends on the volume of transactions and how they occur.
If the transactions occur in small bunches and are spread throughout the day
then the performance impact will be spread out and won't probably be
noticeable.  If large numbers of transactions occur in batch programs you
can see large performance impacts by how the trigger program is designed.
The impact can not only be caused by CL but by RPG programs that always end
with LR on.  We have modified several of our heavily used trigger programs
to leave LR off when ending and the impact to system performance has been
very noticeable.  Leaving LR off has it's drawbacks and you have to design
the program properly so we selective use the technique.  CL programs, as far
as I know, don't have the capability to do something similar as ending with
LR off so you don't have this ability and thus have the program startup
performance hit on every file update.  A real world experience to show this.
This wasn't a trigger program but a heavily used utility program but
illustrates the point.  The utility ended with LR off and was called
extensively throughout the system.  A modification to the utility required a
front end CL for an override.  After putting the change into place, with the
new CL, the system went from operating fine to almost coming to a standstill
due to the overhead of this CL startup occuring every time the utility was
called.  Now this utility was probably called hundreds of thousands of times
in a day and most files don't have that amount of activity.
        What it comes down to is that you can probably use a front end CL
(or RPG ending with LR on) for a trigger program in a lot of places without
a problem.  But you should be aware of this impact and do it as little as
possible and especially not do it on files with a lot of activity.  It is
also worth noting that trigger programs in general should be kept as
efficient as possible while still accomplishing what they need to do.  My
original post just wanted to warn people before they create a performance
problem with a trigger and give up on trigger programs in general because of
it.  We have found triggers to be very valuable as long as you are careful
as to where and how they are used.

Scott Mildenberger

> -----Original Message-----
> From: David Morris [SMTP:dmorris@plumcreek.com] 
> Sent: Thursday, October 28, 1999 3:25 PM
> To:   MIDRANGE-L@midrange.com 
> Subject:      RE: triggered file list problem
> Scott,
> I have not seen any performance problems caused by CL.  I used CL to 
> provide an entry procedure because of RPG's recursive call limitation.  
> This is in use for hundreds of files with many I/Os per day.
> David Morris
> >>> Scott Mildenberger <Smildenber@Washcorp.com> 10/28/99 01:14PM >>>
> I would be very careful about having a CLP for the trigger program if the
> file has a lot of transactions on it due to performance issues with
> starting
> up the CLP every time it is called.  If the volume of transactions is low
> then it won't matter much.
> Scott Mildenberger

| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.