Scenario: Unix 6.5 Integration Server. A Windows based FTP server that pushes files
into the IS FTP port for that service.
Things work great when I send (FTP) the files from a UNIX server. When I use a Windows
server to send the same files, it’s as if the files don’t want to keep ‘streaming’ into the
service. They tend to quit 1/3 of the way through. Sometimes, the first file will go fine, but the others won’t. I only get this behavior when sending from a Windows based FTP client. I have tried to make sure that both were set the same with respect to MODE, content-type, etc. I’m sending a binary file, with a mix of EBCDIC and TIF data.
Has anyone ran into this issue? Could this possibly be a Filesystem issue?
_brett.
I’ve been thinking about this some more and I’m wondering if the FTP server running on IS for the FTP ports is the problem. Does anyone know how to configure the default buffer size for FTP ports that would invoke a service?
_brett.
Found the problem.
The reason the UNIX server was successfully sending large files to the FTP port without
error on the client side, but windows clients were failing was due to a timeout issue.
The default timeout for the client to wait for a server response needed to be increased
on the windows client. When the file would be processed through the port, the integration server was not sending back a response in a timely manner (sometimes 120 seconds after transmission). Thus, the client would error on not receiving a valid response, even though the error displayed usually was tied to ‘broken connection’.
Hope this helps someone else.
_brett.