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

Booth Martin wrote:

What makes the process fails is an effort to clear a file so that it may be re-used.

Open of member FILE1P was changed to SEQONLY(*NO). Open of member FILEL1P was changed to SEQONLY(*NO). Member FILE1P already in use.
That is a snippet from the job log.
Between line 2 and line 3 an RPGLE program is run with this F-spec
FFILE1P ip e disk .
and then FILE1P is cleared. The failure occurs at that point, with the information that FILE1P is in use.

It looks like the first program opens FILE1P too. Maybe it's that program that is leaving the file open.

A debugging suggestion: Run the CLLE program in debug, and after each call to one of the programs, do DSPJOB OPTION(*OPNF). Once you know which program is leaving the file open, step into the program, and see why it is returning with LR off.

There's nothing special about a primary file from the system's point of view. If you return from a module with LR off, and you have open files, the files will stay open. That's true whether you have primary or full-procedure, and whether you have USROPN or not.

I'm having trouble imagining why it would make a difference running the programs from CLLE. If the programs leave files open, they would do that when called from the command line or from any activation group.

The only thing I can think of is that you were using RCLRSC between the calls when you were calling from the command line. If your programs run in *CALLER activation group, RCLRSC would close the files when you call from the command line, but it wouldn't close the files when you call them from an ILE activation group.