From @PUCC.PRINCETON.EDU:BITFTP@PUCC.PRINCETON.EDU Thu Dec 2 19:08:23 1993 Received: from nova.unix.portal.com by jobe (4.1/1.34) id AA02442; Thu, 2 Dec 93 19:08:22 PST Received: by nova.unix.portal.com (5.65b/4.1 1.570) id AA10954; Thu, 2 Dec 93 19:08:19 -0800 Message-Id: <9312030308.AA10954@nova.unix.portal.com> Received: from PUCC.PRINCETON.EDU by pucc.Princeton.EDU (IBM VM SMTP V2R2) with BSMTP id 8199; Thu, 02 Dec 93 22:07:55 EST Received: from PUCC.PRINCETON.EDU (NJE origin VMMAIL@PUCC) by PUCC.PRINCETON.EDU (LMail V1.1d/1.7f) with BSMTP id 6938; Thu, 2 Dec 1993 22:07:55 -0500 Received: by PUCC (Mailer R2.10 ptf008) id 5797; Thu, 02 Dec 93 22:07:54 EST Date: Thu, 2 Dec 1993 22:07:53 EST From: Princeton BITNET FTP Server To: chan@SHELL.PORTAL.COM Subject: BITFTP HELP Status: R BITFTP -- Princeton BITNET FTP Server BITFTP provides a mail interface to the FTP command supplied by the IBM TCP/IP for VM product ("FAL") running on the Princeton University VM/CMS system, to allow BITNET/NetNorth/EARN users to ftp files from sites on the Internet. To use BITFTP, send mail containing your ftp commands to BITFTP@PUCC (or to BITFTP@pucc.Princeton.EDU). The first command in the mail file you send to BITFTP must be "FTP", "HELP", "VMS", or "FTPLIST". Use "HELP" to request a current copy of this help file. Use "VMS" to request a collection of tips provided by BITFTP users on how to handle binary files from BITFTP on VMS systems. Use "FTPLIST" to obtain a list of some of the hosts that allow anonymous ftp. (Note that there is no guarantee that BITFTP can access all the hosts in that list.) The recommended syntax for FTP requests is: FTP hostname NETDATA --or-- FTP hostname XXENCODE USER username password QUIT For "hostname", specify the name (e.g., "Bambleweeny57.Princeton.EDU") or IP address (e.g., "128.112.64.12") of the host from which you wish to request files. Following the hostname on the FTP command, you may specify "NETDATA" or "UUENCODE" or "XXENCODE" to tell BITFTP the format in which you wish to receive files. Please use NETDATA format if you can, as it imposes a substantially smaller burden on both BITFTP and the network. (Users inside IBM will be able to receive NETDATA files only if they send their requests to BITFTP via the VNET/BITNET gateway, rather than via the VNET/Internet gateway.) The "username" in your request should be the userid that owns the files you wish to request. If the username in your ftp request is "anonymous", no password is required; BITFTP will use your userid and and its own nodeid for the password. If the username is not "anonymous", then you must specify the password appropriate for the username. Note that on many systems passwords are case-sensitive; that is, the password may be required to be in lower case or mixed case or upper case. (The same is true of directory and file names.) The following is an example of an ftp request: FTP nis.nsf.net USER anonymous cd introducing.the.internet get intro.to.ip get network.gold get where.to.start get zen.ps get zen.txt QUIT It connects to the host nis.nsf.net and requests five files from the "introducing.the.internet" directory of that host's anonymous login. If the host you wish to connect to uses a non-standard ftp port, you can specify that port number on the FTP command immediately following the hostname field. (This will be required only in unusual circumstances.) BITFTP implements a subset of the ftp subcommands provided in IBM TCP/IP for VM and uses the same syntax. Therefore, you may find it useful to obtain the IBM "TCP/IP for VM User's Guide", IBM order number SC31-6081. The currently supported subcommands are: ACCT -- to send host-dependent account information. format: ACCT account-information ASCII -- to change the file transfer mode to ASCII. format: ASCII BINARY -- to change the file transfer mode to image. format: BINARY CD -- to change the working directory. format: CD directory DIR -- to get a list of directory entries. format: DIR EBCDIC -- to change the file transfer mode to EBCDIC format: EBCDIC GET -- to get a file from the foreign host. format: GET foreignfile If you specify "localfile", it must be in the forms "filename.filetype" or "filename", and the filename and filetype may each be no more than 8 characters long and may not contain periods. If the host you are FTPing to is a VM/CMS system, then you should specify the "foreignfile" as "filename.filetype"; that is, the parts of the name should be separated by periods, rather than blanks as they normally are for CMS file names. LS -- to list the files in a directory. format: LS MODE -- to specify Stream or Block as the file transfer mode. format: MODE PWD -- to print the working directory. format: PWD QUIT -- to disconnect from the foreign host. format: QUIT SYSTEM -- to get the name of the foreign host's operating system. format: SYSTEM TYPE -- to specify ASCII ("A"), image ("I"), Kanji Shift JIS ("B"), EBCDIC ("E"), or EBCDIC IBM Kanji ("F") as the file transfer mode. format: TYPE BITFTP does not provide a PUT capability, and there is no intention to make it do so in the future, nor does it provide an MGET capability. BITFTP accepts requests via RFC822-format mail, IBM NOTE-format mail (with headers in English, French, German, or Danish), PROFS-format messages, or files with no headers at all sent via RSCS. It returns the requested files as NETDATA-format files or as mail files containing uuencoded or xxencoded data. If you specify "UUENCODE", "XXENCODE", or "NETDATA" on your "FTP" command, BITFTP will attempt to use the format you request. If you do not specify the format, BITFTP will attempt to select the appropriate format for your node. BITFTP attempts to determine your return address by parsing the mail file it receives from you. It uses the address specified in a "Reply-to:" line in the mail headers in preference to the address specified in the "From:" line. If you specify a "PATH" command in the body of the mail, that address will be used in preference to either the "Reply-to:" or "From:" address. The format of a "PATH" command is simply "PATH userid@nodeid". If you are on BITNET/EARN/NetNorth, you should not specify a path. In general, you need specify a path only if you get no response from requests to BITFTP otherwise. BITFTP will not send you a file that contains more than 17825792 bytes of data. It will not send you more than 15000 lines of directory listings as the result of one request file. Uuencoded and xxencoded files are broken up into mail files that contain no more than 750 records (containing 62 bytes each). NETDATA-format files that are larger than 900000 bytes are sent in 900000-byte pieces using the BITSEND function. You should be able to receive such files using the BITRCV function available from your nearest NETSERV. (If you do not know how to use NETSERV, ask your local BITNET/EARN/NetNorth Coordinator for assistance. Users inside IBM can get help with BITRCV from the BITNET FORUM.) To recover the original file when BITRCV is not available for your system, use the command you normally use to receive NETDATA-format files and then catenate the files in the order shown in the BITRCV control file. Users in the UK should note that BITFTP attempts to send NETDATA-format files through the gateway from EARN into Janet using the NIFTP facility at Rutherford Lab. Receiving files via NIFTP requires an overt action on your part. If you are at a Janet node and don't know how to use NIFTP, you should ask for assistance locally. Alternatively, you can ask BITFTP to send your files encoded inside mail by specifying the "UUENCODE" or "XXENCODE" option on the FTP command. If BITFTP sends you a file you cannot read, THE FIRST THING TO DO is to make sure that you specified "ASCII" if the file should contain textual material (or "EBCDIC" for text files from an IBM system), or that you specified "BINARY" if the file should contain binary data, executable programs, tar files, or the like. User on IBM systems (VM/CMS or MVS/TSO) should specify "MODE B" (for "Block") when requesting files from other IBM systems, in order to preserve the record structure of the files. VMS users should use RECEIVE/BINARY to receive the NETDATA-format binary files BITFTP sends to them. If BITFTP sends you a uuencoded file that you cannot uudecode, the first thing to do is to translate all occurrences of 0x7E in the file to 0x5E and then try uudecoding again. (Some gateways change 5Es to 7Es when the files pass through them.) There are many different flavors of UUENCODE/UUDECODE. The version that BITFTP uses puts a "guard character" (the letter "M") at the end of each encoded line (to prevent the removal of trailing blanks in the encoded data). Most implementations of uudecode know to ignore this character. If yours does not, then you should remove the "M" at the end of each line before attempting to uudecode the file. When BITFTP is told to transfer a file in FIXED format, such as "BINARY FIXED 512", it will create a file whose total byte count is an integral multiple of the record length (512, in this case). This means that the last record may be padded with binary zeros to get it to the specified record length. In such a case, you may need to use an editor to shorten the last record so that the total byte count of the file is correct. (If the file is encoded when you receive it, shorten it AFTER you have decoded it.) In addition to any files you request, you will also receive a mail file containing a log of your ftp session. In that mail file, entries prefixed by ">" are your original commands; those prefixed by ">>" are your commands as interpreted by BITFTP and passed to FAL; those prefixed by ">>>" are your commands as interpreted by FAL and passed to the remote host; those prefixed by "<<<" are messages from the remote host; and those prefixed by ">>>>" are completion messages from BITFTP. If BITFTP is unable to connect to the host you specify, it will send you mail after the first attempt, but will keep trying at intervals over two days. The only additional mail file you will receive will be when the connection is made successfully or when BITFTP gives up after two days. The load on BITFTP is often very heavy, and network backlogs are often so great that it may take several days for a file to get to you once BITFTP sends it on its way, so please be patient and don't send multiple requests for the same file. If your system allows you to send interactive messages, you can inquire about BITFTP's backlog by sending the query "How are you?", e.g., on a VM system: TELL BITFTP AT PUCC How are you? Questions about BITFTP and suggestions for improvements should be sent to Melinda Varian, MAINT@PUCC on BITNET or MAINT@PUCC.Princeton.EDU on the Internet. When you have a problem, it helps if you send along a log mail file from BITFTP that illustrates the problem. (Please send the entire mail file, including the mail headers.) The author gratefully acknowledges the use of the SENDJANI EXEC written by Alan Flavell and an RFC822 parsing routine written by Eric Thomas. NOTE: If you have any complaints or suggestions about the way any of these routines work in BITFTP, please send them to MAINT@PUCC (Melinda Varian), not to those authors.