John
In 4.1.3. FTP SERVICE COMMANDS, RFC 959 states the following:
<quote>
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.
</quote>
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:
<quote>
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 second 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
