- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: COBOL - CALL LIB$RENAME_FILE limitiations?
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-14-2006 10:40 PM
тАО05-14-2006 10:40 PM
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?
Solved! Go to Solution.
- Tags:
- COBOL
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-14-2006 11:24 PM
тАО05-14-2006 11:24 PM
Re: COBOL - CALL LIB$RENAME_FILE limitiations?
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-14-2006 11:44 PM
тАО05-14-2006 11:44 PM
Re: COBOL - CALL LIB$RENAME_FILE limitiations?
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-15-2006 12:01 AM
тАО05-15-2006 12:01 AM
Re: COBOL - CALL LIB$RENAME_FILE limitiations?
However, if you specify the file-scan-context parameter, you should call LIB$FILE_SCAN_END to free the context.
Rgds
Marc
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-15-2006 01:16 AM
тАО05-15-2006 01:16 AM
Re: COBOL - CALL LIB$RENAME_FILE limitiations?
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-15-2006 02:03 AM
тАО05-15-2006 02:03 AM
Re: COBOL - CALL LIB$RENAME_FILE limitiations?
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-15-2006 02:26 AM
тАО05-15-2006 02:26 AM
Re: COBOL - CALL LIB$RENAME_FILE limitiations?
>>> 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-15-2006 03:43 AM
тАО05-15-2006 03:43 AM
Re: COBOL - CALL LIB$RENAME_FILE limitiations?
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-15-2006 03:44 AM
тАО05-15-2006 03:44 AM
Re: COBOL - CALL LIB$RENAME_FILE limitiations?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-15-2006 04:31 AM
тАО05-15-2006 04:31 AM
SolutionI 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.