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

Hello,

The commitment control is coming from a client job. I should have made that
clear. Client jobs run in a default activation group in a QDASOINIT job.
Commitment control did not work for the client program to roll back changes
in the trigger program unless it ran in the DAG group.

Sorry, I have no idea what "Client Jobs" are in this context. When I refer to "Client", I'm usually talking about a network client... and whether something is or isn't a network client has no impact on activation groups.

What is meant by "client job"?

When you have an error in a trigger program, the only way that you signal
back to the caller is by throwing an exception message. When you throw back
an error and you are running in a named activation and that named activation
is not being used higher up the stack is destroys the named activation group
and the next time you try to call it you are not going to find the service
program because the activation group is gone.

Seems to me, this is a flaw in the way triggers work... DB2 should give us a way to signal an error that doesn't involve abending the program.

But I still don't understand the problem. If your trigger ends with an *ESCAPE message, the database will catch the message, and next time it'll reinvoke your program without any problems. You can't specify a *SRVPGM for a trigger... so I guess I don't know what you're talking about here.

It kinda sounds like you've written your own system for triggers -- (maybe the "trigger mediator" I've heard about -- though I can't remember if that was you.) I'd suggest that this might be a flaw in your system.

At any rate, this is a _very_ specific circumstance, and doesn't apply to activation groups in general.

You will have the same behavior if you have a program running in a named
activation group and it calls a service program running in a another named
activation group (Say QILE calling a service program running QSRVPGM). If
both are running in QILE and the error occurs or you simply signal an error
there is no problem but run them separate and boom.

This doesn't match my experience or tests... If a srvpgm in ACTGRP1 calls a srvpgm in ACTGRP2, and the latter fails with an error, then ACTGRP2 will end, it's true... but on the next call, the srvpgm will be re-resolved, and ACTGRP2 will be recreated.

All our programs are written 100% in modern RPG using ILE call models,
service programs and SQL.

If someone else has a better solution I would sure like to hear it.

I really don't understand the issue.