Re: Trigger programme without a trigger.

On 10/06/2008, at 1:01 AM, Lim Hock-Chai wrote:

Yes, that is why I say I'm not against it. However, of all those 5
things that I mentioned, the only one that is kind of hard to handle is
commitment control.

The trigger interface provides commitment control information. It is easy to write a trigger to operate with or without commitment control.

To handle it correctly, one might need to give up
some speed. For example, I've heard somebody say that to increase the
speed I'm going to have trigger program dumps the input buffer to a data
queue and have another batch process picks up the data from that data
queue and processes it.

That's not really going to speed things up. There may be an apparent improvement in interactive response time because you are changing from an SYNCHRONOUS trigger process to an ASYNCHRONOUS queuing method. However, that rather defeats the point of the trigger. If you want an asynchronous process then have the main job populate the data queue and avoid a trigger.

Well, first of all data queue does not really
goes well with commitment control. Secondly, the programmer that create
the program to update the file under commitment control might not know
that the trigger program will not handle rollback. Yes, it can be
fixed, it just not as easy. :)

The trigger should run under the same commitment definition as the main program. Then it doesn't have to worry about commit or rollback. Database will handle it.

Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists

http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------