Re: triggers and clrpfm and such -- MIDRANGE-L

a good point - i am probably over dramatizing the impact.

I'm just going to start with this one file and modify the code to *disable
the trigger, clrpfm, and then *enabled back.
then see what else we may be facing.

thanks

jay

On Tue, Oct 29, 2019 at 3:31 PM Rob Berendt <rob@xxxxxxxxx> wrote:

Is this really an issue? How often does one CLRPFM a file with triggers
on it? I can't imagine just whilly-nilly performing a CLRPFM on our item
master table.
I suppose if you had a batch header table and a batch detail table and the
trigger on the detail updated the summary in the batch header table might
be an issue. Is this the case?

I would not delete the triggers. Just turn them off/on as needed. This
is what replication H/A solutions do on the target systems. See below for
sample.

create table rob.oktrig (mycol char(5));

create table rob.oktrigcnt (nbrtrig int);

insert into rob.oktrigcnt (nbrtrig) values(0);

create trigger rob.addem
after insert on rob.oktrig
FOR EACH ROW MODE DB2SQL
update rob.oktrigcnt set nbrtrig = nbrtrig + 1;

create trigger rob.dropem
after delete on rob.oktrig
FOR EACH ROW MODE DB2SQL
BEGIN ATOMIC
update rob.oktrigcnt set nbrtrig = nbrtrig - 1;
end;

insert into rob.oktrig values('hi');

call qcmdexc('clrpfm rob/oktrig');
Trigger program or external routine detected an error.

alter trigger rob.dropem disable;

call qcmdexc('clrpfm rob/oktrig');
CALL statement complete.

alter trigger rob.dropem enable;

Of course, at this time the value in rob.oktrigcnt is inaccurate, as you
disabled the 'nbrtrig - 1' logic.

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Jay
Vaughn
Sent: Tuesday, October 29, 2019 1:13 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: triggers and clrpfm and such

CAUTION: This email originated from outside of the organization. Do not
click links or open attachments unless you recognize the sender and know
the content is safe.

so someone added triggers to our db2 file.
Of course now any clrpfm will not execute unless they are *disabled first
for that file right?

So what is the best way to implement a solution for this without having to
comb through the entire application layer?

Any chance some kind of exit pgm could handle this for us? Possibly tied
to such commands like clrpfm... and whatever other command we need to be
aware of with triggers?

tia

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

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com