RE: Trigger programme without a trigger.

The problem normally start up with no existing application is updating
the file under commitment control. So, at the time of design, the
programmer is creating the trigger correctly (not need to consider
commitment control). Thing then starts to go wrong when a new
application got created to update the file under commitment control.
Since we can't predict future, should we say or should IBM recommends
never create trigger that execute task that cannot run under commitment
control?


It would be nice if IBM can give us an option to setup trigger to fire
only after commit (maybe a new parameter TRGAFTCMT(*YES)). Of course if
the file is not under commitment control, it will still get fire.
Aaahhh.. wishful thinking ....


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Tuesday, June 10, 2008 12:19 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Trigger programme without a trigger.

Some comments inline.

Lim Hock-Chai wrote:

Below are some not so traditional-RPG-programmer friendly things about

trigger (They are not problem, just stuffs that traditional RPG
programmer are not familiar with):

1) Commitment control issue. Programmer that creates trigger program

tends to not consider commitment control. If the file is under
commitment control and trigger is not, roll back will not rollback
what trigger has done. Well, depending on what the trigger is doing,
this might not be an easy fix.

That of course is a problem of the programmer, not of triggers. Such
a programmer would apparently have the same problem for any two programs
where the first running with CmtCtl, calls a program which does not
participate in the transaction. Either every step within the entire
transaction is properly isolated & ensures atomicity of the entire
transaction, or they do not. If the programmer is writing a program
that utilizes commitment control, yet does not understand or consider
that for all activity\calls, then they probably should not be writing
that program, nor those programs that it calls.