Re: Trigger issue with authority -- MIDRANGE-L

I question the wisdom of CLRPFM anywhere in production code...

Given that it requires *EXCL access, it just doesn't play well with the
concurrent nature of things today.

I'd say to relegate it to defined maintenance periods like RGZPFM...but IBM
has enhanced RGZPFM to play nicer.

Charles

On Tue, Aug 5, 2014 at 2:20 PM, <rob@xxxxxxxxx> wrote:

I question the whole need for a CLRPFM on each firing of the trigger. This
really sounds like someone trying to shoehorn in an existing solution into
a trigger environment.

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

From: Charles Wilt <charles.wilt@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 08/05/2014 11:00 AM
Subject: Re: Trigger issue with authority
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>

As far as a batch job making hundreds of requests within a few
microseconds...

You need to realize that when your code executes a WRITE and/or UPDATE,
control gets passed to the DB code, then to your trigger. It returns from
the trigger to the DB and then back to your code. So the next op-code in
your RPG code won't be executed until the trigger has completed.

Thus the reason for the best practice that a trigger do as little as
possible. Having a long running task in a trigger is not a good idea.

Now, in the OP's case, besides the wait required for the CLRPFM to
complete
making it a bad idea in the first place. You have to worry about
concurrency in a trigger. Since any job could cause the trigger to fire
at
any time, it's likely that it will. Your tigger program needs to follow
best practices for concurrent resource use. As you may guess, having
multiple jobs randomly doing a CLRPFM on the same table is not a good idea
with respect to concurrency.

Charles

On Tue, Aug 5, 2014 at 10:11 AM, Briggs, Trevor (TBriggs2) <
TBriggs2@xxxxxxxxxxx> wrote:

Good question. I haven't used trigger programs much, so I can't say what
happens if the file is updated again while the first invocation of the
trigger program is still running. However, it does seem like a
bottleneck waiting to happen. What happens if you have, say, a batch job
that makes hundreds of updates to the file within a few microseconds?

Trevor Briggs
Analyst/Programmer
Lincare, Inc.
(727) 431-1246
TBriggs2@xxxxxxxxxxx
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Hoteltravelfundotcom
Sent: Monday, August 04, 2014 6:07 PM
To: Midrange Systems Technical Discussion
Subject: Re: Trigger issue with authority

just on the point about the collision. Once i fix the authority issue.

If one user enters a change to the Physical file, lets call it PF1, and
the
trigger gets kicked off. The CL takes about 20 seconds to run. recall
the
CL, clears the PF used to hold latest data then re-populates via RPG
prgram.

After 5 seconds another user makes a change to PF1. the trigger kicks
off
again, and it wants to clear the file. Which is still going to run 15
more
seconds. Does the second trigger wait, those 15 seconds and then kicks
off?

is there going to be any problem with this?

I much prefer the message queue idea but if the current way will work,
they
seem to be ok with the current way.

On Mon, Aug 4, 2014 at 12:15 PM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:

On 8/4/2014 9:12 AM, Hoteltravelfundotcom wrote:

I had a case happen that the trigger would not run.

the trigger is on a physical file which has 2 logicals to it. I

have a

PF

that will be updated when one field in the PF changes.

When change made and trigger is invoked i run a CL program
which clears my work file and then rebuilds it via RPGLE program.

that is all the CL does, CLear and run the RPG.

But got an error CPF3137 NO Authority to clear, initialize etc.

Do I need now to change the authority on that Temp file I created?

the

current is

*PUBLIC * CHANGE

The Knowledge Centre has a page which explains what security is

required

for which operation: IBM Knowledge Center - Defining how information

can

be accessed

http://www-01.ibm.com/support/knowledgecenter/ssw_ibm_i_72/rzarl/rzarlac
ctyp.htm?lang=en

There is another way to 'clear' the table; use SQL. DELETE FROM

TABLE.

--buck

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

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

************************************************************************************************************************************************************************************************************

This message originates from Lincare Holdings Inc. It contains

information

which may be confidential or privileged and is intended only for the
individual or entity named above.
It is prohibited for anyone else to disclose, copy, distribute or use

the

contents of this message.
All personal messages express views solely of the sender, which are not

to

be attributed to Lincare Holdings Inc., and may not be copied or
distributed without this disclaimer.
If you received this message in error, please notify us immediately at
MailAdmin@xxxxxxxxxxx or (800) 284-2006.

************************************************************************************************************************************************************************************************************

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

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

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