Re: Performance hit with trigger program

To complement Stu's feedback - there is extra overhead any time you cross
an activation group boundary in the call stack, so you want to avoid doing
so. So, if one code object runs in activation group A, and it calls
another code object that runs in activation group B, that call is crossing
an activation group boundary, and extra overhead is incurred. Occasionally
you may have a reason to do that, but you want to avoid it and only do so
if you have a good, specific reason. Isolating separate commitment control
transactions from each other would be one reason where you might
intentionally separate call stack items into different activation groups.

Mike

date: Thu, 7 Apr 2016 13:04:42 -0500
from: Stuart Rowe <rowestu@xxxxxxxxx>
subject: Re: Performance hit with trigger program

THOU SHALT NEVER EVER USE THE *DFTACTGRP WITH AN ILE EXECUTABLE (oh I'm
gonna take it in the backside for that one...)

Considering that a trigger program *may* be executed in a multi-threaded
job, you also do not want to use *NEW because when that activation ends the
whole job will end.

IMO *CALLER is the best bet for a trigger handler. CRTBNDRPG DFTACTGRP(*NO)
ACTGRP(*CALLER) will do it.

If you do away with the file and use a queue instead, activation group is
of less concern but still don't ever let it end for a trigger program.

Stu