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.
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
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.
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.
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