IBM? Two levels of nested Triggers --> locking error! (RPGLE)
Ron Koudijs
See my previous thread: Record already locked to this job!?
(RPGLE Trigger & Commitment Control)
And: on WWW.AS400NETWORK.COM/FORUMS RPG General Forum.
Why do I get a CPF5032 "Record already locked to this job" when using
triggers to perform multiple update's on the same record with one
commitment control transaction.
And why do I not get the same error when performing the same actions
WITHOUT THE USE OF TRIGGERS?
Ron
Ron Koudijs
Bruce Bardini
Here's a thought. When the trigger fires, is it BEFORE update, or AFTER?
If it's AFTER, then without looking at your code, I don't know what's going
on either. But if it's BEFORE, maybe this is what's happening:
Your program reads a record and issues an UPDATE.
This fires the trigger (at this point though, the update hasn't happened in
your program yet, so your program still has a lock on the record)
Trigger program tries to get the same record for UPDATE, but it can't,
because the record is already locked to the job.
Does this make any sense?
Bruce Bardini
--
"Ron Koudijs" <Kou...@Com-Unit.com> wrote in message
news:6622otoran409oion...@4ax.com...
Tim M
trigger? There is no need to do this; all the fields from the before and
after image of the record is available to the program via the parameters
passed to it.
Furthermore, in a *BEFORE trigger with ALWREPCHG specified you can modify
the contents of the record before it is written to the database table.
Remember a trigger program runs in the same commitment definition as the
program that issued the I/O operation and that record locks are held on all
touched records until the transaction is committed or rolled back. If your
trigger program is attempting to update a record (either in the same file,
or another file) that has been touched in the same transaction, you will get
this error.
If this behaviour is unavoidable, make sure that the trigger program opens
the affected file under commitment contral and try using a shared open of
the affected file. This will cause the trigger program to use the same ODP
as the application and may avoid the "already locked to process" message
"Ron Koudijs" <Kou...@Com-Unit.com> wrote in message
news:6622otoran409oion...@4ax.com...
Ron Koudijs
I use *AFTER triggers, so that's not the problem.
BTW In case of an *BEFORE trigger, you are allowed to change to
'new-record' image. So there would be no need to do a read and update
on the perticular record.
In my case the problem is that on the 'first' trigger-call a record is
written which I need to update on a 'second' trigger-call. The record
that is written, is to an other file and that file as no triggers.
Both file's are under commitment control.
Thanks for your help.
Ron
On Mon, 20 Aug 2001 22:21:08 GMT, "Bruce Bardini" <bruc...@home.com>
wrote:
Ron Koudijs
Yes, I know about ALWREPCGH(*YES) but that also not what I need.
Your last statement is, in my opinion, not true. We've got an
interactive "Order Entry" program under commitment control. The order
header has got many different kinds of detail records, all to by
maintained by it's own maintenance program which will be called by the
header maintenance program. The user can go back and forward from
header to details. The user can add, change and delete details as
often as you like, without any problem!
Second, when I change my scenario to one without triggers but still
with commitment control is works fine (John has tested it for me).
When I change my scenario to one without commitment control for my
'problem' file, it also works fine. So the problem must lay some where
in the use of two nested triggers.
I'll repeat my case from (Record already locked to this job!? (RPGLE
Trigger & Commitment Control)):
Program_1 :
- starts commitment control using a call to QCMD: 'STRCMTCTL
LCKLVL(*CHG) CMTSCOPE(*ACTGRP)' and thereafter opens file_B.
- processes file_A with detail records _B.
- each detail record_B is updated (which will trigger program_B).
- after each record_A a COMMIT is performed.
Trigger Program_B:
- opens file_C under commitment control
- writes one or more records to file_C (which will trigger program_C)
upon a curtain update on a record_B.
Trigger Program_C:
- opens file_X under commitment control
- write or updates "balance" records_X.
Within ONE RECORD_A TRANSACTION it might occur that program_C first
writes a record_X and thereafter (in an other call) also updates the
SAME record_X. That's when i get the error! :-(
Program_1 runs in a named activation group, the programs _B and _C
both run in the activation group of their *CALLER.
I run into a CPF5032 "Record already locked to this job" within
trigger_program_C! I can READ the record for update but I'm
unable to do an UPDATE.
Ron
On Tue, 21 Aug 2001 04:04:49 GMT, "Tim M" <scot...@home.com.xyz>
wrote:
Met vriendelijke groeten,
Ron
--------------------
Kou...@Com-Unit.com
Kent Milligan
triggers are supposed to prevent destructive data changes (think of it multiple
changes/visits to a record) from occuring within a transaction/commit boundary.
I'd suggest giving ALWREPCHG(*YES) a try since enables destructrive data changes
in transactions associated with a trigger.
--
Kent Milligan, DB2 & BI team
PartnerWorld for Developers, iSeries
km...@us.removethis.ibm.com GO HAWKEYES!!
(opinions stated are not necessarily those of my employer)
SJ Lennon
news:j425otk0sdmfc5l3f...@4ax.com...
> Trigger Program_C:
> I run into a CPF5032 "Record already locked to this job" within
> trigger_program_C! I can READ the record for update but I'm
> unable to do an UPDATE.
>
it. If that is immediately followed by an UPDATE which fails then it
sounds like a database bug.
Are you up to date on database PTFs for whichever OS release you are
running?
Sam
Ron Koudijs
a solution.
On Tue, 21 Aug 2001 13:27:00 -0500, Kent Milligan <km...@us.ibm.com>
wrote:
>I don't have time completely understand your environment, but by default
>triggers are supposed to prevent destructive data changes (think of it multiple
>changes/visits to a record) from occuring within a transaction/commit boundary.
>I'd suggest giving ALWREPCHG(*YES) a try since enables destructrive data changes
>in transactions associated with a trigger.
Met vriendelijke groeten,
Ron
--------------------
Kou...@Com-Unit.com
Ron Koudijs
I'm on V5R1 and it hasn't been more than 2 weeks that we've received
an installed the last cum-pack. But I also think it's some kind of
bug.
Ron
Met vriendelijke groeten,
Ron
--------------------
Kou...@Com-Unit.com
Robert Dean
reference. One of the things that it specifically states is that for
a trigger with ALWREPCHG(*NO), the record may be read, but it may not
be updated.
Ron Koudijs
Met vriendelijke groeten,
Ron
--------------------
Kou...@Com-Unit.com