Midrange News for the IBM i Community


Posted by: Deepak Deshpande
AS/400 Freelance Programmer/Analyst
India
Record lock situation
has no ratings.
Published: 08 Dec 2011
Revised: 23 Jan 2013 - 1519 days ago
Last viewed on: 22 Mar 2017 (3417 views) 

Using IBM i? Need to create Excel, CSV, HTML, JSON, PDF, SPOOL reports? Learn more about the fastest and least expensive tool for the job: SQL iQuery.

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

Hi

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 

Return to midrangenews.com home page.
Sort Ascend | Descend

COMMENTS

(Sign in to Post a Comment)
Posted by: neilrh
Premium member *
Jackson, MI
Comment on: Record lock situation
Posted: 5 years 3 months 15 days 9 hours 57 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: 5 years 3 months 15 days 8 hours 40 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: 5 years 3 months 10 days 7 hours 50 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!

DD