Re: Problem with FTP and error code 426

[CRPence <CRPbottle@xxxxxxxxx>]

  Yes it is very possible [even probable] that the FTP thinks there is 
a problem due to lack of a response for a request for data, thus kills 
the connection.  There was a similar issue with large save files that I 
had provided input on for its resolution, but the details are no longer 
in memory ;-)  But save files as a /dump space/ object are very simple 
by comparison to a database file with regard to a reset\truncate of the 
data, so even if I remembered, probably not too relevant.

  A CLRPFM is probably a good circumvention; one which would not have 
to be removed even if the feature were to be /improved/ to no longer 
have the issue.

  I am not sure if any timer settings for FTP would have any affect on 
what I infer is a timeout on the wait for the request for the data, but 
the CFGTCPFTP [or CHGFTPA] could be reviewed for what is available.

Regards, Chuck

Dave Odom wrote:
> Even though my error message wasn't the same as the ones on the IBM
> sites your URLs pointed, they did give me a hint of what might be
> wrong.   It appears, at this point, I needed to code a CLRPFM in my
> REXX before my GET.  After adding that, so far, it seems to work.  I
> was assuming (yes, I know) that since I was using GET with (REPLACE,
> the old version of the files would be replaced with no problems.
> With small files this may be the case but as some of my files are in
> the millions of rows, it seems a CLRPFM before my GET makes things
> work better and not get hung up.  My theory is that since the files
> are large and the (REPLACE may take awhile to get rid of the old
> version of the file, TCP/IP drops the connection and when the GET
> tries to do its thing, it fails.   But, I'm guessing here as to
> what's going on based on bits and pieces of info.