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

James H. H. Lampert wrote:

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.

Not that you want people to disable your trigger during production
hours, but for those times when you, using a trigger mediator program is
a good solution. Basically, you write a thin shell that is registered
with ADDPFTRG. The shell reads the trigger buffer and calls a separate
program to do the actual work of the trigger. When you need to
recompile the trigger, you can, because you aren't touching the shell
(which shares locks with the PF).

In the shell you can check a data area or what have you to tell whether
you actually want to fire the processing logic or not.
--buck