Archive-name: ForthFaq/ANSinfo Last-modified: 31.May.93 Version: 1.2 What is this dpANS and what happened to BASIS? dpANS is a draft proposed Ansi National Standard. The BASIS documents were the internal working documents of the Forth Technical Committee X3.J14. Prior to this, to my knowlege, the internal working documents of any ANSI Technical Committees were not released to the public. X3.J14 broke new ground by not only making those documents available, but by making them available electronicly. X3.J14 has now made the Forth dpANS available for public review. While the first two dpANS documents were only available in print form, the 5th is now available electronicly. See below for more info on dpANS 5. Where can I get a copy of the dpANS, and comment upon it? From: gvb@med3.minerva.com (Greg Bailey) Date: Mon, 19 Apr 93 23:05 PDT The attached is a copy of the README document which defines the procedures for this public review. This document is named READMEd5.txt on the FTP servers. These procedures MUST be followed for the electronic public review (so states X3 secretariat who are being bold enough to permit this at all!) ----------------------- cut here ----------------------------- X3J14/93-006 - Procedures for Pilot Electronic Public Review 31 Mar 93 PROCEDURES FOR THE PILOT ELECTRONIC PUBLIC REVIEW of X3.215-199x WARNING: X3 is TESTING - note, TESTING - an electronic public review. The success of the test is dependent upon adherence to these procedures. PLEASE NOTIFY THE X3 SECRETARIAT as issues with this test are identified. Please notify Dan Arnold 75300.2354@CompuServe.COM or by telephone 1-202-626-5747. Applicability: These procedures will be used during the review period from 4/02/93 through 6/01/93 for Programming Language - Forth (X3.215-199x). Introduction: This review period will be supported by the tools developed within the global networking community for collaborative efforts. These tools will be deployed in parallel with a previously planned effort on the proprietary Compuserve public time sharing computer system. Goals: The objective of this review is to obtain the widest practicable review of the draft document and to obtain all available input as to text corrections and internal inconsistencies. This should be done efficiently and with due controls as desired by X3. Participants should register so that they can be notified of future developments with regard to this proposed standard. Participants are asked to pay $20.00 per copy to X3 for the purpose of helping to defray its administrative costs. 1. Posting of the draft document. The "official" copies of X3.215-199x will be posted on the Internet in an anonymous FTP host playground.sun.com in the directory pub/incoming . This directory contains at least the following files: READMEd5.txt Accompanying cover memorandum (This document). x3-215d5.ps Postscript of the draft. x3-215d5.ps.Z Postscript compressed by unix utility. x3-215d5.ps.ZIP Postscript compressed by popular PC utility. FORMATd5.txt If present, describes additional file formats. An "official" copy may be obtained via direct FTP from the above host ONLY, or via the mail resources ftpmail or bitftp for those who lack direct Internet access. Anyone retrieving the official document should obtain this README document and comply with its requests. A001-01G ansforth-request@minerva.com [Page 1] X3J14/93-006 - Procedures for Pilot Electronic Public Review 31 Mar 93 Obviously, anyone is capable of reposting these files. Anyone doing so is strongly asked to repost ALL of the above, and any others that are identified in FORMATd5.txt, with no alterations of course. This possibility jeopardizes the test of electronic public review; please note that the X3 secretariat will consider the range of sources for the files in its review of this pilot. 2. Registration of Reviewers. Each person obtaining a copy of the dpANS is strongly urged to register with X3. Please send the form in appendix A of this memo by electronic mail if you are able to do so. Otherwise it may be sent via facsimile or postal mail using the information on the form. Registered reviewers will be added to a mailing list for announcement of future revisions submitted for public review. Send your registration via electronic mail to the following Internet address: ansforth-request@minerva.com and direct any problems you might be having to postmaster@minerva.com . Please be sure to fill in the form completely, especially including your fax number, if any, and mailing address (REQUIRED!) EXPLICITLY include the best e-mail address and routing, if relevant, for reaching you from the Internet. You will receive with minimum delay a message asking that you verify our ability to reach you. Please respond as requested in this message. When X3J14 has received your response, you will be registered with X3J14 and added to the appropriate mailgroups. ONLY those people who have registered completely via e-mail will be included in these groups. If you work for a large organization or are part of a local group of interested parties in a remote location, and are willing to manage a mail exploder to minimize network traffic, please simply register your exploder as the mailgroup address on the form, and advise those who you plan to service to register the same exploder address on their forms. The person responsible for the exploder should identify him/herself as such and become fully registered before others attempt registration using that exploder. It is IMPORTANT that each reviewing INDIVIDUAL should register, even when sharing a mail exploder. 2.1 Voluntary contribution. Reviewers are requested to make a voluntary contribution of $20.00 per copy directly to X3 at the time of registration or access, as a fee toward defraying the administrative costs they incur in helping technical committes such as ours produce standards. The US standardization process is normally funded by the participants in the development of each standard. The members of X3J14 pay fees annually to X3 for administrative costs, as well as covering all the costs of operating the technical committee itself. Many of these costs directly track the volume of review comments received and acted upon. In the interest of making the X3 review process more globally accessible than it now is, X3 is conducting this experiment in this A001-01G ansforth-request@minerva.com [Page 2] X3J14/93-006 - Procedures for Pilot Electronic Public Review 31 Mar 93 case to gauge the effectiveness of a voluntary payment program. In order for X3 to collect valid data, it is important that you register whether or not you make a contribution. No penalties or prejudice will apply to anyone who elects not to contribute, but the number of such registrations will be useful in estimating the ability of such a program to pay for itself. If you intend to make a contribution, then depending on how you register: - If mailing registration, just include contribution; - If faxing registration, mail the contribution with your name to the address shown for mail registration; - If registering electronically, mail the contribution according to instructions you will receive in your confirmation. 3. Submitting Comments. Two sorts of comments are welcomed by this Technical Committee. 3.1 Formal Public Review Comments (PRC's). A PRC is a document submitted by you to the TC through X3 which is fully governed by all due process rules of X3 procedure, under which you have specific rights to promote and defend your point of view. These have customarily been submitted in writing to X3, and this practice continues. X3 procedures specifically apply to hard-copy documents. As an experiment, PRC's may be submitted to X3J14 electronically. However, in order to do so you MUST have gone through the complete registration procedure. This is required so that we have confidence we can reply to you. You must also have supplied a valid postal mailing address. Normal mailings will be sent to you at this address. The procedure for submitting an electronic PRC is to send electronic mail to ansforth-prc@minerva.com . The PRC will be forwarded to the X3 Secretariat for registration, and when it has been accepted by the Secretariat you will receive a receipt via e- mail. Each PRC that is registered and assigned a PRC number will be announced via a posting to the mailgroup. If you do not receive a receipt in a reasonable amount of time considering your connectivity, send an inquiry to the same mailing address. Please do not send a second copy of the PRC unless you are asked to do so. A001-01G ansforth-request@minerva.com [Page 3] X3J14/93-006 - Procedures for Pilot Electronic Public Review 31 Mar 93 3.2 Friendly Collaboration. Less formal contributions and constructive discussion may take place on the ansforth mailgroup. E-mail sent to ansforth@minerva.com will be forwarded to all addresses on the mailing list. Note that this is a simple explosion operation, not a listserv type processor. Hence minimal transformation occurs to headers. Please take care when doing "reply" operations to this list. ansforth is moderated passively. The moderator's policy is to permit unrestricted postings unless the traffic indicates that a more active role is necessary. The purpose of the list is to complete work on the document in a cooperative fashion, specifically with respect to text unclarities, mistakes, and internal inconsistencies. Inappropriate postings will be regulated using one or more of the available tools. The moderator may be reached at ansforth-request. A001-01G ansforth-request@minerva.com [Page 4] X3J14/93-006 - Procedures for Pilot Electronic Public Review 31 Mar 93 A. X3J14 PUBLIC REVIEW REGISTRATION FORM. To: ansforth-request@minerva.com Subject: Register for Public Review. X3 Secretariat, CBEMA (202) 737-8888 voice 1250 Eye Street, NW 638-4922 \ fax Suite 200 628-2829 / Washington, DC 20005 Please register me as a reviewer for dpANS X3.215-199x, Programming Languages - Forth, a project of Technical Committee X3J14, during 1993. I have answered the following questions completely and accurately: Name: ___________________________________________________________ Affiliation: ____________________________________________________ Telephone: __________________________ (not required) Facsimile: __________________________ (not required) Mailing address: ________________________________________________ (REQUIRED) ________________________________________________ ________________________________________________ ________________________________________________ Electronic Mail Address (please show a form that may be used directly from the Internet. Please use an address that is expected to remain valid for at least one year): ____________________________________________________________ E-Mail Address for mailgroup ansforth if different: ____________________________________________________________ Name and e-mail address for responsible party if the address for mailgroup is an exploder: ____________________________________________________________ ____________________________________________________________ The X3 Secretariat has requested $20.00 US per copy contribution for administrative costs associated with public review of this project. Do you intend to mail $20.00 to the above X3 Secretariat address for this purpose? __________. If yes, please include in the envelope your name and that of the project (X3.215-199x for dpANS-5). Signature ___________________________________ (PEM signatures encouraged for all with capability) A001-01G ansforth-request@minerva.com [Page 5] X3J14/93-006 - Procedures for Pilot Electronic Public Review 31 Mar 93 B. X3 Official Message. Please read this document in detail before attempting to make any Public Review comments. B.1 Definitions. You have an "Official Copy" of the Draft if (1) it is hardcopy published by Global Engineering Documents, Inc., or (2) you obtained the Draft -directly- from the FTP server identified in section 1 above, or (3) you obtained the draft directly from the XCB archives on Compuserve(tm). A Draft obtained by other means, including a draft which came from an intermediate agent who claims to have obtained the document from an X3-approved source, is not an Official Copy. The "Draft" refers to the hardcopy image produced by printing the Postscript files. Only such an image is considered to be the official document which has been involved in the X3/ANSI approval process. The "Pedigree" of your Draft is the route by which the Draft came to you; that is, the list of places the Draft had been before it came to you. (This information is generally important only in the case that the draft is not an Official Copy, in case some question comes up about whether your copy has been damaged or altered, so that we can detect how or why.) You are a "Registered Purchaser" if you obtained a copy of the draft in hardcopy from Global Engineering Documents, Inc. You are a "Registered Commenter" if you submitted a properly formed Public Review comment in hardcopy per X3/SD-2 procedures (summarized below), or have registered per the procedures in section 2 above. You are a "Registered Participant" if you are either a "Registered Purchaser" or a "Registered Commenter". You are a "Registered electronic participant" only if you have registered electronically according to section 2. B.2 Ordering Hardcopy. You may order "X3.215, 199x, Programming Language Forth" from Global Engineering Documents, Inc. 15 Inverness Way East Englewood, CO 80112-5704 1-800-854-7179 (within USA) 303-792-2181 (outside USA) A001-01G ansforth-request@minerva.com [Page 6] X3J14/93-006 - Procedures for Pilot Electronic Public Review 31 Mar 93 B.3 Status. The Draft in this directory has been formally approved as a draft proposed American National Standard (dpANS). The Draft is now in a period of Public Review which began on 2 April 1993 and ends on 1 June 1993. Depending on the number and nature of Public Review comments, there is the possibility that there will be one or more subsequent Public Review periods. (See "Notification" below.) B.4 Procedures for Making Public Review Comments. Public review comments MAY be submitted via e-mail by registered electronic particpants ONLY. Public review comments may be submitted by anyone, however, in the traditional HARDCOPY format. Here are the hardcopy procedures: You must submit your hardcopy comments IN DUPLICATE to the following two addresses: X3 Secretariat Attn.: Lynn Barra 1250 Eye Street NW, Suite 200 Washington, DC 20005 and American National Standards Institute Attn: BSR Center 11 West 42nd St., 13th Floor New York, NY 10036 In your communication, PLEASE include the following information: - Your name - Your postal mail address (i.e., for hardcopy mail) - Your telephone number - An electronic mail address (optional) - As complete as you know it, the Pedigree of your Draft. (For a discussion of Pedigrees, see "Definitions" above). - Your comment(s). For further information on procedures for making Public Review comments, refer to the document X3/SD-2. B.5 Notification. In the event that there is a need for a subsequent Public Review period, X3 will specifically notify Registered Commenters (see "Definitions" above). Individuals who are not Registered Commenters may choose to rely on the same ad hoc communication processes through which they heard about the present Public Review (currently in effect), but there is A001-01G ansforth-request@minerva.com [Page 7] X3J14/93-006 - Procedures for Pilot Electronic Public Review 31 Mar 93 no claim by X3 that this mechanism will be reliable. Note that no recipient of an online document is automatically a Registered Purchaser because currently there is no established mechanism for such online access to notify X3 of an intent to be registered. Recipients of the online document only become Registered Participants if they become Registered Commenters by filing a Registration per section 2 above, by making Public Review comments (see "Procedures for Making Public Review Comments" above), or if they redundantly purchase hardcopy from Global Engineering Documents, Inc. B.6 Questions about Procedures for this Public Review or X3 Procedures in General. Mail Lynn Barra X3 Secretariat, CBEMA 1250 Eye Street, NW, Suite 200 Washington, D.C. 20005 Phone +1-202-626-5747 FAX +1-202-638-4922 B.7 Questions about X3J14 or its activities. Mail Elizabeth D. Rather X3J14 Technical Committee Chair FORTH, Inc. 111 N. Sepulveda Blvd. Manhattan Beach, CA 90266 Phone +1-310-372-8493 FAX +1-310-318-7130 B.8 Technical questions about e-mail or file transfer procedures. Mail Greg Bailey X3J14 Technical Subcommittee Chair ATHENA Programming, Inc. 24680 NW Dixie Mountain Road Hillsboro, Oregon 97124 US Internet gvb@minerva.com Phone +1-503-621-3215 FAX +1-503-621-3954 or to the current X3J14 Ombudsmen (the preferred method) at Internet ansforth-request@minerva.com A001-01G ansforth-request@minerva.com [Page 8] X3J14/93-006 - Procedures for Pilot Electronic Public Review 31 Mar 93 C. E-mail access to FTP servers. If your Internet access is limited to mail, you may still retrieve files from FTP servers. To begin with you will need to find out how to send mail to Internet addresses, and you will also need to know how to express your e-mail address so that Internet entities can send mail back to you. This information is best obtained from advisors who work with/for whatever e-mail system you have. They can also help you make use of the following information, which was obtained from two Internet mail oriented file retrieval servers and is reprinted as it was received. ======================= FTPMAIL INFORMATION ======================= From: "ftpmail service on inet-gw-2.pa.dec.com" To: gvb@med3.minerva.com Subject: your ftpmail request has been received X-Complaints-To: ftpmail-admin@inet-gw-2.pa.dec.com X-Service-Address: ftpmail@inet-gw-2.pa.dec.com -- Help -- >>> $Id: help-text,v 1.6 1993/02/16 14:55:03 vixie Exp $ >>> >>> commands are: reply set reply addr, since headers are usually wrong connect [HOST [USER [PASS [ACCT]]]] defaults to gatekeeper.dec.com, anonymous ascii files grabbed are printable ascii binary files grabbed are compressed or tar or both chdir PLACE "get" and "ls" commands are relative to PLACE (only one CHDIR per ftpmail session, and it executes before any LS/DIR/GETs) compress compress binaries using Lempel-Ziv encoding compact compress binaries using Huffman encoding uuencode binary files will be mailed in uuencode format btoa binary files will be mailed in btoa format chunksize SIZE split files into SIZE-byte chunks (def: 64000) ls (or dir) PLACE short (long) directory listing index THING search for THING in ftp server's index get FILE get a file and have it mailed to you (max 10 GET's per ftpmail session) quit terminate script, ignore rest of mail message (use if you have a .signature or are a VMSMAIL user) >>> notes: -> you should send complaints to the ftpmail-admin address. our postmaster does not handle ftpmail problems and you can save her the trouble of forwarding your complaints by just mailing them to the right address. the "ftpmail-request" address is gone; don't use it. A001-01G ansforth-request@minerva.com [Page 9] X3J14/93-006 - Procedures for Pilot Electronic Public Review 31 Mar 93 -> the "index" command depends on the "SITE EXEC INDEX" feature of some ftp servers. Gatekeeper.dec.com originated this feature, and ftp.uu.net duplicated it (with a format change to the output, naturally). Wuarchive.wustl.edu also has this feature, though their index seems to be empty. The source for an ftpd that supports this feature is on Gatekeeper.DEC.COM in /pub/DEC/gwtools. -> a password of "" or '' will be sent as a null string. if you need this you will know it, if you don't, you won't. -> the "Subject:" of your request will be contained in the "Subject:" of all of ftpmail's responses to you regarding that request. You can therefore use it to "tag" different requests if you have more than one outstanding at any given time. -> you must give a "connect" command, default host is gatekeeper.dec.com, default user is anonymous, default password is your mail address with a hyphen prepended. -> binary files will not be compressed unless 'compress' or 'compact' command is given; use this if at all possible, it helps a lot. note that many files are already compressed. if you use any of the binary-file qualifiers (compress, compact, uuencode, btoa) without setting 'binary' first, your session will abort in error. -> binary files will always be formatted into printable ASCII with "btoa" or "uuencode" (default is "btoa"). if you don't use the "binary" command, ftpmail will cheerfully try to mail you the binary data, which will absolutely, positively fail. -> all retrieved files will be split into chunks and mailed. the size of the chunk is 64000 characters unless you change it with the "chunksize" command. CompuServe users will need to set this to 49000. there is no way to set it higher than 100000, so please don't ask. -> if you ask for more than 10 files in a session, you will receive an error message and your entire request will be rejected. -> VMS/DOS/Mac versions of uudecode, atob, compress and compact are available, ask your LOCAL wizard about them if you can't locate them (but try gatekeeper.dec.com in /archive/pub/VMS if you're still using a VMS system.) -> several mail unsplitters are hiding on gatekeeper.dec.com in /pub/mail/ua/misc/unsplit. there is one in c, one in perl, and one in VMS DCL. -> there is no way to request only certain parts of a file and we do not plan to add one in the near future, so please don't ask. -> there is no way to delete things from the queue or to find out the status of things in the queue, and we do not plan to add A001-01G ansforth-request@minerva.com [Page 10] X3J14/93-006 - Procedures for Pilot Electronic Public Review 31 Mar 93 either feature in the near future, so please don't ask. >>> examples: -> connect to gatekeeper.dec.com and get a root directory listing: connect ls quit -> connect to gatekeeper.dec.com and get the README.ftp file: connect get README.ftp quit -> connect to gatekeeper.dec.com and get the gnuemacs sources: connect binary uuencode chdir /pub/GNU get emacs-18.58.tar.Z quit -> connect to ftp.uu.net as anonymous and get a root directory list: connect ftp.uu.net binary chdir /index/master get by-name.Z quit -- End of Help -- -- Ftpmail Submission Transcript -- <<< help >>> Help is on the way. <<< quit >>> Done - rest of message will be ignored -- End of Ftpmail Transcript -- -- Full Mail Header From Request -- From gvb@med3.minerva.com Sun Feb 28 22:17:42 1993 Received: by inet-gw-2.pa.dec.com; id AA26906; Sun, 28 Feb 93 22:17:42 -0800 Message-Id: <9303010617.AA26906@inet-gw-2.pa.dec.com> From: gvb@med3.minerva.com Date: Sun, 28 Feb 93 22:18 PST To: ftpmail Content-Type: text Content-Length: 10 -- End of Request Mail Header -- A001-01G ansforth-request@minerva.com [Page 11] X3J14/93-006 - Procedures for Pilot Electronic Public Review 31 Mar 93 ===================== BITFTP INFORMATION ============================== Date: Mon, 1 Mar 1993 01:17:55 EST From: Princeton BITNET FTP Server To: gvb@MED3.MINERVA.COM Subject: BITFTP HELP Content-Type: text Content-Length: 10534 Status: RO 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@ESUBTASKNOTACTIVE Subtask not active.ESUBTASKNOTACTIVE Subtask not active). The first command 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 UUENCODE 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 "UUENCODE" or "NETDATA" 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.) A001-01G ansforth-request@minerva.com [Page 12] X3J14/93-006 - Procedures for Pilot Electronic Public Review 31 Mar 93 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. 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. A001-01G ansforth-request@minerva.com [Page 13] X3J14/93-006 - Procedures for Pilot Electronic Public Review 31 Mar 93 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 data. If you specify "UUENCODE" 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".) 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 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 A001-01G ansforth-request@minerva.com [Page 14] X3J14/93-006 - Procedures for Pilot Electronic Public Review 31 Mar 93 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 uuencoded inside mail by specifying the "UUENCODE" option. 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 specify "BINARY F 512" and 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 uuencoded when you receive it, shorten it AFTER you have uudecoded 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 A001-01G ansforth-request@minerva.com [Page 15] X3J14/93-006 - Procedures for Pilot Electronic Public Review 31 Mar 93 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. 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. ======================= END OF DOCUMENT ============================ A001-01G ansforth-request@minerva.com [Page 16] ----------------------- end of text -------------------------- --- If you have any questions about ForthNet/comp.lang.forth or any information to add/delete or correct in this message or any suggestions on formatting or presentation, please contact Doug Philips at one of the following addresses: Internet: dwp@willett.pgh.pa.us Usenet: ...!uunet!willett.pgh.pa.us!dwp GEnie: D.PHILIPS3