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

Hi Alan,

<snip>
Again, why destroy an activation group just because an error occurred?
</snip>

The activation group is only destroyed if the *ESCAPE message percolates to the control boundary (waving as it passes through everybody on the way), is promoted to a function check (CPF9999) and the default handler starts closing down call levels up to the boundary and there are no active levels in the call stack from that activation group - other entries from that AG can't exist above the control boundary.
In this circumstance it is 'assumed' that the last entry for that AG to get hit was the first to be called in that AG. Now there are none left its time to clean up.

Remember - the point of the control boundary is to prevent this percolating mess to start taking out calling application code. It is there for your protection. If you called a JDE function (for example) you wouldn't want its failure to crash your job. You'd want it to clean itself up and let you know about the problem calmly and in a gentle fashion.
Activation groups were designed to be mini jobs within jobs, with a level of isolation - commitment control, overrides, file access, resources, and even exception handling. If you call code running in another activation group and it goes tits-up then you would want it to clean itself up and let you know by passing a lovely CEE9901 'Application Error Occurred' message over the control boundary wall to your calling code.

Nowadays we use jobs with many activation groups causing many, many control boundaries to occur in a single call stack. This is MUCH harder to manage when an exception is thrown - especially from a SRVPGM. But (to labour a point) this is also why we have such good exception handling software as part of ILE. We should be using it.

The question would be - why are you letting the exception percolate to the control boundary? You can use monitor groups, *PSSR/*INFSR subroutines, e-extenders, condition handlers. The point is to catch the exception before it gets there - especially if you know the consequences if it does. If you are intentionally throwing the exception then another strategy must (obviously) be found.

Also, regarding the unresolved reference issues you encounter after activation group clean-up. I'm with Scott on this one. I've never encountered that.
Maybe the problem you describe is a side effect of the DB being sandwiched between your calling code and your trigger. I'd imagine IBM had to do some serious smoke/mirrors stuff there to try and take the DB out of the equation when using a trigger with *CALLER. I'd imagine the DB runs in the DAG so there'd be two control boundaries in there but I'm sure a trigger running in *CALLER still takes the AG from the object that called the DB code. This suggests there's some serious fudging going on in there to make that happen!. Maybe they haven't got it quite right yet. It maybe be that particular circumstance where your issues arise and not in the general ILE environment itself.

Would be worth having a non-working example to try it out. You never know, IBM may be able to offer a solution via a DCR.

Cheers

Larry Ducie