Scott, 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 >>> David, 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:email@example.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: firstname.lastname@example.org +---
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.