home *** CD-ROM | disk | FTP | other *** search
/ Garbo / Garbo.cdr / pc / doc_net / bitftp.hlp < prev    next >
Encoding:
Internet Message Format  |  1991-08-16  |  8.9 KB
  1. From news.funet.fi!sunic!mcsun!uunet!cis.ohio-state.edu!ucbvax!PUCC.BITNET!BITFTP Sat Aug 10 14:48:50 EET DST 1991
  2. Article: 296 of comp.archives.admin
  3. Path: uwasa.fi!news.funet.fi!sunic!mcsun!uunet!cis.ohio-state.edu!ucbvax!PUCC.BITNET!BITFTP
  4. From: BITFTP@PUCC.BITNET (Princeton BITNET FTP Server)
  5. Newsgroups: comp.archives.admin
  6. Subject: BITFTP HELP
  7. Message-ID: <9108090425.AA00849@ucbvax.berkeley.edu>
  8. Date: 9 Aug 91 04:25:10 GMT
  9. Sender: daemon@ucbvax.BERKELEY.EDU
  10. Lines: 201
  11.  
  12.  
  13.                BITFTP -- Princeton BITNET FTP Server
  14.  
  15. BITFTP provides a mail interface to the FTP portion of the IBM
  16. TCP/IP product ("FAL") running on the Princeton VM system, to allow
  17. BITNET/NetNorth/EARN users to ftp files from sites on the Internet.
  18.  
  19. To use BITFTP, send mail containing your ftp commands to BITFTP@PUCC
  20. (or to BITFTP@PUCC.Princeton.edu).
  21.  
  22. The first command to BITFTP must be "FTP", "FTPLIST", "HELP", or
  23. "VMS".  If you send BITFTP mail or a message containing only the
  24. command "FTPLIST", it will send you a list of some of the hosts that
  25. allow anonymous ftp.  (Note that there is no guarantee that BITFTP
  26. can access all the hosts in that list.)  Use "HELP" to request a
  27. current copy of this help file.  Use "VMS" to request a collection
  28. of tips provided by BITFTP users on how to handle binary files from
  29. BITFTP on VMS systems.
  30.  
  31. The recommended syntax for FTP requests is:
  32.  
  33.    FTP hostname NETDATA    --or--    FTP hostname UUENCODE
  34.    USER username password
  35.    <other ftp subcommands>
  36.    QUIT
  37.  
  38. Following the hostname on the FTP command, you may specify
  39. "UUENCODE" or "NETDATA" to tell BITFTP the format in which you wish
  40. to receive files.
  41.  
  42. If the username is "anonymous", no password is required; BITFTP will
  43. use your userid and nodeid as the password.  Note that on many
  44. systems passwords are case-sensitive; that is, the password may be
  45. required to be in lower case or mixed case or upper case.  (The same
  46. is true of directory and file names.)
  47.  
  48. The following is an example of an ftp request:
  49.  
  50.    FTP  f.ms.uky.edu  NETDATA
  51.    USER  anonymous
  52.    CD  /pub/msdos/Games
  53.    DIR
  54.    BINARY
  55.    GET  robotron.arc  msdos.robotron
  56.    QUIT
  57.  
  58. BITFTP implements a subset of the ftp subcommands provided in the
  59. IBM TCP/IP and uses the same syntax.  Therefore, you may find it
  60. useful to obtain the "IBM TCP/IP for VM Command Reference Manual",
  61. IBM order number GC09-1204.
  62.  
  63. The currently supported subcommands are:
  64.  
  65.   ACCT        -- to send host-dependent account information.
  66.     format:   ACCT account-information
  67.  
  68.   ASCII       -- to change the file transfer type to ASCII.
  69.     format:   ASCII
  70.  
  71.   BINARY      -- to change the file transfer type to image.
  72.     format:   BINARY <FIXED record-len> <VARIABLE>
  73.  
  74.   CD          -- to change the working directory.
  75.     format:   CD directory
  76.  
  77.   CLOSE       -- to disconnect from the foreign host.
  78.     format:   CLOSE
  79.  
  80.   DIR         -- to get a list of directory entries.
  81.     format:   DIR
  82.  
  83.   EBCDIC      -- to change the file transfer type to EBCDIC
  84.     format:   EBCDIC
  85.  
  86.   GET         -- to get a file from the foreign host.
  87.     format:   GET foreignfile <localfile>
  88.  
  89.               If you specify "localfile", it must be in
  90.               the forms "filename.filetype" or "filename",
  91.               and the filename and filetype may each be no
  92.               more than 8 characters long and may not contain
  93.               periods.
  94.  
  95.   LOCSTAT     -- to display local status information.
  96.     format:   LOCSTAT
  97.  
  98.   LS          -- to list the files in a directory.
  99.     format:   LS <name>
  100.  
  101.   PWD         -- to print the working directory.
  102.     format:   PWD
  103.  
  104.   QUIT        -- to disconnect from the foreign host.
  105.     format:   QUIT
  106.  
  107.   STATUS      -- to retrieve status information from a foreign host.
  108.     format:   STATUS <name>
  109.  
  110.   SYSTEM      -- to get the name of the foreign host's operating
  111.                  system.
  112.     format:   SYSTEM
  113.  
  114.   TYPE        -- to specify Image, ASCII, or EBCDIC file transfer.
  115.     format:   TYPE <I|A|E>
  116.  
  117. BITFTP does not provide a PUT capability, and there is no intention
  118. to make it do so in the future.
  119.  
  120. BITFTP currently accepts requests only via RFC822-format mail, IBM
  121. NOTE-format mail, PROFS-format messages, or files with no headers at
  122. all.  BITFTP currently returns the requested files as NETDATA-format
  123. files or as mail files containing UUENCODED data.  If you specify
  124. "UUENCODE" or "NETDATA" on your "FTP" command, BITFTP will attempt
  125. to use that format.  If you do not specify the format, BITFTP will
  126. attempt to select the appropriate format for your node.
  127.  
  128. UUENCODED files are broken up into mail files that contain no more
  129. than 50,000 bytes of data.  NETDATA-format files that are larger
  130. than 300,000 bytes are sent in 300,000-byte pieces using the BITSEND
  131. function.  You should be able to receive such files using the BITRCV
  132. function available from your nearest NETSERV.  (If you do not know
  133. how to use NETSERV, ask your local BITNET/EARN/NetNorth Coordinator
  134. for assistance.)  If BITRCV is not available for your system, use
  135. the command you normally use to receive NETDATA-format files and
  136. then concatenate the files in the order shown in the BITRCV control
  137. file to recover the original file.
  138.  
  139. Users in the UK should note that BITFTP attempts to send
  140. NETDATA-format files through the gateway from EARN into Janet via
  141. the NIFTP facility at Rutherford Lab.  Note that receiving files via
  142. NIFTP requires an overt action on your part.  If you are at a Janet
  143. node and don't know how to use NIFTP, you should ask for assistance
  144. locally.  Alternatively, you can ask BITFTP to send your files
  145. UUENCODED inside mail by specifying the "UUENCODE" option.
  146.  
  147. If BITFTP sends you a file you cannot read, THE FIRST THING TO DO is
  148. to make sure that you specified ASCII if the file should contain
  149. textual material or that you specified BINARY if the file should
  150. contain binary data, executable programs, tar files, or the like.
  151. VMS users should specify BINARY F 512 and should use RECEIVE/BINARY
  152. to receive the NETDATA-format binary files BITFTP sends them.
  153.  
  154. If BITFTP sends you a uuencoded file that you cannot uudecode, the
  155. first thing to do is to translate all occurrences of 0x7E in the
  156. file to 0x5E and then try uudecoding again.  (Some gateways are
  157. changing 5Es to 7Es when the files pass through them.)
  158.  
  159. There are many different flavors of UUENCODE/UUDECODE.  The version
  160. that BITFTP uses puts a "guard character" at the end of each encoded
  161. line.  Most implementations of uudecode know to ignore this
  162. character.  If yours does not, then you should remove the last
  163. character of each line before attempting to uudecode the file.  Note
  164. that the guard character is not always "M"; the short lines at the
  165. end of the file may have some other guard character, rather than
  166. "M".  Whatever that character is, it should be removed (or your
  167. uudecode should be fixed).
  168.  
  169. When BITFTP is told to transfer a file in FIXED format, such as
  170. "BINARY FIXED 128", it will create a file whose total byte count is
  171. an integral multiple of the record length (128, in this case).  This
  172. means that the last record may be padded to get it to the specified
  173. record length.  In such a case, you may need to use an editor to
  174. shorten the last record so that the total byte count in the file is
  175. correct.  (If the file is uuencoded when you receive it, shorten it
  176. AFTER you have uudecoded it.)
  177.  
  178. In addition to any files you request, you will also receive a mail
  179. file containing a log of your ftp session.  In that mail file,
  180. entries prefixed by ">" are your original commands; those prefixed
  181. by ">>" are your commands as interpreted by BITFTP and passed to
  182. TCPIP; those prefixed by ">>>" are your commands as interpreted by
  183. TCPIP and passed to the remote host; those prefixed by "<<<" are
  184. messages from the remote host; and those prefixed by ">>>>" are
  185. completion messages from BITFTP.
  186.  
  187. If BITFTP is unable to connect to the host you specify, it will send
  188. you mail after the first attempt, but will keep trying at intervals
  189. over three days.  The only additional mail file you will receive
  190. will be when the connection is made successfully or when BITFTP
  191. gives up after three days.
  192.  
  193. The load on BITFTP is often very heavy, and network backlogs are
  194. often so great that it may take several days for a file to get to
  195. you once BITFTP sends it, so please be patient and don't send
  196. multiple requests for the same file.  If your system allows you to
  197. send interactive messages, you can inquire about BITFTP's backlog by
  198. sending the query "How are you?", e.g., on a VM system:
  199.  
  200.    TELL BITFTP AT PUCC How are you?
  201.  
  202. Questions about BITFTP and suggestions for improvements should be
  203. directed to Melinda Varian, MAINT@PUCC on BITNET or
  204. maint@pucc.princeton.edu on the Internet.
  205.  
  206. The author gratefully acknowledges the use of the FTP SUBCOM
  207. interface written by David Nessl, the SENDJANI EXEC written by Alan
  208. Flavell, the uuencoding utility written by John Fisher, and the
  209. RFC822 parsing routine written by Eric Thomas.  NOTE:  If you have
  210. any complaints or suggestions about the way any of these routines
  211. work in BITFTP, please send them to MAINT@PUCC (Melinda Varian), not
  212. to the authors.
  213.  
  214.  
  215.