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 - 1703 days ago
Last viewed on: 21 Sep 2017 (3792 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)

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 9 months 16 days 12 hours 13 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 9 months 16 days 10 hours 56 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 9 months 11 days 10 hours 5 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