FTP - Put Error - EZA2590E
Alvaro Quintupray B.
I have Zos 1.6
When executing the FTP of a big file from IBM to an UNIX server... I have
the following errror:
EZA2590E send send_data error from - EDC5140I Broken pipe.
(errno2=0x74500442)
I have seen the manual of messages and appears glosses different for the
message
As it is the true error? Where I look for it.?
Thanks.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
McKown, John
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@BAMA.UA.EDU] On Behalf Of Alvaro Quintupray B.
> Sent: Friday, July 07, 2006 1:00 PM
> To: IBM-...@BAMA.UA.EDU
> Subject: FTP - Put Error - EZA2590E
>
>
> Hi.
>
> I have Zos 1.6
> When executing the FTP of a big file from IBM to an UNIX
> server... I have
> the following errror:
>
> EZA2590E send send_data error from - EDC5140I Broken pipe.
> (errno2=0x74500442)
>
> I have seen the manual of messages and appears glosses
> different for the
> message
>
> As it is the true error? Where I look for it.?
>
> Thanks.
That means that the FAR END, that is, the UNIX server, disconnected for
some reason. Somebody needs to look at the logs on the UNIX side to
determine why. As as example, we had this happen here once with a
Windows server when it ran out of disk space.
--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology
This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law. If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.
Mark Zelden
<aquin...@NEXUSSA.CL> wrote:
>Hi.
>
>I have Zos 1.6
>When executing the FTP of a big file from IBM to an UNIX server... I have
>the following errror:
>
>EZA2590E send send_data error from - EDC5140I Broken pipe.
>(errno2=0x74500442)
>
>I have seen the manual of messages and appears glosses different for the
>message
>
>As it is the true error? Where I look for it.?
>
When did you get it? I was FTPing a stand alone dump late last
night and when got into the office this morning I saw the same
error (can't say for sure about errno2, I purged the output).
Have you tried it more than once?
Regards,
Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group
mailto: mark....@zurichna.com
z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
Alvaro Quintupray
Well this happened in the department of Operations... I requested to them
that they try it again.
They are trying to execute FTP (Put) from IBM to a Unix server .. The log
is :
They are trying to carry out FTP (Put) from IBM to a servant...
The log is:
EZA1485I 2137743360 bytes transferred - 10 second interval rate 687.36
KB/sec
EZA1485I 2144563200 bytes transferred - 10 second interval rate 674.56
KB/sec
EZA2590E send error from send_data - EDC5140I Broken pipe.
(errno2=0x74500442)
EZA2603E Error sending the file
452 Error writing file: No such file or directory.
EZA1735I Std Return Code = 27452, Error Code = 00010
EZA1701I >>> QUIT
221-You have transferred 2147483492 bytes in 0 files.
221-Total traffic for this session was -2147483217 bytes in 0 transfers.
221-Thank you for using the FTP service on condor.
221 Goodbye.
Regards.
Atte.
Alvaro Quintupray B.
Ingeniero de Sistemas
Nexus S.A.
Fon : 420 8149
Fax : 420 8508
-----Mensaje original-----
De: IBM Mainframe Discussion List [mailto:IBM-...@BAMA.UA.EDU] En nombre de
Mark Zelden
Enviado el: Viernes, 07 de Julio de 2006 14:43
Para: IBM-...@BAMA.UA.EDU
Asunto: Re: FTP - Put Error - EZA2590E
Mark Zelden
<aquin...@NEXUSSA.CL> wrote:
>Hi Mark.
>
>
>Well this happened in the department of Operations... I requested to them
>that they try it again.
>
>They are trying to execute FTP (Put) from IBM to a Unix server .. The log
>is :
>
>They are trying to carry out FTP (Put) from IBM to a servant...
>
>
Sorry... I read your original post to quuickly. I thought you were
trying to put to "IBM" (meaning an IBM owned unix server). It sounds
like you meant you were trying to put from an IBM z/OS system to a
unix server.
Try again...
Tom Marchant
<aquin...@NEXUSSA.CL> wrote:
>Hi Mark.
>
>
>Well this happened in the department of Operations... I requested to them
>that they try it again.
>
>They are trying to execute FTP (Put) from IBM to a Unix server .. The log
>is :
>
>They are trying to carry out FTP (Put) from IBM to a servant...
>
>
>
>The log is:
>
>EZA1485I 2137743360 bytes transferred - 10 second interval rate 687.36
>KB/sec
>EZA1485I 2144563200 bytes transferred - 10 second interval rate 674.56
>KB/sec
>EZA2590E send error from send_data - EDC5140I Broken pipe.
>(errno2=0x74500442)
>EZA2603E Error sending the file
>452 Error writing file: No such file or directory.
>EZA1735I Std Return Code = 27452, Error Code = 00010
>EZA1701I >>> QUIT
>221-You have transferred 2147483492 bytes in 0 files.
>221-Total traffic for this session was -2147483217 bytes in 0 transfers.
>221-Thank you for using the FTP service on condor.
>221 Goodbye.
>
It failed after transferring 2 GB. Are you sure there is space on
the drive that is being used on the server?
McKown, John
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@BAMA.UA.EDU] On Behalf Of Tom Marchant
> Sent: Friday, July 07, 2006 2:34 PM
> To: IBM-...@BAMA.UA.EDU
> Subject: Re: FTP - Put Error - EZA2590E
>
>
<snip>
> >
> It failed after transferring 2 GB. Are you sure there is space on
> the drive that is being used on the server?
>
Ah! that may be it. Some older UNIX filesystems, especially 32 bit
systems, would max out a single file at 2GB! Also, the UNIX userid which
is being used may have a filesize quota limit placed on it.
--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology
This message (including any attachments) contains confidential
information intended for a specific individual and purpose, and its
content is protected by law. If you are not the intended recipient, you
should delete this message and are hereby notified that any disclosure,
copying, or distribution of this transmission, or taking any action
based on it, is strictly prohibited.
Chris Mason
As John and Tom have said, this is a "true", that is *real*, problem and
means that the FTP data connection between the z/OS client and the UNIX
server has been broken while the client was attempting to send data.
I think - something seems to have been lost in translation - you were
complaining that the messages were unclear - otherwise why doubt it was a
"true" error. I followed up what the messages indicated and I was able to
work out what I said in the previous paragraph.
I'll admit it is something of a "paper chase". First you need to lookup
"EZA2590E" using - why not? -
http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/lookat/
This says:
<quote>
EZA2590E function error from location - error
Explanation: The FTP client has issued a socket call and received an error
return code.
function is the C library function that failed and returned an error.
location is the location in the FTP client.
error is the C run-time library error message for the failure. For more
information, refer to z/OS Language Environment Run-Time Messages.
System Action: Communications are interrupted. The current operation is
ended.
</quote>
Incidentally, the fact that the message ends in the letter "E", rather than
the letter "I", indicates that the message describes as *e*rror rather than
being simply *i*nformative.
Now you need to follow the reference to "z/OS Language Environment Run-Time
Messages" for "EDC5140I":
<quote>
EDC5140I Broken pipe.
Explanation: A write was attempted on a pipe or FIFO for which there was no
process to read the data. This message is equivalent to the POSIX.1 EPIPE
errno.
Programmer Response: Refer to z/OS XL C/C++ Run-Time Library Reference for
the function being attempted for the specific reason for failure.
System Action: The request fails. The application continues to run.
</quote>
Now you need to follow the reference to "z/OS XL C/C++ Run-Time Library
Reference" for the "send" function and "EPIPE":
One of the 10 - not so many - search "hits" for "EPIPE" is the following:
<quote>
3.768.4 Returned Value
If successful, send() returns 0 or greater indicating the number of bytes
sent. However, this does not assure that data delivery was complete. A
connection can be dropped by a peer socket and a SIGPIPE signal generated at
a later time if data delivery is not complete.
If unsuccessful, send() returns -1 indicating locally detected errors and
sets errno to one of the following values. No indication of failure to
deliver is implicit in a send() routine.
..
EPIPE
For a connected stream socket the connection to the peer socket has been
lost. A SIGPIPE signal is sent to the calling process.
..
</quote>
I hope that's clear - even if long-winded.
Chris Mason
wtro...@ibm-main.lst
We've had a similar problem here in the past. Different platform, but
similar symptons. In our case, we had problems ftpying to a wintel machine
which in turn was writing data to another
machine thru remote shared folder (MS networking); another thing was that
remote machine was in a different network, so the connection was going
thru routers to the other side. The solution in our
case was to zip files on the mainframe before sending, because we found
that problem just happens with large file. Also, take a look at apar
PQ45544.
http://www-1.ibm.com/support/docview.wss?uid=isg1PQ45544
HTH,
Walter Trovijo Jr
Chris Mason
Thanks for pointing out APAR PQ45544. This is not a "code-correcting" APAR
but a "new function" APAR - and dating from 2001, meaning that the "new
function" is available in z/OS 1.6, the level used by the OP.
In effect what you have done is indicate where this relatively new parameter
FTPKEEPALIVE might be particularly useful.
The specific circumstances described by the APAR are for when a firewall
destroys the FTP control connection.
The TCP "keepalive" function is not fully intuitive based on the name. As
the APAR text states, left alone a TCP connection is supposed to stay active
indefinitely - it stays alive without a "heartbeat". It's the potential
non-architected action of the firewall which destroys this happy
circumstance.
If you want to kill an inactive TCP connection, you need to arrange for a
"heartbeat" - sending a null TCP packet typically - which, if not answered
by a "heartbeat" from your connection partner, following a number of
plaintive "second chances"[1], causes death.
Originally I thought that what FTPKEEPALIVE is doing is ensuring that the
FTP control connection, which is necessary in order to provide the message
which assures that the transfer on the FTP data connection completed
successfully, sets the sockets option which allows the TCP "keepalive" to
operate. However it may be that from the introduction of the APAR, the
"keepalive" option is always set - see later.
Despite the presence of the INTERVAL parameter - and the SENDGARBAGE
parameter - on the TCPCONFIG statement and the good explanation of the
"keepalive" mechanism, *nothing happens* unless the sockets application, in
this case the FTP client control connection application, approves the use of
the mechanism by setting the sockets option "on" (the setsockopt()
SO_KEEPALIVE option) which causes the mechanism to operate.
In addition, the "keepalive" interval can be specified using the number
following the FTPKEEPALIVE parameter (using the setsockopt() TCP_KEEPALIVE
option).
Reading what is said about the FTPKEEPALIVE parameter, there's an
implication that, from the time the APAR was applied or the following
release, the FTP client - and server - *always* operate the "keepalive"
mechanism. The default specification is FTPKEEPALIVE 0. The significance of
this appears to be not that the "keepalive" mechanism is switched off but
merely that the interval is determined by the TCPCONFIG INTERVAL value. By
contrast, if the TCPCONFIG INTERVAL value is set to 0 (not the default which
is 120 minutes, 2 hours), the "keepalive" mechanism is switched "off"
globally and thus cannot by used by any application running with that CS IP,
in other words, the "keepalive" mechanism cannot be switched "on" by any
application.
The APAR text, which I was foolish enough to read initially, implies what I
deduced originally, a deduction called into question by the manual text.
This is sadly par for IBM authors - even APAR text writers' - course -
ambiguity reigns. Perhaps someone with the facilities and energy - and
inclination - to check can report what happens when an FTP client connection
with FTPKEEPALIVE 0 - or FTPKEEPALIVE not specified together with TCPCONFIG
INTERVAL (say) 1 is traced.
In case the OP is using defaults, the "keepalive" mechanism may well be
operating for the FTP client but, with a default interval of 2 hours, it
probably may as well not be.
As far as I can tell - "also" - you did not see the need to use the
FTPKEEPALIVE parameter - or - you felt that referring to the APAR was the
most efficient way to describe FTPKEEPALIVE - curious - 'cos it's not as
clear as it might be.
Chris Mason
[1] "a total of ten probes are then sent at 75-second intervals" CS IP
Configuration Reference 1.2.56 TCPCONFIG
----- Original Message -----
From: "Walter Trovijo Jr" <wtro...@ibm-main.lst>
Newsgroups: bit.listserv.ibm-main
To: <IBM-...@BAMA.UA.EDU>