Re: FTP Error 426
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: IBM-MAIN@BAMA.UA.EDU 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
FTP Error 426
Hi, All, 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. TIA, -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
byte is sent, the out-of-band pointer seems to move to the second byte and the first byte becomes normal data. /quote Chris Mason - Original Message - From: Chase, John [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Friday, May 18, 2007 3:47 PM Subject: FTP Error 426 Hi, All, 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. TIA, -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
-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
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
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
