Re: Code too slow for a trigger?

John,

I've done something similar in BPCS on our Customer Master, and saw no 
appreciable performance impact. 

The approach I took was to create my trigger program with two modules, the 
entry 
module being the main source of the trigger, and the other being a bound module 
that sends and receives a program message using the QMHSNDPM and 
QMHRCVPM api's, backing 4 levels up the call stack to the the id of the program 
that 
sent the update that called the trigger.  The results are written to a log file 
(our 
problem was somewhat different than yours, we were trying to trap for who was 
making a specific type of data change).

I have seen programmers attempt something similar using DSPJOB     
OUTPUT(*PRINT) OPTION(*PGMSTK) in a CL and then reading the stack in the 
resulting spooled file to determine the program that issued the update.  I 
could see 
that causing a performance hit, if that is what you are doing.

--Chris


On 10 Mar 2003 at 11:41, John Furniss wrote:

> Hello List,
>     I've put code in a trigger program attached to our Item Master
>     file
> that will determine the program that called it. The reason being is
> that this trigger caused a "record already locked by this job" error
> during our month end processing (when CHAINing to the Item Balance
> file). Would this code cause the trigger to run slow, thus causing
> slow downs for users accessing the item file?
> 
>     TIA,
>     John Furniss
> 
> --
> John Furniss
> Applications Programmer
> Allied Machine & Engineering Corp.
> mailto:jfurniss@xxxxxxxxxxxxxxxxx
> Phone (330) 343-4283 ext. 8371
> 
> 
>