Record already locked to this job!? (RPGLE Trigger & Commitment Control)
Ron Koudijs
I run into a CPF5032 "Record already locked to this job", but I don't
know what I did do wrong? I can READ the record for update but I'm
unable to do an UPDATE. In other programs I can do the same without
any problem.
My 'problem' case:
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.
What am I missing?
Ron
Met vriendelijke groeten,
Ron
--------------------
Kou...@Com-Unit.com
Ron Koudijs
--------------------------------------------------------------------------------
Date: August 20, 2001 01:36 AM
Author: John Lewis (jle...@jmasl.co.uk)
Subject: Commitment control locks
Ron,
By the sound of it, a probable explanation is that when program_C
writes the record under commitment control, it remains locked until a
commit or rollback operation is done. So when it tries to lock it for
update it finds it's already locked to the job.
If that's the problem then it sounds like it could be messy to fix.
Regards
John
(http://www.as400network.com/Forums/Index.cfm?CFApp=54&Message_ID=77106)
--------------------------------------------------------------------------------
Date: August 20, 2001 01:48 AM
Author: Ron (Kou...@Com-Unit.com)
John,
I know what you mean, but I've done that before without problems.
Within our 'Order Entry' program we do the same. The user can add,
update and delete (detail)records under commitment control is often
has he or she likes. The program commits or rolls back al the update
on order (header)level.
That's what's puzzling me ...
Ron
(http://www.as400network.com/Forums/Index.cfm?CFApp=54&Message_ID=77107)
--------------------------------------------------------------------------------
Date: August 20, 2001 02:06 AM
Author: John Lewis (jle...@jmasl.co.uk)
Subject: Puzzled
Ron,
I'm also puzzled. I've tried several different ways to reproduce your
problem and so far it always writes, locks and updates the records
successfully.
Does your program_C write and update records through the same open
data path or does it use separate open data paths (ie. more than one
file in the F-specifications)?
John
(http://www.as400network.com/Forums/Index.cfm?CFApp=54&Message_ID=77109)
--------------------------------------------------------------------------------
Date: August 20, 2001 02:15 AM
Author: Ron (Kou...@Com-Unit.com)
I think you've solved my puzzle! ;-)
Here are some of my F-spec's. BAEMBAP, BAEMBAP1 and BEAMBAP2 represent
one and the same file.
I guess that's my problem, so I'm going to change this solution into a
one file approach.
I'll all of you keep you posted. Thanks for the help.
* BA : Packing Balance
FBAEMBAP UF A E K DISK COMMIT INFDS(BA#INFDS)
FBAEMBA01 IF E K DISK RENAME(BAEMBAF:BAEMBAR1)
FBAEMBAP1 UF A E K DISK RENAME(BAEMBAF:BAEMBAF1)
F PREFIX(P1) USROPN
F COMMIT INFDS(BA#INFDS_P1)
FBAEMBAP2 UF A E K DISK RENAME(BAEMBAF:BAEMBAF2)
F PREFIX(P2) USROPN
F COMMIT INFDS(BA#INFDS_P2)
(http://www.as400network.com/Forums/Index.cfm?CFApp=54&Message_ID=77111)
--------------------------------------------------------------------------------
Date: August 20, 2001 03:22 AM
Author: Ron (Kou...@Com-Unit.com)
And again I'm clueless! :-(
I've changed my F-specs, know BAEMBAP is the only (BA)file for update.
But still I get:
- Record 177 member BAEMBAP already locked to this job.
- I/O error CPF5032 was detected in file BAEMBAP.
Now that I've changed my program I wonder weather multiple data paths
could have ever have
caused the problem, because I always refer to the same 'type' of
record through
the same physical / logical / data path.
What else could cause my problem?
- I've checked Activation Groups again, only one named group.
- I've checked Locked Records, 3 records all under the name of
BAEMBAP.
I've also included the actual write and update spec's.
F*****************************************************************
* F I L E D E S C R I P T I O N S P E C I F I C A T I O N S *
*****************************************************************
* OG : Customer
FOGOPDRP UF E K DISK COMMIT INFDS(OG#INFDS)
* TA : Transport Address
FTATRANP UF E K DISK COMMIT INFDS(TA#INFDS)
* Q1 : System Parameters
FQ1SYSPP IF E K DISK
* BA : Packing Balance
FBAEMBAP UF A E K DISK COMMIT INFDS(BA#INFDS)
FBAEMBA01 IF E K DISK RENAME(BAEMBAF:BAEMBAR1)
FBAEMBAP1 IF E K DISK RENAME(BAEMBAF:BAEMBAF1)
F PREFIX(P1) USROPN
* COMMIT INFDS(BA#INFDS_P1)
FBAEMBAP2 IF E K DISK RENAME(BAEMBAF:BAEMBAF2)
F PREFIX(P2) USROPN
C IF NOT %Found(BAEMBAP )
* Balance: Customer * Transport Address
C CLEAR BAEMBAF
...
C WRITE BAEMBAF
C ELSE
* Read with retry in case of locks
C EVAL #RETRY = *ZERO
C DOU *IN22 = *OFF
C @BAAP CHAIN BAEMBAP 22
C IF *IN22 = *ON
C EVAL #INFSR_AK = '*CHECK_LCK'
C EXSR BA#INFSR
C ENDIF
C ENDDO
C EVAL BABASALD = BABASALD + U#BBAANT
C IF BABASALD <> *Zero
C UPDATE BAEMBAF
C ELSE
C DELETE BAEMBAF
C ENDIF
C ENDIF
The "UPDATE" statement above is causing the problem while updating a
record that was
previously written within the same program but on an other
trigger-call
and also within an other 'similar' routine.
Other info:
Commitment definition . . . . . . . . : SPR_VO
-------------Changes--------------
File Library Member Commit Rollback Pending
BAEMBAP SPR4DO BAEMBAP 0 0 3
BBEMBAP SPR4DO BBEMBAP 0 0 4
OGOPDRP SPR4DO OGOPDRP 0 0 1
TATRANP SPR4DO TATRANP 0 0 1
VEVERVP SPR4DO VEVERVP 0 0 1
(http://www.as400network.com/Forums/Index.cfm?CFApp=54&Message_ID=77114)
--------------------------------------------------------------------------------
Date: August 20, 2001 03:52 AM
Author: John Lewis (jle...@jmasl.co.uk)
Ron,
yes, I've not been able to produce your problem using a single ODP nor
using multiple ODPs.
Does your program actually fail on the UPDATE operation rather than
the CHAIN operation?
John
(http://www.as400network.com/Forums/Index.cfm?CFApp=54&Message_ID=77116)
--------------------------------------------------------------------------------
Date: August 20, 2001 04:10 AM
Author: Ron (Kou...@Com-Unit.com)
John,
Thanks for 'still' responding and helping me. ;-)
Yes, the problem really occurs on the UPDATE and not on the READ
instruction.
Message: I/O error CPF5032 was detected in file BAEMBAP (C G D F).
Cause: The RPG procedure BB910S in program SPR6PO/BB910S received the
message CPF5032 at statement 032200 while performing I/O operation
UPDATE on file BAEMBAP. The actual file is SPR4DO/BAEMBAP(BAEMBAP).
Message (CPF5032): Record 186 member BAEMBAP already locked to this
job. Cause: The record in record format BAEMBAF member number 1 of
file BAEMBAP in library SPR4DO is already locked to this job.
I've tried removing an F-spec for the file in 'trouble' from the first
trigger program. Which BTW uses this file for input only. (I'm
starting to become desperate :-() No use ... as we would both expect!
Have you got any other suggestions for me to try?
(http://www.as400network.com/Forums/Index.cfm?CFApp=54&Message_ID=77118)
--------------------------------------------------------------------------------
Date: August 20, 2001 04:38 AM
Author: John Lewis (jle...@jmasl.co.uk)
Ron,
does file_X itself have a trigger program at all?
John
(http://www.as400network.com/Forums/Index.cfm?CFApp=54&Message_ID=77121)
--------------------------------------------------------------------------------
Date: August 20, 2001 04:22 AM
Author: Ron (Kou...@Com-Unit.com)
John,
After reading the underneat information of the message text for
CPF5032. I've tried an explicit UNLOCK BAEMBAP just before the RETURN
with trigger program_B. Unfortunately without any succes ...
Recovery: ... bla bla ... The error code is 1. If the error code is 1,
then this error occurred in a trigger program.
Technical description: ... bla bla ... This lock will not be released
until the record is updated, and the update option is released, the
record is deleted, or the lock is released with a release instruction.
... bla bla ...
(http://www.as400network.com/Forums/Index.cfm?CFApp=54&Message_ID=77120)
--------------------------------------------------------------------------------
Date: August 20, 2001 04:48 AM
Author: Ron (Kou...@Com-Unit.com)
John,
No, file_X itself has no triggers.
At this moment I've tried a USR_OPEN and CLOSE of file_X within
"Trigger Program_C".
This upon a response of "David Abramowitz" stating I should perform an
RCLRSC after the completion of program "A". I just don't know which
program he refers to by "A".
But it was no use! We didn't do such a thing within our "Order Entry'
program either, so I did not have much hope ... :-(
BTW "Trigger Program_C" is the only program that is called twice
before I get my error.
Ron
(http://www.as400network.com/Forums/Index.cfm?CFApp=54&Message_ID=77122)
--------------------------------------------------------------------------------
You are at an AS400Network.com site.
Contact Us | Report Bugs | Submit Comments/Suggestions | Advertise |
Check Your Profile | Site Use Agreement | Privacy Policy
Copyright Š 2001 Duke Communications International, unless otherwise
noted.
This site is best viewed with the latest versions of Netscape or
Internet Explorer, 800 x 600 resolution (or higher), and at least 256
colors.
Ron Koudijs
Thanks for all you've done to help me.
I think it's time for IBM to give us the answer to this problem.
I'm a freight that RPGLE & DB2/400 can't handle my two level nested
triggers approach very well. :-( If that's true it's no use for me to
use triggers at all. Because, what's the use of using triggers to do
only 'half of the work' for me?
Ron
On Mon, 20 Aug 2001 14:44:12 +0200, you wrote:
>Ron,
>I'm afraid my internet connection is down at the moment so I can't post to the
>RPG forum, but I have finally managed to reproduce your problem on our
>machine.
>Interestingly the same problem does NOT occur if the trigger program for
>file_C is run NOT as a trigger program. Therefore, it seems reasonable to
>assume that whatever is causing the problem is a specific consequence of the
>program running as a trigger.
>I still don't know what the solution is but perhaps that might get us a little
>closer (?)
>Regards
>John
Ron Koudijs
Kent Milligan
--
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)
Ron Koudijs
causes trigger to be activated is not the same file as I've got a lock
error on! The file that get's a lock error has no triggers.
The problem is with in the combination of "Commitment Control" and
"Nested Triggers". A change on file 1 causes trigger program 1 to be
activated, that program write records to file 2. The records cause
trigger program 2 to be activated, that program maintains file 3.
Within one transaction the records '2' can make trigger program '2' to
write a record '3', which has to be updated when a next record '2' is
written. That's where the error occurs.
I can simply avoid the problem by no longer maintaining file '3' under
commitment control. But that, of course, is no solution ...
... I'm a freight the combination of DB2/400 and RPGLE just can't
handle my scenario. Which is a shame! :-(
Ron
On Tue, 21 Aug 2001 10:01:51 -0500, Kent Milligan <km...@us.ibm.com>
wrote:
>Did you try adding your trigger with the ALWREPCHG attribute set to *YES?
Met vriendelijke groeten,
Ron
--------------------
Kou...@Com-Unit.com
Ron Koudijs
I've tried ALWREPCHG(*YES) and it works just fine! ;-)
The only thing that still wonders me is: Why does a trigger definition
for file X, interfere with update (under commitment control) for file
Y!?
Thanks for all the help.
Ron
On Tue, 21 Aug 2001 10:01:51 -0500, Kent Milligan <km...@us.ibm.com>
wrote:
>Did you try adding your trigger with the ALWREPCHG attribute set to *YES?