ftp hangs for long transfers

[Tom Geudens]

Hi all,
The situation :
We use Control-M to schedule jobs that contain steps on both (IBM)Mainframe and HP(Unix). We initiate the ftp's from the HP platform (initiating them on Mainframe makes them real slow).

The problem :
Sometimes (for Datawarehouse) we ftp files that run into the gigabytes. Most nights this works fine. But sometimes these ftp's hang. And they hang for days (they don't get a timeout) until we at last have mercy on them and kill them.

What I already did :
- Installed the latest ftp patch
- Made sure the filesystems support largefiles

Any help would be welcome. The suggested workaround would be to check if the ftp does something and if not kill it ... but personally I don't like that kind of solution.

Regards,
Tom

[Duncan Edmonstone]

It's all very well making the UNIX end work correctly, but I'd me much more tempted to check on the config of your mainframe... Historically the TCP stack on OS390 & MVS was incredibly flakey, and if your not on an up-to-date version this could be where your problem lies. Does the HP server have difficulty doing FTP transfers to other (non MF) systems on the same site as the mainframe - I would check this out first.

HTH

Duncan

[Tom Geudens]

Hi,
For clarification (thanks Deepak for making this clear) :
- We issue ftp get's. The files are on the mainframe and datatwarehouse is on Unix.
- The mainframe runs on OS/390 V4R1M0 which (I'm being told) is very up-to-date.

Tom

[Tom Geudens]

Hi again,
Must be really asleep today. I meant "thanks Duncan" :-)
Tom

[Mark Greene_1]

try adding the "hash" command at the beginning of the ftp process so you get some more packets sent back to the HP.

HTH
mark

[Craig Rants]

I would do the same thing that Mark has suggested, sometimes the STDOUT to the console keeps the connection up.

GL,
C

[Tom Geudens]

Hi,
Ok, I'm gonna try hash. As this will be for tonight, I'll assign the points (which are coming) in the morning (naughty me :-).

Tom

[Tom Geudens]

Hi,
hash seems to work ... at least, the connection wasn't lost.
I didn't forsee (never worked with hash before) the fact however that a # is added to the stdout for every 1024 bytes. With big files this tends to generate a serious logfiles. We need these logfiles because everything runs in batch ...
To make a long story short :-) ... I ran out of filesystem space on the logfiledirectory. I'll try again next night ... but if anyone has a different solution ... I'd still like to here it.

Regards,
Tom

[Steven Sim Kok Leong]

Hi,

If you run a firewall in-between the FTP client and FTP server, one possibility is the TCP session timeout (TCP connection idle timeout) set at your firewall.

When you have a huge file transfer, commands are sent to the FTP control connection (port 21), subsequently, the FTP data connection (port 20) takes over for the file transfer. The FTP control connection is left to sleep until the file transfer completes. If the period of file transfer over the FTP data connection exceeds the TCP session timeout value set at your firewall, this results in the FTP data connection sleeping longer than the TCP session timeout value. As a result, your FTP control connection will be terminated by the firewall.

I suspect that "hash on" sends hashes via the FTP control connection, thus ensuring that the FTP control connection never exceeds the TCP session timeout and this prevented your FTP session from hanging.

If there is a firewall between the FTP client and FTP server, check the TCP session timeout settings at the firewall.

Hope this helps. Regards.

Steven Sim Kok Leong

[Tom Geudens]

Hi,
The DATATIMEOUT parameter (which - so they tell me - is the only parameter that could have effect) on the mainframe is set to 5 minutes. They also tell me that this can not have a negative effect ...

We do not have a firewall between the Unix server and the mainframe (both are "internal" servers).

Regards,
Tom

[Duncan Edmonstone]

Hmm, I seem to remember that some ftp clients let you set the number of bytes of data that are tx before a hash is sent... but not the default HPUX ftp client...

Of course if all these annoying hashes are just filling up your logs, you could filter the output of ftp thro sed to get rid of them, something like:

ftp -n < my_ftp_cmds | sed s/^##.*/g > my_ftp_log


Yes I know its a kludge!!

Duncan

[Tom Geudens]

Hi All,
It took me a while to get back to this, but the problem is solved. Apparently the problem was situated on the IBM Mainframe (OS390). The fix is APAR PQ47412 - PTF UQ53021 (for those interested in OS390 patches ;-).

Regards (and "thank you" for everbody that replied),
Tom

[Steven E. Protter]

You might want to do some simple ping tests on the NIC card.

Are ping times consistent, are they changing a lot. This could point to network glitches that could be bothering your transfer.

also try traceroute and make sure some router isn't causing you problems.

I would investigate patches with the name largefiles and ftp in them, and have at the very least a near current patch bundle on the machine.

Steve