Re: Trigger or Stored Procedure?

Since the action must be triggered on change requests to data in a column on the TABLE, the trigger seems the desirable approach. To limit directly by the database, the changes to a specific column, the trigger would be create by CREATE TRIGGER FOR UPDATE OF. That trigger program can defer directly to a non-SQL program by an SQL CALL to a program which has been registered as an external stored procedure on the System i. However AFaIK a non-SQL trigger added by ADDPFTRG will have the same CONNECT restriction according to:
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/dbp/rbafotrgncmd.htm
This seems confirmed by the following book; refer to "You cannot perform DRDA access in a trigger program." at:
http://www.redbooks.ibm.com/abstracts/sg246503.html?Open

Thus I believe the trigger must defer the connect and further work, to a separate process that initiates [and maintains] the DRDA connection with the DB2 LUW. In *that* connection, to then do _either_ a CALL of a stored procedure on the remote database or perform the INSERT/UPDATE directly -- in response to the message enqueued with the request details. A trigger program [or a program it calls] can add a request to a queue that is being monitored by a server job, then optionally await feedback from the background request - accounting for trigger timeout concerns.
If transaction integrity is required, that second link implies a DDM connection may be possible for the insert/update activity on the target system, using two-phase commit.

Regards, Chuck