Re: FTP Error 426
ession that the server was behaving badly[3]. Perhaps tracing can reveal what really happens - which is fine if it is reproducible as implied. [3] Beware of course that in "smoke and mirrors" world of networking, whether SNA or IP - but particularly IP - what arrives is not always what was sent by the supposed partner. Well, conscientious as ever - I hope - I thought it best not to mention something without researching a little. It turns out that FWFRIENDLY is a "client-side" parameter - so why not give it a try. Also I was directed to the EPSV4 parameter, the description of which has the right sort of "ring" about it - "If your client has trouble establishing a data connection" - as a possible way out of the problem as described - with all the key functions piled together, "security protected", "encrypted session", "NAT", "firewall" ... you name it, we've got it covered! Chris Mason - Original Message - From: "Patrick O'Keefe" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: Sent: Saturday, May 19, 2007 2:51 AM Subject: Re: FTP Error 426 On Fri, 18 May 2007 11:26:35 -0500, George Kozakos <[EMAIL PROTECTED]> wrote: ... On the meaning of out-of-band: It relates to the method of signaling between the client and server. Normally subcommands are processed one after the other and are received within the data stream (or in band). In the case of an ABOR, you don't want the other end to wait to get your command, so it is sent Out of Band. You really want to interrupt the other end and have it respond to the ABOR instead of finishing what it was doing. Out of Band is a method of signalling that gets processed immediately. Please don't ask me what any of that means. ... There was apparently a change in terminology somewhere along the line. I found a few pages on the web that said "out of band" TCP data is TCP data sent with the "Urgent" flag. THAT is mentioned in the TCP RFC (RFC0793 / STD0007) - data sent outside of the normal TCP flow controls, data that should be acted on right away by the receiver. The "out of band" idea is that this urgent data should be processed even if there is buffered "in band" data ahead of it. But in this case we already sort of new that. An ABORT was sent and the receiver should process it right away. Ok. But why? The only thing you can say for sure is that the remote end didn't like something. Hopefully there is some indication of a problem on the remote end. While there isn't much to go on, but it may be significant that this an ABORT request (which is part of FTP, I think) rather than a RESET flag. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTP Error 426
On Fri, 18 May 2007 11:26:35 -0500, George Kozakos <[EMAIL PROTECTED]> wrote: >... >On the meaning of out-of-band: >It relates to the method >of signaling between the client and server. Normally subcommands >are processed one after the other and are received within the data >stream (or in band). In the case of an ABOR, you don't want the other >end to wait to get your command, so it is sent Out of Band. You really >want to interrupt the other end and have it respond to the ABOR >instead of finishing what it was doing. >Out of Band is a method of signalling that gets processed immediately. > >Please don't ask me what any of that means. >... There was apparently a change in terminology somewhere along the line. I found a few pages on the web that said "out of band" TCP data is TCP data sent with the "Urgent" flag. THAT is mentioned in the TCP RFC (RFC0793 / STD0007) - data sent outside of the normal TCP flow controls, data that should be acted on right away by the receiver. The "out of band" idea is that this urgent data should be processed even if there is buffered "in band" data ahead of it. But in this case we already sort of new that. An ABORT was sent and the receiver should process it right away. Ok. But why? The only thing you can say for sure is that the remote end didn't like something. Hopefully there is some indication of a problem on the remote end. While there isn't much to go on, but it may be significant that this an ABORT request (which is part of FTP, I think) rather than a RESET flag. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTP Error 426
Hi John, I'm not a TCP/IP person but from my searches... On the return code 426: The FTP server sends message that it's about to open a data connection but we don't see an incoming SYN from port 20 and 2 seconds later, it sends "426 Connection closed. Transfer aborted" which causes the control connection to be closed. This could be due to a firewall not allowing the data connection to flow. On the meaning of out-of-band: It relates to the method of signaling between the client and server. Normally subcommands are processed one after the other and are received within the data stream (or in band). In the case of an ABOR, you don't want the other end to wait to get your command, so it is sent Out of Band. You really want to interrupt the other end and have it respond to the ABOR instead of finishing what it was doing. Out of Band is a method of signalling that gets processed immediately. Please don't ask me what any of that means. -- Regards, George Kozakos z/OS Level 2 Software Service -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTP Error 426
> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Greg Shirey > > John, > > I Googled '"out of band" FTP' and got a link to RFC 0529. > I'm no expert in IP networking, but to my reading, > out-of-band is sort of an interrupt caused by the ABOR. Hmmm.. From Chris Mason's explanation I got the impression that the ABOR subcommand was the "payload", and the "out of band" is somewhat analogous to the SNA DFASY transmission. > So, > why did the client send the abort? Could it be the timeout > value had passed? I think the default is 120 seconds, but it > can be overridden. > > If this is a batch job, you might check your EZA1617I > messages in the aborted runs and see if your transfer rate > was running really slow at the time. Not likely, because the batch FTP jobstep started and ended in the same second. Here's the message sequence: EZA1736I APPEND 'ZOS.DATASET.NAME' + EZA1736I /AIX/pathname/filename.ext EZA1701I >>> SITE FIXrecfm 599 LRECL=599 RECFM=FB BLKSIZE=27554 500 'SITE FIXrecfm 599 LRECL=599 RECFM=FB BLKSIZE=27554' EZA1701I >>> PORT 200 PORT command successful. EZA1701I >>> APPE /AIX/pathname/filename.ext 150 Opening ASCII mode data connection for 426 Connection closed; transfer aborted. EZA1735I Std Return Code = 04426, Error Code = 2 EZA1701I >>> QUIT 221 * FILE TRANSFER FAILED It's as though z/OS said "just kidding" immediately after the 150 reply. > We've found IP traffic > to be so flaky that we coded a proc that runs a REXX that > attempts the FTP x number of times (4 as a default), sleeping > 30 seconds between attempts (adapted from something we > acquired from Terry Linsley somehow -- thanks, Terry). And > all our batch jobs that need to FTP use the FTPRETRY proc - > most of them are successful on the first attempt, but many of > them wind up taking 2 or 3 > attempts. And when the programmers discover a site they are > FTP'ing to > that seems to fail a lot, they generally increase the timeout > value too. > > > Anyway, our shop has viewed this unreliability in FTP > transfers as SOP (or WAD) and have adapted. OK, we may have to categorize this kind of situation as "unexplainable" for the time being. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTP Error 426
> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Chris Mason > > [ technical minutiae snipped ] So in this context, "Out Of Band" is somewhat analogous to SNA's DFASY? But we'd still like to learn "why" it occurred. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTP Error 426
John, I Googled '"out of band" FTP' and got a link to RFC 0529. I'm no expert in IP networking, but to my reading, out-of-band is sort of an interrupt caused by the ABOR. So, why did the client send the abort? Could it be the timeout value had passed? I think the default is 120 seconds, but it can be overridden. If this is a batch job, you might check your EZA1617I messages in the aborted runs and see if your transfer rate was running really slow at the time. We've found IP traffic to be so flaky that we coded a proc that runs a REXX that attempts the FTP x number of times (4 as a default), sleeping 30 seconds between attempts (adapted from something we acquired from Terry Linsley somehow -- thanks, Terry). And all our batch jobs that need to FTP use the FTPRETRY proc - most of them are successful on the first attempt, but many of them wind up taking 2 or 3 attempts. And when the programmers discover a site they are FTP'ing to that seems to fail a lot, they generally increase the timeout value too. Anyway, our shop has viewed this unreliability in FTP transfers as SOP (or WAD) and have adapted. HTH, Greg Shirey Ben E. Keith Company -Original Message- From: IBM Mainframe Discussion List On Behalf Of Chase, John Sent: Friday, May 18, 2007 8:48 AM Trying to understand the explanation for this FTP error: 426 Connection closed; transfer aborted. The manual says only this: The FTP server received an Out Of Band ABOR subcommand from the FTP client requesting that the data transfer in progress end. The FTP server aborted the data transfer. The client in this context is z/OS 1.7; server is an AIX machine in our local network. What is an "Out Of Band" condition, and why would the z/OS FTP program (client) originate it? BTW, the same FTP job finally succeeded after four of the above aborts. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTP Error 426
John In 4.1.3. FTP SERVICE COMMANDS, RFC 959 states the following: ABORT (ABOR) This command tells the server to abort the previous FTP service command and any associated transfer of data. The abort command may require "special action", as discussed in the Section on FTP Commands, to force recognition by the server. No action is to be taken if the previous command has been completed (including data transfer). The control connection is not to be closed by the server, but the data connection must be closed. There are two cases for the server upon receipt of this command: (1) the FTP service command was already completed, or (2) the FTP service command is still in progress. In the first case, the server closes the data connection (if it is open) and responds with a 226 reply, indicating that the abort command was successfully processed. In the second case, the server aborts the FTP service in progress and closes the data connection, returning a 426 reply to indicate that the service request terminated abnormally. The server then sends a 226 reply, indicating that the abort command was successfully processed. Interestingly enough, it doesn't mention "out-of-band". I expect this explanation text you found means that the TCP OOB function is used with the sending of the ABOR command from the FTP client to the FTP server over the TCP connection. OOB is some weird protocol used within TCP which is a pale shadow of the SNA expedite function. I expect this means that the FTP client was trying to "hurry along" the "abort" request - quite understandable - and maybe it worked! Here are my presentation notes on OOB: Out-Of-Band Data Out-of-band data may be used for whatever purpose an application may have for it. It is usually thought of as of use for sending urgent data. It may be compared to the use of SIGNAL in SNA. The sending and receiving of out-of-band data is supported by modified versions of the standard WRITE and READ subroutine calls: SEND and RECV. These subroutine calls allow for the additional specification of a flag parameter which includes the ability to send out-of-band data with a SEND subroutine call and receive out-of-band data with a RECV subroutine call. The flag has the name MSG_OOB. Out-of-band data may be received either "inline" in the position it was placed in the data stream by the SEND subroutine call or not "inline" so that it can be received as soon as it appears in the arriving data and ahead of any normal data in the stream. Setting the option to define how out-of-band data should be received is one of the functions of the SETSOCKOPT subroutine call. The ability to query the current setting of this option is one of the functions of the GETSOCKOPT subroutine call. The socket option is specified with the name SO_OOBINLINE. Whether the out-of-band data is "inline" or not "inline", the fact that out-of-band data is next to be read can be detected by use of one of the functions of the IOCTL subroutine call. The function has the name SIOCATMARK. The function is normally used when the out-of-band data is "inline". Note that, whereas normally stream data accumulates such that data from multiple subroutine calls of any of the send types can be received with one subroutine call of any of the receive types, the presence of out-of-band data effectively creates boundaries in the stream so that a receive subroutine call stops, as it were, at the out-of-band marker. Thus there is no risk that "inline" out-of-band data can be missed by being embedded in normal data. However, when out-of-band data is not "inline", there is a risk that the data can be lost entirely unless it is received *before* normal data which was sent after the out-of-band data. Whether the out-of-band data is "inline" or not, the SELECT subroutine call will indicate that out-of-band data is present by setting the exception condition for the relevant socket. This condition is cleared when the out-of-band data is received or it has been, as it were, passed over. The author has had some difficulty getting very definite descriptions of other than the most basic socket functions from available sources. At least one implementation of socket subroutine calls, namely, TCP/IP for MVS (and, almost certainly, also VM and, very probably, VTAM V3R4.2) implement out-of-band data as *a single byte*. This is nowhere precisely documented. Strangely enough, if the SEND subroutine call used to send out-of-band data specifies more than one byte of data, all bytes, other than the last, enter the stream as normal data. A further point, also discovered only by testing, is that only one out-of-band byte may be sent at any one time. If a s
