Re: avoid running ILE programs in the DAG...

<snip>
You could solve the problem by reclaiming the TRYAG1 activation group
(this'll cause the pointer to be reset), or by handling the procedure
pointer logic manually in your program.
</snip>

Wait, did you mean reclaim the TRYAG2 activation group? I have a message broker service program that runs plug-ins inside their own named activation groups. The plug-ins are not service program sub-procedures, but programs that are called via variable. Each leaves LR on, and does not close files for speed as they are called in some random order, and with high frequency. The Plug-ins use their own named activation group (PLUGIN for example, I can't remember what the real name is right now). The reason for this is that periodically a process needs a lock on one of the files that could be locked by the broker, and since the plug-ins do not close down, they do not give up locks. The process that needs the lock notifies the broker to suspend activities, then the broker runs to a good suspend point and reclaims the PLUGIN activation group to release all of the locks. Once the process that needed the lock is complete a notification process allows the broker to resume operation. Even if the plug-in is the same on either side of reclaiming the activation group (therefore requiring no re-resolution of pointers), no error is generated when calling back into the activation group that was reclaimed.

Maybe Alan needs to have a wrapper for his trigger mediator that uses *CALLER (and therefore runs in whatever activation group the DB process is running in) that would trap any errors coming from the trigger and reclaim the Trigger activation group before returning. Then the next attempt to call into that same trigger would not fail. I did not test this hypothesis.