Check for open file before reading 3

[jewilson2]

I'm using a MFCobol program in an interface to pick up a file ftp'd from another server for processing. Intermittently, I receive a 9 0018 error file status on that file (which equates to Read Error: Reached EOF before EOR or open in wrong mode).

I'm guessing that because both of these jobs (the feed and the read) are on separate schedulers running at different intervals, that they could be trying to write/read simultaneously.

With that said, what is the best way to add the capability to my program to check the file to see if it's open for writing BEFORE it attempts to read it?

Thanks,
JW

 

[Dimandja]

One way is to use the OS APIs to let your program know when data has been transfered to the file you are monitoring.

The best way is to code your program to always OPEN the file, READ the file, and AT END, CLOSE the file. Repeat at nauseaum. Getting an end of file is not necessarily a bad thing - it's information that you need.

If the file is structured, you could use a START verb before attempting to READ the file.

 

[k5tm]

JW,

This will be a rare occasion for me to disagree (slightly) with Dimandja. There is a standard COBOL way to do this (with the exception of file level locking, which is supported by Micro Focus, among others).[ul][li]Place a section in your DECLARATIVES (at the beginning of the PROCEDURE DIVISION) for your file to trap errors.[/li][li]Place a file status in the SELECT statement.[/li][li]Use the OPTIONAL clause in your SELECT statement.[/li][/ul]

If you attempt to OPEN a file and cannot, you will receive a nonzero error status and will perform the declarative section associated with the file. You should be able to deduce from the error status whether (1) the file is present but unavailable to your program, or (2) not present at all.

When you open the file, make sure you assert a high enough lock level that the FTP program cannot get to the file simultaneously, or that your program cannot get the lock if the FTP program is already there.

No operating system APIs required...

Tom Morrison

http://www.liant.com

 

[fredericofonseca]

Yes ... but. When ftpin'g a file lock does not always work.

I have found the hard way the it is possible to reach the end of the file before the file has been completely transferred.

I have since adopt the following when using FTP into folders that have a program monitoring for a particular file name.

split the existing FTP commands to look like
put orig.file dest.file.tmp
rename dest.file.tmp dest.file

This makes the assumption that the program(s) that are monitoring for new files to the FTP folder will ignore files that do not follow a particular naming convention.



Regards

Frederico Fonseca
SysSoft Integrated Ltd

http://www.syssoft-int.com

 

[k5tm]

Frederico,

A star for you -- very good suggestion.

I think that one can assert a level of file locking that will prevent interference from FTP, but your suggestion has the added benefit of reducing a colision between the FTP source and the COBOL datasink to (almost) zero.

Tom Morrison

http://www.liant.com

 

[MuadDubby]

Hi guys

Another method we've implemented on our end (for similar purposes) entails using flag files. This has the advantage of not having to know what extension of a file to look for.

You download a file as usual, without renaming it or anything. When the download is complete, you create a second file that has the same name as the first one (extension and all), plus a new extension of .DON (for example).

This way you end up with (when the download is complete):

myfile.txt
myfile.txt.don

Then the process that needs to open the file first searches for any .DON files, and if they're found, it deduces the files that they refer to by unstringing the DON filename. Then you delete the DON file, open the downloaded one, and life goes on.

.DaviD.

 

[ceh4702]

What if the directory is unreachable, i.e. server or network is down. Cant you use FTP commands to attempt to read the directory first and look for errors?

Another problem might be storing a file of a name which already exists in case might receive an error or a message back or just an incompletion code. You may not want to force an file rewrite or the replacement of the existing file.

If you do not like my post feel free to point out your opinion or my errors.

 

[ceh4702]

Nevermind I read your post wrong.

Could build in a delay of say 5 minutes. I was just thinking one thing a person might do after FTP'ing is to open the file to see if it actually worked.

If you do not like my post feel free to point out your opinion or my errors.