Re: PF Trigger question

On 25 Mar 2013 12:26, Jack Tucky wrote:

I'm working on a project where a shop floor device will use FTP
to insert a record into a PF file. The plan is to use a trigger
to process the incoming record, but the specs also call for the
trigger to write a result record into the same file.

For instance, the shop floor device might put a record in the file
that says "SERIAL#=12345678', then I need to write a result record,
either 'SERIAL#=12345678 not found' or 'SERIAL#=12345678,PCS=100',
or several other replies

The trigger will fire again when we write the record. I've tried
setting the trigger to *DISABLED before I write my result record,
but I'm still getting RNX8888, RPG program TRIGGER was called
recursively.

That seems incorrect. I verified on v5r3 that the database manager would not invoke the *INSERT trigger for what would otherwise be a recursive insert event [the insert for the "result record"], if the trigger had been disabled. In my test, the CHGPFTRG STATE(*DISABLED) was issued in the trigger program before the next insert.

No matter... as the concept of disabling the trigger for such a purpose is not valid, *unless* all insert-I/O is known to always be serialized. That is because the disabled-state affects every insert, not just the next one invoked from the trigger program in the current thread\process. As such any first\non-recursive insert would not have the trigger invoked if its I/O was performed after the trigger was disabled but not yet re-enabled.

IMO the best solution to enable keeping that design [if a new row really needs to be inserted], is to do whatever enables the trigger program to be called recursively; e.g. linear-main as Charles suggests, if an RPG program is to be used. Note that an SQL TRIGGER [CREATE TRIGGER] can be called recursively, as can a CLP used as a /native/ [ADDPFTRG] trigger; for examples. The functions that the RPG would have performed could be exposed to the SQL or to the CLP, so they can perform that work instead.

I'm not sure that the shop floor device could receive the result
transactions in a different file. Is there a way for the trigger
to ignore certain events?

The trigger program can have logic coded to ignore certain events. However the database can not ignore those events, because the whole point of the trigger would be defeated; i.e. the trigger is there to implement rules on the database [data] irrespective of the invoker, as ensured by the database when the trigger is enabled [and operative]. The trigger could be removed or disabled, but that is a declaration [by the administrator of the database] that the defined events should not trigger an action by the user program.