Re: Triggers, Activation Groups, Performance

Joe,

If you do not set on LR in your trigger program and you use library lists 
to determine what file is open, you may need to use named activation groups.  
Unless you reclaim your trigger program activation group when library list or 
environments are changed, the trigger and application that called the trigger 
can be from different environments IE: test and production.  This is the case 
with our trigger programs.  We use a single trigger program that passes control 
to the appropriate service program for a file.  We never set on LR.  For this 
reason the trigger program must determine the environment and pass control 
to a stub program that sets the activation group.  This is really not a lot of 
overhead but before we started doing this it was possible to validate 
production data against test or vice-versa.  Another alternative would have 
been duplicate trigger programs for each file.  In our case it would have been 
really nice to be able to specify an activation group on the activate program 
API.

David Morris

>>> "Joe Teff" <jteff19@idt.net> 01/21 8:49 AM >>>
When I first started writing triggers, I assumed that the only way to get
good performance was to leave LR off when I exited the program. All
subsequent calls in that job would then use a program that was
already loaded and initialized. I now understand that programs (PAG
portion anyway) do not get cleaned up automatically when a program
ends even with LR on. All subsequent calls to that program are faster
because of the lack of cleanup for a named Activation Group.

As a rule, I use DFTACTGRP(*NO) and ACTGRP(QILE). Should I
still leave LR off when I exit my program and code it to be re-enterable?
Or can I seton LR and let the system handle re-initialization without
any real penalty?

Joe Teff

+---
| 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
+---