Re: FTP rename results in two files in IFS

On 1/26/11 12:47 PM, CRPence wrote:

On 1/26/11 11:03 AM, Gary Thompson wrote:

<<SNIP>> the results are put in a .csv file and sent by FTP to a
directory under the IFS Root on our iSeries, resulting in hundreds of
small files a day.

We run a process every few minutes to read these .csv files and post
picking results files on our iSeries

To avoid processing a file before the FTP process completes, we use a
naming convention where the voice pick server does the FTP PUT using
a file named with a prefix of FTP_, and the iSeries post process
ignores any such files.

When the PUT command completes, the VP server re-names the file,
removing the prefix.

About 98% of the time (just a guess) the re-name works as expected.

For some files, however, the re-name results in two files, the
"first" file that has the FTP_ prefix and the "second" or re-named
file without the prefix.

Has anyone seen this?

Any suggestions as to a fix?

<<SNIP Maybe VP server sent the same file name twice?>>

Less likely I would expect, but again given RENAME is part of an FTP scripted request, after the PUT...

The FTP subcommand RENAME is a bit odd for its seeming to perform in two steps, something which one would expect to complete atomically; i.e. RNFR "use accepted" and RNTO "renamed" steps are logged for a RENAME. Perhaps the implementation is such that both names can exist at some point during the RENAME processing, and that some conflict is encountered for which both names remain. Given that assumption, then probably the conflict would arise due to the periodic processing of the non-"FTP_ prefixed" files [for which comparing timestamp for the processing of the non-"FTP_ prefixed" files with the timestamp of the creation and change for the objects might suggest this as a possibility], and probably that effect being allowed per some error having been logged by the REName, but that error having been ignored by a scripted FTP which has effectively no error handling, merely allowing the capability to optionally review the log.

If that were the issue, perhaps instead of the FTP subcommand RENAME, generate a CL request invoked by QUOTE RCMD RNM and see if the error no longer occurs.

Regards, Chuck