We have a number of FTP jobs that send files which might sometimes contain zero records.  This is not necessarily an error condition, but FTP prints a message "CONNECTION CLOSED;TRANSFER ABORTED", (but, IIRC, does not set FTPLASTERROR.)

Our STDLIST scanning product then picks up on the word "ABORTED", and someone gets to dial-in in the late evening to find out there is no problem.

Sure, we can pipe those mesages to $null and check FTP@ variables, removing important information from the $stdlist.

And we could easily test the file for emptyness, and not send it if empty, but it is desireable that the user on the other end see a new empty file (with new time stamp) rather than an old empty file or no file.

We could stuff an "empty file" message record into the empty file, ..... not quite elegant.

Ideally, empty files would get sent to the remote (NT) and no "ABORT" string of characters would be produced by FTP.

Whether FTP, by convention, is supposed to work this way is of academic interest, but not of practical utility.

Is there any configuration option, command, parameter, or other "trick" to make FTP act like send <emptyfile.txt> is A-OK?
Bound to be other imaginative workarounds from list members.  NOTE: file is fixed length, so cannot put a zero-length record into the file.

Thanks,

Dave

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *