From: larry@eco.twg.com (Lawrence B. Henry III)
Subject: Re: ftp: subcommand error codes
Keywords: ftp AIX error
Reply-To: larry@eco.twg.com
Organization: The Wollongong Group (East Coast Operations)
Date: Thu, 7 Jan 93 19:21:57 GMT


In article <160@bjcong.bj.co.uk>, maf@bjcong.bj.co.uk (AUSTIN FARR) writes:
|>
|>ftp on AIX: subcommand errors
|>-----------------------------
|>
|>What is the meaning of the 3-digit numbers in messages relating to ftp (on AIX)
|>subcommands?  In particular, how is a failure signalled?
|>
|>The following is an extract from an ftp dialogue:
|>ftp> get absent
|>200 PORT command successful
|>550 absent: No such file or directory
|>ftp> cd tmp
|>250 CWD command successful
|>
|>The leading 3-digit numbers in messages from ftp appear to relate to
|>interactions with the remote machine.  A number beginning with '5' appears to
|>signify failure of the operation.  If the last message before the 'ftp>' prompt begins with a digit other than '5' - is this a sufficient test for successful
|>completion of the last subcommand?
|>
|>I would be grateful for further information.  Please reply by email.
|>Thank you.
|>

Austin,
	Check out rfc640.. I believe that this is the latest source of 
information on this topic.. it is readily available from nic.ddn.mil in the
RFC sub-directory..

-Larry.


---Excerpt from RFC640 showing response codes for FTP---

       There are four values for the first digit of the reply code:      11a

       1yz   Positive Preliminary reply                                  11b

          The requested action is being initiated; expect another
          reply before proceeding with a new command.  (The
          user-process sending another command before the  completion
          reply would be in violation of protocol; but server-FTP
          processes should queue any commands that arrive while a
          preceeding command is in progress.)  This type of reply can
          be used to indicate that the command was accepted and the
          user-process may now pay attention to the data connections,
          for implementations where simultaneous monitoring is
          difficult.                                                    11b1

       2yz   Positive Completion reply                                   11c

          The requested action has been successfully completed.  A
          new request may be initiated.                                 11c1

       3yz   Positive Intermediate reply                                 11d

          The command has been accepted, but the requested action is
          being held in abeyance, pending receipt of further
          information.  The user should send another command
          specifying this information.  This reply is used in command
          sequence groups.                                              11d1

       4yz   Transient Negative Completion reply                         11e

          The command was not accepted and the requested action did
          not take place, but the error condition is temporary and
          the action may be requested again.  The user should return
          to the beginning of the command sequence, if any.  It is
          difficult to assign a meaning to "transient", particularly
          when two distinct sites (Server and User-processes) have to
          agree on the interpretation.  Each reply in the 4yz
          category might have a slightly different time value, but
          the intent is that the user-process is encouraged to try
          again.  A rule of thumb in determining if a reply fits into
          the 4yz or the 5yz (Permanent Negative) category is that
          replies are 4yz if the commands can be repeated without any
          change in command form or in properties of the User or
          Server (e.g. the command is spelled the same with the same

    NWG/RFC# 640                               JBP NJN 5-JUN-74 16:07  30843
    Neigus                                       FTP Reply Codes  [5]



          arguments used; the user does not change his file access or
          user name; the server does not put up a new
          implementation.)                                              11e1

       5yz   Permanent Negative Completion reply                         11f

          The command was not accepted and the requested action did
          not take place.  The User-process is discouraged from
          repeating the exact request (in the same sequence).  Even
          some "permanent" error conditions can be corrected, so the
          human user may want to direct his User-process to
          reinitiate the command sequence by direct action at some
          point in the future (e.g. after the spelling has been
          changed, or the user has altered his directory status.)       11f1

       The following function groupings are encoded in the second
       digit:                                                            11g

          x0z   Syntax - These replies refer to syntax errors,
                  syntactically correct  commands that don't fit any
                  functional category, unimplemented or superfluous
                  commands.                                             11g1

          x1z   Information -  These are replies to requests for
                  information, such as status or help.                  11g2

          x2z   Connections - Replies referring to the TELNET and
                  data connections.                                     11g3

          x3z   Authentication and accounting - Replies for the logon
                  process and accounting procedures.                    11g4

          x4z   Unspecified as yet                                      11g5

          x5z   File system - These replies indicate the status of
                  the Server file system vis-a-vis the requested
                  transfer or other file system action.                 11g6

       The third digit gives a finer gradation of meaning in each of
       the function categories, specified by the second digit.  The
       list of replies below will illustrate this.  Note that the
       text associated with each reply is suggestive, rather than
       mandatory, and may even change according to the command with
       which it is associated.  The reply codes, on the other hand,
       should strictly follow the specifications in the last section;
       that is, Server implementations should not invent new codes
       for situations that are only slightly different from the ones
       described here, but rather should adapt codes already defined.

    NWG/RFC# 640                               JBP NJN 5-JUN-74 16:07  30843
    Neigus                                       FTP Reply Codes  [6]



       If additional codes are found to be necessary, the details
       should be submitted to the FTP committee, through Jon Postel.     11h
                                                                             
Newsgroups: comp.unix.aix