165 pts.
 CPF5032 member already locked to this job
I have a program written in RPGLE which calls numerous other programs. These programs all share similar files. In my main program, when trying to read a particular file, I get error CPF5032 even though I unlock the file right before I do the setll reade. As a result, I figured the lock must be coming from one of the called programs. However, I thought if I turned *INLR on before exiting the programs, all record locks would be released. Is this not true? Also, is there a way to tell which program actually has the record locked? As I said before, the program calls numerous other programs and it could be any one of them? 

Software/Hardware used:
AS400 V5R4
ASKED: May 4, 2011  6:39 PM
UPDATED: February 21, 2012  10:35 AM

Answer Wiki:
If your file is opened in input mode then there should not be any problem. If it is in update mode then the UPDATE opcode should be executed before going to the next program. And if your are not updating a record then use CHAIN(N) while reading a file. Please let me know if this answers your question!!! Thanks No, it does not answer my question. I still hit the CPF5032 error when I use CHAIN(N). I also try UNLOCK file. Still hit CPF5032.
Last Wiki Answer Submitted:  February 21, 2012  10:34 am  by  Trishaful   70 pts.
All Answer Wiki Contributors:  Trishaful   70 pts.
To see all answers submitted to the Answer Wiki: View Answer History.


Discuss This Question:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _


 

However, I thought if I turned *INLR on before exiting the programs, all record locks would be released. Is this not true?

Maybe. It might depend on how programs are compiled. What activation group does the outer program run in? How about the inner programs? What access methods are used? (At the simplest level, are these native I/O or SQL?) Are any overrides in effect at any level?

First thing to check is the CPF5032 error code shown in the 2nd-level text. What is it?

Tom

 107,995 pts.

 

If you are locking the file in main program and if you try to access the same in one of the sub programs it will give the same result(i.e., CPF5032).
in this case, *INLR ON will actually not release the locks before calling subprogram.

But, If you are locking the file in one of the sub programs and once the sub program finishes(*INLR ON) you can access the same in main program or any other sub programs.

If you really dont need to update the file in main program then you can use ‘READ(N)’ while reading the file. So, that Main program will not lock the file(Similar to Sub programs also).

PRADEEP

 3,370 pts.