More info
1 - one system is Unix (the receiver) the sender is not
2 - we are trying to see if there is a logical reason for this hang, that
can be fixed without redesigning the transfer from the gorund up (changing
the push/pull partners, changing to binary and converting to ebcdic later,
etc etc etc - all GOOD ideas, but we might not be able to implement at this
time)
I am just looking for anyone who has seen this, and was able to tweak the
client or server to stop this.
Keep the ideas coming. Thanks.
> -----Original Message-----
> From: Bochnik, William J
> Sent: Wednesday, October 11, 2000 2:36 PM
> To: tru64-unix-managers_at_ornl.gov
> Subject: RE: ftp hanging on bare linefeeds
>
> Clarification - both systems are not Unix, so we "have" to send the file
> as ascii - the sender is and EBCDIC IBM system (cough cough) and it is
> doing an EBCDIC->ASCII conversion as part of the ftp, and some of the
> characters map to LF's :-(.
>
> -----Original Message-----
> From: Bochnik, William J [mailto:BochnikWJ_at_bernstein.com]
> Sent: October 11, 2000 2:27 PM
> To: tru64-unix-managers_at_ornl.gov
> Subject: ftp hanging on bare linefeeds
>
>
> anyone else have ftp processes into a DUnix box hang on a "malformed"
> ascii
> file (one with multiple bare linefeeds in it when you tell the system the
> file is ascii)?
>
> The system(s) in question are 4.0D and 4.0F with relatively recent patches
>
> ftp> put ex.std
> 200 PORT command successful.
> 150 Opening ASCII mode data connection for ex.std (xx.xx.xx.xx).
> 230-WARNING! 2 bare linefeeds received in ASCII mode
> File may not have transferred correctly.
> 226 Transfer complete.
> 421 Timeout (900 seconds): closing control connection.
>
>
> The problem is that we might not be able to tweak the data file before it
> is
> sent, and occasionally it does end up with multiple bare linefeeds. We
> also
> do not want to xfer it as binary and convert later.
>
> Any comments/ideas/etc??? We're having discussions as to the approach to
> fixing this.
>
>
> William J. Bochnik
>
> Systems Programmer
> Operations, CMIS
>
>
Received on Thu Oct 12 2000 - 11:27:05 NZDT