Re: FTP Fails with "426 Transfer cancelled"

hi Sam,

The remote session records 10054, if I read correctly what the remote
support guys sent me. (There is a slight language barrier.) I think
10054 means "connection reset by peer".

Correct, 10054 is Windows Sockets error code WSAECONNRESET, which does indeed mean "Connection reset by peer".

Typically, this error message ("connection reset") implies that the socket was disconnected in a way that would lose data. So data may have been sent (by one side or the other) and never received. That's the difference between "connection reset" and other methods that indicate that the connection has ended.

Our network guy suggests that we are timing out somewhere in the
transfer because the remote system isn't getting back to us quickly
enough.

Errr... It seems rather unlikely that a timeout would generate a WSAECONNRESET. Bear in mind that the error is occurring during the transfer of data on the data channel -- it's not occuring in the command channel. (If the command channel had been reset, you couldn't receive a "426 Transfer Cancelled" message.) Since the data channel has no user interaction, it's purely a program-to-program transfer of file data, I don't see how it could time-out?

I guess a time-wait timeout might cause this. Take a look at the value you have for CHGTCPA TCPCLOTIMO(xxx).

Where would I configure how long we wait before cancelling the
transmission?

Is CHGFTPA the right place to look? If so, all I see there related to
time is INACTTIMO, which is set to 300.

It sounds to me that you are using the client (rather than the server) on IBM i. CHGFTPA pertains to the server.

I don't think there's a client-side timeout setting. Since the client-side is interactive, you'd normally just hit an F-key to abort when you're tired of waiting.