Re: Problem with FTP and error code 426

[vhamberg@xxxxxxxxxxx]

Chuck

CHGFTPA has only 1 timer it can change - but there are actually 2 of them - I'm on vacation and not at a machine - but you set these using something like the TIME function on QUOTE or some such. I think one is for the connection wait, one for data wait. From a client running QUOTE STAT will show them both, I think.

Vern

-------------- Original message -------------- 
From: 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.