A few years back, when we were sending data, there was a gargantuan file,
sent out weekly. It was over 1G. Took many hours, and usually failed
several times. I seem to think that there was a parameter for sftp that
allowed a resume of a download. That may be a faulty memory. I ended up
using PKZIP and that dropped the file size to a few hundred MB and the
problem ceased.

Looking at the script now. There is a set timeout 20 sent to the remote
server, and later a set timeout 7200 is sent. There is no parameter on the
sftp command to resume a failed send. On my personal computer, running
Linux, the sftp command has a resume option. Not sure if the PASE version
has that option.


John McKee

On Tue, Nov 3, 2015 at 8:34 AM, Steinmetz, Paul <PSteinmetz@xxxxxxxxxx>

I changed the SFTP process to send a 3mb zip file instead of the 110mb
uncompressed file.
SFTP now working with a zipped 3mb file.
Large file issue for SFTP still exists, possibly 30 to 40mb limit.
Still looking to resolve this issue.


-----Original Message-----
From: Steinmetz, Paul
Sent: Monday, November 02, 2015 2:43 PM
To: 'midrange-l@xxxxxxxxxxxx'
Subject: SFTP client via PASE, large files possibly timing out

In production, I converted an FTP to SFTP via PASE, all appeared to be
I did see some issue, large files are possibly timing out.
I could see this from the output of the SFTP process.
The default timeout from what I could find is 30 seconds.
I changed the timeout in the SFTP input script to 300, that appeared to
make the problem worse set timeout 300 Back to set timeout 30 Are there
other timeout settings or other settings that would improve large file

sftp> lcd /BRC/TOA
sftp> put BRCSAI_1102_1350 to_toa/inventory_upload/BRCSAI_1102_1350
Uploading BRCSAI_1102_1350 to /to_toa/inventory_upload/BRCSAI_1102_1350

BRCSAI_1102_1350 0% 0 0.0KB/s
--:-- ETA
BRCSAI_1102_1350 1% 1440KB 1.4MB/s
01:16 ETA
BRCSAI_1102_1350 2% 3136KB 1.4MB/s
01:13 ETA
BRCSAI_1102_1350 4% 4800KB 1.5MB/s
01:11 ETA
BRCSAI_1102_1350 5% 6528KB 1.5MB/s
01:09 ETA
BRCSAI_1102_1350 7% 8256KB 1.5MB/s
01:07 ETA
BRCSAI_1102_1350 8% 9920KB 1.5MB/s
01:05 ETA
BRCSAI_1102_1350 10% 11MB 1.5MB/s
01:03 ETA
BRCSAI_1102_1350 11% 13MB 1.5MB/s
01:02 ETA
BRCSAI_1102_1350 13% 15MB 1.6MB/s
01:00 ETA
BRCSAI_1102_1350 15% 16MB 1.6MB/s
00:59 ETA
BRCSAI_1102_1350 16% 18MB 1.6MB/s
00:57 ETA
BRCSAI_1102_1350 18% 20MB 1.5MB/s
00:59 ETA
BRCSAI_1102_1350 19% 21MB 1.5MB/s
00:57 ETA
BRCSAI_1102_1350 21% 23MB 1.5MB/s
00:56 ETA
BRCSAI_1102_1350 22% 25MB 1.5MB/s
00:55 ETA
BRCSAI_1102_1350 23% 26MB 1.5MB/s
00:54 ETA
BRCSAI_1102_1350 25% 28MB 1.5MB/s
00:52 ETA
BRCSAI_1102_1350 26% 29MB 1.6MB/s
00:51 ETA
BRCSAI_1102_1350 28% 31MB 1.6MB/s
00:49 ETA
BRCSAI_1102_1350 29% 33MB 1.6MB/s
00:48 ETA
BRCSAI_1102_1350 31% 34MB 1.6MB/s
00:47 ETA
BRCSAI_1102_1350 32% 36MB 1.6MB/s
00:46 ETA
BRCSAI_1102_1350 34% 38MB 1.6MB/s
00:44 ETA2015-11-02,13:52:17

Thank You
Paul Steinmetz
IBM i Systems Administrator

Pencor Services, Inc.
462 Delaware Ave
Palmerton Pa 18071

610-826-9117 work
610-826-9188 fax
610-349-0913 cell
610-377-6012 home


This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].