> -----Original Message-----
> 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

For simplicity's sake, I would advise leaving LR off and using the
traditional technique running in ACTGRP(*CALLER) or *DFTACTGRP.

If you run the trigger program in a named activation group, any variables
which are not local to a procedure in the program are necessarily static
while the named activation group is active, so the code could be made
re-entrant with LR on if you were sure that the Activation Group remains

However, since you would not want the Activation group to terminate between
successive calls of the trigger program, you would need to ensure that your
calling program runs in the same activation group as your trigger program.
This could be a little difficult since the calling program would be some
OS/400 Database Manager program. Even if you make your trigger program
ACTGRP(*CALLER), you still cannot be sure that the OS/400 program does not
terminate the activation group. (Perhaps someone from IBM could clarify
exactly what activation group the calling database manager program runs in)
If the OS/400 program runs in ACTGRP(*CALLER), then using a single
'across-the-board' named activation group would enable your trigger programs
to be re-entrant. Also, it would open up the intriguing possibility of
exporting static variables from the trigger program to and from the program
which accessed the database file to fire the trigger.

Hope this helps.

Chris Jewell

Christopher J. Jewell.vcf

This thread ...


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

This mailing list archive is Copyright 1997-2019 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].