Have you ever changed your password, then forgot what you changed it to? No, of course you haven't. But I have, and on more than one occasion! Have you ever revoked your own authority to an object? It seems to me I've done that, too. When I do such things, I lock myself out of some resource. Recently, I was asked to work on a program that had locked itself out of a database record. I've seen one program lock another program out of a record many times, but I can't ever remember a program locking itself out of a record. Anyway, there's a lesson in this experience we can all benefit from.
Here's the situation. An RPG program accessed one physical file through three access paths--the physical file itself and two logical files that were built over the physical file. The program screeched to a halt when a record that had been read and locked for update through one access path was requested to be read for update through another access path. The system generated error message CPF5032 (Record 2 member CUSMASLC already locked to this job.)
I wrote a short demo program to illustrate this situation.
*** CusMas is a physical file keyed on company number & customer number.
FCusMas uf e k disk rename(CusMasMA: CusMas1)
F infds(infds1)
F
*** CusMasLC is a logical file keyed on customer name.
FCusMasLC uf e k disk rename(CusMasRC: CusMas2)
F infds(infds2)
D SearchComp s 2p 0
D SearchCus s 8p 0
D infds1 ds
D Stat1 *status
D infds2 ds
D Stat2 *status
C Search klist
C kfld SearchComp
C kfld SearchCus
C
C eval SearchComp = 1
C eval SearchCus = 302
C
C eval *inlr = *on
C
C Search chain CusMas1
C if %found and CusCl ='27'
C eval Terrn = 5
C update CusMas1
C endif
C
C* imagine a lot of calculation specs here
C
C CusNm chain CusMas2
C if %found
C eval DCode = 3
C update CusMas2
C endif
C
C return
CUSMAS is a physical file containing customer information. CUSMASLC is a logical file that accesses CUSMAS by customer name. The first chain succeeds, but the IF that follows the chain fails because customer 302 in company 1 does not have a class code of 27. The UPDATE does not happen, which means that customer 302's record remains locked.
Imagine a lot of calculations taking place, until finally the second chain attempts to retrieve the same record by customer name. The record exists, of course, but it is locked. After the time-out period, the system sends CPF5032. By the way, if another program tried to access the locked record, it would error out with message RNQ1218 (Unable to allocate a record in file CUSMAS (R C G D F).)
It's not hard to see the proper solution, which is to unlock the record if the condition fails.
C Search chain CusMas1
C if %found and CusCl ='27'
C eval Terrn = 5
C update CusMas1
C else
C unlock CusMas
C endif
(I wonder: "If the solution is obvious and so easy to implement, why didn't the programmer code the unlock in the first place?")
Those of you who have had your morning coffee are wondering: "What if the chain fails? There's nothing to unlock." And the answer is that the unlock doesn't blow up. Suppose the update is buried within two or more levels of nested logic.
C Search chain CusMas1
C if %found and CusCl ='27'
C RepKey chain RepMas
C if %found and Terr = 'W'
C eval Terrn = 5
C update CusMas1
C endif
C endif
C unlock CusMas
Rather than code an unlock operation for each level, one unlock suffices for all.
Anyway, I try hard to develop and adhere to good programming practice. Here's a rule of thumb that's worth keeping in mind: If you embed an update or delete operation within a condition, be sure to release the lock if the condition doesn't pan out.