COBOL - CALL LIB$RENAME_FILE limitiations?

[Hitesh Rawal]

Does anybody know if there are limitations to the number of files that can be renamed using a call to the RTL LIB$RENAME_FILE?

I have recently included this call within a COBOL program and the program fails whenever it reaches the 286th file.

I originally look for a valid file using the LIB$FIND_FILE call (wildcard) and then use the LIB$FIND_FILE_END call as I understand that the virtual memory needs to be deallocated.

Unfortunately, there does not seem to be a LIB$RENAME_FILE_END routine?

The rename does not use wildcards.

Can anybody shed some light on this?

[Marc Van den Broeck]

Hi,

I use following code to rename thousands of files in the same program run:

000770 01 WS-FILENAME-IN PIC X(100).
000780 01 WS-FILENAME-OUT PIC X(100).

003780 CALL "LIB$RENAME_FILE" USING BY DESCRIPTOR WS-FILENAME-IN
003790 BY DESCRIPTOR WS-FILENAME-OUT
003800 OMITTED
003810 OMITTED
003820 OMITTED
003830 OMITTED
003840 OMITTED
003850 OMITTED
003860 OMITTED
003870 OMITTED
003880 WS-FILENAME-OUT-VERSION
003890 GIVING RETURN-CODE.
003900 IF SS$_NORMAL
003910 DISPLAY " -E- -> file renamed naar "
003920 WS-FILENAME-OUT-VERSION
003930 ELSE
003940 DISPLAY " -E- -> FOUT bij rename file code: "
003950 RETURN-CODE CONVERSION.

This probably formats bad but I hope you can read it.

Rgds
Marc

[Hitesh Rawal]

I notice that you do not supply the file-scan-context - LIB$RENAME specifies 12 parameters, the last being the [file-scan-context].

I will change my call to remove the context parameter and see what the outcome is.

Alternatively, could I follow the LIB$RENAME with a LIB$FILE_SCAN_END providing the [file-scan-context] used?

Thanks in advance
Hitesh

[Marc Van den Broeck]

The file-scan-context is optional. So, if you dont need it, dont use it. Normally you use OMITTED for a parameter you dont need, but if it is the last parameter you can leave the OMITTED away.
However, if you specify the file-scan-context parameter, you should call LIB$FILE_SCAN_END to free the context.

Rgds
Marc

[Hein van den Heuvel]

You really should try to figure out whether the file scan context is of value to your application.
First and foremost... are you using wildcard matches?

Maybe there are currently 'smarts' in the cobol to massage the file names which RENAME can take care of when asked.

If you are doing simple one-at-a-time renames (and it sounds like your do), then I would recommend Omiting the context argument.

If you are doing series of related renames, then you should close each series with
LIB$FILE_SCAN_END as the documentation clearly indicates:


"LIB$FILE_SCAN uses this context to retain multiple input file related file
context. This is an optional argument; it need only be specified if you are using
multiple input files, as the DCL command RENAME does.

You may deallocate
the context allocated by LIB$FILE_SCAN while processing the LIB$RENAME_
FILE requests by calling LIB$FILE_SCAN_END after all calls to LIB$RENAME_
FILE have been completed. See the description of LIB$FILE_SCAN for a more
detailed description of this argument."

hth,
Hein.

[Hitesh Rawal]

Thanks for the information.

The program looks in a directory for any file matching TRF_*.DAT (wildcard) using LIB$FILE_FIND. I then isse a LIB$FILE_FILE_END immediately after.

I then open the file, process the contents and then move the file to a different directory using LIB$RENAME (so as not to process it again).

That being the case, I decided that the context was not needed and removed it, simplifying the entire call to :

CALL "LIB$RENAME_FILE"
USING BY DESCRIPTOR WS-TRF-FILENAME
BY DESCRIPTOR WS-RENAME-FILENAME
END-CALL.

Unfortunately this too encounters the same problme on execution - 286 files followed by a failure to rename.

I have logged the error further and now receive an error stating that there is an "error in device name"??

We are now looking into the possibility that there is a problem with the logical directory we are trying to rename into.

Thank for the help. I will be doing some further investigation/testing and will let you know the outcome.

[Hein van den Heuvel]

>>> The program looks in a directory for any file matching TRF_*.DAT (wildcard) using LIB$FILE_FIND. I then isse a LIB$FILE_FILE_END immediately after.

Sounds like a missed performance opportunity.
Can the logic be altered to loop through all the files, processing them before closing with FILE_END?

Anyway, the program is probably leaking channels. Check with F$GETJPI(pid,"FILCNT")
Freeze the program with a debugger at the various interesting spot: Before/after FIND_FILE, FIND_FILE_END, RENAME_FILE.
Maybe the _END call is not made correctly?

Be sure NOT to have a wildcard in the rename spec.
Also be sure to try with an input spec which is not a search list. It may make a difference.


Hein.

[Hitesh Rawal]

Red herring on the invalid device.

Rename does not use wildcards.
I will also look into doing the file end after processing. Should I use the same context value in the rename?

Eg

- FIND_FILE using by reference WS-FF-CONTEXT
- process the file
- RENAME using by reference WS-FF-CONTEXT
- FIND_LINE_END using by reference WS-FF-CONTEXT

I have just run in debug and the program aborts at the 278th file. All executions without debug failed at file no. 286

Pretty certain now that this is a virtual memory allocation issue and I am not issuing a FIND_FILE_END somewhere.

Thanks again.

[Hitesh Rawal]

Sorry. Just remembered, I don't need the Context on the rename

[Hein van den Heuvel · Accepted solution]

Right, you do not seem to need the context on the rename, and if you did it must be a different one from the find.


I think you are doing
LOOP:
Find - process - rename - end_find

Please consider

find first
loop: proc - rename - find-next
end_find

If you are not actually using the find context, then I'd prefer to see the find immediately being followed by the end, simplifying the error handling/cleanup. eg:
Loop:
find - end_find - proc - rename


I still suspect you are running out of channels, not memory.
Just make sure to check with GETJPI or similar tool (ANAL/SYS).

$write sys$output f$getjpi(PID,"PAGFILCNT")
$write sys$output f$getjpi(PID,"FILCNT")

Hein.