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.