MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » August 2014

Re: Trigger issue with authority



fixed

Correct, job B may wait or it may throw an object in use exception causing
the update operation to fail; depending on the the appropriate wait setting.

I disagree with your gut feeling.

I have no issues with bolting on an appropriately designed trigger program.
Sure you need to look at any existing triggers on the same file _AND_ any
existing triggers on the file the new trigger uses. But the nice thing
about triggers is that the DB tracks them for you.

Like anything else, triggers are a tool. You need to learn to use them
appropriately or they can hurt 'ya!

Charles


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

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.


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







Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact