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.
--
This is the RPG programming on the IBM i / System i (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.