RE: Making Triggers Resilient

Scott;

What if the file is being accessed under commitment control. The trigger
being in a seperate activation group from the database manager and/or the
program doing the I/O would cause any I/O done by the trigger to be out of
the commitment control scope. Depending on what the program is doing this
may not be what you want to happen. I am assuming that commitment control
scoped to an activation group and is not scoped to the job.

Duane Christen

-----Original Message-----
From: Scott Klement [mailto:rpg400-l@xxxxxxxxxxxxxxxx]
Sent: Monday, February 28, 2005 2:47 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: Making Triggers Resilient



>
> Is there a downside to using *CALLER for the activation group on triggers?
> That sounds like it would "adapt" better to calls from various sources.
>

Unless I'm confused, triggers are always called by the database manager 
in the operating system. Not much to "adapt" to, since it's always the 
same program. I don't see why you'd want your trigger to be run in the 
same activation group as the database manager -- particularly since it's 
probably the default activation group (Though, I haven't tested that 
theory...).

Putting it in a named group gives me more control. I like to activate my 
triggers once, keep the files open, etc, so that they can be called over 
and over with the smallest possible performance penalty.

Putting them in a named activation group makes it possible for them to be 
cleaned up simply be deleting the activation group.  I have a lot of 
utility service programs with very useful routines that I tend to call 
from all of my programs, including triggers. Because I used a named 
activation group for the trigger, and the utilities are compiled with 
*CALLER, I can reclaim the activation group and unload all of the 
utilities, and close all of the files, and free up all of the resources 
that they use with one simple command.

This is particularly helpful when I'm debugging my programs.

But, it's also occasionally useful for other things.  For example, we have 
a daily batch job that rebuilds some of our files. Before that can be run, 
you have to get each user who uses those particular files to close them.

When my triggers that use them are compiled in a named activation group, I 
can have a break-handling program reclaim that actgrp, thus closign the 
files.  Or, I can have a menu option that a user can run that does it. Or 
even have it be reclaimed by a CL program just before returning to the 
menu.

That allows me to keep a trigger loaded in memory, and only reclaim it 
when I need to.

If my triggers ran in the default activation group, I'd either have to 
close the files with each call to the trigger (awful performance!) or I'd 
have to make the user completely sign-off to close the files.

-- 
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.



NOTICE: This electronic mail transmission may contain confidential
information and is intended only for the person(s) named.  Any use, copying
or disclosure by any other person is strictly prohibited. If you have
received this transmission in error, please notify the sender via e-mail.