Re: Trigger state: *DISABLED -- what the heck is that, and from what OS revision, and what do I do about it?

I suppose that the idea is to be able to disable all of a table's triggers,
without worrying about what has been written for it. If you use the RMVPFTRG
cmd, you must be sure to know beforehand (source, object, etc.) what
triggers were written, in order to do the corresponding ADDPFTRG (or CREATE
TRIGGER) when you want to enable them again.

Regards,


Luis Rodriguez
IBM Certified Systems Expert — eServer i5 iSeries


On Fri, Oct 16, 2009 at 12:40 PM, James H. H. Lampert <
jamesl@xxxxxxxxxxxxxxxxx> wrote:

Luis Rodriguez wrote:

Use CHGPFTRG File(FileName) TRG(TriggerName) STATE(*ENABLED)

This parameter allows you to activate or inactivate a trigger (instead of
deleting/recreating it).

Thanks.

Something like that MIGHT actually be useful.

IF it could be done while there were users in the file.

Unfortunately, I just found out that it can't. So it's no more useful
than just adding or removing the trigger (indeed, worse, because
PRTTRGPGM doesn't indicate anything about whether a trigger is
deactivated), and looks like the result of somebody in Rochester having
WAAAYY too much time on his or her hands.


And in this case, unless there's something else besides CHGPFTRG that
will put triggers into a disabled state, somebody at the customer went
to a LOT of trouble to turn Workflow off while making it LOOK like it
was still turned on.

--
JHHL
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.