RE: Trigger issue with authority -- MIDRANGE-L

Thanks for the clarification, Charles. So what I believe you're saying
is that if Job A issues an update that causes a long-running trigger to
fire and then Job B issues an update to the same file, then Job B's
program will wait (the default wait time for the file?) and, if it
cannot successfully update in that time, the update operation will fail?
So, that is potentially even more dangerous than just causing a
slow-down in updates. My gut feeling is that you can never just "bolt
on" a trigger program to a file without evaluating the potential effect
on every program that touches the file.

Trevor Briggs
Analyst/Programmer
Lincare, Inc.
(727) 431-1246
TBriggs2@xxxxxxxxxxx

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Charles Wilt
Sent: Tuesday, August 05, 2014 11:00 AM
To: Midrange Systems Technical Discussion
Subject: Re: Trigger issue with authority

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.