Record lock situation

Posted by: Deepak Deshpande

AS/400 Freelance Programmer/Analyst

India

Record lock situation
has no ratings.

Published: 08 Dec 2011
Revised: 23 Jan 2013 - 4110 days ago
Last viewed on: 25 Apr 2024 (5453 views)

Main URL:

Record lock situation Published by: Deepak Deshpande on 08 Dec 2011 view comments(3)

I have an interesting situation. In our order processing system, we have a series of programs. Since there are multiple ways (Punched/Through FTP/Through Telxon units etc.) in which order gets created, the entry programs are different.

So far, we had about 6 to 7 members (Ex. FTP/POS/TLX etc.) in our order file where the orders get created through work file & then the subsequent flow is same for all members until orders get transferred to 'ORDER' member.

Today I added a new member and a new entry point for orders. All programs work fine except one RPG program. This particular program reads LF1(NEWMBR) & updates LF2(NEWMBR). Both LFs are in UPDATE mode. Here I get a record lock condition. Please see the code below.

FLF1     UF  E           K        DISK
FLF2     UF  E           K        DISK

I@REC1
I              FLD1                            XFLD1
I              FLD2                            XFLD2


C           KEY2      SETLL LF2
C           *INLR     DOUEQ'1'
C           KEY2      READE LF2                      LR
C           *INLR     IFEQ '0'
C           KEY1      CHAIN LF1                     91

Since READE would lock the record, CHAIN would fail. But how did it work earlier?

I am on V6R1, if it helps.

Totally clueless on this, any help appreciated.

TIA,
Deepak

Sort Ascend | Descend

COMMENTS

(Sign in to Post a Comment)

Posted by: neilrh

Premium member *

Jackson, MI

Comment on: Record lock situation
Posted: 12 years 4 months 19 days 7 hours 56 minutes ago

CHAIN will always pick up the first matching record, so if you have 10 records that match KEY1, the CHAIN will always pick the first - either by next key field of LF not specified in KEY1 or FIFO. If the READE has picked a record that is not the first then the CHAIN will not fail.

You can avoid this by adding a LO indicator on the CHAIN and when ON you can probably assume that you're trying to read the same record.

Posted by: DaleB

Premium member *

Reading, PA

Comment on: Record lock situation
Posted: 12 years 4 months 19 days 6 hours 39 minutes ago

Do LF1 and LF2 have the same keys? If they're not UNIQUE, and you haven't specified FIFO, LIFO, or FCFO, then the order of the duplicates is not guaranteed, so you can read different rows with what appears to be the same key value. If KEY1 and KEY2 are partial keys, order of duplicates is controlled by the lower order unspecified keys, but after that it falls back to UNIQUE/FIFO/LIFO/FCFO; again if none of these order is not guaranteed.

Posted by: DeepakD

Premium member *

India

Comment on: Record lock situation
Posted: 12 years 4 months 14 days 5 hours 49 minutes ago

Actually it was very stupid of me. Since I had not changed any logic in the RPG program, I had not given enough thought to its logic. Later I realized that KEY1 and KEY2 had ORTY (Order type) field but had different values always. The program is expected to read LF2, check if record exists in LF1 (Which doesn't because ORTY is diff.) and then update ORTY. So essentially, one would never find the same record in LF1 & LF2 and control would always go to ELSE part.

Anyway, thanks to neilrh and DaleB for your responses, I appreciate!

Have a good day!