Re: Why is an Input/Primary file in an RPGLE program in a CLLE program locking a file?

Booth Martin wrote:

Why is an Input/Primary file in an RPGLE program in a CLLE program locking a file?

There is a series of steps, including calls to three RPGLE programs. These steps all run fine when one after another from the command
line.
Now, I have put the steps into a CLLE program. When I run the CLLE
I get a halt saying a file I am trying to clear is locked. The only thing I see, so far, is that the second program has the locked file as Input/Primary, so there is *INLR set on in the program. Could
that be my problem? If not, any ideas? If so, what fixes the
problem?

A file open [for read only] implicitly locks the *FILE object, the Member [*MEM object], and the Data [*QDDS DataSpace object] with a *SHRRD lock level. Open for more than read-only may effect higher lock levels for the data [and\or member]. Thus the input primary file is locked, because it is open.

It seems several comments are being offered, beyond apparently the same alluded by the OP, whereby "in use" is being misspoken as "locked". An open file is /in use/ by the job, but no lock within that same thread will conflict with another [in this case probably the job with one thread]. The job could have an exclusive lock on the member, but that lock will not prevent the same job from performing the clear; nor anything else that simply requires a lock. A CPF3202 [or CPF3203] indicates that there is a /lock/ conflict for the failed attempt, but a CPF3220 indicates there is a /use/ conflict for the failed attempt. So indeed, the file must be /closed/ to enable the clear, which LR, RCLRSC, or RCLACTGRP can effect, but that has nothing to do with locks that are held.

Note that a request processor, a command line, may implicitly perform an effective RCLRSC for a number of reasons; e.g. for any failed command invocation. A CLP or CLLE program which monitored for an error would not effect the same reclaim, and thus a program that was called which did not close the file, could result in different functionality between command line invocations and program invocations. Running both scenarios with a breakpoint in '/1' of QDMRCLSE [reclaim close processing] will likely pinpoint where the file is being closed in one scenario, but not in the other. That combined with the WRKJOB OPTION(*OPNF) after each program call as suggested by Barbara, is what needs to be known; i.e. almost surely locks can be ignored for the given scenario, which is presumably for an /in use/ condition manifest instead [of CPF3220] as CPF3130 for CLRPFM and for similar operations that access the mbr.data for pseudo-I/O operations; those operations not initiated by an /open/.

Regards, Chuck