Re: Applying a trigger

Just some clarification inline.

Regards, Chuck

Alan Campin wrote:

Something must have changed. We are at V5R4M0 and I tried to add with
file in use and it wouldn't let me. Years ago you could. They must
have tightened everything up. The bigger trick is removing it.

The only in-use cases which will not impact a request to add a trigger are those opens which are either:

- A pseudo-closed SQL cursor that can be closed by the event defined for /request release/ as /lock conflict action/ within the defined /default wait/ time [ALCOBJ CONFLICT(*RQSRLS)]. Because the close of this type of open is event-driven, such a lock may be held in another job and still allow the close, and is how the DFTWAIT matters

- A /native/ open in the current job which would be closed by a normal Reclaim Resources [RCLRSC] at the current invocation level; and maybe only in the default activation group.

All other /in use/ cases will cause the ADDPFTRG request to fail with either CPF3220, CPF3202, or CPF3203 because the add request requires an exclusive lock on the file being modified by that request.

If trigger is in use, there is no way to remove unless you remove all locks and if you have a file that is in use all the time that
probably means shutting down everything. The other problem is that
the system puts an exclusive lock on the program so you cannot change
it or update it.

It is any change to the trigger program that requires an exclusive lock; the file opened for action that may invoke the trigger, presumably has locked the trigger program with only a *SHRRD which prevents any other requester from effecting any /change/ activity.

<<SNIP Trigger Mediator details>>