Monster Media 1993 #2/Image.iso/internet/cld9z89.zip/Z0000091.TXT

Text File | 1993-06-09 | 42KB | 1,154 lines

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: [e-mail] (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
   [e-mail] or by telephone [phone].

       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            [e-mail]              [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: [e-mail] and direct
   any problems you might be having to [e-mail] .
   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            [e-mail]              [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 [e-mail] .  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            [e-mail]              [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
   [e-mail] 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            [e-mail]              [Page 4]






       X3J14/93-006 - Procedures for Pilot Electronic Public Review   31 Mar 93


       A.  X3J14 PUBLIC REVIEW REGISTRATION FORM.

          To: [e-mail]
          Subject: Register for Public Review.

               X3 Secretariat, CBEMA         [phone] 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            [e-mail]              [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            [e-mail]              [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            [e-mail]              [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     [phone]
               FAX       [phone]

       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     [phone]
               FAX       [phone]

       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      [e-mail]
               Phone         [phone]
               FAX           [phone]

          or to the current X3J14 Ombudsmen (the preferred method) at

               Internet      [e-mail]










       A001-01G            [e-mail]              [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" <[e-mail]>
     To: [e-mail]
     Subject: your ftpmail request has been received
     X-Complaints-To: [e-mail]
     X-Service-Address: [e-mail]

       -- Help --
     >>> $Id: help-text,v 1.6 1993/02/16 14:55:03 vixie Exp $
     >>>
     >>> commands are:

          reply <MAILADDR>    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            [e-mail]              [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            [e-mail]              [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 [e-mail]  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: <[e-mail]>
     From: [e-mail]
     Date: Sun, 28 Feb 93 22:18 PST
     To: ftpmail
     Content-Type: text
     Content-Length: 10
       -- End of Request Mail Header --








       A001-01G            [e-mail]              [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 <[e-mail]>
     To:       [e-mail]
     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
        <other ftp subcommands>
        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            [e-mail]              [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 <FIXED record-len> <VARIABLE>

       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 <localfile>

                   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            [e-mail]              [Page 13]






       X3J14/93-006 - Procedures for Pilot Electronic Public Review   31 Mar 93


       LS          -- to list the files in a directory.
         format:   LS <name>

       MODE        -- to specify Stream or Block as the file transfer
                      mode.
         format:   MODE <S|B>

       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 <A|I|B|E|F>

     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            [e-mail]              [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            [e-mail]              [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
     [e-mail] 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            [e-mail]              [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: [e-mail]
    Usenet:   ...!uunet!willett.pgh.pa.us!dwp
    GEnie:    D.PHILIPS3