Comments on: CPF5032 member already locked to this job http://itknowledgeexchange.techtarget.com/itanswers/cpf5032-member-already-locked-to-this-job/ Thu, 23 May 2013 23:54:02 +0000 hourly 1 By: deepu9321 http://itknowledgeexchange.techtarget.com/itanswers/cpf5032-member-already-locked-to-this-job/#comment-91846 deepu9321 Thu, 05 May 2011 12:30:22 +0000 #comment-91846 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

]]> By: tomliotta http://itknowledgeexchange.techtarget.com/itanswers/cpf5032-member-already-locked-to-this-job/#comment-91829 tomliotta Wed, 04 May 2011 20:35:04 +0000 #comment-91829 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

]]>