Re: Applying a trigger

[CRPence <CRPbottle@xxxxxxxxx>]

  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>>