









                                  B I N K L E Y T E R M



                        A FREELY AVAILABLE FIDONET COMPATIBLE

                 ELECTRONIC MAIL INTERFACE AND DUMB TERMINAL PACKAGE

                                    VERSION 2.60

                             Technical Reference Manual


                                     April  1996

                Software Written by Vince Perriello and Bob Hartman,
                      with contributions from countless others.

                  Original Documentation written by Alan D. Bryant
                       Revised by Barrie Smith and W.R. Davis



                  Copyright (C) 1987-1996 Bit Bucket Software, Co.

                      Terms and Conditions Contained Separately



                              BIT BUCKET SOFTWARE, CO.
                                  P. O. Box 460398
                                  Aurora, CO 80046

                        "BinkleyTerm" and "Freely Available"
                     are trademarks of  Bit Bucket Software, Co.




                                  Table of Contents


     WORKING WITH BINKLEYTERM                                                  3

      SYSTEM SECURITY                                                          3
       Session Passwords                                                       3
       Secured Inbound File Areas                                              2
       Protected Systems                                                       2
       Known Systems                                                           2
       NoSec Systems                                                           2
       Implementing Incoming Mail Security                                     2

      CONTROL OF FILE REQUESTS                                                 3
       Outgoing file requests                                                  3
       Incoming file requests                                                  3
       Update Requests                                                         7
       Request Response Files                                                  8
       Response file Templates                                                 8
       Template Statements:                                                    9
       Function Requests                                                      11

      BBS INTERFACE                                                           14
       BBS Exit                                                               14
       BBS Spawn                                                              15
       BBS Batch                                                              16
       Passing control to the BBS                                             16

      EXTERNAL MAIL PROGRAMS                                                  17

      MULTIPLE BBS SYSTEMS                                                    18

      POINTS                                                                  20

      FAX                                                                     21
       Is your modem suitable?                                                21
       Adaptive Answer                                                        22
       Baud Rate                                                              22
       Fax Commands                                                           23
       AT+FLI="xxx-xxx-xxxx"                                                  24
       Modem Fax Response String                                              24
       Handling the incoming faxes internally with BinkleyTerm                24
       Handling Fax Reception with a Rear-end program                         25
       Fax Transmission                                                       26

      DOMAIN ADDRESSING                                                       26

      DIAL TRANSLATION                                                        29

      FLAGS OR SEMAPHORE FILES                                                29

      BI-DIRECTIONAL PROTOCOLS                                                32
       THE JANUS MAIL PROTOCOL                                                33
       Configuring Janus                                                      34
       Configuration File Statements for Bi-directional protocols             34
       HYDRA MAIL PROTOCOL                                                    37

      CALL COSTING                                                            37
       The American Costing System                                            37



       The Eurocost System                                                    37
       EMSI                                                                   38


     THE CONFIGURATION FILE                                                   38

      LAYOUT                                                                  38

      FULL ALPHABETICAL LIST OF CONFIGURATION STATEMENTS                      39


     EVENT FILES AND SCHEDULING EVENTS                                        71

      EVENT FILE FORMAT                                                       72

      PARAMETERS AND FLAGS FOR EVENT FILES                                    73


     SCRIPTS                                                                  78

      SCRIPT FILE USAGE                                                       78

      PREPARING SCRIPTS                                                       79

      SCRIPT STATEMENTS                                                       79


     THE BINKLEYTERM WINDOWED INTERFACE                                       83

      VIDEO FOSSIL                                                            83

      THE DISPLAY SCREEN                                                      83

      CURRENT SETTINGS WINDOW                                                 83

      TODAY AT A GLANCE WINDOW                                                84

      PENDING OUTBOUND MAIL WINDOW                                            84

      RECENT ACTIVITY WINDOW                                                  86

      TRANSFER STATUS WINDOW                                                  86


     BINKLEYTERM LOG FILE                                                     86


     COMMAND LINE PARAMETERS                                                  87


     TERMINAL MODE KEYSTROKES                                                 89


     UNATTENDED MODE KEYSTROKES                                               92


     ZOOMED OUTBOUND WINDOW KEYSTROKES                                        96


     MODIFICATION/TRANSLATION OF BINKLEYTERM INTERNAL TEXT                    97





                                 WORKING WITH BINKLEYTERM


     SYSTEM SECURITY


     Session Passwords
             BinkleyTerm supports session-level password protection. Using such
             protection helps prevent situations where someone uses a FidoNet
             mailer to "impersonate" a legitimate FidoNet node, and pickup mail
             addressed to the node.  When implemented, both the sending and
             receiving systems must have it in operation, with the same password
             on both ends (exceptions noted below).

             With Point systems, password protection can be automatic.  Simply
             use the 'BossPwd' configuration file option, and choose a password.
              Make sure your Boss also uses the same password.

             For other types of systems, password information is kept in the
             nodelist data file.  ParseLst (and some other nodelist processors)
             can easily add a password to a nodelist entry.  Refer to the
             documentation for your nodelist processor.

             When talking with other BinkleyTerm, Opus, FrontDoor or compatible
             systems that use the YooHoo (WaZOO) or EMSI session negotiation
             methods, full, two-way protection is available.  The systems
             connect and exchange the password right at the beginning of the
             session.  If the passwords do not match, the session is terminated,
             regardless of who initiated the call. 

             The only exception is when you have a password implemented, but the
             remote has NO password implemented.  In this case, if YOU placed
             the call, then a session will still occur.  If the REMOTE placed
             the call, then the session will be aborted.

             When connected with systems that do not support WaZOO or EMSI
             session handshaking (such as older versions of SEAdog), password
             matching takes place only when you are picking up mail from the
             remote system.  You may send to such a system without a password
             match taking place.  (The assumption is that you always know who
             you're calling, but don't always know who's calling you.)

             Note that session passwords must not exceed eight (8) characters,
             and are case insensitive.

             When BinkleyTerm cannot find a password for a remote system when
             placing a call, it will not check for a password during the
             session.  This responsibility is left to the remote system, if the
             remote chooses to perform checking.

             BinkleyTerm allows easy implementation of new passwords.  Simply
             add the agreed upon password as outlined above, and send the remote
             system a message.  BinkleyTerm will allow an outbound session to
             take place in cases where you have designated a password, but the
             remote has not yet implemented it.  This is handy for letting a
             remote system know that a password was implemented.  Note that in
             this case, BinkleyTerm will NOT allow the remote to have a
             successful session when the remote calls your system; only when you



     BinkleyTerm 2.60 Reference Manual                        Page 2  


             place the call (as stated above, the idea is that you know who
             you're calling, not who's calling you).

     Secured Inbound File Areas
             Another method of securing the flow of mail involves controlling
             the processing of incoming mail to your system.  In most cases, you
             will want to protect common mail links with session passwords, as
             outlined in the previous section.  Still, the potential exists for
             another abusive system to send you rogue mail, or mail "planted"
             onto your system in hopes that it will be routed to another system
             at your expense, or find its way into a national EchoMail
             conference.

             BinkleyTerm makes it possible for mail from "Protected" and "Known"
             systems to be directed to separate inbound areas whilst mail from
             unknown systems (or all systems if security is not implemented)
             will be placed as designated by the 'NetFile' statement.

     Protected Systems
             A group of systems with which you have implemented session
             passwords.  These links are "protected" by passwords. See page 3
             "Protected" systems are the top-level, or "most favored" systems
             since you generally know the other person at the other end (a pre-
             requisite to establishing a password).

             Configuration Statements concerned with these systems commence with
             the letters "Prot"

     Known Systems
             Systems that are listed in the nodelist ("known" to you) but with
             whom you have not established a session password..  This group
             represents the middle-level of security.

             Configuration statements concerned with these statements commence
             with the letters "Known"

     NoSec Systems
             All mail not "filtered out" by a Prot or Known statement is placed
             in the area designated by the statement in this group.

             Obviously, if no security arrangements are enabled then ALL
             incoming requests are dealt with by the NoSec group.

             When Prot and/or Known statements have been enabled, all other
             systems, i.e. those without passwords or not in the Nodelist, for
             example the "Points" of other systems, are considered as "unknown"
             or no security (NoSec) systems.

             This group of systems represents the lowest-level of security,
             since you really have no idea who owns such systems, or where they
             are located.

     Implementing Incoming Mail Security
             The configuration file statements used to implement redirection of
             the incoming mail are as follows:                         




     BinkleyTerm 2.60 Reference Manual                      Page   3


                 SYSTEM GROUP    PROTECTED       KNOWN           NO SEC
                 --------------  --------------  --------------  --------------

                 STATEMENT       ProtInbound     KnownInbound    NetFile

             It is essential to enable the 'NetFile' statement if you wish to
             receive mail or files as this is the "catchall" statement telling
             BinkleyTerm where to put all mail and files not directed elsewhere.

             The statements in the "Prot" and "Known" groups are optional.

             In a typical "secured" installation, you would arrange that mail is
             automatically  processed only if received to the 'ProtInbound'
             area.  Mail received to 'KnownInbound' or 'NetFile' must be
             examined and processed manually.  Of course, you could choose to
             configure your system in a such a manner that mail received in any
             of the three areas is processed automatically to your liking,
             possibly to special message areas.

             The only "hole" in this is with FTS-0001 sessions, such as those
             with SEAdog or Fido.  Since BinkleyTerm has no way of knowing the
             address of the sending system until a packet is received, that
             first packet (.PKT file) will always be placed in the default area
             specified by the 'NetFile' statement. Once the packet has been
             received, BinkleyTerm will then move it to the appropriate
             directory if need be.

     CONTROL OF FILE REQUESTS

             BinkleyTerm supports the two popular file request methods currently
             in use in FidoNet: "Bark" requests as designed for and used by
             SEAdog, and "WaZOO" as designed for and used by Opus-CBCS.  Either
             style can be used on an incoming or outgoing basis.

     Outgoing file requests
             These can be generated by BinkleyTerm or by using one of the many
             utilities designed for the purpose, such as Amax, Bonk,  Please,
             etc.  Any Opus-compatible file request builder can be used with
             BinkleyTerm.  You may also manually build file requests.  They are
             a single-line flat ASCII text file, and are named in the same
             manner as packets (refer to the User Manual section "How
             BinkleyTerm Handles Mail" for information on the naming convention)
             and have a file extension of .REQ.  Outgoing requests should NEVER
             have a drive and path designation; only the file name.  The remote
             system handles the drives and paths.

             The .REQ file is placed in your outbound holding area.

             BinkleyTerm will not place calls for a stand-alone .REQ file.  In
             order for a call to be placed, a packet or file attach of the
             proper flavor must also exist (this will be prepared, along with
             the .REQ file, by utilities such as Bonk and Amax).  You can also
             manually poll to send the request immediately.

     Incoming file requests
             Where the facility is required, BinkleyTerm offers a method of
             establishing limitations on file requests received from systems



     BinkleyTerm 2.60 Reference Manual                      Page   4


             that are not session password protected, or are not found in the
             nodelist. 

             This support is optional; if you do not wish to limit file requests
             in this manner, use only the files and configuration file
             statements mentioned in the NoSec Group.

             The list of statements concerned with File Requests may be
             tabulated as follows:

                    Protected Group   Known Group      NoSec Group
                    ---------------   -----------      -----------
                    ProtReqList       KnownReqList     OKFile
                    ProtAvail         KnownAvail       Avail
                    ProtAbout         KnownAbout       About
                    ProtReqLim        KnownReqLim      MaxReq
                    ProtReqTpl        KnownReqTpl      ReqTemplate
                    ProtSec           KnownSec         FileSec

             The rule is simple, BinkleyTerm will use the configuration
             statement in the "NoSec" group (provided that you have enabled it)
             in all cases where no equivalent higher security statement has been
             enabled




          1. OKFile <filespec>

             (Also the secured statements ProtReqList and KnownReqList)

             Designates a file (the full drive, path and filename should be
             given) containing a listing of files, in machine-readable form,
             that you will allow to be sent to remote systems via file request.
             Wildcards are allowed, and nearly always used. When an incoming
             request is received, the request is checked against the listing to
             see if you permit the file to be sent.

             It is essential, if you wish to allow File Requests, that the
             OKFile statement is enabled as it is the "Catchall" statement used
             by all requests not directed elsewhere. The equivalent Prot and
             Known statements are optional.

             OKFILE.TXT is is often used as the filename for the OKFile
             statement in the NoSec group.

          Magic Filenames

             You may implement "magic filenames" which are words used to
             represent a file. For example, you could set-up your OKFILE in such
             a way as to send BDOS_260.ZIP if someone requests "BINKLEY" from
             you   This frees the person making the request from having to know
             the exact filename of the file he wants.  "Magic" filenames are
             generally used by systems which are software distribution points,
             hubs, and so on.



     BinkleyTerm 2.60 Reference Manual                        Page 5  


          Password Protection

             You may implement password protection  for any particular file or
             group of files.

          Faster File Searches

             If you run a Maximus BBS then its MAXFILES.IDX can be used for file
             request searches.
             Adding "*path\MAXFILES.IDX" in the OKFILE list lets BinkleyTerm
             search through this database when processing file requests. This is
             much faster than seeking through the whole of a partition (and it's
             more "multitasking friendly", too!). The asterisk (*) is required.
             You will have to enable the following statements in your
             BINKLEY.CFG:

             MaxAreas d:\max\area.dat 
             FileSec n  or the equivalent KnownSec n  and or ProtSec n where n
             is the following security level:

                    0=Disgrace      4=Privileged     8=Asstsysop
                    1=Limited       5=Favored        10=Sysop
                    2=Normal        6=Extra          11=Hidden
                    3=Worthy        7=Clerk          -2= Twit

             Each caller's access rights in the Maximus file area will be
             compared to the level set for NoSec (FileSec n), Known (KnownSec n)
             and Prot (ProtSec n) as stated above. If his security level is too
             low, the caller will get a password error.

             Search details will be logged if you have a log file implemented.




          Sample OKFILE:

                         b:\aprog.ARC
                         c:\file\stuff\*.*
                         c:\file\programs\wlc*.txt
                         c:\file\private\*.* !mypass
                         @BINKLEY c:\file\dist\bdos_260.lzh
                         @MYEDIT !outpass c:\file\private\editmax.arc
                         *c:\max\maxfiles.idx

             The first line gives an exact filename.  The second and third lines
             show the use of wildcards.  The fourth line shows password
             protection, with an exclamation point (!) followed by the password.
              The fifth line shows a magic filename, an "at" symbol (@) followed
             by the magic filename, followed by an exact drive, path and
             filename designation.  The sixth line shows a magic filename with
             password protection. The seventh line shows the use of the
             MAXFILES.IDX. The initial asterisk is required.
             Note that in all cases, a password (if any) is always the second
             argument in an OKFILE entry.



     BinkleyTerm 2.60 Reference Manual                        Page 6  



             If you want to send two or more files from one magic filename
             simply specify the same magic filename for each file.

             For example:

                         @GOODSTUFF drive\path\file.zip
                         @GOODSTUFF drive\path\dif_file.lzh


          2. Avail <filespec>

             Also the secured statements ProtAvail and KnownAvail)

             This designates a file containing a list of the files you have
             available for request, in human readable form.  The list will be a
             flat ASCII text file, giving the name of each file, and usually its
             size in bytes and a short description. There are utilities
             available that can construct this file automatically based on your
             BBS system's internal listings.  Of course, it could also be
             manually created. When someone requests the magic filename "Files"
             BinkleyTerm will send this file.

             It is usual, but not essential, to have the NoSec version of this
             statement enabled. The Prot and/or Known equivalents are optional.




          3. About <filespec>

             Also the secured statements ProtAbout and KnownAbout)

             When someone makes a request for the magic filename "About" or when
             someone makes an invalid WaZOO file request, this file is sent by
             BinkleyTerm.  It normally contains a short advertisement about your
             system, as well as a notification that the calling system could
             possibly have made an invalid request.

             This is a flat ASCII text file in human-readable form.
             It is usual, but not essential, to have the NoSec version of this
             statement enabled. The Prot and/or Known equivalents are optional.

             The About file is sent only on failed WaZOO requests.  The file is
             NOT sent on failed Bark requests.




          4. ReqTemplate <filespec>

             (Also the secured statements ProtReqTpl and KnownReqTpl)



     BinkleyTerm 2.60 Reference Manual                        Page 7  



             BinkleyTerm has the ability to generate a response file based on a
             template that you preset. See page 8. This is optional.

             If you configure a template file the About file will not be sent.




          5. MaxReq <number>

             (Also the secured statements ProtReqLim and KnownReqLim)
             This designates the maximum number of files that will be sent
             during one file request session.




          6. FileSec <number>

             (Also the equivalent secured statements ProtSec and KnownSec)

             Only needed if the MaxFiles.IDX search method is being used. See
             page 5.


     Update Requests
             Update requests are a method of obtaining an "update" of a file you
             already have, from another system you believe to have a newer copy.
              They differ from file requests in that when you construct an
             update request, you include a drive/path/file specification that
             points to an existing file on your system.  Generally, wildcards
             are acceptable.  When BinkleyTerm connects with the desired remote,
             it will compare the date and time stamp on your copy of the file(s)
             to the date and time stamp of the same-named file(s) on the remote
             system.  If the remote system has a newer copy of a given file, it
             will be sent.  If it does not, no file will be sent. 

             Note that the drive and path specification DO NOT need to be the
             same on the remote system; the drive and path you give refer only
             to YOUR copy of the file.  The remote may have any file structure.

             Update requests were originally implemented in SEAdog, a mailer
             from System Enhancement Associates, Inc.  In addition to supporting
             update requests with SEAdog systems, BinkleyTerm implements a WaZOO
             update request for use with other BinkleyTerm systems, or other
             mailers that support WaZOO update requests.

             Update requests are most commonly used to handle GroupMail, a 
             method of sharing conferenced or group message areas developed by
             System Enhancement Associates, Inc.  GroupMail generally requires
             update request capability on both ends of the connection.

             Like file requests, update requests are kept in .REQ files in your
             outbound area.  In fact, a combination of update and file requests
             can be contained in the same physical .REQ file.  An update request
             entry contains a filename, as well as a date and time code that



     BinkleyTerm 2.60 Reference Manual                        Page 8  


             corresponds to the date and time stamp of the file on your system.
              Because the date and time code is in a special format, it is not
             recommended that you attempt to create an update request entry
             yourself.

             Various utility programs such as Amax are available which support
             the creation of update requests in the manner that BinkleyTerm
             requires.

             Please note that in order for update requests to work, the remote
             system must have the file you want updated available for regular
             file request.  You cannot update a file that would not otherwise be
             available for file request from the remote system.

     Request Response Files
             If a File or Update Request is unsuccessful, the file designated by
             the 'About' statement is sent, by default, as a reply (assuming
             that the About statement has been enabled)

             If the 'ReqTemplate' statement is enabled a more informative file
             will be built during the session based on a template file which you
             preset (see next section).

             If the 'PktRsp' configuration statement is also enabled, use of the
             'ReqTemplate' statement will build a message packet instead of a
             file. This will then appear as regular mail to the calling system.
             Note that you must have a flags directory specified in your
             configuration file as this is used when building the packet.

          Notes

               1. The "About" file is not sent if 'ReqTemplate' is enabled.
               2. When a response file is sent, it is counted against the
                    maximum number of file sent in response to a request, as
                    designated by the 'MaxReq' statement in the configuration
                    file.
               3. Response files are named similarly to outbound packets or
                    request files.  They are named <net><node>.RSP.  Both <net>
                    and <node> are four- digit hexadecimal numbers with leading
                    zeroes.
               4. The response file is a plain text file. Its content is preset
                    by creating a template file.

     Response file Templates
             Normally, the response file contains information such as the date
             and time the request was made, what file was requested, and why the
             request failed.  You may wish to include information such as the
             times your system accepts requests, what magic filenames you
             support, and so on.
             Response files will be generated according to the template under
             any one of the following cases, called reason codes:

                    1 - File Not Found
                    2 - No Update Necessary
                    3 - Password Missing or Wrong
                    4 - Requested no. of Files exceeded MaxReq
                    5 - Start of No-Requests-Honored Event



     BinkleyTerm 2.60 Reference Manual                        Page 9  


                    6 - Requested no. of Bytes exceeded MaxBytes
                    7 - Requested no. of Minutes exceeded MaxTime
                    9 - Successful Request

             By default, when a template is designated in the configuration
             file, BinkleyTerm will always generate a response file for all of
             the above reasons.  It is possible, however, to control or limit
             what the response file says based on a particular reason code, or
             to not have a response file generated at all for a particular
             reason code.

             The template file designates exactly what is to be placed in the
             finished response file.  Most options perform simple macro
             substitution; others allow conditional inclusion of text, or
             instruct BinkleyTerm what to do with the response file.
             BinkleyTerm uses the template file serially, and copies everything
             found in the template directly to the response file, performing
             substitution or conditional copies as directed by template file
             statements.  When the end of the template is reached the response
             file is closed and sent to the calling system (unless an %exit
             statement is used before the end of the file).
             All the allowed statements in the template begin with a percent
             sign (%), a character which should not be used for any other
             purpose within the file.




     BinkleyTerm 2.60 Reference Manual                      Page  10


     Template Statements:
              Statement               Function
              -------------           --------------------
              %;                      When placed in column 1 (far left),
                                      denotes a comment line.  When in any
                                      other column, indicates that remainder
                                      of line should be ignored.

              %abort                  Don't send response file.

              %abort <number>         When <number> matches the reason code,
                                      don't send response file.

              %bink                   Copies BinkleyTerm program name and
                                      version into the response file.

              %date                   Copies the current date into the
                                      response file.

              %exit                   Close the response file and send as-is.

              %exit <number>          When <number> matches the reason code,
                                      close response file and send as-is.

              %line <number> <text>   If <number> matches the reason code,
                                      <text> is copied into the response
                                      directly.  The <text> should not exceed
                                      255 characters in length, and may
                                      contain other template file statements
                                      such as %system, %date, and so on.

              %mynode                 Copies your node address into the
                                      response file.

              %request                Copies into the response file the actual
                                      line from the incoming request that
                                      prompted the creation of the response
                                      file.  Normally this is the name of the
                                      file that caused the response file to be
                                      generated.

              %status                 Copies text previously defined for the
                                      current reason code with the %text
                                      statement into the response file.

              %sysop                  Copies your Sysop name, as given in the
                                      BinkleyTerm configuration file, to the
                                      response file.

              %system                 Copies your system name, as given in the
                                      BinkleyTerm configuration file, to the
                                      response file.



     BinkleyTerm 2.60 Reference Manual                       Page 11  


              %text <number> <text>   When %status is given later in the
                                      template, <text> is copied into the
                                      response file if <number> matches the
                                      reason code.  The <text> should be no
                                      longer than 255 characters in length,
                                      and may contain other template
                                      statements such as %system, %date, and
                                      so on.

              %time                   Copies the current time into the
                                      response file.

               %yrnode                Copies the node address of the calling
                                      system into the response file.


     Function Requests
             Two additional special entries that operate like magic filenames
             may be included in the file list specified by the OKFile statement.
             These function requests allow an incoming request to trigger the
             operation of a program.

          $ Function Requests

             The first style uses a dollar sign ($) in the first column of an
             OKFILE entry, followed by a function request name.  If the name is
             matched, then the command after the password (if any) is executed.
              In addition, three arguments which correspond to the net, node and
             point numbers of the calling system can be sent if desired by
             adding "%d %d %d" to the end of the OKFILE entry.  For example:

                         $INFO INFO.BAT %d %d %d

             If an incoming file request is for "INFO" then the program INFO.BAT
             would be executed, and it would receive three command line
             arguments that correspond to the net, node and point numbers
             respectively.  For instance, if 141/491.0 requested "INFO" then the
             following would be issued to DOS for execution:

                    INFO.BAT 141 491 0

             Another example of such an OKFILE entry would be:

                    $CLEANUP !mypass CLEANUP.BAT %x %x %x

             In this case, a password is included as the second argument of the
             line, and must be matched by the incoming request in order for the
             program to be executed.  Note also that in this example, "%x %x %x"
             was used, and would cause a hexadecimal representation of the net,
             node and point number to be sent as command line arguments to the
             program being executed. In our example, if 104/36.10 requests
             "CLEANUP" with a password of "mypass" then the following would be
             sent to DOS for execution:

                    CLEANUP.BAT 68 24 a



     BinkleyTerm 2.60 Reference Manual                       Page 12  



             Note that you can use a "%04x %04x %04x" mask to pass the numbers
             as 4 hex digits; handy for directly building .?LO addresses in a
             batch file, or a simple program.  For example, if you specified:

                    $CLEANUP !mypass CLEANUP.BAT %04x %04x %04x

             Then using the same example, if 104/36.10 requests "CLEANUP" with a
             password of "mypass" then the following would be sent to DOS for
             execution:

                    CLEANUP.BAT 0068 0024 000a

             Cleanup.bat could then do something like:

             set addr=%outbound%\%1%2
             if %3 == 0000 goto notpoint
             if not exist %addr%.PNT\nul mkdir %addr%.PNT
             set addr=%addr%.PNT\0000%3
             :notpoint
             REM process the request, generate output file/s,
             REM send each with:
             echo [^#]d:\path\filename.ext >>%addr%.QLO

             See page 13 for additional information



     BinkleyTerm 2.60 Reference Manual                       Page 13  



          + Function Requests

             A second type of function request is also supported, and is
             designated by a plus sign (+) in the first column of an OKFILE
             entry.  In this case, if the filename and optional password are
             matched, then the entire line from the incoming .REQ file is passed
             to DOS for processing, with the <zone>:<net>/<node>.<point> address
             appended as individual arguments to the command line.  An example
             of an OKFILE entry might be:

                         +GETREV !mypass

             If an incoming .REQ file from 1:343/491 contained the line:

                         GETREV !mypass BT 2.60

             Then the following would be passed to DOS for execution:

                         GETREV !mypass BT 2.60 1 343 491 0

             A program or batch file called GETREV would be executed, and would
             need to process or filter the command line as needed.
             Note that the <zone:net/node.point> number arguments are always
             passed as decimal, and cannot be specified, as they can with $
             requests.

             Note also that only + function requests pass the caller's zone, so
             it may be necessary to receive a + request, saving the zone, before
             any $ requests intended to build output for other-zone callers. 
             Function requests are convenient for allowing a remote system to
             have a batch file or utility of some kind (not included) place a
             particular file on hold for a node for later pickup, to cause the
             system to send a particular file, to trigger some other sort of
             function or activity remotely, etc., etc.

             If a program called as part of a function request creates a file in
             the appropriate outbound area called <net><node>.QLO (where <net>
             and <node> are 4-digit hexadecimal numbers with leading zeroes),
             BinkleyTerm will treat this file as a legitimate "flow" (file
             attach) file and send the file(s) listed in it back to the caller
             as part of the request logic.

          Function Request Notes

             If a function request triggers a program or batch file to build a
             file attach (flow) file, then BinkleyTerm will process the file
             attach during the current session.  In other words, if a file
             attach is generated during a function request, then the file(s)
             shown in the file attach will be sent during the current session.

             Note that the normal logic for the handling of .HLO (Hold file
             attaches) still applies; i.e., file(s) designated within a .HLO
             file will be sent only when the destination node polls for pick-
             up.



     BinkleyTerm 2.60 Reference Manual                       Page 14  


     BBS INTERFACE

             One of the most common uses of BinkleyTerm is as a mail front-end
             for a bulletin board system, or "BBS".  BinkleyTerm offers three
             different methods for passing control to a BBS.  The method used is
             determined by a configuration file statement.


          Method 1


     BBS Exit
             When a caller wishes to access the BBS, BinkleyTerm will exit to
             the start-up batch file with an errorlevel of the baud rate divided
             by 100.  For example, a 300 baud caller exits to the batch file
             with an errorlevel of 3, a 2400 baud caller at errorlevel 24. See
             the table and notes in the User Manual, under Errorlevels, for
             higher baud rate exit details.
             The batch file then detects the errorlevel, and jumps to a section
             of the batch file you designate to start the BBS program with the
             baud rate information. 

             When the call ends, the batch file should restart BinkleyTerm.

             This is the method which the original version of BinkleyTerm used
             to start a BBS.
             It is still used in some cases but with the continued advance of
             technology it presents some problems: ie., the batch file used to
             control program operation becomes rather unwieldy and now that
             modems with higher baud rates are in general use dividing the baud
             rate by 100 does not always provide a unique errorlevel.

             Moreover the method does not provide for passing. any parameters
             other than the baud rate and it cannot be used with OS/2 or Win32
             operating systems as the connection will be lost when BinkleyTerm
             exits (ie before the BBS starts).


          Notes on Methods 2 & 3

             Many BBS programs can accept parameters on the command line which
             provide extra functionality. (Refer to the documentation of your
             BBS for details)

             When the older 'BBS Exit' option is used it is not possible to pass
             these parameters, but when the 'BBS Spawn' or 'BBS Batch' options
             are employed, BinkleyTerm can pass the following five parameters:

                    %1     The speed of the computer to modem link rate in bps
                    %2     The caller's connect rate as reported by the Modem
                    %3     The communications port which is in use
                    %4     The time to the next Event in minutes
                    %5     Any extended information given in the modem connect
                           string (/ARQ, etc.)

             When using either the 'BBS Spawn' or 'BBS Batch' options you need
             to create a batch file called SPAWNBBS.BAT ( or, if using OS/2,



     BinkleyTerm 2.60 Reference Manual                       Page 15  


             SPAWNBBS.CMD) whose function is to start your BBS program with as
             many of the above parameters as the BBS program can accept. Any or
             all of the above parameters may be used in the normal way within
             the batch file.

             The way in which SPAWNBBS is invoked depends on whether the 'BBS
             Spawn' or the 'BBS Batch' option is to be used, but in either case
             BinkleyTerm will provide the actual parameter information for the
             current call and you "get at" that information by using the correct
             parameter descriptor (%1-%5)  in the batch file called SPAWNBBS.BAT
             (for DOS or Win32) or SPAWNBBS.CMD (for OS/2) which you write to
             start the BBS.
             An example of the parameter information provided by BinkleyTerm for
             use by the SPAWNBBS file is:

                         SPAWNBBS 9600 2400 1 47 /Arq

             The information is the DTE link rate in bps, the baud rate, port
             number, time in minutes to the next non-BBS event and extended
             information from the connect string. In this case, there is a 9600
             link rate, a 2400 baud caller, on communications port 1, with 47
             minutes remaining to the next non-BBS event, and a modem
             information string of /Arq.





          Method 2


     BBS Spawn
             OS/2 and Win32 users should always use this method. With methods 1
             and 3, the operating system will drop the carrier during the
             handover to the BBS, and the connection will fail.

             This method can also be used when running under DOS but as
             BinkleyTerm remains resident, memory shortage may be a problem
             (depending on the size of your BBS program) unless you also enable
             the 'SwapDir' configuration statement (see page 69)

             When a caller wishes to access the BBS BinkleyTerm will execute
             "SPAWNBBS" as a child process (or "shell") providing information
             for the five parameters mentioned above.

             When the call ends the child process will terminate and control
             will pass back to BinkleyTerm.

             IMPORTANT NOTE for OS/2 and Win32 (Windows NT/Windows 95) users:
             The third parameter provided for SPAWNBBS describes the comm port
             but OS/2 and Win32 systems use comport "Handles" instead of a fixed
             Port number. These port handles may change "on the fly" so the Port
             number should not be hard coded.  BinkleyTerm knows this and passes
             the comport handle as parameter 3 (%3) which is the information
             expected by Maximus, Lora BBS etc..



     BinkleyTerm 2.60 Reference Manual                       Page 16  


          Method 3


     BBS Batch
             This method is not recommended under OS/2 or Win32 systems as the
             connection is lost when BinkleyTerm exits. For systems running
             under DOS, the 'BBS Batch' method uses the best of both of 'BBS
             Exit' and 'BBS Spawn' and makes the most efficient use of memory.

             When a caller wishes to access the BBS, BinkleyTerm will physically
             write a file to the disk. This file will be named BBSBATCH.BAT
             which will consist a single line, the filename "SPAWNBBS" and 5
             parameters. See example above. After writing this file, BinkleyTerm
             exits with an errorlevel  describing the baud rate of the caller
             (as for 'BBS Exit', see method 1, above).


     Passing control to the BBS

          Method 1,  Errorlevel testing

             This method has been described under the BBS Exit heading. With
             modern modem speeds many errorlevels need to be checked so the
             batch file becomes complex.

             Your main batch file, usually BINKLEY.BAT, will decide what happens
             when a BBS related errorlevel is received, and it should be set to
             execute  BBSBATCH.BAT which in turn will execute BBSSPAWN which you
             will have written in such a way that it  starts the BBS, passing to
             the BBS any or all of the five parameters pre-set by BinkleyTerm

             When the call ends your batch file should restart BinkleyTerm


          Method 2,  "If exists"

             This method does not depend on checking each BBS related errorlevel
             and these checks can be omitted from your main program control file
             ( probably called BINKLEY.BAT or BINKLEY.CMD)  which will only now
             need to test for NON BBS related exits such as "mail received"
             etc..

             Amend your main program control batch file as follows:

             BINKLEY.BAT      (change all references to ".BAT" into ".CMD" if
             using OS/2)

             :TOP
             rem    First delete any old BBSBATCH file which exists
             if exist BBSBATCH.BAT del BBSBATCH.BAT
             rem    Now start BinkleyTerm in your usual way. Example:
             BT share unattended
             rem    When Bink exits, check for presence of BBSBATCH.BAT, if it
             now exists



     BinkleyTerm 2.60 Reference Manual                       Page 17  


             rem    Bink has made it because a caller wants into the BBS
             if exist BBSBATCH.BAT goto BBS
             rem    Now check for NON BBS exits, fro example:
             if errorlevel 20 goto mail_in
             rem    etc., etc..

             :BBS
             rem    Call BBSBATCH which runs SPAWNBBS.BAT with %1=connect rate
             rem    %2=portrate etc..(these params being provided by Bink)
             call BBSBATCH
             rem    Now loop round and restart BinkleyTerm
             goto TOP

     EXTERNAL MAIL PROGRAMS

             BinkleyTerm can be used with external mail programs, such as UUCP.
             When an 'ExtrnMail' statement is used in the configuration file,
             BinkleyTerm will answer the phone and wait for a YooHoo or TSYNC
             (the start of a mail session) or a string you designate with the
             'ExtrnMail' option. When the designated string is received from the
             remote system, BinkleyTerm will send the string associated with the
             'MailNote' configuration file option (if any), then will physically
             write a batch file called MAILBAT.BAT to the disk, and exit the
             start-up batch file with an errorlevel as given with the
             'ExtrnMail' statement, or with errorlevel 99 if none was given. 
             MAILBAT.BAT contains a single line:

               EXTMAIL %1 %2 %3 %4 %5 %6

             where:

             %1 = speed of the computer-to-modem link rate in bps
             %2 = caller's connect rate reported by the modem
             %3 = the comm port in use (or in OS/2and Win32, the port handle in
             use)
             %4 = time to the next event in minutes
             %5 = errorlevel exit in your ExtrnMail statement(default 99)
             %6 = extended info in the modem connect string (/ARQ, etc.)

             Notice the similarity in concept between this and the 'BBS Batch'
             method of invoking a BBS (as described previously).

             When BinkleyTerm exits with the previously defined errorlevel, your
             batch file must capture the errorlevel and invoke MAILBAT.BAT,
             which will in turn invoke EXTMAIL.BAT with the various command line
             parameters shown above.

             If you prefer to leave BinkleyTerm resident you can include the
             configuration statement 'Extern spawn' and all external mail exits
             will be spawned in a manner similar to a 'BBS spawn'. That is to
             say, when the 'ExtrnMail' statement causes an exit

                    EXTMAIL.BAT %1 %2 %3 %4 %5 %6

             will be executed as a child process, the parameters being  as
             described above.



     BinkleyTerm 2.60 Reference Manual                       Page 18  


             In either case, EXTMAIL.BAT is then used to invoke the external
             mail program of your choice, taking the needed command line
             parameters as supplied by the batch file, and processing and/or
             using them as needed. Once the external mail program session has
             been completed, your original start-up batch file for BinkleyTerm
             should be invoked to place BinkleyTerm on-line again.

          NOTES:

               1.   If you're locking your FOSSIL driver, the link rate and
                    connect rate passed by BinkleyTerm will be the same (unless
                    the connect rate is one of the intermediate rates reported
                    by some newer modems). BinkleyTerm has no way of knowing the
                    port's been locked unless it does the locking itself via the
                    'LockBaud' configuration statement. For further details,
                    please refer to the detailed link/connect rate table in the
                    User Guide. 
               2.   The entire "Connect" line is treated as a potential external
                    mail string.  This allows BinkleyTerm to shell out to an
                    external program for some FAX modems. 
               3.   OS/2 users should use the 'extern spawn' option and set up a
                    EXTMAIL.CMD file.
               4.   Win32 users should use the 'extern spawn' option.

          Uses for the external mail facility:


               1.   Fax Modems.  The facility allows BinkleyTerm to shell out to
                    an external program to deal with Fax.
               2.   Multiple BBS systems are possible and are described more
                    fully in the next section.


     MULTIPLE BBS SYSTEMS

             With the external mail facility it is possible for multiple BBS
             systems to reside at the same telephone number, and to give BBS
             users the ability to select the desired BBS from a menu.  It would
             be possible to run completely separate systems, to run the same
             system with different BBS packages, and so on.  This section will
             give an overview of the procedure.

             Basically, 'ExtrnMail' statements in the configuration file are
             used to build the menu options themselves.  If you want to exit to
             the batch file when a user presses "A" on their terminal, then a
             configuration file entry like this would be needed:

                    ExtrnMail 130 A

             This would cause BinkleyTerm to write MAILBAT.BAT to the disk, and
             exit to the batch file with an errorlevel of 130.  As described in
             the previous section on external mail programs, your batch file
             should invoke MAILBAT.BAT, which in turn invokes EXTMAIL.BAT. 
             EXTMAIL.BAT would be the batch file that acts upon the choice, and
             physically invokes the desired BBS program.



     BinkleyTerm 2.60 Reference Manual                       Page 19  



             If you want the choices to be case-insensitive, then two
             'ExtrnMail' statements would be needed for each letter, like this:
                         ExtrnMail 130 A
                         ExtrnMail 130 a

             This would cause BinkleyTerm to use errorlevel 130 when either "a"
             or "A" is received from the user.

             The menu presented to users should be kept in a file called
             BINKLEY.BAN (refer to the "Banner" section below for more
             information).  This file might look like this:

             Welcome to Multi-System 100.  Please choose the desired BBS: 
             A - "Garden Central" Using QuickBBS Software
             B - "Margarita Bay" Using Opus-CBCS Software
             C - "Margarita Bay" Using Fido 11w Software

             Such a menu would allow users three options.  Each lettered option
             would require a separate 'ExtrnMail' statement in the configuration
             file; two each if case insensitivity is required.

             A string "Make your selection by letter..." is added with a
             'Banner' statement in the configuration file so that the line is
             re-displayed each time a user makes an incorrect choice (refer to
             "Configuration File" section for information).

             Once the user has made a selection, and MAILBAT.BAT is invoked and
             in turn EXTMAIL.BAT is invoked, then the batch file must determine
             which selection is made and act upon it.

             In EXTMAIL.BAT (where the BBS systems are invoked), the top of the
             batch file should make a determination as to which choice was given
             by the user.  One of the parameters on the command line when
             EXTMAIL.BAT is invoked by MAILBAT.BAT is the errorlevel which
             corresponds to the choice the user gave (as designated by an
             'ExtrnMail' statement in the configuration file).

             A section of the batch file might look like this:

                    if %4 == 130 goto bbs1
                    if %4 == 140 goto bbs2
                    if %4 == 150 goto bbs3

             The fourth parameter given on the command line is the errorlevel
             value, and is reference by "%4" as shown.  For example, if the
             errorlevel that corresponds to the choice was 130, then batch file
             execution would jump to the "bbs1" label, and invoke a particular
             BBS program.

             Please note that the default is for a user to press the "escape"
             key to enter the BBS.  One of the BBS systems should be setup as
             the default system as described in the section "BBS Interface".
             Should a user press "escape," or if the time limit to make a
             response should expire, the default BBS would be invoked.



     BinkleyTerm 2.60 Reference Manual                       Page 20  


             Note also that the configuration file parameter 'Timeout' should be
             extended to allow a user more time to read and make a selection
             prior to making a default exit.  A 'Timeout' value of 30 to 60
             seconds is suggested.

             Placing multiple BBS systems on-line at one number takes some work
             and experimentation in order to operate correctly.  Hopefully the
             tips given here will point you in the right direction.

          Using the Banner File

             When a file named BINKLEY.BAN is present in the directory that
             BinkleyTerm is invoked from, the file will be displayed to callers
             immediately after the BinkleyTerm identification line.

             The file is a flat ASCII text file, and may contain extended
             information for the benefit of callers.

             The file can be used in combination with external mail processor
             definitions to present users with a rich BBS selection menu, or
             just to give the user something to read while waiting for a BBS to
             load.

     POINTS

             Points are essentially a "system under a system" and allow the
             point operator to have limited access to the network without the
             normal requirements of keeping a system on-line at certain hours.

             For use as a point, check the 'BossPhone' and 'BossPwd'
             configuration statements. If both of these are enabled then a
             Nodelist is not needed by a point.

             BinkleyTerm is well suited to the task of being a "boss" (or host
             system) of a point network and BinkleyTerm is also widely used by
             Points, needing only a very simple configuration file in that use.

             Originally, point addressing was not part of the FidoNet standard
             and certain "kludges" were used in order to handle a point network.
             A private network was established under the Boss and "fake" node
             numbers were used. This method is still in use by some systems but
             is tending to be replaced by proper 4D and 5D addressing now that
             this is available.

             BinkleyTerm uses 5D addressing (zone:net/node.point@domain) unless
             the configuration statement 'PrivateNet' is included, in which case
             the older privatenet (or fakenet) method is adopted.

             It is suggested that wherever possible the new method should be
             used by new users. If a description of how to set up a private
             network is needed please refer to older BinkleyTerm documentation.

             To set up the Boss end of a point network take the following steps:



     BinkleyTerm 2.60 Reference Manual                       Page 21  



             In your private nodelist segment, include points as follows (be
             SURE that you EXACTLY duplicate the information in the distributed
             nodelist for your net host and your node):

             Host,106,Houston_Area,Houston_TX, Scott Royall,etc,etc
             ,2000,COMM_Port_OS/2,Sugar_Land _TX,Bob_Juge,etc,etc,etc
             Point,1,Point_1,Houston_TX,John_Smith,etc,etc,etc
             Point,2,Point_2,Houston_TX,Mike_Jones,etc,etc,etc
             etc.

             Run a nodelist processor which can generate points in Version6 (for
             small nodelists only) or Version7 format.

             In the index to Version6, Points will be listed as -1/pointnumber
             in entries following the bossnode.

             In the NODELIST.DAT file (NODEX.DAT for Version 7), point entries
             will be shown with node flag bit 12 (hex 1000) set to indicate that
             this entry is a point, and the hub node field will contain the
             point number instead of a hub.

             Where is the outbound area for points?  Let's say you are storing
             mail for points off of a system whose address is 1:132/491.  You
             would do so by creating a directory 008401EB.PNT in your Zone 1
             FidoNet outbound directory. (the hex representation of "132" is
             "84", "491" translates to hex "1EB", so "008401EB" represents
             132/491 in hexadecimal)

             If you were in Zone 1 of FidoNet, a crash packet to this system's
             point 12 ("12" is "C" in hex) would be something like:

                    C:\BINKLEY\OUTBOUND\008401EB.PNT\0000000C.CUT

     FAX


     Is your modem suitable?

          Modem Classes

             Modems fall into three classes:

          Class 1

             With this class of modem most of the work is done by the software.

             Many modems in the class are not capable of adaptive answering (see
             below) and so they are *NOT* suitable for use with BinkleyTerm. A
             few modems in this class do have adaptive answering capability so
             consult your modem documentation.

             Class 1 modems receive data in "Direct bit order".
             Class 1 modems when in fax mode operate at a maximum baud rate of
             19200



     BinkleyTerm 2.60 Reference Manual                       Page 22  


          Class 2

             This is quite different from Class 2.0


             Like class 1, Class 2 modems can only operate for FAX purposes at a
             maximum baud rate of 19200.

             Class 2 modems are capable of adaptive answering (see below) so
             they can be used with BinkleyTerm for automatic FAX reception

             Class 2 modems receive fax in Reverse bit order.


          Class 2.0

             The official standard, called Class 2.0 to differentiate it from
             class 2 above, is NOT the same as Class 2. Such modems have several
             added features, the most important, for fax work, being that they
             are capable of receiving fax when the DCE rate (modem to computer
             speed) is set or locked at speeds above 19200 baud.

             Class 2.0 modems receive data in direct bit order.


          AT+FCLASS=?

             If you send the above command to your modem whilst in Terminal mode
             you may well be able to find out which classes your modem can
             support.

             A response of     0     indicates data mode
             A response of     1     indicates class 1 fax capability
             A response of     2     indicates class 2 fax capability
             A response of     2.0  indicates class 2.0 fax capability
             Error                         indicates  no fax capability.

     Adaptive Answer
             "Adaptive Answering", or "call selection" as USR chooses to call
             it, is a feature of Class 2 and Class 2.0 modems and  is the modem
             feature that enables the MODEM to decide if an incoming call is Fax
             or Data and send out an appropriate response code (such as FAX or
             +FCO) for a fax call.

             In general, Class 1 modems need to be set to receive fax *OR* to
             receive Data before a call is received. If set to Data they will
             not receive Fax, and vice versa. That is they do not adaptively
             answer the call but there are a few Class 1 modems, such as the
             Supra 144LC with the 1.80 revision ROMs which do support adaptive
             answering.

     Baud Rate
             As noted above, Class 1 and Class 2 modems can only operate for FAX
             reception at a computer to modem rate not exceeding 19200 baud.

             This is a big snag with modern high speed modems where the baud
             rate may normally be locked at either 57600 or 112500.



     BinkleyTerm 2.60 Reference Manual                       Page 23  



             Unless you can accept locking the baud rate for all transmissions
             to 19200 it becomes necessary with these modem classes to leave the
             fossil unlocked and to control the baud rate by other means.

             Do not lock the Fossil but instead use the 'Faxbaud' statement to
             lock at 19200 for faxes and other controls (such as 'LockBaud
             /Arq') for data.

             If the Fossil is not locked then BinkleyTerm will set the baudrate
             to 19200 on a FAX connection unless you set `FaxBaud X' , in which
             case your specified rate will be used.

             .

             Class 2.0 modems can operate with a fossil locked at the speeds
             used for normal BinkleyTerm operations


     Fax Commands
             First of all note that BinkleyTerm translates some characters and
             it so happens that these may be required in the Fax initialization
             strings. In particular the "." (period) is translated into a comma
             by BinkleyTerm unless you precede the period with a backslash . For
             example some modems want "AT+FCLASS=2.0" as part of their
             initialization, but this needs to be entered in the configuration
             as "AT+FCLASS=2\.0" to prevent BinkleyTerm translating the .
             (period) into a comma.

             The characters that BinkleyTerm translates are listed in the Dial
             Translation section on Page  29

             The command strings vary from Class to Class.  There is very good 
             documentation on Fax in the docs of BGFAX ( a shareware program
             which is available from many sources).


          AT+FCLASS=?

             All Classes. Requests Class information (see above)

          AT+FAA=1

             Class 2.0 command. Put modem in adaptive answer mode.
             Modem will then issue it's fax response string (see below) when the
             connection is fully established. Some modems may respond earlier
             with "FAX" when they hear a fax calling tone.
             Some modems forget the +FAA command once another command has been
             issued to the modem so it is advisable to put the command in the
             answer string (i.e., use "AT+FAA=1;A" instead of "ATA").

          AT+FAE=1

             Class 1 command. Enable adaptive answering if the modem is capable
             of this.



     BinkleyTerm 2.60 Reference Manual                       Page 24  


          AT+FCR=1

             Class 2 and Class 2.0 command Gives the modem permission to take
             faxes. It is not actually needed in Class 2.0 as it is a default
             setting in that class.

          AT+FLID="xxx-xxx-xxxx"

             Class 1 command. Sets fax ID string. Max 20 characters. should only
             be space, +, or 0 through 9. Letters should not be used and may
             cause problems with some fax machines.
              AT+FLI="xxx-xxx-xxxx"

             Class 2 and Class 2.0 command. Same rules as for +FLI above.

          AT+FDCC=1,3,0,2,0,0,0,0

             Class 2 command. Sets the resolution, fax speed, compression type
             etc. Can be shortened to +FNR=1,3.  Using 1,5 would allow 14.4 fax
             rate working but many fax modems and most standalone fax machines
             only work well at 9600 so 1,3 is preferred.
             The command is not needed on either Class 1 or Class 2.0 modems.
             When commands are "stacked" one after the other this command must
             come at the end of the stack.

          AT+FNR=1,1,1,1

             Class 2.0 command. Report details of the current call to a rear end
             fax program, such as BGFAX.

          AT&B1+FCLASS=6

             ZyXEL modem command. Fully explained in the ZyXEL manual.

          AT+FBO=1

             This toggles the bit order of a received Fax between "Direct Bit
             Order" and "Reversed Bit Order"  See Section below about "Handling
             faxes internally with BinkleyTerm"

     Modem Fax Response String
             Some modems return "FAX" as soon as they receive a fax CNG tone,
             and follow this with another response when the connection is fully
             established. Most modems simply return a single string which must
             be made known to BinkleyTerm.

             Known response strings are:
             ZyXEL :          Connect FAX followed by ZyXEL
             Some Supra's     FAX followed by +FCON

             Most modems have a single response, for example:
             FAX         Hayes, Supra, Zoom and most Rockwell based chipsets
             +FCON       Intel, GVC, PPI and some other class 2 modems
             +FCO        USR v everything and other class 2.0 modems.


     Handling the incoming faxes internally with BinkleyTerm



     BinkleyTerm 2.60 Reference Manual                       Page 25  


             BinkleyTerm can handle the fax reception internally producing a
             "Raw fax" file

             To do it this way, include a Fax Directory in your Binkley.cfg
             file, e.g.,

                    FaxInDir C:\Bink\Fax

             The fax, as received, is in a Raw Fax format which is not viewable
             so you would then normally include an event in your Binkley.evt
             file telling BinkleyTerm to exit after receiving a fax (using the
             EF=nn flag) and pick up the Errorlevel nn to go to a section of
             your batch file which can process the raw fax data.

             When fax is received internally the program outputs raw fax files
             from all three classes of modem (Classes 1,2 and 2.0) in Reverse
             bit order whereas in fact the output from Class 1 and class 2.0
             modems should be in Direct bit order. To correct this, put an
             instruction "+FBO=1" in the configuration file for class 1 and
             class 2.0 modems.   Note that this only applies to INTERNAL fax
             reception.

             If you wish, you can read the raw fax with the View.exe program
             which comes with BGFAX (BGFAX is one of the standalone programs
             which are available).

     Handling Fax Reception with a Rear-end program
             Rear end fax reception is possible using a spawned child process.

             With either operating system, arrange command or batch files so
             that the handover takes place as quickly as possible. Some users
             advocate the use of a Vdisk for faster working but this has not
             been found necessary using the Extern Spawn method with a 386DX40
             machine.

             The configuration file is arranged much as for Internal FAX
             reception except that the "FaxInDir" statement must be omitted or
             commented out as this acts as the semaphore to BinkleyTerm
             instructing it to use internal reception. Either one or two
             additional statements should then be added. These are:
                    Extern Spawn
                    ExtrnMail  <chosen errorlevel> <Modems fax Response string>

             Used together, these two statements act so that reception of the
             modem's fax response string causes execution of the command
             "SPAWNBBS" as a child or shell process. You write the SPAWNBBS.CMD
             (or .BAT if you try it in DOS or Win32). Before it is executed,
             SPAWNBBS is passed 5 parameters by BinkleyTerm. and you can utilise
             any or all of these within the batch file.

             In the case of BGFAX that program needs the comm handle (port in
             DOS) passed as parameter 3 (%3) of the SPAWNBBS command

             If the ExtrnMail is used alone, without Extern Spawn, receipt of
             the modem response string causes BinkleyTerm to exit to the start-
             up batch file where the errorlevel used in the ExtrnMail statement



     BinkleyTerm 2.60 Reference Manual                       Page 26  


             can be trapped and used to go to a further batch file which would
             start the rear end fax program.

     Fax Transmission
             BinkleyTerm does not handle this but it should be simple to arrange
             a Function key exit with a suitable errorlevel which can start up a
             standalone program to send the fax and then re-cycle to
             BinkleyTerm.



     DOMAIN ADDRESSING


          When is it needed?

             Domain Addressing is only needed if you operate in two or more Fido
             Technology Networks (FTNs)  using the same Zone numbers, or you
             wish to keep different Domains' compiled nodelists separate.

          What is it?

             Domain addressing is an extended method of designating various FTNs
             as compared with the zone-only method previously used. Domain
             addressing adds an additional "layer" to address designation that
             represents a particular FTN.  Within that FTN, zones and nets can
             be specified without conflicting with identical zones and nets in
             other FTNs.

          How is it used?


          To use domain addressing you would:

               1)   Add a domain string to your address statements.
               2)   Include the domain statement in the configuration file with
                    its required parameters, i.e.,

                         Domain <Designator><Abbreviation>[<Nodelist>]

                    <Designator> is the actual Domain name which can be up to
                    about 30 characters long.

                         Examples:
                         "Fidonet.org" mirrors Internet use
                         ("FidoNet" is a sufficient FTN domain name).
                         "Alternet.ftn"
                         "Eggnet".



     BinkleyTerm 2.60 Reference Manual                       Page 27  



                    <Abbreviation> is the shortened form of the domain name
                    with a limit of  8 characters. BinkleyTerm uses this to
                    decide which directory to use for non-primary domains.

                         Examples:  "FidoNet", "Alternet", "Eggnet"

                    <Nodelist> is an optional parameter indicating which
                    compiled nodelist to use. The default is to use the same
                    name as <abbreviation>.

                         Example: with a V7 FidoNet nodelist you use "Nodex". 
                         (V6 used "Nodelist".)

                    Each FTN can have its own nodelist, but if the zone and net
                    numbers do not overlap, it is possible to combine all the
                    Nodelists, in which case the Domain statements should all
                    reference the combined Nodelist/s.

               3) Include DomainKludge statements:
             These enable BinkleyTerm to fill in a domain if addresses are
             without domain specification, either from local entry or in FidoNet
             handshaking.

             If no DomainKludge specification exists for any zone, it is assumed
             to be part of your primary domain. Thus, with a FidoNet primary
             address, there is no need to specify DomainKludges for Zones 1 to
             6.

             The "DomainKludge" lines must follow the "Domain" lines, and if you
             set a DomainKludge without having previously defined a domain, it
             will not be processed.

             REMEMBER, DOMAIN KLUDGE LINES *MUST* FOLLOW  THE DOMAIN LINES!

           How should Outbound Areas be Named when domains are used ?

             As always, the outbound area for your primary address (including
             domain) is given with the 'Hold' statement.

             Separate Outbound Areas are needed for each Zone in each Domain
             These take an identical stem path to the primary outbound, except
             that the name of the last sub-directory is changed to the
             <abbreviation> parameter, plus the zone extension.

             For example, if your 'Hold' statement designates
             C:\BINKLEY\OUTBOUND for the outbound holding area (and you are in
             FidoNet), Alternet (zone 7) outbound mail would be held in the
             C:\BINKLEY\ALTERNET.007 directory instead.  Note that outbound
             areas for domains other than your primary will ALWAYS have a zone
             extension, and that zone extensions are always specified in
             Hexadecimal, up to .FFF (4095)

             As an example, assume that your BINKLEY.CFG includes the
             statements:

             Hold c:\bink\outbound



     BinkleyTerm 2.60 Reference Manual                       Page 28  


             Address 1:104/501@fidonet.org
             Address  89:555/66@Alternet.ftn
             Address  99:444.33@eggnet
             Domain fidonet.org fidonet nodex
             Domain alternet.ftn alternet anetlist
             Domain eggnet.ftn eggnet egglist

             * note: if all the nodelists were combined then the domain
             statements could be:

             Domain fidonet.org fidonet nodex
             Domain alternet.ftn alternet nodex
             Domain eggnet eggnet nodex

             * If used, DomainKludge statements must come after Domain
             statements.

             DomainKludge 7 alternet.ftn
             DomainKludge 99 eggnet

             What else needs to be done?

             You need to tell your packer that you have different Outbounds for
             the Zones in your other Domains.  For example, using "Squish" as
             your packer, this would mean adding extra Outbound keywords in
             Squish.cfg., as follows:

             Outbound  C:\bink\outbound ; default outbound primary zone
             Outbound  C:\bink\Alternet.89
             Outbound  C:\bink\Eggnet  .99

             Note the zone no. parameter required for outbounds other than the
             primary.


             The outbound holding areas (for Zone 1 FidoNet) would then be as
             follows:

                     c:\bink\outbound            (Default Outbound)
                     c:\bink\outbound.002        (FidoNet Zone 2)
                     c:\bink\outbound.003        (FidoNet Zone 3)
                     c:\bink\outbound.004        (FidoNet Zone 4)
                     c:\bink\outbound.005        (FidoNet Zone 5)
                     c:\bink\outbound.006        (FidoNet Zone 6)
                     c:\bink\alternet.007        (Alternet Zone 7)
                     c:\bink\alternet.059        (Alternet Zone 89)
                     c:\bink\eggnet.063          (Eggnet Zone 99)


             If you are updating an older Configuration you should beware that
             the unofficial "EE" version used reversed zone and domain name
             references and also accepted zone number ranges after the domain
             statement. BinkleyTerm  2.60 ignores any extra zone numbers but
             does not like the reversed references!



     BinkleyTerm 2.60 Reference Manual                      Page  29

     DIAL TRANSLATION

             When BinkleyTerm is in modem command mode, several dial
             translations take place automatically.

                  ASCII   Char.  Name              Action
                  -----   -----  ----              ------
                  032            Space             Stripped
                  045     -      Hyphen            Stripped
                  046     .      Period            Translated to a Comma
                  094     ^      Caret             Raise DTR Line
                  096     `      Backquote         1/20th Second Delay
                  118     v      Lower Case V      Lower DTR Line
                  124     |      Pipe, Split Bar   Carriage Return Sent
                  126     ~      Tilde             1 Second Delay

             A comma is not translated but is handled by your modem settings,
             usually a preset delay of 1-8 seconds (must not be less than 4 secs
             in the UK). Note, a comma does not produce a delay in BinkleyTerm,
             only in the MODEM i.e., as part of a dial string. For example, to
             delay sending an answer command you would use "~~ATA|" and not
             ",ATA|"

             The escape character "\" can be used to escape (i.e. send
             unchanged) any subsequent character that otherwise would be
             interpreted by BinkleyTerm's dialer; for example "\ " to send a
             space,"\." to send a period. To send the "\" backslash character
             itself, use "\\".

     FLAGS OR SEMAPHORE FILES
             BinkleyTerm has built in support for flag files, which are also
             known as semaphore files.

             BinkleyTerm's flag support is mainly intended for multi node or
             multi line use, i.e. to prevent two nodes of the same system both
             calling another system at the same time, but flags can also be
             useful in multi-tasking situations.

          To enable flag support:
               A. The Flags <directory> statement in your BINKLEY.CFG file
                    should be enabled and point to an existing directory.  This
                    directory:

                     a)  Holds the "TASK.#" file. see below.
                     b)  Is the fallback directory for the *.BSY files mentioned
                         below.
                     c)  Is used for the BTRESCAN.yy and BTEXITxx.yy flags

               B. The TaskNumber <#> must be enabled and set to a different
                    number for each node's BINKLEY.CFG. and each task number
                    must be greater than zero. 

                    Note however that with 'BTEXIT' or 'BTRESCAN' methods
                    mentioned below, the task number may be zero for single line
                    systems that do not use the TaskNumber statement.



     BinkleyTerm 2.60 Reference Manual                         Page 30 blank
     BinkleyTerm 2.60 Reference Manual                                Page 31


          How are the directory and the task numbers used?


             1.      BinkleyTerm creates a "TASK.#" file (where # is the number
             stated in the  TaskNumber statement) in the flags directory
             whenever BinkleyTerm has carrier and a  mail session is in
             progress. This can be used to determine if any given  BinkleyTerm
             task is currently running.

             2.      BinkleyTerm will also create a file named "xxxxyyyy.BSY"
             whenever it is transacting business with a system, for each AKA
             address presented by that system. In each case xxxx is the net
             number in hex of that system and yyyy is the node number of the
             system, also in hex.

             The file is placed in the outbound directory for the Domain and
             Zone in question or, if there is no such directory, then in the
             flags directory if one has been set up.

             These files serve as flags to other tasks or compatible programs so
             that the other tasks can be instructed not to handle any mail for
             that node (or its AKAs) until the *.BSY flags have been cleared.

             Additionally, BinkleyTerm will not send any mail to a node for
             which there is a .BSY flag.

             Note that inbound FTS-0001 sessions will have to accept a packet
             before the flag can be tested, as the packet is used to indicate
             the address of the system.

             3.      An external program (for example, one of your batch or .cmd
             files) can place a flag in the flags directory. This flag should be
             in the form:

                    BTEXIT##.@@

             (where ## is an exit errorlevel in hex and @@ is the task number,
             also in hex)

             BinkleyTerm scans the flags directory frequently and if it finds
             such a file with the task number matching that in the BINKLEY.CFG
             file, then it will exit with the errorlevel specified in the flag
             file.
             for example:

                    BTEXIT10.B0
             will make a BinkleyTerm with tasknumber 176 exit with errorlevel 16

                    BTEXIT20.00

             will make a BINKLEYTERM with no task number exit with errorlevel 32

             4.      In a similar way to that shown above an outbound mail
             rescan can be forced from an external program by creating a file in
             the flags directory in the form:



     BinkleyTerm 2.60 Reference Manual                       Page 32  



                    BTRESCAN.@@   (where @@ is the tasknumber in hex)

             for example:

                    BTRESCAN.40

             will cause a BinkleyTerm with task number of 64 to rescan its
             outbound areas.

             5.      If the forcexit <errorlevel> statement in BINKLEY.CFG has
             been enabled BinkleyTerm will also periodically check the flags
             directory for a file called FORCEXIT (or FORCEXIT.@@ if a
             TaskNumber is set) When found BinkleyTerm will delete the file and
             exit with the errorlevel specified in the Forcexit statement.

     BI-DIRECTIONAL PROTOCOLS

             Bi-directional protocols were introduced in version 2.40 of
             BinkleyTerm, using "JANUS", a protocol developed by Rick Huebner.

             Janus is a bi-directional, full-duplex protocol, and generally
             requires a full-duplex modem to work properly.  Under ideal
             conditions, Janus allows you to transfer mail simultaneously in
             both directions with Zmodem- like performance.

             Hydra is another bi-directional protocol developed by Arjen Lentz
             and Joaquim Homrighausen. Support for this protocol has been added
             in the DOS and OS2 versions of BinkleyTerm  2.60

             Naming of Bi-Directional Configuration file statements

             Originally, Janus was the only protocol supported and the
             configuration file statements used to control its operation were
             named JanusBaud and JanusOK.

             Now that there is support for two bi-directional protocols, the old
             statement names are not entirely appropriate (though they may still
             be used if you wish) and new names, BiDiBaud and BiDiOK are often
             used in place of JanusBaud and JanusOK.

             BiDiBaud is synonymous with JanusBaud. Use whichever you prefer

             BiDiOK is synonymous with JanusOK. Use whichever you prefer

             For simplicity, within this section of the documentation reference
             will be made to the BiDiBaud and BiDiOK statements, but remember
             that in each case, the equivalent "Janus" statements (JanusBaud and
             JanusOK respectively) could be used

             Two additional statements are available:

             NoJanus  to explicitly disable Janus
             NoHydra  to explicitly disable Hydra



     BinkleyTerm 2.60 Reference Manual                       Page 33  


             Note that if the other system with whom you are working offers both
             bi-directional protocols, Janus will take priority unless you
             specifically disable it.



     THE JANUS MAIL PROTOCOL

             NOTE:   There is no assurance or guarantee that Janus will work for
             you in your environment.  PLEASE READ THIS SECTION IN ITS ENTIRETY
             IN ORDER TO UNDERSTAND AND PROPERLY IMPLEMENT JANUS.  FAILURE TO DO
             SO WILL YIELD UNPREDICTABLE RESULTS!


          An Introduction to Janus

             Janus is a file transfer protocol specifically designed for WaZOO
             mail transfers.  It can achieve Zmodem-like performance and
             reliability, with the major added benefit of being able to do
             transfers in both directions simultaneously.  It is implemented as
             dual independent state machines; one for sending files, and one for
             receiving files.  Both state machines run simultaneously, sharing
             the phone line.  All data is exchanged in variable-length packets,
             with either a 16 or 32 bit CRC.  Under ideal conditions, you can
             expect Zmodem-class performance going both ways at the same time.

             The bottom line is that when two machines exchange mail using
             Janus, the smaller of the two nodes' batches of files will be sent
             for free while the larger batch is being sent.  If you poll your
             EchoMail feed nightly, and usually only send a couple of kilobytes
             while picking up a couple hundred, you won't get any real benefit
             from using Janus.  But if you normally send 100kb and pick-up
             200kb, you'll see significant time and money savings.

             However, even if you don't usually need to send and receive much
             data at once, and don't get much benefit from the full-duplex file
             transfers, you should get Zmodem-level performance even on one-way
             transfers, and so shouldn't have any penalty for using Janus rather
             than ZedZap (Zmodem).  The idea is for the benefits to be there
             when you need them, without costing you anything extra if you
             don't.


          What You Should Be Aware Of

             There are some important considerations that you should be aware of
             before using Janus.  Most importantly, Janus is a FULL DUPLEX
             protocol, and works best with a full-duplex connection.

             It's not a good idea to try and shove streaming, non-stop, full-
             duplex data through a half-duplex connection, since the modems will
             end up constantly flip-flopping the line around and retraining, and
             you'll get terrible performance. 

             What this means is that normal low speed (1200 and 2400 baud)
             connections should work fine with Janus, and that high speed links
             that use V.32 should also work fine.  High speed connections with



     BinkleyTerm 2.60 Reference Manual                       Page 34  


             high speed in one direction and a low speed back channel (such as
             an HST) will not allow Janus to work well at all.

             There are some other situations where Janus will not work very
             well.  Many systems, modems and networks just don't seem to have
             the sustained bandwidth to allow full-duplex streaming data to be
             transferred accurately. 
             Telenet's PC Pursuit service is a good example.  The service has
             great difficulty with Janus, frequently dropping and mangling data.
              Janus simply saturates the capabilities of the packet switched
             connection.

             Some modems and even some serial port hardware doesn't seem to bear
             up very well under the tremendous load Janus can put on them
             either.  This is probably to be expected, since full-duplex
             streaming protocols are rare, and the hardware has probably never
             been tested under this type of extreme, sustained load.

             The bottom line is that Janus may or may not work for you with your
             hardware, and if it does work, it may not work well on all
             connections.  Its implementation in BinkleyTerm has been tested
             thoroughly, and works very well in many cases.  You'll need to
             enable Janus (by default, Janus is not enabled) and test it
             yourself in your own environment to know whether Janus is a
             workable solution for you.

     Configuring Janus
             DOS Fossil driver buffer configuration.

             Your first consideration before using Janus is your FOSSIL driver
             buffer configuration.  Janus really needs at least a 2kb receive
             buffer (or better yet, 3kb) and no more than about a 1kb transmit
             buffer (including whatever transmit buffering your modem does). 

             The reason for the large receive buffer may be obvious; the largest
             packet Janus ever sends is 2kb, and while it's sending 2kb, you can
             obviously receive 2kb, which Janus won't be able to read from the
             FOSSIL until it's done sending.  So up to 2kb of data can easily be
             received before Janus gets a chance to read any of it, and possibly
             a bit more in some situations.  If your receive buffer is too
             small, you'll constantly lose incoming data and require massive
             numbers of retransmissions. 

             The send buffer should be kept fairly small, because of the way the
             packets for the two directions are  interleaved on the phone lines.
              If I'm receiving a large file from you while I'm sending you lots
             of small files, every time I finish sending you a small file I have
             to wait until I've received your entire send buffer's worth of data
             before I see the acknowledgment that says you received my file
             okay.  If your send buffer is more than 1 or 2kb, this can end up
             wasting a lot of time.


     Configuration File Statements for Bi-directional protocols

             BiDiBaud <max_connect_rate>



     BinkleyTerm 2.60 Reference Manual                       Page 35  


             IF YOU HAVE A LOW SPEED MODEM (2400 baud or under), then you will
             generally use the 'BiDiBaud' statement in your configuration file.
              Set 'BiDiBaud' to your highest supported baud rate.

             IF YOU HAVE A HIGH SPEED MODEM (9600 baud or above), 'BiDiBaud'
             should be set to the highest FULL DUPLEX baud rate you support.

             Note: The maximum setting for <max_connect_rate> is no longer
             limited to 32767, as it was in earlier versions.

             If your high speed modem is single-standard, then the 'BiDiBaud'
             statement is all you will probably need to use.

             BiDiOK <extended_connect_info>

             Multi-standard modems require 'BiDiOK' statement(s) in order to
             take full advantage of high speed full duplex (V.32) connections
             when they occur.

             Your multi-standard modem should be set to return extended modem
             connect information.  This information is appended to the end of
             the modem connect message, and can be used to determine what type
             of connection has been made in conjunction with the 'BiDiOK'
             statement.

             In the case of a USRobotics HST Dual Standard, you will normally
             want to use a bi-directional transfer on V.32 connects, but not on
             HST connects.  For example, these connect strings would indicate
             connections where a bi-directional protocol can be used:

                  CONNECT 9600/Arq/V32
                  CONNECT 9600/V32

             But a connection like this would not take advantage of a bi-
             directional protocol :

                  CONNECT 9600/Arq/Hst

             NOTE:  The extended connect information is not shown in all upper
             case, since BinkleyTerm will convert everything but the first
             character to lower case for display, automatically.

             You would permit a bi-directional protocol only on the desired
             connects, like this:

                  BiDiOK /Arq/V
                  BiDiOK /V      
             (you may not wish to use a bi-directional protocol on an non-secure
             connect, if not then omit the BiDiOK /V line

             When using 'BiDiOK', make certain that you also set 'BiDiBaud' no
             higher than 2400, or your 'BiDiOK' statements may not have the
             desired effect.

             In addition, you will probably want to dial out in V.32 mode if you
             frequently connect with multi-standard modems of the same make and



     BinkleyTerm 2.60 Reference Manual                       Page 36  


             model.  This will allow a bi-directional protocol to be enabled on
             the maximum number of connections.

             If your multi-standard modem is not an HST Dual Standard, consult
             your modem manual for details extended connect information for your
             particular modem make and model.

             NOTE:  In testing, it has been found that the "PEP" mode of the
             Telebit Trailblazer series modems can handle the bi-directional
             protocols, even though PEP mode is not full duplex.  Throughput may
             not be as high as it would be on a true full duplex connection.



     BinkleyTerm 2.60 Reference Manual                       Page 37  



     HYDRA MAIL PROTOCOL
             This is fully described in the documentation available with the
             Hydra program.

             "Hydra (mythology), in Greek mythology, nine-headed monster that
             dwelled in a marsh near Lerna, Greece. A menace to all of Argos, it
             had fatally poisonous breath and when one head was severed, grew
             two in its place; its central head was immortal. Hercules, sent to
             kill the serpent as the second of his 12 labors, succeeded in
             slaying it by burning off the eight mortal heads and burying the
             ninth, immortal head under a huge rock".

             "The term hydra is commonly applied to any complex situation or
             problem that continually poses compounded difficulties."
                                 "Hydra (mythology)," Microsoft (R) Encarta.
                                 Copyright (c) 1993 Microsoft Corporation.
                                 Copyright (c) 1993 Funk & Wagnall's
                         Corporation"

             Hydra is only supported in the OS/2 and DOS versions of BinkleyTerm
             at present. No doubt this will change shortly.


     CALL COSTING

             BinkleyTerm allows two call costing systems to be used.

                             The American Costing System
             This is the original system used in earlier versions and it is the
             default unless you enable the 'Eurocost' statement. Using the US
             system, the Nodelist "cost" field is set to indicate the cost of a
             call in cents per minute. 

                                 The Eurocost System
             In Europe calls are priced by "call units", the current cost of a
             unit in the UK being 4.935 pence. Each unit buys you a certain
             amount of time, the time depending on whether the call is a Local,
             Long Distance (within the country) or International call.
             The time per unit also depends on the time of day. i.e., whether
             Cheap /standard /peak rates apply. Binkley cannot yet handle the
             variations of cheap/standard and peak rates but you can set up your
             event file to call out only at times when cheap rates apply.
             To enable the European Costings put the following three statements
             in your BINKLEY.CFG:

                EuroCost            This will establish the revised costing
                                    method.
                CostLog <filespec>  Provides a very neat log of call costs
                                    (choose a filename).
                CostUnit <number>   Defines the cost of one call unit in
                                    your currency. Cost is just a number
                                    which can represent pence, pfennigs or
                                    anything else (in the UK where a unit
                                    costs 4.935 pence  use 5).



     BinkleyTerm 2.60 Reference Manual                       Page 38  


             To make this work BinkleyTerm expects new information in your
             NODELIST. It will look at the "Cost" fields and expect to find the
             *TIME* allowed for one unit, this time being expressed in tenths of
             a second. This means altering the configuration file of your
             nodelist compiler and recompiling the list, but the alterations are
             not difficult. Just bear in mind that BinkleyTerm will expect a
             "time per unit" wherever it you would previously have put a "cost
             per second".

             If you previously entered the call cost in cents (for example this
             is how Fastlst and ParseLst want the information) then enter the
             time allowed for one unit measured in tenths of a second.  
             (Example.. a local call in the UK at cheap rate gives you 220
             seconds per unit. You would enter 2200 in the COST fields)

             If you previously entered the call cost in dollars (as BONK
             expects), then you would enter 22.00 for a UK cheap rate call.

             Note: You *will* need to revise your event file because European
             calls get cheaper as the L parameter gets larger!   Refer to the L
             flag under Event File for more information.

     EMSI
             EMSI is a handshake protocol credited to Joaquim H. Homrighausen
             which allows maximum flexibility in session startup and control.

             To enable EMSI  you will need to ensure that there is no NOEMSI
             statement in the configuration file (or that it is commented out)
             and that all four of the following statements are  included:

               MyListFlags   MyLocation   MyMaxBaud   MyPhone

             Note: This information should be given in Nodelist form as it
             appears that other mailers may refuse to connect if the items in
             the MyListFlags entry are not valid nodelist flags.

                               THE CONFIGURATION FILE

             The BinkleyTerm configuration file, by default named BINKLEY.CFG,
             is the place where you communicate information about your system to
             BinkleyTerm.

      LAYOUT

             Statements are made one per line, with any necessary parameters.
             Statements are not case sensitive. The keyword of the statement
             must start in column one, i.e. if there is a blank at the start of
             the line BinkleyTerm will report "illegal statement".

             Any line having a semi-colon (;) as its first character is deemed
             to be a comment line. A sample configuration file comes with the
             BinkleyTerm  distribution package.



     BinkleyTerm 2.60 Reference Manual                       Page 39  


     FULL ALPHABETICAL LIST OF CONFIGURATION STATEMENTS


          About <filespec>

             This tells BinkleyTerm the name of the ABOUT file, a special file
             used with incoming file requests.  <filespec> is a complete drive,
             path and filename designation.  Refer to the section "Controlling
             File Requests" for more information.

          Address [<zone>:]<net>/<node>[.<point>][@<domain>]

             This statement (or multiple statements) designates the network
             address(es) of your system.  Although the <zone>, <point> and
             <domain> parameters are optional, it is recommended that the <zone>
             parameter ALWAYS be used.
             Example of address for node 1:104/501

               Address 1:104/501  (or 1:104/501.0)

             Example of address for point off 1:104/501

               Address 1:104/501.11

             Example of address with domain for 1:104/501.11

               Address 1:104/501.11@fidonet.org

             If you designate a Domain in the 'Address' statement then you
             *must* also create a corresponding 'Domain' statement.
             When the Address statement is used, the older style addressing,
             such as 'Aka', 'Point' and 'Zone' should NOT be used, nor should
             'Boss' be used by point systems (the address statement covers
             this).

             Multiple 'Address' statements, each with a different <zone>
             parameter, may be used.  This allows BinkleyTerm to identify itself
             differently to different zones, thereby making multi- net operation
             somewhat more simple.  You may have up to 25 address statements
             including the primary one.

             Note that if you are connected to a zone for which an 'Address'
             statement does not exist, that the 'Address' statement that appears
             first in the configuration file will be used as a default.

             The zone given in the 'Address' statement that appears first
             determines your "default" outbound area, as given by the 'Hold'
             statement. 

             Mail for all other zones is stored in distinct outbound areas for
             each zone.

          AfterCall <number> <modem_string>

             If the Configuration file contains this statement (in which
             <number> is the number of responses expected from the modem and
             <modem_string> is an AT command) then BinkleyTerm will send the



     BinkleyTerm 2.60 Reference Manual                       Page 40  


             string to the modem after any call, incoming or outgoing, and will
             note up to <number> of response lines in the log file.
             For example, with a USR Courier or an ATI PM14400FXMT
             "AfterCall 16 AT16|" works well.

          AfterMail <command_line>

             If used, BinkleyTerm will invoke a Command Shell and execute the
             <command_line> after receiving mail.  It is suggested that
             <command_line> designate a batch file, rather than a specific
             program.  The batch file would contain command line(s) for the
             program(s) that will actually unpack and/or toss incoming mail.

             NOTE!  If this statement is used, no E2= or E3= exits during event
             schedules should be used, since they take priority over this
             statement.  Refer to the section "Event Files" for details.

             See 'Packer <command_line>' on page 62 and 'Cleanup <command_line>'
             on page 45 for related information.

          Aka <net>/<node>                     [This Statement is Obsolete]

             NOTE:  This statement is supported for backward compatibility only.
              To specify alternate addresses, use multiple 'Address' statements
             as described previously.

          AltNumber <primary number> <alternate number>

             This statement defines an alternate number which BinkleyTerm will
             dial if a call to the <primary number> was unsuccessful.

             The alternate number must have the same node number as the <primary
             number> or have the same node number as an aka.

             If a system you frequently call has 2 or more nodes that share the
             same node number, you can now call the alternate numbers if the
             primary number (nodelisted number) is busy or doesn't answer.

             For Example:

                         AltNumber 555-1111 555-2222

             If 555-1111 was busy, BinkleyTerm would automatically call 555-
             2222. If there was more than one alternate number they would be
             specified as follows:

                         AltNumber 555-1111 555-2222
                         AltNumber 555-1111 555-3333

             As in the first example, if 555-1111 was busy, a call would be made
             to 555-2222.  If that number was busy, BinkleyTerm would attempt to
             call 555-3333.

             This type of setup, multiple nodes sharing the same node number, or
             having the same node number as an aka, is most often used by, but
             not limited to, mail distributors. The only limitation of the



     BinkleyTerm 2.60 Reference Manual                       Page 41  


             number of AltNumber statements you can specify is the amount of
             memory you have.

             If the various modemxxxx statements (see "Modem result code array")
             are NOT included in your configuration file, then BinkleyTerm
             defaults to 'ModemRetry BUSY' and alternate dialing will occur if a
             BUSY response is received from the main number.

             If the Modemxxxx statements are in your config, you must include
             'ModemRetry BUSY' to make busy responses eligible for alternate
             number dialing.

          Answer <modem_string>

             When this statement is used, BinkleyTerm assumes that the modem has
             been set NOT to answer the phone automatically (by the modem
             initialization string, or the modem's DIP switches). 

             When BinkleyTerm receives a response string of "RING" from the
             modem, it sends the <modem_string> command to the modem to answer
             the phone.

             The advantage is that BinkleyTerm must be "alive and well" before
             the modem will answer a call.  If for some reason BinkleyTerm is
             not available, yet the modem still has power, no calls will be
             answered.

             NOTE!  Some modems DO NOT like commands to be sent while they're
             sending response strings, similarly, some modems prefer command
             echo off (ATE0)..in testing, this feature DOES NOT work on all
             modems.  Only by trying it will you be able to determine if it
             works with your modem.

          AnswerBack <text>                            [Terminal Mode Only]

             In Terminal Mode, when an ENQ (ASCII decimal 5, hex 5) is received,
             <text> will be sent in response.  Normal BinkleyTerm character
             translations are available.  Many BBS packages send this character
             immediately prior to requesting a user name.

          Application <app_name> [<parm> <parm> ... ]

             Allows addition of application dependent data to the configuration
             file.  Any 'Application' statement is ignored by BinkleyTerm
             entirely. <app_name> is the name of or reference to a specific
             application, such as a message editor or outbound maintenance
             utility that uses the BinkleyTerm configuration file.  Zero or more
             application specific parameters, shown as <parm> in the example,
             may follow <app_name>.

          Autobaud

             In Unattended Mode, provided the Fossil is not locked, this forces
             BinkleyTerm to call out at the baud rate specified by the 'Baud'
             statement, regardless of the baud rate associated with a given
             nodelist entry.  This assures connects at the highest possible baud
             rate. If the Fossil is locked, BinkleyTerm cannot change the rate.



     BinkleyTerm 2.60 Reference Manual                       Page 42  


          Avail <filespec>

             This designates the name of the file to be sent to a remote system
             that file requests "FILES" from your system.  The <filespec>
             identifies the file, and may contain an optional drive and path
             designation.

          Banner <string>

             The line designated by <string> is sent to callers immediately
             following the BinkleyTerm identification line, and before the line,
             "Press <Escape> to enter BBS."  Generally, this is the name of your
             BBS or something else of interest to callers.

          Baud <max_baud_rate>

             In DOS, valid <max_baud_rate> settings are 300, 1200, 2400, 4800,
             9600, 19,200 and 38,400. but the 'ExtBaudRates' statement described
             on page 50 can be used to add  higher rates when used in
             conjunction with Ray Gwinn's X00 FOSSIL Driver v1.53a.

             The Baud statement does not support the "three-quarter rates" i.e.
             7200, 12000 and 14400. Set your modem to a higher full rate e.g.
             19200 or 38400.

             In OS/2 and Win32 systems, 57600 baud and 115200 baud can also be
             set.  Note that for this to work with the OS/2 version, you must
             have version 2.5 or above MAXCOMM.DLL or any version of
             SIOCOMM.DLL.

          BBS <exit_option>

             This designates the method to be used to access your BBS software
             when a human caller dials your system.  Valid options for
             <exit_option> are 'Batch,' 'Exit' and 'Spawn.'  Refer to the "BBS
             Interface" section for more information on the options, and how to
             use them.

          BBSNote <string>

             After a human caller presses Escape to access the BBS program, or
             after the number of seconds designated by the 'Timeout' statement,
             BinkleyTerm will display the <string> to the caller. Generally,
             this is a notification that the BBS software is loading.

          BBSSound <filename.wav>

             Play a sound on exit to a BBS (OS/2 and Win32 machines only at
             present)

          BiDiBaud <max_connect_rate>

             This will enable both bi-directional protocols (Janus and Hydra)
             and set the maximum baud rate to be used with such transfers.
             The action of this statement may be modified by one or more BiDiOK
             statements, q.v..
             Note: The <max_connect_rate> is not limited to 32767 as it was



     BinkleyTerm 2.60 Reference Manual                       Page 43  


             in earlier versions of BinkleyTerm.
             See also 'NoHydra', 'NoJanus' and the details in the "Bi-
             Directional Protocol" section on page 32

             'BiDiBaud' has exactly the same action as 'JanusBaud'


          BiDiOK <extended_connect-info>

             Modifies the action of the 'BiDiBaud' statement by only allowing
             bi-directional transfers for those connections where the modem
             returns extended connect information which matches the <extended-
             connect-info> parameter.

             The BiDiOK statement is not required with a single standard modem.

             A multi-standard modem should be set to return extended modem
             connect information appended to the end of the modem CONNECT
             message. If the modem returned CONNECT 9600/Arq/V32 then a
             statement: BiDiOK /Arq/V32 will enable the bi-directional protocols
             for that connection but the protocol would not be enabled if the
             Modem returned CONNECT 9600/Arq/Hst as the strings do not match.

             It is thus possible to differentiate between HST and other
             connections.

             NOTE:  The extended connect information is not shown in all upper
             case, since BinkleyTerm will convert everything but the first
             character to lower case for display, automatically.
             Multiple BiDiOK statements may be used to cover the various   
             modem result strings where Bi-directional transfers are to be
             allowed.

             See also 'NoHydra', 'NoJanus' and the details in the "Bi-
             Directional Protocol" section on page  32

             'BiDiOK' has exactly the same action as 'JanusOK'

          BlankWait <number>

             Sets the number of seconds BinkleyTerm will wait before blanking
             the screen when the 'ScreenBlank' configuration statement is
             enabled.

          Boss <net>/<node>                    [This Statement is Obsolete]

             NOTE:  This statement is supported for backward compatibility only.
             It is not needed when the 'Address' statement is used, as described
             previously.

             This specifies a FidoNet node address. For regular FidoNet nodes,
             place your assigned address here. For Point systems, place the
             address of your Boss node here.



     BinkleyTerm 2.60 Reference Manual                       Page 44  


          BossPhone <phone_number>

             This statement, used in Point installations, contains the telephone
             number of your Boss node for use with the Alt-Y command in Terminal
             Mode. This statement is optional in all cases except Point
             installations that do not wish to use a nodelist.

          BossPwd <password>

             Used for Point installations, this statement designates the
             password to be used for session-level passwording with your Boss
             node.  Refer to the section "Session Passwords" for additional
             information.  The Boss node must also have session passwording
             implemented, using this password.

             When this statement AND 'BossPhone' are BOTH implemented, a
             nodelist is NOT required for a Point system.

          BoxType <number>

             When full-screen mode is used (default), this tells BinkleyTerm
             what type of boxes to use for the various on- screen windows. 
             Legal values are from 0 to 4.  They produce the following results:

                0 = Hatches (Non-IBM)
                1 = Single Rule
                2 = Double Rule
                3 = Single Top, Double Sides
                4 = Double Top, Single Sides

          Busy <modem_string>

             While BinkleyTerm performs certain functions, and when you exit the
             program from Unattended Mode, BinkleyTerm sends the <modem_string>
             to the modem.  Normally, this is a short set of modem commands, as
             shown in the sample configuration file, to take the phone off-hook
             to prevent incoming calls.  Callers will hear a busy signal.

             If you lower DTR instead, using a lower-case letter "v", this would
             cause callers to hear ringing, but with no answer.

          CaptureFile <filespec>                       [Terminal Mode Only]

             If used, this statement tells BinkleyTerm the name of a file to use
             for session capturing in terminal mode.  The Alt-L command toggles
             session capture on and off.  If this statement is not used, then
             BinkleyTerm will prompt for a name each time Alt-L is pressed. 
             When activated, all communications session I/O will be echoed to
             this file.

          Carrier <hex_carrier_mask>

             This tells DOS BinkleyTerm which FOSSIL status bit it should use to
             determine whether or not carrier is present.  A value of 80
             (hexadecimal) is nearly always correct.  Some modems do not support
             CD (carrier detect) and other signal lines may be used.



     BinkleyTerm 2.60 Reference Manual                       Page 45  


             NOTE:  This value is in HEXADECIMAL (base 16).  Other systems, such
             as Opus-CBCS, ask for this value in DECIMAL (base 10).  Normal
             setting is 80 hex, which equals 128 decimal.

          Cleanup <command_line>

             If used, BinkleyTerm will execute <command_line> at the beginning
             of each event, but prior to the 'Packer' statement's command line
             (if used).  This might be used to unpack any previously packed
             outbound mail for later repacking, or to perform minor outbound
             area maintenance, etc.  It is suggested that <command_line>
             designate a batch file that would contain the command line(s) for
             the program(s) actually used to unpack mail and/or perform
             maintenance.

             See 'AfterMail <command_line>' on page 40 and 'Packer
             <command_line>' on page 62 for related information.

          Colors <brdr> <set> <tday> <pndg> <actvty> <trnsfr> <rev> <popwin>

             The first 6 parameters refer to parts of the window display, <rev>
             is the reverse video used in the pending outbound window and
             <popwin> refers to the color of pop up windows, e.g., the popup
             which appears when Alt-G is pressed.

             Specify the color you want for each section, for example:
               Colors  112 9 10 11 14 12 48 7          (This combination once
             won a competition)

             Remember that you need a Video Fossil installed for color displays
             if you are running under DOS.  See page 83

             The default colors are black background with white foreground for
             all areas.

             The following chart may assist you in determining your desired
             color attribute values.  The numbers listed under "Foreground" will
             yield the given color on a black background.  By adding the value
             shown under "Background Value" to the foreground value will yield a
             background of the selected color.



     BinkleyTerm 2.60 Reference Manual                       Page 46


             For example, to get yellow characters on a blue background, add the
             foreground color for yellow, 14, to the background value for blue,
             16 - use a color attribute of 30. Note that gray, bright colors and
             yellow cannot be used for the background.

                 Color              Foreground          Background
                 ---------          ----------          ----------
                 Black                      0                      0
                 Blue                       1                     16
                 Green                      2                     32
                 Cyan                       3                     48
                 Red                        4                     64
                 Magenta                    5                     80
                 Brown                      6                     96
                 White                      7                     112
                 Gray                       8                     N/A
                 Bright Blue                9                     N/A
                 Bright Green               1                     N/A
                 Bright Cyan                11                    N/A
                 Bright Red                 12                    N/A
                 Bright Magenta             13                    N/A
                 Yellow                     14                    N/A
                 Bright White               15                    N/A

             On IBM-compatible monochrome displays and using a black background,
             colors 9 through 15 yield high intensity characters, 1 through 7
             normal intensity characters.  0 and 8 yield invisible characters. 
             1 gives underscored white and 9 will yield underscored bright
             white. You may find that you need to have a Video fossil installed,
             even with a mono screen, to get these responses. See Page 83

             See also the 'Mark_Kromm' statement on page 56 which installs a
             popular color set without further effort.

             The easiest way of all to set the colors to your choice is to
             obtain one of the available color adjunct programs, for example 
             SBC (a DOS tool) , which allows you to set the colors on the fly.

          CostLog <filespec>

             Include this statement to produce a neat Cost log. When using the
             Eurocost option, the log has an error field but this is not at
             present implemented. It is left at zero.

          CostUnit <number>

             This is for use with the Eurocost option and defines the cost of
             one call-unit in your local currency. The costings will then be
             shown in that currency, i.e., if you define the unit cost in pence
             then the costings (shown as tariff in the log) will represent the
             cost of that call in pence.

          Curmudgeon

             NOTE:  This statement is not for general use.
             If used, this will cause your system to refuse mail connections
             from any "Unknown" systems, i.e systems not within your compiled



     BinkleyTerm 2.60 Reference Manual                       Page 47  


             nodelist.  Note that in FidoNet, systems using this keyword must
             have the "LO" flag in their nodelist entry, and run a full-world
             nodelist (to avoid refusing any valid FidoNet mail connections).

          CursorCol <column>

             For use with multi-tasking systems, this tells BinkleyTerm the
             column number to place the cursor in, after screen writes.  For
             DESQview, <column> should be set to 1.  The default value is 80.

          CursorRow <row>

             For use with multi-tasking systems, this tells BinkleyTerm the row
             number to place the cursor in, after screen writes.  For DESQview,
             <row> should be set to 1.  The default value is 23.

          Debug

             NOTE:  This statement is not for general use.
             Provided that you set LogLevel to 5 (see "LogLevel
             <log_level_number>" on page 56), then use of the Debug statement
             will cause BinkleyTerm to send additional information about the
             progress of its operations to your log file.

          Dial <match_string> <new_prefix>/[<new_suffix>]

             This option allows for real-time telephone number translation.
             BinkleyTerm will look at the telephone number it is to send to the
             modem.  If the prefix of the telephone number matches that shown in
             <match_string>, then the prefix will be changed to <new_prefix>,
             and <new_suffix> (optional) will be added to the end.
             In most cases, this will be used to strip-off "1-" and/or area
             codes for systems in a local exchange. Example:

             DIAL 1-603-888 888/

             The result of the above statement will be that a number in the
             nodelist as 1-603-888-8179 would be changed to simply 888-8179 and
             dialed.

             An AT command to your modem can be included e.g.,

               DIAL 1-303-555 555/&M0

             A number in the nodelist as 1-303-555-1234 would be changed to 555-
             1234 and dialed with the "&M0" being sent to the modem.

             There is a maximum of 20 characters each for <match_string>,
             <new_prefix> and <new_suffix>.

             Another use for this feature would be for dialing scripts:

                         DIAL 1-404 "GA_PCP.SCR"404/

             This line could be used to invoke a PC Pursuit script, for example,
             for the state of Georgia.  The script would be used for all
             outgoing calls to area code 404.



     BinkleyTerm 2.60 Reference Manual                       Page 48  


             For permanent translations it is probably more efficient to perform
             these translations with your nodelist processing program (i.e.,
             Fastlst, ParseLst, XlaxNode).  Refer to your nodelist processing
             software documentation for more information.

             The escape character "\" can be used in a phone number to escape
             subsequent chars that otherwise would be interpreted by
             BinkleyTerm's dialer.  To send the "\" backslash character itself,
             use "\\".

          DoingMail <string>

             If used, this statement will cause BinkleyTerm to send <string> to
             a caller when an event without a "B" flag is active, indicating
             that BBS access is NOT allowed.  This replaces the default string
             "Processing Mail.  Please hang up". See page 71 for more
             information on event flags.

          Domain <Designator> <abbreviation> [<nodelist>]

             <Designator> is the actual Domain name. FidoNet would be
             "Fidonet.org" and "Alternet" would use "alternet.ftn".

             <Abbreviation> is the shortened form of the domain name. This is
             limited to EIGHT (8) characters. In most cases this will be the
             common name of the network (i.e. "FidoNet" and "Alternet" in the
             examples).

             <nodelist> is an optional parameter which indicates the nodelist to
             associate with this domain. If not given, the default is to use the
             same name given as <abbreviation>.
             Refer to the "Domain" notes in this Manual for examples

          DomainKludge <ZoneNumber> <domainName>

             This will fill in a domain if addresses are without domain
             specification, either from local entry or in FidoNet handshaking.

             These lines must follow the "Domain" lines, and if you set a domain
             kludge without having previously defined a domain, it will not be
             processed. Refer to the "Domain" notes in this Manual

          Downloads <path>                             [Terminal Mode Only]

             This tells BinkleyTerm where to place files downloaded while in
             Terminal Mode.  The <path> is a complete drive and path
             designation.  This path has no effect on mail transfers made in
             Unattended Mode.

          DTRHigh

             If used, BinkleyTerm will leave the DTR (data terminal ready) line
             to the modem "high" whenever it is exiting.  By default,
             BinkleyTerm takes the DTR line "low" when exiting.  The use of
             'DTRHigh' has no effect when doing an Alt-J shell escape which will
             leave DTR low.  'DTRHigh' should be used with modems that go back
             on-hook when DTR is lowered.



     BinkleyTerm 2.60 Reference Manual                       Page 49  


          EnterBBS <string>

             If used, this statement will cause BinkleyTerm to send <string> to
             a caller when the BBS is available, during events with a "B" flag,
             indicating that BBS access is allowed.  This replaces the default
             string "Press <Escape> to enter BBS."  Note that <string> must not
             exceed one line.  See page 71 for more information on event flags.

          ErrLevelShell <errlevel> <shell command>

             When <errlevel> matches an exit errorlevel specified in the event
             file BinkleyTerm will spawn a shell instead of exiting. The spawned
             shell will run the command specified by <shell command>
             For example, if the event file had the following:

               Event ALL 08:00 12:00  E4=91,TIC A=60 T=3,10

             ...and the configuration file had the following:

               ErrLevelShell 91  DOTICK

             Instead of exiting with an errorlevel of 91 when a TIC file is
             received, DOTICK.CMD (or .BAT) will be executed.  If you are using
             the OS/2 or Win32 version of BinkleyTerm (or the DOS version on
             Windows 95) and specify:

             ErrLevelShell 91 Start /I /C "Tick Processing" DOTICK

             ...DOTICK.CMD (or .BAT) will be started as a separate session.

             Unlike the exit procedure, where if more than one E4-E9 exit
             applies the first one is taken, if more than one E4-E9 has a
             matching ErrLevelShell that applies, then each shell that applies
             will be taken.

             If an E4-E9 exit applies and does not have a matching ErrLevelShell
             then that exit will occur after the shells have been taken.

             For instance, if there was an error level specified for E4 through
             E9, and if each applied at the end of a session, and an
             ErrLevelShell was specified for E4, E7, and E8, the 3 shells would
             be taken, and then BinkleyTerm would exit because of E5.

             Note however that if E3 is an ErrLevelShell then any E2 exit will
             be ignored on the assumption that the E2 (packet) stuff will have
             been processed by the shell for E3 (which handles compressed and
             other mail).

             Note also that this statement only applies to errorlevels specified
             *in the event file*. It is not (yet?) available for such things as
             function key exits, which are not in the event file.

          EuroCost

             This enables the European style of costing in which the charge for
             a "call-unit" is fixed and the time allowed for each call-unit



     BinkleyTerm 2.60 Reference Manual                       Page 50  


             varies for local, national and international calls, and also
             depends on the time of day.

             See 'CostLog <filespec>' on page 46, and 'CostUnit <number>' on
             page 46  or refer to the section on Call Costing for more
             information.

             If Eurocost is not enabled, BinkleyTerm defaults to the original US
             cost per minute tariff calculation.

          Event <event_flags...>

             NOTE!  Normally the 'Event' statement is used only in the event
             file, BINKLEY.EVT.  Events should NOT be scheduled in the
             configuration file. 

             Due to the depth of this topic, it is covered in the section "Event
             Files and Schedules"

          ExtBaudRates

             Used by the DOS version of BinkleyTerm only. Under DOS the baud
             rate cannot normally be set to exceed 38200, but a recent version
             of the X00 FOSSIL driver (ver 1.53a) supports additional baud
             rates.  This is not yet a standard so BinkleyTerm needs to be told
             to use this extension by means of the ExtBaudRates statement.
             BinkleyTerm can then support up to 115200 baud.
             Notes:
             1.   Only use this statement if your FOSSIL supports this function,
             or you will regret it!
             2.   Put this statement in your configuration file *BEFORE* any
             line that deals with baud rates.
             3.   This statement is not required in OS/2 or Win32 versions,
             which can directly support 115200 baud.

          Extern spawn

             This causes each external mail exit to be a "spawn".

             Read the comparable 'BBS spawn' description for details.
             On spawning BinkleyTerm will execute

               EXTMAIL.BAT %1 %2 %3 %4 %5 %6

             The parameters to EXTMAIL are exactly the same as the exit case, so
             you can find the "errorlevel" from the command line if you need it.

             EXTMAIL.BAT is a file that you create which can use the above
             parameters.

             Note: if you enable this option, all external mail is spawned.

          ExtrnMail [<errorlevel>] <string>

             This is used in conjunction with BinkleyTerm's external mail
             program feature. Refer to the section "External Mail Programs" for



     BinkleyTerm 2.60 Reference Manual                       Page 51  


             information. The [<errorlevel>] parameter is optional, the default
             value is 99.
             <String> is something sent by the remote system which is to trigger
             the errorlevel exit. When used for an external mail program,
             <string> should be relatively long, without too many repeating
             characters, to assure accuracy.  When used with multiple BBS
             functionality, <string> may be only one letter.

             Up to 16 'ExtrnMail' statements that each use [<errorlevel>] may be
             used.

             Note: If the Extern Spawn statement is also used then ALL external
             mail exits are spawned.

          ExtSession <mask> <ProgramName>

             Using this statement, BinkleyTerm can have "external mail
             sessions". <mask> should be a hex mask which corresponds to a
             "modem type" in the nodelist. When BinkleyTerm attempts to "call" a
             system, it will use the external mail facility if the modem type
             exactly matches the mask. BinkleyTerm will then turn off everything
             (close log files, busy the modem) and, for every file to send to
             this system (packets, non-zero length attached files), it will
             call:

              programname <full-address> <tasknumber> <filename>

             This designates the name of the response file template used for est
             response file construction.  The <filespeer is defined) and that
             filename is the full path and filename, in the same case as it
             appears in the file attach.  Binkley only calls programname for
             listed files that actually exist (not logging missing files).

             When BinkleyTerm regains control it will look for a file in the
             current directory named "programname.tasknumber". If this file
             exists it will continue the mail session; if this file does not
             exist it will interpret this as a session failure and will handle
             it like any other session failure (bad flags, etc.). When the
             session ends, one way or the other, BinkleyTerm will restart itself
             and proceed.
             Example:    Assume point 2 on the system is defined as having modem
             flag 64 (0x40).
                    (With a private list, I could do this by putting a "UGATE"
                    flag on the node, then with XLAXNODE, "MODEMTRANS 7 UGATE").
             create the file "points.bat" containing these commands:

                        echo %0 %1 %2 %3 >> points.log
                        if "%1%" == "1:343/491.2@fidonet" copy %3 m:\point2
                        if errorlevel 1 goto end
                        touch points.%2%
                        :end
             Now include the statement 'ExtSession 40 points' in the Binkley.cfg

             The result will be that all sessions with point 2 put the mail into
             m:\point2.



     BinkleyTerm 2.60 Reference Manual                       Page 52  


             Note that this mechanism is designed mostly for callout. However, 
             you can poll for mail by creating a dummy packet and "sending" it,
             and your batch file can copy files into your inbound.

          EXTSound <filename.wav>

             Play a sound on exit to an external (UUCP) mailer (OS/2 and Win32
             machines only at present)

          FaxBaud <number>

             Various fax modems behave differently with respect to baudrate
             after a fax connection. This version of BinkleyTerm will leave the
             baudrate alone by default after a fax connect but will set it to a
             user-specified rate of <number> if 'FaxBaud' is enabled.


          FaxInDir <path>

             Sets a directory for receipt of FAX. This tells BinkleyTerm to
             receive incoming Fax using its own internal Fax reception routine.
             For now we've left the code as is but expect to change to PCX
             format.

             Do NOT include this statement if you intend to use an external
             program to receive the fax.

          FaxSound <filename.wav>

             Play a sound on FAX exit (OS/2 and Win32 machines only at present)

          FileSec  <number>

             Part of the implementation of faster file searching using Maximus
             information. See page 5

          FileSound <filename.wav>

             Play a sound on E3 or user specified mail exit (OS/2 and Win32
             machines only at present)

          Flags <path>

             Specify the path and directory name to be used to hold task
             identification files created by BinkleyTerm.  The filename is
             TASK.# where # is the task number.  These files can be used to
             determine if any given BinkleyTerm task is currently running.  The
             files are created whenever BinkleyTerm has carrier present and a
             mail session is in progress.



     BinkleyTerm 2.60 Reference Manual                       Page 53  


          ForcExit <errorlevel>

             This will cause BinkleyTerm to check in the flags directory
             periodically for a file called FORCEXIT or FORCEXIT.@@ if a task
             number has been set. (@@ represents the task number in hex). When
             found BinkleyTerm will delete the file and exit with the errorlevel
             specified in the ForcExit statement.
             For further information refer to the section on Flags and semaphore
             files in this manual.  Refer also to the TaskNumber statement, and
             the use of the BTEXITxx.yy flag files.

          FTS-0001                   [Normally Used for Test Purposes Only]

             When used, this statement will force BinkleyTerm to use only base
             FidoNet protocol (FTS-0001), effectively enabling the equivalent of
             the following statements:  NoWaZOO, NoResync, NoSLO and NoSEAlink.
              Used mostly for debugging and testing of FidoNet policy
             compliance; not for regular use.

          Gong                                         [Terminal Mode Only]

             This statement is only applicable in Terminal Mode. It causes
             BinkleyTerm to sound an alarm on connecting with a system it's
             attempting to dial, or after a download has been completed.
             'Gong' also works when doing a manual mail poll operation (Alt-M)
             in Terminal Mode.

          Hold <path>

             This specifies the complete drive and path designation for the
             directory that will be used as your outbound mail holding area.
             Your mail processing software must place outbound mail in this area
             for BinkleyTerm to send to or hold for other FidoNet systems.
             It should be mentioned that this area should NOT contain any other
             files of any kind, and that the contents of the directory should
             NOT be manipulated by you unless you know EXACTLY what you're
             doing.  For all practical purposes, BinkleyTerm maintains this
             directory for you.

          Include <filespec>

             If used, this tells BinkleyTerm the name of a file to include while
             reading the configuration file.  The include file must contain
             additional configuration file statements in the same format as
             expected for the primary configuration file.  When end-of-file is
             reached, BinkleyTerm will continue reading the main configuration
             file at the line immediately following the 'Include' statement that
             initially caused BinkleyTerm to branch.
             <filespec> gives the filename  and may optionally include a drive
             and path designation.
             Note: Included files may include other files, recursively.

          Init <modem_string>

             BinkleyTerm sends the <modem_string> to the modem to  initialize
             it, and make it ready for communication.  The string is sent to the
             modem verbatim, with the exception of special dial translation



     BinkleyTerm 2.60 Reference Manual                       Page 54  


             characters.  These characters are shown in the section "Dial
             Translations."

             Refer to your modem instruction manual for help in finding a
             correct init string for your particular modem and configuration.


          JanusBaud <max_connect_rate>

             This statement is synonymous with 'BiDiBaud', q.v.


          JanusOK <extended_connect_info>

             This statement is synonymous with 'BiDiOK', q.v.


          KnownAbout <filespec>

             This tells BinkleyTerm the name of the ABOUT file, a special file
             used with incoming file requests received from "known" systems. 
             <filespec> is a complete drive, path and filename designation.

          KnownAvail <filespec>

             This designates the name of the file to be sent to a "known" remote
             system which file requests "FILES" from you.  The <filespec>
             identifies the file, and may contain an optional drive and path
             designation.

          KnownInbound <path>

             Used with secured inbound areas, this statement designates the path
             to the inbound file area used for mail received from "known"
             systems.

          KnownMaxBytes <number>

             See 'MaxBytes <number>' on page 57 for information.

          KnownMaxTime <number>

             See 'MaxTime <number>' on page 57.

          KnownReqLim <number>

             Limits the maximum number of files that will be sent to "known"
             systems in response to incoming file requests during any one mail
             session.  Regardless of whether the incoming requests has
             wildcards, or whether multiple file requests are sent in one mail
             session, the maximum number of files that will be sent is <number>.

          KnownReqList <filespec>

             This designates a file, specified with full drive, path and
             filename.ext, similar to 'Okfile <filespec>' on page 62 but which
             holds details of files available to "Known" systems.



     BinkleyTerm 2.60 Reference Manual                       Page 55  


          KnownReqTpl <filespec>

             This designates the name of the template file used to construct
             response files generated for "known" systems. The <filespec> is a
             complete drive, path and filename designation.

          KnownSec  <number>

             Optional part of the implementation of faster file searching using
             Maximus information. See page 5

          LineUpdate                          [Used for Test Purposes Only]

             Updates BinkleyTerm's log file on a line by line basis, so that if
             a system crash occurs the logged information will be as up to date
             as possible.

          LockBaud [<lock_rate>]

             The FOSSIL should NOT be locked if this option is used.

             The <lock_rate> parameter tells BinkleyTerm the baud rate at which
             locking should occur. 

             This is useful for modems that allow a floating baud rate up to a
             certain speed, then are locked at higher connect rates. Most ROM
             revisions of the USRobotics Courier V Everything allow this type of
             operation by setting the modem for &B0 which floats the baud rate
             at 2400 bps or lower.  Bit 7 (and perhaps Bit 6) of the S27
             register also need to be set appropriately. This would give
             improved interactive performance on low speed connects.
             Example: When using a Courier modem, To LOCK at 38400 and FLOAT at
             slow speeds, use the 'Baud 38400' and 'LockBaud 4800' statements in
             your configuration file, and set the modem for &B0 and S27=192.

             'LockBaud 0' (or just 'LockBaud') will lock the baud rate at
             all connect speeds. Even with a locked FOSSIL port, this may be
             used to have Binkley pass a constant rate (say 38400) as its
             parameter to the BBSbatch or ExtMail batch files.


          Lockbaud <ConnectSuffix>

             The <ConnectSuffix> is that part of the connect string from the
             modem that identifies an error-free connection.  The FOSSIL should
             NOT be locked if this option is used.

             The modem must also have the ability to set a floating/locked baud
             rate.

             See the detailed explanation in the "High speed and Error
             correcting Modem" section of the User Manual.

             If you have a modem with more than one response code which
             indicates an error-free connection, you can use multiple "LockBaud"
             lines (up to 16).



     BinkleyTerm 2.60 Reference Manual                      Page  56


          LogLevel <log_level_number>

             This tells BinkleyTerm how verbose to make the status log. 
             Acceptable values for <log_level_number> are from 1 to 5, 1
             indicating minimal information, 5 maximum information.  See
              Statuslog <filespec>
             '                    ' on page    for additional information.
                                            69

             Each log entry is preceded by a symbol or a blank, indicating the
             importance of the entry.

                 LogLevel      Symbols That Precede Included Entries
                 --------      ----------------------------------------
                      1        ! *
                      2        ! * +
                      3        ! * + :
                      4        ! * + : #
                      5        ! * + : # and blank (no character)


          Macro <number> <macro_string>                [Terminal Mode Only]

             This allows the sending of predefined macros from within Terminal
             Mode.  Macros are typically used to send your name, user ID, or
             passwords while on-line.
             The <number> parameter is a digit between 1 and 9, which
             corresponds to the F1 through F9 keys.  While in Terminal Mode, you
             send a macro by pressing Alt-Fx, x indicating the macro number you
             desire to send.
             The <macro_string> is sent verbatim.  A carriage return is
             indicated by the pipe symbol (|).  No other translations take
             place.

          MailNote <string>

             Used in conjunction with BinkleyTerm's external mail program
             feature.  When the string designated by the 'ExtrnMail' statement
             is received, <string> is sent to the caller as notification that
             the external mail program is being loaded.  Refer to the "External
             Mail Programs" section for information.

          MailSound <filename.wav>

             Play a sound on E2 mail exit (OS/2 and Win32 machines only at
             present)

          Mark_Kromm

             Installs a color set judged best in a competition
             This uses colors 112, 9, 10, 11, 14 and 12.

          MaxAreas <filespec>

             Users of MAXIMUS can implement faster searches using their
             MAXFILES.IDX for file request searches. See Page 5.



     BinkleyTerm 2.60 Reference Manual                       Page 57  


          MaxBytes <number>

             Together with the 'ProtMaxBytes' and 'KnownMaxBytes' statements,
             you can control file requests by number of bytes sent.  These three
             statements work in the same manner as the other file request
             limiting statements detailed in the documentation.

          MaxPort <quantity>

             BinkleyTerm is capable of supporting up to 32 communications ports,
             far more than any current FOSSIL driver is capable of supporting. 
             Normally the <quantity> will be 1 or 2, depending on your FOSSIL.

             Refer to the documentation for your FOSSIL for information about
             the number of ports it is capable of supporting.  For Unattended
             Mode, the port number in use is set by the 'Port' statement.  In
             Terminal mode, you may change the port in use (dependent on the
             number of ports your FOSSIL can support and the hardware you have
             available).

          MaxReq <quantity>

             Limits the number of files that will be sent during one mail
             session in response to an incoming file request. Regardless of
             whether the incoming requests has wildcards, or whether multiple
             file requests are sent in one mail session, the maximum number of
             files that will be sent, including any response file, is <number>.

          MaxTime <number>

             Specifies the maximum time in minutes allowed for this file request
             session.  This statement can be used in combination with the file
             request size limiters (MaxBytes, KnownMaxBytes, ProtMaxBytes) as
             well as the file request quantity limiters (MaxReq, KnownMaxReq,
             ProtMaxReq).



          The next 7 statements allow users to create their own Modem
          Response Array. If  none of these 7 statements is used then
          BinkleyTerm will use the original hardcoded defaults.

          ** Note that if *any* of these statements are used then the user
          must create a complete array of all the Modem Response strings he
          needs to use by means of multiple statement lines. Ordering of
          the statements is very important as the first correct prefix
          match is taken.

          Be sure there are no trailing spaces or invisible characters in
          any of these strings.

          As a guide to producing your own array, the order of the
          statements in BINKLEY.CFG, and the modem response strings which
          would produce the defaults are:

             ModemIgnore RINGING
             ModemIgnore RING RESPONSE



     BinkleyTerm 2.60 Reference Manual                       Page 58  


             ModemRinging RING
             ModemConnect CONNECT
             ModemIgnore RRING
             ModemRetry BUSY
             ModemFailure VOICE
             ModemFailure ERROR
             ModemFailure OK
             ModemFailure NO CARRIER
             ModemIncoming NO DIAL
             ModemIgnore DIALING
             ModemFailure NO ANSWER
             ModemIgnore DIAL TONE
             ModemFax +FCO

          ModemConnect <modem response>

             Put in <modem response> any prefix (such as Connect) issued by your
             modem and which you wish BinkleyTerm to regard as a CONNECT
             instruction. The remainder of the modem response string is then
             parsed to determine connection speed etc..

          ModemFailure <modem response string>

             Put in <modem response> any string returned by the modem which you
             wish BinkleyTerm to regard as a failure to connect when dialling
             out.

          ModemFax <modem response>

             Put in <modem response> any string returned by the modem that you
             wish to identify as an incoming Fax connect.

          ModemIgnore <modem response string>

             Put in <modem response> any string returned by the modem that
             BinkleyTerm should ignore.

          ModemIncoming <modem response string>

             Put in <modem response> any string returned by the modem which the
             outdialer should interpret as a collision with an incoming call

          ModemRetry <modem response>

             This is a special statement to be used with the AltNumber
             statement. It could also be used (with caution) in place of other
             Modemxxxx statements.

          ModemRinging <modem response>

             Put in <modem response> any string returned by the modem which
             identifies an incoming ring. Don't add the Caller-ID or equivalent
             lines -- only those which identify an incoming ring. Usually RING
             is all that should be defined.



     BinkleyTerm 2.60 Reference Manual                      Page  59


          ModemTrans <number> [<prefix>]/[<suffix>]

             This instructs BinkleyTerm to dynamically select the modem prefix
             and suffix strings based on the modem type field found in the
             nodelist, or in a NODELIST.EXT file (see the section "Nodelist" in
             the User's Manual).
             The [<prefix>]/[<suffix>] have the same purpose and usage as they
             do in conjunction with the 'Dial' statement described previously. 
             Refer to that statement for more information.
             The value of <number> corresponds to a given modem type.  If this
             type is matched, then the given <prefix>/[<suffix>] values are
             used.  Possible values currently are:

                     <number>          Nodelist Modem Flag Set
                     --------          -------------------------
                     1                 HST
                     2                 PEP
                     3                 Either HST or PEP
                     4                 Not Currently Used by BinkleyTerm

             BinkleyTerm matches modem types exactly rather than using a bitwise
             AND as in version 2.50. This allows lots more modem types, but if
             you were using this feature with BinkleyTerm 2.50 or below, you
             must change your nodelist generation and configuration stuff.

             Callout to nodes with a particular modem type can be disabled. This
             is achieved using 'ModemTrans <number>' with no prefix or suffix.
             This allows sharing BinkleyTerm between lines with particular modem
             types.

          MultiLink

             Used by the DOS version of BinkleyTerm only. Include this if the
             MultiLink multi-tasker is installed, to release time-slice to the
             multi-tasker during certain non-processor-intensive operations. 
             This increases efficiency for systems using MultiLink.

                         The next four statements are all needed
                         in order to enable EMSI (See note about
                         EMSI on page 38)

          MyListFlags

             Nodelist flags in nodelist format for EMSI

          MyLocation

             Defines your location in nodelist format for EMSI

          MyMaxBaud

             Max baud rate in nodelist format for EMSI

          MyPhone

             Give your phone number in nodelist format



     BinkleyTerm 2.60 Reference Manual                       Page 60  


          NetFile <path>

             This specifies the complete drive and path of the directory that
             will hold files being sent to your system via FidoNet.  Incoming
             mail is stored here prior to processing.

             If secured inbound areas are being used (see "Secured Inbound File
             Areas" on page 2), then this statement designates the inbound file
             path for mail received from systems not in the nodelist and not
             password protected.

          NetMail <path>

             This specifies the complete drive and path of the directory where
             your netmail will be placed.

             BinkleyTerm will now scan a Squish style netmail message base to
             see if there is any unread netmail pending.  To specify a Squish
             style netmail area, you must prefix the path with a "$" and add the
             name of the message base (no extension).  The message will remain
             until all mail is moved out of the netmail directory.
             Example:

                    Netmail $C:\Bink\Netmail

             The 'NetMail' statement was originally used by BTCTL to build a
             MAIL.SYS file produced for the benefit of certain older mail
             processing utilities. BTCTL is not now supplied  but if needed it
             can be found in archives of older BinkleyTerm Versions.

          NewNodeList                          [This Statement is Obsolete]

             An older way of telling BinkleyTerm to use a Version 6 nodelist.
             Use the Version6 statement (q.v.), if using V6.

          NoCollide

             By default, if an incoming call is detected while preparing to make
             an outgoing call outgoing call will be aborted.  This feature is
             called "call collision detection," and may not work on all modems.
              Using 'NoCollide' disables this feature entirely.

          Nodelist <path>

             This specifies the complete drive and path where processed,
             compiled nodelist files can be found.

          NoDietIfna                          [Used for Test Purposes Only]

             Do not allow the DietIFNA handshake method for mail sessions.

          NoEMSI

             disables EMSI (see the note about EMSI on page38)



     BinkleyTerm 2.60 Reference Manual                       Page 61  


          NoFilter <ConnectSuffix>

             Defines connect suffixes for which MNP filter can be disabled.
             'NoFilter /Arq' will disable filtering for any "Connect xxxxx/arq".
             Up to 16 of these suffixes can be defined, one per line. If you
             have a lot of strings starting with /ARQ, you only need the one
             /ARQ line.
             Without NoFilter /Arq, Binkley makes no assumptions about what YOUR
             modem can do.  It therefore watches the incoming data stream to see
             if your modem is passing through protocol negotiation things that
             it (the modem) doesn't handle, and filters them out.  This can make
             a connection start slower. If your modem can negotiate with the
             other modem and settle on a protocol (it doesn't have to be ARQ)
             without letting any of that stuff leak through then this is a waste
             of time and effort.  NoFilter lets you specify connect strings that
             guarantee that no stuff leaked through, so Binkley can expect "real
             data" right from the start.."

          NoFullScreen

             By default, a full-screen interface is used when in Unattended
             Mode.  When this statement is used,  the line-by-line screen write
             mode employed by BinkleyTerm Version 1.10 and earlier will be used.
              This statement has no effect in Terminal Mode.

          NoHydra

             Explicitly disables Hydra protocol

          NoJanus

             explicitly disables Janus protocol

          NoPickup

             During mail sessions, deliver mail, but do not pickup any mail that
             may be waiting for your system.

          NoRequests

             Refuse incoming file requests at all times.

          NoResync                            [Used for Test Purposes Only]

             Do not allow SEAlink Resync (an ability to restart failed SEAlink
             mail sessions).

          NoSEAlink                           [Used for Test Purposes Only]

             Do not allow SEAlink mail sessions at all, including SEAlink
             extensions to base FidoNet protocol (FTS-0007) and WaZOO/DietIFNA
             sessions.

          NoSharing

             Disables file sharing calls in networked environments.



     BinkleyTerm 2.60 Reference Manual                       Page 62  


          NoSize

             Disables the calculation and display of queued file sizes for the
             pending outbound window display.  If you see a big performance
             problem associated with the queued file size display, try adding
             this statement. When in force, the "Q=nnn" schedule flag is also
             disabled.

          NoSLO                               [Used for Test Purposes Only]

             Do NOT employ SEAlink "Overdrive" (an ACK-less variety of the
             SEAlink protocol) for any SEAlink network mail transfers.

          NoWaZOO                             [Used for Test Purposes Only]

             NOTE:  Not for normal use, performance with other WaZOO-capable
             mailers (BinkleyTerm, Opus, D'Bridge, FrontDoor, etc.) may be
             adversely affected.
             Forces BinkleyTerm to be strictly a EMSI or  FTS-0001 mailer by
             disabling WaZOO functionality.

          NoZedZap                            [Used for Test Purposes Only]

             Do not allow ZedZap (Zmodem) transfers during a WaZOO session.  It
             is primarily intended to force BinkleyTerm to use DietIFNA mode
             (SEAlink) during WaZOO sessions.

          NoZones                             [Used for Test Purposes Only]

             Tells BinkleyTerm to handle zones in the same manner as version
             1.50 and previous versions.  This essentially means that multi-zone
             support is turned off.

          Okfile <filespec>

             This designates the name of the OKFILE, a special file used with
             incoming file requests.  <filespec> is a complete drive, path and
             filename designation. See the File Request section of this manual.

          Overwrite

             Allow existing files to be overwritten when receiving a file in
             Unattended Mode, or when  downloading a file in Terminal Mode. Use
             with care. BinkleyTerm by default will NOT allow overwriting of an
             existing file if you're receiving a file with the same name. 
             Instead,  the name of the file being received will be slightly
             altered to differentiate it from the existing file.

          Packer <command_line>

             If used, <command_line> will be executed at the beginning of each
             event, but after the "Cleanup" statement's command line (if used).
              This might be used to pack any pending outbound mail for sending.
              It is suggested that <command_line> designate a batch file that
             would contain the command line(s) for the program(s) actually used
             to scan and/or pack mail.



     BinkleyTerm 2.60 Reference Manual                       Page 63  


             See 'AfterMail <command_line>' on page 40 and 'Cleanup
             <command_line>' on page 45 for related information.

          PickUpAll

             When a connection has been made using EMSI this enables the pick up
             of mail for all your system addresses (or akas) that match the
             domains/zones of the other system, in the one call.

          PktRsp

             Build and send a packet back instead of an .RSP file. Note that you
             must have a flags directory for this feature to operate, as the
             flags directory is the "staging area" for the packet as it is being
             built. See the "Request Response File" section.

          Point <net>/<node>                   [This Statement is Obsolete]

             NOTE:  This statement is supported for backward compatibility only.
              To specify a system address, use the 'Address' statement described
             previously.
             This statement specifies a FidoNet node address.  For regular
             FidoNet nodes, this is your assigned node address.  For Point
             systems, this address is the one assigned to you by your Boss node
             Sysop.

          PollTries <number>

             This controls how many call attempts will be made when calling a
             system using:
             Alt-D keypress in Terminal Mode,  or,
             A command line invocation of BinkleyTerm using the keyword "POLL"

          Port <port_number>

             Indicates which communications port your modem is connected to or
             configured as.  The <port_number> corresponds to the COMM. port
             number, 1 for COM1, 2 for COM2, etc.  Most FOSSIL drivers support
             COM1 and COM2, some support more.  Refer to your FOSSIL
             documentation for information on port support and installation
             information.   Note that in Terminal Mode, it is possible to
             temporarily override this setting (it will revert when you exit
             terminal mode).

          PreDial <modem_string>

             This statement will override BinkleyTerm's default predial string
             which is:
                         v``^`````
             The <modem_string> designates a string, which will have standard
             modem translations performed upon it, that is to be sent to the
             modem BEFORE the dial string (designated by the 'Prefix' statement,
             or the prefix part of a ModemTrans statement, if used) is sent.
             Some modems give responses when DTR is lowered, and others require
             an extended period of time to resync.  By using 'PreDial', you can
             provide an outward dialing situation better suited to your modem. 
             In testing, a single backquote (`) has been used with the USR HST



     BinkleyTerm 2.60 Reference Manual                       Page 64  


             high speed modem to provide extremely fast outward dialing
             responsiveness.

          Prefix <modem_string>

             The <modem_string> is a modem command to cause the modem to dial. 
             To dial a system, BinkleyTerm sends the <modem_string>, followed by
             the telephone number, to the modem.  Normally, for touch-tone
             systems, "ATDT," is used. For pulse dial exchanges (usually older,
             rotary-dial lines), "ATDP," would be used.
             Refer to your modem manual for more information on control options.

          PreInit <modem_string>

             BinkleyTerm has a default 'PreInit' string of:
                         |v~^````` |`````
             In the PreInit statement, <modem_string> designates a string, which
             will have standard modem translations performed upon it, that is to
             be sent to the modem BEFORE the modem initialization string
             (designated by the 'Init' statement) is sent.
             The default string is optimized to be suitable for a wide variety
             of modems.  However, many modems may be able to work with a shorter
             string, which would yield faster modem initialization sequences. 
             In testing, this 'PreInit' string has proven fast and effective:
                         |v``^``
             Note that 1/2 second is still added at the end of the 'PreInit'
             string for timing purposes, and therefore, 1/2 second is the
             fastest initialization that could be realized by using your own
             'PreInit' setting.

          PrivateNet <fakenet>

             This tells BinkleyTerm the net number of a private network for
             which you serve as a gateway, if any.  This statement is also used
             by Point systems to designate their private net number.

          ProtAbout <filespec>

             Defines the special file used with incoming file requests that are
             received from "protected" systems.  The <filespec> is a complete
             drive, path and filename designation.

          ProtAvail <filespec>

             This designates the name of the file to be sent to a "protected"
             remote system which file requests "FILES" from you.  The <filespec>
             identifies the file, and may contain an optional drive and path
             designation.

          ProtInbound <path>

             Used with secured inbound areas, this statement designates the path
             to the inbound file area used for mail received from "protected"
             systems.



     BinkleyTerm 2.60 Reference Manual                       Page 65  


          ProtMaxBytes <number>

             See 'MaxBytes <number>' on page 57 for information.

          ProtMaxTime <number>

             See 'MaxTime <number>' on page 57 .

          Protocol <filespec>                          [Terminal Mode Only]

             Enables the use of an external file transfer protocol.  The
             <filespec> is a complete drive, path and filename that points to an
             Opus-CBCS compatible external file transfer protocol program. 
             Refer to the User's Manual section "External Protocols" for more
             information.
             Note that the first letter of <filespec> will be the letter used to
             access the protocol from the upload and download menus in Terminal
             Mode.  Because the first letter of the filename may conflict with
             another external protocol, or with a hard- coded protocol, you may
             need to rename the executable file for the external protocol to
             begin with a letter that is not currently in use.
             Note also that external protocols are available in Terminal Mode
             ONLY - they cannot be used for mail session in Unattended Mode!

          ProtReqLim <number>

             Limits the number of files that will be sent during one mail
             session in response to an incoming file request received from a
             "protected" system. Regardless of whether the incoming requests has
             wildcards, or whether multiple file requests are sent in one mail
             session, the maximum number of files that will be sent is <number>.
             If a response file is to be sent this will be included in the file
             count.

          ProtReqList <filespec>

             This designates a file, specified with full drive, path and
             filename.ext, similar to 'Okfile <filespec>' on page 62 but which
             holds details of files available to "protected" systems.

          ProtReqTpl <filespec>

             This designates the name of the template file used to construct
             response files generated for "protected" systems. The <filespec> is
             a complete drive, path and filename designation.

          ProtSec <number>

             Sets the protection level applicable to systems which are
             "protected"
             Optional part of the implementation of faster file searching. See
             Page 5.

          QuickNodeList                        [This Statement is Obsolete]

             This tells BinkleyTerm to use a QuickBBS 2.0x nodelist.  This
             nodelist must not be produced by QuickBBS' Qnode program, as it



     BinkleyTerm 2.60 Reference Manual                       Page 66  


             WILL NOT work correctly for BinkleyTerm as of this writing.  A
             current version of ParseLst is the recommended nodelist processor
             for use with BinkleyTerm, however, other nodelist processors may be
             able to produce a QuickBBS nodelist of the required format.  Refer
             to the User's Manual section "Nodelist" for more information.
             Note: The above support is not compiled into BinkleyTerm by
             default, you will have to recompile the source code to use it.

          Reader <command_line>

             Using the Alt-E command in Unattended Mode causes <command_line> to
             be sent to COMMAND.COM for execution as a child process.  This is
             typically used to invoke your local console message base
             reader/editor.

          RecentActivityLines <number>

             Used to define the total number of lines you wish to have
             scrollable in the Recent Activity window. Use with care under DOS
             due to the amount of memory this will use. See further description
             under heading of Recent Activity Window.

          ReqOnUs

             When this statement is used, incoming file requests will be filled,
             even if your system initiated the call.  Otherwise, incoming
             requests "on your dime" will be refused.

          ReqTemplate <filespec>

             This designates the name of the response file template used for
             request response file construction.  The <filespec> is a complete
             drive, path and filename designation.

          Rev3               [Obsolete and was used for Test Purposes Only]

             Used by the DOS version of BinkleyTerm only. In normal use, the
             revision level of the FOSSIL driver you use is determined
             automatically.  Using 'Rev3' forces the assumption that a revision
             3 FOSSIL is installed., this was only used on systems which were
             using developmental FOSSIL drivers that did not yet fully support a
             higher revision.

          RingTries <number>

             Limits the <number> of unanswered rings allowed before hanging up
             on an outbound call.  Your modem must be able to identify and
             report "RINGING" for this feature to work. default is 4.

             Note: many modern modems can return a number of other responses
             before the "CONNECT" response; Binkley will count  these unknown
             responses as if they were "RINGING" responses, and thus on the 4th
             response (which may be the "CONNECT"), Binkley will hang up,
             reporting "No Answer".  For these modems, setting RingTries to a
             higher value, say 7, will be necessary.



     BinkleyTerm 2.60 Reference Manual                       Page 67  


          RingWait <number>

             Causes the program to wait <number> rings before answering. Default
             is 1 ring.
             This can be used to get caller-ID information into the log. Most
             Caller-ID systems will work with RingWait 2

          SameRing

             'SameRing' is used when your modem reports "RING" on BOTH incoming
             and outgoing calls (most modems reports "RING" on incoming and
             "RINGING" on outgoing), and partially disables call collision
             detection (see NoCollide).

          ScreenBlank [<method>]

             If 'ScreenBlank' is used, and 10 minutes pass without any activity
             (incoming call, outgoing call), then the screen will be blanked. 
             The screen will remain blanked until the user presses the space
             bar.  Once the space bar is pressed, the next time BinkleyTerm
             writes to the screen, the screen will be reactivated.
             The optional <method> parameter may be "Key" or "Call". "Key" tells
             it to unblank upon a keypress (and is the default); "Call" tells it
             to unblank when a call comes in or is placed.

             'ScreenBlank' works only if a Video Fossil is installed. See page
             83
             Also see 'BlankWait <number>' on page 43.

          ScriptPath <path>

             Where BinkleyTerm should look for outward dialing scripts (refer to
             the section "Scripts" for more information).  <path> is a standard
             DOS path line, with optional drive designation.

          Serial <number>

             By default BinkleyTerm identifies itself as "UNREGISTERED".

             You can include the 'Serial' statement, with a number of your
             choice, and the "UNREGISTERED" notices will disappear. This is OK
             with the authors as long as you are complying with LICENSE.260
             (which basically says that unless you're a pretty seriously
             commercial situation, you are licensed free of charge).

             The number should NOT include any punctuation characters.

          Server

             NOTE:  This statement is not for general use.
             Instructs BinkleyTerm to assume that a connection has been made
             immediately upon startup. BinkleyTerm will act as if carrier detect
             is always high.
             This is useful when establishing a null modem session between two
             copies of BinkleyTerm.



     BinkleyTerm 2.60 Reference Manual                       Page 68  


          Shell <number> <command_line>

             This allows you configure up to 9 keystroke accessible Command
             Shells to run programs while BinkleyTerm stays memory resident. 
             Shells work only in Unattended Mode.  While in Terminal Mode, the
             same keystrokes work as macros keys (see 'Macro <number>
             <macro_string>' on page 56 for information).
             The <number> parameter is a digit between 1 and 9, which
             corresponds to the F1 through F9 keys.  While in Unattended Mode,
             you invoke a shell by pressing Alt-Fx, x indicating the shell
             number you wish to invoke.
             The <command_line> is sent to COMMAND.COM verbatim for execution. 
             If the program you're invoking uses command line parameters,
             include them in <command_line> as you would at the DOS prompt.

          SlowModem

             Using 'SlowModem' causes the insertion of a 1/10th second delay
             between each character sent to the modem while in command mode. 
             This is for use with modems that may otherwise have a hard time
             keeping up with BinkleyTerm's modem commands. Most modern modems
             have no need for this option.

          SmallWindow

             During mail transfers that use the SEAlink protocol, a default run
             ahead, in blocks, of the baud rate divided by 400 is used. This
             statement will limit the run ahead no more than 6 blocks.  This
             option is used primarily with high speed modems.

          Snoop

             For OS/2 use only. This is used in conjunction with a program
             called PMSNOOP. You can then run BinkleyTerm minimized and monitor
             its activity/progress in Snoop's PM desktop window. 
             To use, include the snoop statement with a pipe name, for example:
                    Snoop   \pipe\line1
             Run PMSNOOP with the same pipe name.
             (SNSERVER.DLL  is also required but is usually provided with
             PMSNOOP)
             If you use Maximus then both BinkleyTerm and Maximus (V2.xx) can
             use the same pipename and display to the same PMSNOOP window. Note:
             this support is not built into BinkleyTerm 2.60 by default. You can
             use the supplied source code and appropriate makefile to compile a
             snoop-enabled executable.  Addenda: a compiled version of BT32.EXE
             with snoop support is now available under the filename BOS2S260.ZIP
             and can be found on  Bob Juge's BBS and also on his FTP site.

          StartBlkLen <number>

             Allows adjustment of the starting Zmodem session block size. The
             start value can be set in the range 64 bytes to 2048 bytes. 
             Communications on noisy lines often benefit from use of a smaller
             initial block size.



     BinkleyTerm 2.60 Reference Manual                       Page 69  


          StartSound <filename.wav>

             Play a sound at start of Unattended mode (OS/2 and Win32 machines
             only at present)

          Statuslog <filespec>

             Gives the location and name of the log file. The <filespec> is a
             complete drive, path and filename. See 'LogLevel
             <log_level_number>' on page 56 which shows what information will be
             recorded.

          Suffix <modem_string>

             NOTE:  Unlike some communications packages such as Telix, normally
             you DO NOT need a 'Suffix' with BinkleyTerm.
             BinkleyTerm will send the 'Prefix' string, followed by the phone
             number, followed by a carriage return to the modem for the purpose
             of dialing a number.
             If for some reason you need to put characters immediately after the
             phone number BUT PRIOR TO THE RETURN CODE, use the 'Suffix' field.

          SwapDir <path>

             Used by the DOS version of BinkleyTerm only. This will enable
             "memory swapping." The <path> designated will be used for storage
             of a swapfile when spawning subtasks, such as jumping to DOS or
             invoking a packer. BinkleyTerm will swap itself out of memory
             except for about 5k to 8k of code.  If <path> points to a RAM disk
             (you will need about 384k of space available), BinkleyTerm exits
             and reloads very quickly.  The <path> parameter may designate a
             directory path, or both drive and directory path.
             Note: If sufficient XMS (extended) or EMS (Expanded) memory is
             available to BinkleyTerm, it will use that for it's swap file. This
             is faster even than using a ramdisk.

          Sysop <sysop_name>

             The WaZOO method of mail transfer (originally designed by Wynn
             Wagner for Opus-CBCS, and supported by BinkleyTerm) and the EMSI
             method, designed by Joaquim Homrighausen, send a variety of
             information during session negotiation.  Among the information is
             the Sysop name, normally your name.  This information is not passed
             during an FTS-0001 mail session, and is not used in Terminal Mode.

          System <system_name>

             Sends the system name, normally whatever name you have given to
             your BBS or Point system, during WaZOO or EMSI session negotiation.

          TaskNumber <number>

             See the "Flag Files and Semaphore" section for details.



     BinkleyTerm 2.60 Reference Manual                       Page 70  


          TaskView

             Used by the DOS version of BinkleyTerm only. Indicates that the
             TaskView multi- tasker is installed, so that processor time-slices
             will be given up when the system is idle and while certain
             functions are being performed.  This increases system efficiency.

          TBBSList                             [This Statement is Obsolete]

             This tells BinkleyTerm to expect and use a TBBS style nodelist.  To
             fully utilize this option, you must create the nodelist files with
             ParseLst 1.01 (or above), making sure that the proper adjunct
             nodelist files are available in addition to NODELIST.DOG.
             Note: The above support is not compiled into BinkleyTerm by
             default, you will have to recompile the source code to use it.

          TermInit  <modem_string>

             Identical in structure to the 'Init' statement, this statement
             provides a modem initialization string for use in Terminal Mode. 
             The string will be sent to the modem if BinkleyTerm is initialized
             in Terminal Mode, or when switched to Terminal Mode from Unattended
             Mode.  The string will also be sent when an Alt-I command is issued
             in Terminal Mode. 
             NOTE:  Even if the 'PreInit' statement has been enabled it will NOT
             be used in conjunction with this initialization string.

          Timeout <seconds>

             Wait this length of time for a caller to press Escape or for a mail
             session to begin before assuming that the incoming call is for your
             BBS.  The default value is 20 seconds.  Note that <seconds> cannot
             be set lower than 20.

          TopView

             Used by the DOS version of BinkleyTerm only. Indicates that the
             TopView multi-tasker is installed, and that processor time-slices
             should be given up when the system is idle and while certain
             functions are being performed.  This increases system efficiency.

          Unattended

             By default, BinkleyTerm is in Terminal Mode when invoked.  When
             this statement is used, the program will be in Unattended Mode when
             invoked from DOS.  This option should be used on systems where
             BinkleyTerm's primary purpose is as a FidoNet mail interface.

          Version6                          [This Statement is Obsolescent]

             NOTE:  This statement is not recommended for new users. The full
             nodelist's NODELIST.IDX file is now too large for BinkleyTerm to
             load, so nodes near the end of the list will not be found.
             If a Version 6 nodelist is used, BinkleyTerm will expect to find
             the files NODELIST.IDX and NODELIST.DAT compiled and ready for use.



     BinkleyTerm 2.60 Reference Manual                       Page 71  


          Version7

             Enables support for the Version 7 compiled nodelist format. This
             format offers a 40% savings in file size compared to the older
             Version 6 format
             Make sure your nodelist compiler can handle Version 7 and be aware
             that the files needed are named NODEX.DAT and NODEX.NDX. The "sysop
             name lookup" feature in Version7 uses the SYSOP.NDX file, not
             FIDOUSER.LST as in Version6.


          WinFossil

             If you have installed Bryan Woodruff's WinFOSSIL program, this
             statement will cause the Win32 version of BinkleyTerm to use it and
             so be able to pass a com port handle to a DOS application.

             If WinFOSSIL is not used, BinkleyTerm/Win32 uses NT or Windows95
             communications which do not make provision for passing the port
             handle.

          WinSlice

             Used by the DOS version of BinkleyTerm only. Use Windows' timeslice
             rather than the MSDOS (int 28) timeslice.

             When using BinkleyTerm with Windows 95 The WinFOSSIL program is
             often used. (You can use BinkleyTerm/32 to frontend a Dos based
             Bulletin board on Windows 95 using WINFOSSIL 1.10 or above and the
             WinFOSSIL command. Contact Bryan Woodruff at 1:343/294 for details)

             Under MS Windows 3.1 a comm driver replacement is usually required.
             Try WFXCOMM (free from Delrina) used with CHCOMB which is a buffer
             (virtual com port) replacement. There are also two commercial
             programs, Turbocom and Kingcom which do the job of both the above
             programs.

             If you are using Workgroups for Windows 3.11 then no additional
             Comm programs are necessary, since its standard communications
             driver works well.



          Zone <zone_number>                   [This Statement is Obsolete]

             NOTE:  This statement is supported for backward compatibility only.
             Use the 'Address [<zone>:]<net>/<node>[.<point>][@<domain>]'
             statement discussed on page 39 to designate a zone.

                          EVENT FILES AND SCHEDULING EVENTS

             It is essential that there is an event file in your system. Without
             it BinkleyTerm will just sit and wait for ever!



     BinkleyTerm 2.60 Reference Manual                       Page 72  


             The purpose of an event file is to tell BinkleyTerm precisely when
             and how it should operate, for example:
                    .    to make calls
                    .    to allow housekeeping
                    .    to ensure that Zone Mail Hour is observed
                    .    to allow access to BBS users (if you have a BBS system)
                         at certain times but exclude them at other times (such
                         as ZMH)
                    .    to restrict long distance calls to times when they are
                         cheap
                    .    to send high priority mail as quickly as possible

             Moreover, you can do all this on a presettable minute by minute,
             daily, weekly or monthly basis .
             Many other options are possible as explained below.

     EVENT FILE FORMAT

             Although events may be placed in the configuration file, they
             should be contained in a special file named BINKLEY.EVT.  In this
             way, small changes to the configuration file will not cause
             BinkleyTerm to re-run the current event; this will only happen if
             the BINKLEY.EVT file is edited.

             By storing event schedules in a flat text file, events can be
             easily edited at any time with a standard ASCII text editor.  No
             special utilities are required.

             Note that each time an edit is made to BINKLEY.EVT (or to the
             configuration file if events are listed there), the files
             BINKLEY.SCD and BINKLEY.DAY should be deleted at a time when
             BinkleyTerm is not running. When restarted, BinkleyTerm will re-
             build its binary schedule file, which will in turn cause
             BinkleyTerm to re-run the current event. This is normal operation,
             and is necessary to allow BinkleyTerm to properly register the
             schedule changes.

             Note: To avoid all Forced events (such as daily maintenance, or
             scheduled polls) being rerun when BinkleyTerm restarts,  after
             deleting BINKLEY.SCD as above, you should restart Binkley with the
             NOFORCE command line parameter, then exit and restart it as usual.
             This procedure will prevent the rerunning of all such Forced
             events.

             Each event is on a separate line in the BINKLEY.EVT or
             configuration file. Here is a sample of such a line:

             Event All 03:00 04:00 L=10 N B E1=10 E2=20 E3=30



     BinkleyTerm 2.60 Reference Manual                       Page 73  


     PARAMETERS AND FLAGS FOR EVENT FILES

             The syntax for the entries is:

             Event <day> <start> [<stop>] [<string>] <flags/options>

             Details of these parameters are as follows:

          <day>

             This tells BinkleyTerm which days this event line applies to. This
             is a REQUIRED parameter.  Options are:

                   All      Every day of the week
                   Week.    Weekdays, Monday through Friday only
                   WkEnd    Weekends, Saturday and Sunday only
                   Sun      Sunday only
                   Mon      Monday only
                   Tue      Tuesday only
                   Wed      Wednesday only
                   Thu      Thursday only
                   Fri      Friday only
                   Sat      Saturday only

             Several <day> parameters can be linked with the pipe character (|)
             to indicate more than one option.  For example, "Mon|Wed|Fri" would
             indicate that the event applies to Monday, Wednesday and Friday
             only.  No spaces may be used between the parameters.

          <start>

             This tells BinkleyTerm what time to start the event, in 24 hour
             "military" time, in the format hh:mm, where hh is the hour and mm
             is the minute.  Note that <start> must NOT be greater than <stop>,
             i.e., events may NOT stretch through the midnight hour.  The
             <start> parameter is REQUIRED.

             The <start> parameter may optionally take date information as well.
              Allowable additional information is the month in numeric form (1
             for January, 2 for February and so on, ending with 12 for December)
             and a day of the month.  This additional information is used IN
             ADDITION to the <day> parameter previously described.  A field that
             includes date information would be in the format:

             hh:mm,month,day

             Where hh is the hour, mm is the minute, month is the numeric month,
             and day is the day of the month.  You may also leave out the day
             parameter, like this:

             hh:mm,month

             If you wish to leave out a month parameter, simply place a zero
             into that field, indicating that the event is to take place on all
             months, like this:
             hh:mm,0,day



     BinkleyTerm 2.60 Reference Manual                       Page 74  



             Using the date options with the <start> parameter offers
             significant scheduling power.  For example, if you wanted something
             to occur on the second Friday of each month, you can do so without
             a lot of manipulation by creating seven events with the same
             errorlevel, each corresponding the possible date values for the
             second Friday of each month, like this:

                    Fri 23:00,0,8  23:00 F E1=131
                    Fri 23:00,0,9  23:00 F E1=131
                    Fri 23:00,0,10 23:00 F E1=131
                    Fri 23:00,0,11 23:00 F E1=131
                    Fri 23:00,0,12 23:00 F E1=131
                    Fri 23:00,0,13 23:00 F E1=131
                    Fri 23:00,0,14 23:00 F E1=131

             In any given month, the event required on the second Friday of the
             month would cause an errorlevel 131 exit (which has been previously
             associated in your batch file with the function you wish to occur).
             If you wanted something to happen every leap year, you could create
             an event to cause an errorlevel 132 exit on February 29, like this:

             All 23:15,2,29 23:15 F E1=132

             Note that if you want a specific exit on a specific date regardless
             of the day-of-the-week, you should use "All" for the <day>
             parameter for that event.

          [<stop>]

             This tells BinkleyTerm what time to stop the event.  This parameter
             is OPTIONAL, and defaults to 60 minutes after the start time should
             the parameter be omitted.  This is given in the same format the
             <start> parameter, as military time, hh:mm where hh is the hour and
             mm is the minute.

          [<string>]

             This parameter is OPTIONAL.  If used, <string> designates a string
             of characters to be added to the command line of the configuration
             file parameters 'Packer,' 'AfterMail' and 'CleanUp.' The string
             should be enclosed in quotation marks.  For example:

                         Event All 00:00 01:00 "-sA -c"

             The <string> is appended to the command lines given for these
             options in the configuration file, and should be ignored by those
             that do not need it.  It is suggested that batch files be used with
             the above mentioned configuration file options, and that the batch
             file(s) filter out unneeded information given in <string> before
             calling a program that might "cough" because the command line is
             wrong.
             Up to 32 extra characters can be added with the <string> parameter.



     BinkleyTerm 2.60 Reference Manual                      Page  75


          <flags/options>

             These provide information about the event.  The various flags and
             options should be separated by a space.

               Flag  Description
               ---   --------------------
               $     This flag causes all bad-call files in the outbound areas
                     to be deleted.
               A=    Controls the idle time between outgoing call attempts.
                     The format is "A=x" where x is the number of seconds
                     desired, which can be a number between 0 and 1800 (1800
                     seconds = 30 minutes).
                     The average wait between calls is based on +/- 50% of the
                     number specified, i.e., A=60 would yield a wait time in
                     the range of 30 to 90 seconds, 60 being the average.
                     Should the A= parameter not be used, the default value is
                     120, for an average wait time of between 60 and 180
                     seconds.
                     This flag does NOT operate when a forced (Alt-M) poll is
                     made. In that case repeated calls are made until a
                     connection is established.
               B     Indicates that BBS operation is allowed during this
                     event.  If this flag is NOT present, callers will be
                     greeted with the message "Processing mail. Please hang
                     up." Use this option at all times (if you run a BBS)
                     except during mail schedules, such as Zone Mail Hour.
               C     Means call out during this event only if there is  mail
                     marked as Continuous Mail. The call is still subject to
                     any other restraints such as cost.
               D     Indicates that the event is dynamic. Dynamic events
                     continue until there is no longer any mail of the
                     specified type to be sent.  For example, if the dynamic
                     event specifies that local Continuous Mail is to be sent,
                     the event will continue until there is no more local
                     Continuous Mail to be sent, or until the event ends,
                     whichever happens first.  When the dynamic  event ends,
                     the non-dynamic event scheduled for the same time slot
                     will take over.  If no such event exists, the system will
                     accept mail, but will dial out to no one.  Note that
                     dynamic events must be started before or at the same time
                     as non-dynamic events, if the dynamic event is to overlap
                     a non-dynamic one.
                           Notes on Event exits E2, E3, E4-9, and
                         AfterMail:
                           The order of exit precedence is as follows:
                                 E3, E4-E9, E2, AfterMail.
                           Where more than one E4-E9 exit applies, the
                         lowest one is taken.
                         If the ErrLevelShell statement is enabled then
                         each of the shells which apply will be taken,
                         one after the other. If any E4-E9 exits also
                         apply, the one with the highest priority will
                         be taken after the shells.



     BinkleyTerm 2.60 Reference Manual                      Page  76


               Flag  Description
               ---   --------------------
               E1=   Causes an exit with the given errorlevel at the beginning
                     of the event.  'E1=10' would cause an exit to the start-
                     up batch file with errorlevel 10 when the event begins. 
                     This is a good method of executing functions once daily,
                     for example, message base maintenance software, and so
                     on.  Once the E1= exit has been made, it will not occur
                     again until the next time the event is scheduled.
               E2=   Causes an exit with the given errorlevel after mail is
                     received.  The E2= exit is only executed if the incoming
                     mail does not meet the criteria for an E3= exit, or if an
                     E3= exit does not exist.  Using your batch file, the
                     errorlevel set for the E2= option should invoke mail
                     unpacking software to merge the incoming mail with your
                     message base.
               E3=   Causes an exit with the given errorlevel after compressed
                     mail is received.  If mail is received during the event,
                     and compressed mail is not a part of the mail received,
                     then an E2= exit is performed.  If compressed mail was
                     received (even in conjunction with other mail or files)
                     then the E3= exit is performed. Using your batch file,
                     the errorlevel you set for this option should invoke mail
                     unpacking software that can handle compressed mail and
                     merge it with your message base.
               E4=   Event exits E4-E9 can now be followed by a three
               to    character string.  If that string is matched in the file
               E9=   extension of a received file, then the designated
                     errorlevel exit will be taken.  For example:
                     E4=100,TIC (Received .TIC Files Cause Exit 100)
                     E5=100,FLE (Received .FLE Files Cause Exit 100)
                     E6=110,REQ (Received .REQ Files Cause Exit 110)
                     E7=120,MO? (Received .MO? Files Cause Exit 120)
               EF=   Causes an exit with the given errorlevel on Fax reception
               F     Indicates that the event should be "forced" so that it
                     will occur at the first possible moment.
                     USUALLY YOU DO NOT NEED TO USE THE F FLAG.  BinkleyTerm
                     will execute the current event anyway if for some reason
                     the start time is bypassed (but before the stop time
                     passes).  If you do use this option, use it only on zero-
                     length events; those events for which the <start_time>
                     and <stop_time> are the same.
               H     "High-Priority Mail" - BinkleyTerm will send Continuous
                     flavored  mail IMMEDIATELY, no matter what the cost.  All
                     other mail flavors are sent according to cost or other
                     constraints imposed by the current event.
                     This behavior mirrors that of Crashmail under Opus 1.1x+
                     with one exception - BinkleyTerm makes calls at normal
                     intervals during an H event, rather than forcing a
                     repetitive poll as with Alt-M.
               K     Means "Do not to send to any nodes marked in the nodelist
                     as #CM (accepts Continuous Mail) during this event".



     BinkleyTerm 2.60 Reference Manual                      Page  77


               Flag  Description
               ---   --------------------
               L     The L flag is concerned with call costs and is usually
                     used to stop calls being made at times when call costs
                     are high.
                     There are two alternative methods of using this flag:
                     1) The default method is the original US system where L
                     refers to the COST of a call in Cents per minute as
                     indicated in the Nodelist Cost field.
                     2) The Eurocost method (See "CALL COSTING" on page    for
                                                                        37
                     more details) where L refers to the TIME allowed for one
                     "Call Unit". To use this system statements are added to
                     the BINKLEY.CFG and the Nodelist cost field is used to
                     hold TIME values measured in tenths of a second.
                     Note: In the original US system LOW values of "L"
                     indicate cheap calls whereas with Eurocost calls get
                     cheaper as the "L" value rises.
               L     Can be used alone, without any parameter, and is then
                     equivalent to "L=0". The L flag used in this way where
                     local calls are free is sometimes called the "Local"
                     flag.
               L=nn  Means: "Only send mail in this event if the figure in the
                     nodelist cost field is equal to OR LESS THAN nn"
               L<nn  Means: "Only send mail in this event if the figure in the
                     nodelist cost field is less than nn"
               L>nn  Means: "Only send mail in this event if the figure in the
                     nodelist cost field is greater than nn"
               M     The "M" flag indicates that the event is a "mail" event,
                     and that it is okay to send mail to anyone in the
                     nodelist, regardless of their #CM designation.  This flag
                     is normally used during local mail schedules, and during
                     Zone Mail Hour.
               N     Means "Do not accept inbound file requests during this
                     event".
               Q=    Inhibits BinkleyTerm from calling out with less than nnn
                     bytes  of data for a node (?LO + ?UT sizes).  You should
                     probably  have at least one event with Q=0 (the default
                     if none is specified) in order to get the mail out.
               R     Indicates that the event is "Receive Only" so outgoing
                     calls will not be made to send mail, however, the mail
                     will be sent if a poll is received.
               S     Designates an event which is "send only" meaning that
                     BinkleyTerm will continue to send normally, but will not
                     answer the phone (or if the modem is in auto-answer mode,
                     BinkleyTerm will not respond).
                     Note that you can use "R S" for events where BinkleyTerm
                     should neither dial out nor answer the phone.



     BinkleyTerm 2.60 Reference Manual                      Page  78


               Flag  Description
               ---   --------------------
               T=    This option allows you to control the maximum number of
                     call attempts and failed connects that will be acceptable
                     to BinkleyTerm.  The T= option accepts two parameters,
                     and is used in the format "T=x,y" where x is the maximum
                     number of failed connects (carrier established, session
                     fails - a chargeable call in toll situations), and y is
                     the maximum number of call attempts (no answer, no
                     session - generally NOT a chargeable call in toll
                     situations).
                     Generally, set the x parameter very low, so as not to
                     rack up charges on your phone bill should the call be
                     long distance or another toll call.  Set the y parameter
                     high, since these calls are usually not charged for.
                     The default x parameter is 3, the default y parameter is
                     10,000
               X     The X flag is now obsolete for the reasons given below.
                     Many users will have this flag in their event file and
                     these notes may explain why it may not work as expected.
                     The X flag was intended to prevent a call out being made
                     for stand alone .REQ files, but, since version 2.40,
                     BinkleyTerm's behavior has been altered and calls are
                     never made for standalone .REQ files.
                     The X flag never prevented BinkleyTerm from calling out
                     if other mail (such as a packet) existed. It follows that
                     because most utility programs nowadays create a packet on
                     which to piggyback the .REQ, BinkleyTerm may still call
                     out for a file request even if the X flag is set.

             Many of the above options can be used with one another, and in fact
             usually are.  Constructing a working event schedule can be a time
             consuming process requiring a certain amount of trial and error. 
             Since the event schedule plays a very important role in deciding
             when mail will be sent, it should be manipulated VERY carefully to
             avoid having BinkleyTerm make toll calls during high rate periods.

             A very minimal sample event schedule is shown in NEWUSER.EVT,
             contained in the distribution package.

                                       SCRIPTS


     SCRIPT FILE USAGE

             A script is a series of instructions used when dialing a particular
             system.  They allow the system to "look" for particular information
             coming across the line, and act according when the desired
             information is received within a set time limit.  Scripts are
             essentially a mini programming language, and as such, take study
             and practice to use effectively.

             Once written, scripts are associated with a particular nodelist
             entry for use each time the given node is dialed.



     BinkleyTerm 2.60 Reference Manual                       Page 79  


             Possible applications for scripts include accessing packet switch
             networks, such as GTE/Telenet's PC Pursuit service, that require
             multiple sets of operations to reach the desired destination.

             The use of a script is triggered by the appearance of a file name,
             inside double quotes, in the phone number field of a nodelist
             entry.  For example, instead of seeing 1-303-555-6789 in the
             nodelist data file, you might see "MYSCRIPT.SCR"1-303-555-6789

              Notice that the name of the script file is IMMEDIATELY (without
             spaces) followed by the area code and phone number.  The field must
             appear in the format shown, including hyphens.  The area code
             portion of the number can be up to 10 characters long (for use with
             certain long distance carriers).
             Refer to the documentation for your nodelist processor for
             information on inserting information into the phone number field of
             a nodelist entry.

             Script references can also be placed in your configuration file by
             way of the 'Dial' statement.  See 'Dial <match_string>
             <new_prefix>/[<new_suffix>]' on page 47 for details.

     PREPARING SCRIPTS

             Scripts are stored in a flat ASCII text file, and edited using any
             standard text editor.

             The following restrictions apply when creating scripts:
             1.   Any line beginning with anything other than a letter or a
             colon (:) is ignored as a comment.
             2.   All lines must begin flush left (no leading spaces or tabs)
             3.   All statements that take parameters must be followed by
             exactly ONE space between the statement and the parameter.
             4.   There should be NO extra characters at the ends of lines. 
             This includes space characters.  All characters on a line are
             significant, including any extra spaces that you may have
             inadvertently included.
             5.   Script statements and script labels are NOT case sensitive.

             Please note that spaces can cause hard-to-track-down problems. 
             Spaces are significant characters, meaning they are NOT ignored in
             patterns, etc.  Do not use a space unless you intend to, and do not
             leave any at the ends of lines unless you want them there.

     SCRIPT STATEMENTS


          :<label>

             The colon (:) starts a label.  Labels can be up to 20 characters
             long.  Control can be passed to the location in the script
             identified by a label using the "If" and "Goto" script statements.
              Up to 50 labels per script are allowed.



     BinkleyTerm 2.60 Reference Manual                       Page 80  


          Abort [<start_time> <stop_time>]

             Allows conditional aborting of script execution based on time of
             day.  If used without parameters, it causes unconditional aborting
             of execution.  If parameters are used, script execution will abort
             if the current time is between the hours given with <start_time>
             and <stop_time>.  For example, "Abort 8:00 22:00" would make the
             script abort between the hours of 8:00am and 10:00pm.  The hours
             CAN wrap through midnight, "Abort 22:00 3:00" would be an example
             of this.

          Areacode

             Transmits the areacode portion of the phone number to the modem, as
             shown in the given nodelist entry.

          Baud [<baud_rate>]

             This statement sets the baud rate for the call to the value given.
              If no <baud_rate> is given, the baud rate as listed in the
             nodelist for this node is used.

          BPSxxxx

             Allows branching or actions based on baud rate.
             For example, the statement

                         IF BPS2400 DO2400

             would cause script execution to jump to the previously defined
             label "DO2400" if the current connection was at 2400 bps (baud).

          Break [<duration>]

             This causes a "break" signal to be sent, as needed with some types
             of host systems.  <duration> designates the number of hundredths of
             a second for the break signal to last.  If the <duration> parameter
             is not given, the default duration value of 100 (1 second) will be
             used.

          Carrier

             Continue the script if there is carrier, abort if not.

          Comm <settings>

             Allows setting of the communications parameters.  <settings> is a
             three-character string, consisting of the number of data bits,
             parity and number of stop bits.  For example, a <settings> string
             of "8N1" would cause the parameters to be set to 8 data bits, No
             parity, and 1 stop bit.  "7E1" would cause 7 data bits, Even
             parity, and 1 stop bit.  "7O2" would cause 7 data bits, Odd parity,
             and 2 stop bits.
             Possible values are 7 or 8 for data bits, E (even), O (odd) or N
             (none) for the parity, and 1 or 2 for stop bits.
             NOTE!  The string is NOT checked for accuracy.  The user is
             responsible for making sure that it is correct!



     BinkleyTerm 2.60 Reference Manual                       Page 81  


          Dial

             Dial the entire telephone number, and wait for a valid response. 
             Continue if there is carrier, abort if there is not.

          DOS <command_line>

             Causes the <command_line> to be sent to DOS for execution.
             Upon completion, script execution continues.  Sufficient memory
             must exist for any application executed by this command.

          Download <x>

             <x> is a protocol selection, Z for Zmodem, or S for SEAlink

          Goto <label>

             This statement causes the script processor to jump to the location
             in the script pointed to by <label>.  A colon (:) must have
             previously been used in the script to identify the <label>.  If the
             label does not exist, the script aborts.

          If <pattern_number> <label>

             If a match for <pattern_number> was found at the last 'Wait'
             statement, transfer control to the point in the script identified
             by <label>.  If a match was not found, control continues to the
             next statement in the script.  'If' can be used at any time prior
             to the next 'Wait' statement.

          NoEMSI

             Disables EMSI for the session with the system the script is
             calling.

          NoWaZOO

             Forces BinkleyTerm to be strictly an FTS-0001 mailer by disabling
             WaZOO functionality for the current outgoing session only.  This is
             primarily of interest to coordinators who wish to verify that their
             nodes are meeting FidoNet compatibility requirements.
             There is no benefit to the average user from using this statement.
              In fact, performance with other WaZOO-capable mailers
             (BinkleyTerm, Opus, D'Bridge, FrontDoor, etc.) will be adversely
             affected.

          Pattern <pattern_number> <string>

             This statement establishes a pattern for the script handler to look
             for during the next 'Wait' statement.  <string> IS case sensitive.
              The script handler will look an EXACT match for the series of
             characters in <string> during the next 'Wait' statement.  Up to 8
             patterns can be used, and they can be reused or reset at will.  Up
             to 20 characters can be used in a pattern.   The purpose is to wait
             for a given string from the host, or a particular modem response
             string, and to act accordingly.



     BinkleyTerm 2.60 Reference Manual                       Page 82  


          Phone

             Transmits the local portion of the phone number to the modem, as
             shown in the given nodelist entry.  Hyphens are stripped
             automatically.

          Rawxmit <string>

             This works in the same manner as the 'Xmit' statement, except that
             dial translation is NOT performed.

          Session

             This should be used at the end of a script which has been
             successful.  It tells BinkleyTerm to begin a NetMail session with
             the remote system.

          Speed

             Causes BinkleyTerm to send the baud rate divided by 100 as a
             string.  The baud rate used it the rate specified for the node in
             the nodelist, or the rate specified by a prior call to the 'Baud'
             statement.  For example, if the current connect rate was 2400 baud,
             the string "24" would be sent when this statement is encountered.

          Timer <seconds>

             Sets a master countdown timer to <seconds>.  If the timer expires,
             the script will abort.  This allows you to set timeouts on any
             portion of, or the entire script.  You may reset the timer by using
             another 'Timer' statement.

          Wait [<seconds>] [<label>]

             Wait for a maximum of <seconds> for one of the previously set
             patterns to be matched.  If a pattern is matched, the script
             continues, otherwise it aborts.  If <label> is provided, the script
             will resume operation at the label specified upon timeout.  Note
             that the default value is 40 seconds.  Both <seconds> and <label>
             are optional.  A <label> may be specified without specifying
             <seconds>.  For example:

             Wait 40 foo     is the same as:     Wait foo

          Upload <x> <filespec>

             where <x> is the protocol selection: Z for Zmodem, S for SEAlink

          Xmit <string>

             Transmits <string> to the modem.  Normal BinkleyTerm translations
             are valid (refer to the section "Dial Translation" for
             information).



     BinkleyTerm 2.60 Reference Manual                       Page 83  


                         THE BINKLEYTERM WINDOWED INTERFACE

             BinkleyTerm features a windowed user interface which  provides "at-
             a-glance" convenience for watching mail sessions in progress, as
             well as determining what activity has taken place with the system
             recently.

     VIDEO FOSSIL

             A Video Fossil (VFOSSIL) is a separate driver program used by
             BinkleyTerm when running in a DOS environment. VFOS_IBM is a video
             fossil in common use. This is a freeware program likely to be
             available from wherever you obtained BinkleyTerm.

             OS/2 and Win32 users do not require a Video Fossil.  Video services
             similar to those made available in DOS by using the Video Fossil
             are native to the operating system and are used directly by
             BinkleyTerm.

             When running under DOS, a video fossil is required for color
             displays. Even if you have a monochrome display it is recommended
             that a Video Fossil be used as the windowing operations mentioned
             below can take place much faster than they would without one. Also
             the 'ScreenBlank' function requires the presence of a Vfossil.

             Some more recent Video Fossil implementations may also allow
             BinkleyTerm to be used on EGA and VGA systems in extended text
             modes of 132 columns by 43 lines.  The mode switching must be
             performed by the utility software that accompanied your video card
             prior to invoking BinkleyTerm.

     THE DISPLAY SCREEN

             There are five information windows displayed on-screen:

     CURRENT SETTINGS WINDOW

             This window contains various information about your system,
             including the current date and time, current event, port and
             current baud rate, status and multitasker type, if any.
             The current event line features a number, and a list of event
             flags.  The number corresponds to which entry in the Event file
             contains the line that covers the current event.  The first 'Event'
             statement in the file would be event 1, the second would be event
             2, and so on.  The flags are letters that are a subset of those
             used with event scheduling.  Here is a list of letters that may be
             found in this window:



     BinkleyTerm 2.60 Reference Manual                       Page 84  



                       C          Continuous Mail Only Event
                       L          Local Only Event
                       N          Do Not Accept Inbound File Requests
                       R          Receive Only Event
                       B          BBS Use Allowed
                       D          Dynamic Event
                       K          Do Not Send to #CM Nodes

             Note that not all event flags will be displayed in the window. For
             details of all event flags, see "EVENT FILES and SCHEDULING EVENTS"
             on page 71.

     TODAY AT A GLANCE WINDOW

             This window contains several lines of information regarding the
             activity on your system since midnight.  Note that the totals given
             apply only to calls handled by BinkleyTerm's Unattended (mailer)
             Mode, and do not include Terminal Mode totals.

             The first line, "BBS/Mail," lists how many BBS calls and mail calls
             have come in, separated by a slash.  For example, 2/15 would
             indicate 2 BBS calls and 15 mail calls since midnight.

             The second line, "Calls Out," lists the number of dial attempts
             that have been made by your system, successful or otherwise.

             The third line, "Good/Cost," shows how many successful outward
             connects have been made and the cumulative cost of all the
             successful calls, separated by a slash.  For example, 3/100 would
             indicate that 3 successful outbound calls have been placed, and
             that together, they cost 100 units (in the United States, units are
             cents, which would mean that the cost was 100 cents or $1.00).  The
             cost is calculated based on the cost shown in your compiled
             nodelist files; the cost shown there is assumed to be a per-minute
             value in calculating a per-call cost.

             The fourth line, "Files I/O," shows how many files (packets,
             compressed mail or other incoming files) have been received and
             sent, separated by a slash.  For example, 12/3 would indicate that
             12 files have been received, and 3 have been sent.

             Finally, the fifth line indicates the type of last call.  If the
             last call was incoming, the display will indicate whether the call
             was a BBS call, external mail call or incoming FAX, or the node
             address will be displayed if it was a mail call.  If the last
             successful call was outgoing, the node address will be displayed.

     PENDING OUTBOUND MAIL WINDOW

             This window displays a list of systems for whom mail is pending,
             along with related information.  The window can be scrolled using
             PgUp, PgDn, Home, End, Up-Arrow and Down-Arrow keys.  The top line
             of the window lists the node that is being called, or was just
             called.  The second line lists the node to be called next.



     BinkleyTerm 2.60 Reference Manual                      Page  85


             For each node, BinkleyTerm lists the number of files which
             BinkleyTerm needs to send, the total size of the files, and a
             "status" which is explained below. The file size and file count
             display can be disabled by means of the NoSize configuration
             statement.

          Pending Outbound Status Information:

             In the "status" column, information about the mail for the various
             nodes is also displayed.  Each attribute of the mail is marked by a
             single letter.  The letters and their meaning are:

                         Letter        Meaning
                         ------        ------------
                            C          Continuous Mail
                            H          Hold-for-Pickup Mail
                            D          Direct Mail
                            N          Normal Mail
                            R          File and/or Update Request
                            S          Status


             To the right of the mail attributes, BinkleyTerm will show a single
             character status which indicates whether it expects to be making
             any outgoing calls to deliver mail to this node.  The values which
             BinkleyTerm will display and their meanings are:

                       Symbol     Meaning
                       ------     -----------
                         *        Outgoing mail will be sent
                         x        Too many bad connects (considered undialable)
                         #        Already called, but mail still pending
                         -        Cannot call this node during this event
                         !        This node not found in the Nodelist

             When BinkleyTerm is making an outbound call, the node which is
             being called is highlighted in the Pending Outbound Mail window. 
             This allows you to know which node has been called, even after the
             pertinent information has scrolled out of the Recent Activity
             window (described below).  This feature can also be helpful in
             determining whether an active mail session was initiated by you, or
             was started by an incoming call.

          Rescan of the Outbound Area

             The outbound area is re-scanned for new additions under the
             following circumstances:
                    After a keyboard shell has been invoked
                    After 'AfterMail' is run (if designated)
                    After 'Packer' is run (if designated)
                    After message editor (Alt-E) has been run
                    After user manipulates the outbound, sending, requesting
                       files, etc. either from unattended mode or in zoomed
                       outbound window
                    After 10 minutes of no activity
                    After executing an Alt-I modem Init in unattended mode



     BinkleyTerm 2.60 Reference Manual                       Page 86  


                    After BinkleyTerm finds a BTRESCAN.@@ file in the flags
                       Directory
             Note the 'AfterMail', 'Packer' and 'Reader' (message editor) are
             designated in the configuration file.  Refer to the "Configuration
             File" section for additional information.

     RECENT ACTIVITY WINDOW

             This window gives information about what the system is currently
             doing, or has just done.  This includes identification of the
             remote system, the type of connection, what files were transferred,
             etc.

             The information in this window essentially reflects the information
             that BinkleyTerm is writing to its logfile.

             The recent activity window is scrollable. Set the Max lines to
             scroll with the RecentActivityLines configuration statement and use
             CTRL+(uparrow/dnarrow, pgdn/up, home end) keys to scroll. DOS users
             should beware that this uses a fair bit of memory, and should also
             note that for some reason the CTRL/UPAR and CTRL/DNAR do not seem
             to work under DOS. You should be able to redefine these commands to
             other keys and recompile your language file to gain access to the
             functions.

     TRANSFER STATUS WINDOW

             This window gives particulars about current file transfers that may
             be taking place if a connection is active.  For most types of mail
             transfers, this includes filename and the number of bytes
             transferred; for other types of transfers, the number of blocks
             transferred may be given.

             Between mail sessions, the window will display the amount of time
             until the next event begins and the flags associated with the next
             event.  If your message base uses the .MSG format, BinkleyTerm is
             able to determine that unread mail is waiting in the NetMail area
             and an indicator will be displayed in this window. This feature can
             now be enabled for a Squish type message base by including the
             'NetMail' statement in your Binkley.cfg with the associated
             filename preceded  by a dollar sign($). For example:

                  NetMail     $c:\bink\netmail

                  The success or otherwise of the "squish Netmail advise
             feature" depends on how you handle your netmail area. The message
             advising you of unread netmail will remain as long as there is any
             unread mail, even outgoing messages, areafix msgs etc., which you
             would not normally read. No doubt this will be amended in a future
             release.


                                BINKLEYTERM LOG FILE

             If a log file is defined with the StatusLog configuration statement
             then information about the program' activities can be logged. The
             LogLevel statement defines the extent of the logged information.



     BinkleyTerm 2.60 Reference Manual                      Page  87



             File request searches can be logged, see  the section on Incoming
             File requests.

             If the AfterCall statement is used then details of each call can be
             logged.

             For debugging purposes, the Debug and LineUpdate statements provide
             additional information to the log.

             BinkleyTerm can maintain a separate log of call costs. Enable this
             by setting the "EuroCost"
             command, and making "CostLog <file>" and "CostUnit" settings.

             US CostUnit
             seems to be about 2 and European seems to be 23. Adjust as you
             need.

             With the CostLog in use, quite a bit of additional information is
             available and is logged at the end of each session. i.e.
             Day number for this record    
             Number of BBS callers          
             Number of mail calls             
             Number of outgoing calls made
             Number of outbound call successes
             Number of files received         
             Number of files sent             
             Type of last call                
             Address of last, excl. Domain
             Domain of last                 
             Time of last outbound session    
             Address of next, excl. Domain   
             Domain of next                 
             Cumulative of call costs    
             Size of files received         
             Time of files received       
             Errors while receiving files
             Size of files sent               
             Time of files sent             
             Errors while sending files



                               COMMAND LINE PARAMETERS

             BinkleyTerm offers a selection of command line parameters which
             each have a unique function.  The words that are described below
             are simply placed on the DOS command line - no hyphens or slashes
             are necessary.  For example:

                         BT NoForce Unattended Share Config C:\BT\SYS1.CFG

             A full list of the command line parameter options is as follows:

              Command       Function
              -------       --------
              NoForce       Don't force events that have already passed.



     BinkleyTerm 2.60 Reference Manual                      Page  88


              Command       Function
              -------       --------
              Mail          For Point system use, this causes BinkleyTerm to
                            attempt connection to the boss upon start-up.
              Share         Leaves the FOSSIL driver "hot" (does not de-
                            initialize the driver upon exit) for use with other
                            FOSSIL-based systems.
              Dynam         Restart the current dynamic event, if any, even if
                            it may have already executed.
              Unattended    Run in Unattended Mode, regardless of whether the
                            'Unattended' configuration file statement is used.
              Config        Allows specification of a configuration file other
                            than the default (BINKLEY.CFG).  This parameter
                            must be followed by a single space, and then the
                            name of the configuration file, including drive and
                            path if applicable, for example:
                              "BT Config C:\BT\MYCONFIG.CFG"
              Poll          Instructs BinkleyTerm to immediately poll a given
                            node and keep trying until successful. No notice is
                            taken of any event file entry.  Upon completion of
                            the poll, BinkleyTerm will exit.
                            Example: 
                            "BT Poll 1:132/101"



     BinkleyTerm 2.60 Reference Manual                      Page  89



                              TERMINAL MODE KEYSTROKES

             While in Terminal Mode, several keystrokes are available that allow
             uploading and downloading of files, changing of communications
             parameters, and so on.

             Keystroke         Function
             ---------         --------
             Alt-=             Used to toggle "Doorway Mode" on and off. When
                               in this mode, all keystrokes are sent out the
                               modem as entered (except for the command used
                               to toggle the mode on & off).  If a function
                               key is used, a zero followed by the scan code
                               is sent.
             Alt-B             This allows you to step the baud rate up to
                               the next higher value.  BinkleyTerm supports
                               baud rates of 300, 1200, 2400, 4800, 9600,
                               19,200 and 38,400.  38,400 baud wraps to 300
                               baud.
             Alt-C             This allows you to set various communications
                               parameters, including number of data bits,
                               parity, and number of stop bits.  You are
                               prompted for the information.  Note that when
                               8 bits are set, BinkleyTerm defaults to no
                               parity, and you are not prompted for the
                               setting.
             Alt-D             Allows you to dial out.  When prompted, you
                               may enter one of three items: a telephone
                               number, a FidoNet node address in the form
                               [<zone>:]<net>/<node>, or a FidoNet Sysop
                               name.
                               Entering a FidoNet address requires the
                               presence of a compiled nodelist, properly
                               referenced in the BinkleyTerm configuration
                               file.  Entering a Sysop name requires that
                               your nodelist compiler has created a
                               compatible list, either FIDOUSER.LST for a
                               Version6 Nodelist or SYSOP.NDX for Version7.
             Alt-E             Erases the display screen.
             Alt-F1 through    These keystrokes allow you to send user-
             Alt-F9            defined macros.  Please refer to the section
                               "Configuration File" for information on
                               Terminal Mode macros.
             Alt-F10           This provides a brief help screen, listing the
                               key-presses available to you in Terminal Mode.
             Alt-H             Hang-up.  This command toggles the modem's DTR
                               (data  terminal ready) line, thereby
                               disconnecting any call in progress.  The modem
                               init string is sent to the modem after DTR is
                               toggled.
             Alt-I             Re-initializes the modem.



     BinkleyTerm 2.60 Reference Manual                      Page  90


             Keystroke         Function
             ---------         --------
             Alt-J             Jump to DOS.  Invokes COMMAND.COM to allow for
                               "quick and dirty" DOS commands on the fly. 
                               Enter "EXIT" at the DOS prompt to return to
                               BinkleyTerm.  BinkleyTerm will automatically
                               return to the directory it was run from when
                               returning from DOS.
             Alt-L             Toggle session logging on and off.
                               If 'CaptureFile' is enabled in BINKLEY.CFG,
                               Alt-L opens that file (for append if it
                               already exists). If 'CaptureFile' not enabled,
                               this session logging function allows you to
                               designate a file or printer, and have the
                               entire terminal mode session echoed to the
                               selected file or device.
                               When first invoked, this command will prompt
                               you for a file name.  Type in the desired name
                               of the log file, including drive and path
                               designation if desired.  You may also enter a
                               printer device name, e.g., PRN, LPT1, LPT2,
                               etc. for printer echoing.
                               Invoke the command again to end logging to the
                               file or device.
             Alt-M             Poll a node in the nodelist, by node address.
                                This command requires that mail handling be
                               implemented as described in the User's Manual
                               section, "Unattended Mode Overview".
                               You are prompted for a FidoNet node address.
                               Once entered, BinkleyTerm will dial the system
                               (if it exists in the nodelist) and attempt to
                               exchange mail with the system.  If there is
                               outgoing mail to the system, or if mail is
                               waiting for you on the remote system, it will
                               be sent during the mail session.
             Alt-P             This command allows you to change the
                               communications port in use.  Invoking the
                               command shifts the port number to the next
                               higher port.  The number of ports supported is
                               determined by your hardware, and by the
                               'MaxPort' statement in the configuration file.



     BinkleyTerm 2.60 Reference Manual                      Page  91


             Keystroke         Function
             ---------         --------
             Alt-R             This allows you to dial out with a "scan
                               list".  Empty elements are designated by
                               'Null.'  Using the function keys  (or
                               equivalently numbered numeric keys) you can
                               select the scan list element you wish to
                               enter.  Enter a telephone number, node address
                               or Sysop name, just as you would with the Alt-
                               D command.  Press "Enter" to "store" your
                               entry for that element.  When you have stored
                               all the desired elements, press "Enter" to
                               begin the dialing process.
                               Each number will be dialed in sequence, until
                               a connection is made.  After the session is
                               completed, a 'Null' will be stored for that
                               element.  Invoke Alt-R again, and press
                               "Enter" to dial the remaining elements.  Press
                               "Escape" at any time to abort the dialing
                               process.
                               Note that unless saved, the dialing list is
                               volatile.  Once you exit the Terminal Mode,
                               your dialing list will be erased.   It is
                               possible to save to and retrieve from the disk
                               media up to 10 separate lists of entries.  To
                               save a list, press Shift- Fn, where 'n' is the
                               number of the list to save.  For example,
                               Shift-F3 would save the current list of 10
                               entries to list number 3.  To retrieve a
                               previously saved list, press Alt-Fn, where 'n'
                               is the number of the list to retrieve.  For
                               example, Alt-F5 would retrieve the 10 entries
                               previous saved as list number 5.
             Alt-S             Invoking this command sends a "break" signal
                               via the modem to the remote host.  This
                               command requires that a FOSSIL of revision 5
                               or later be installed.
             Alt-U             This command is used in Point and BBS
                               installations to shift to Unattended Mode. 
                               BinkleyTerm is put into the mailer mode, ready
                               to accept calls from remote systems.  In order
                               to operate, the mailer functions must be
                               implemented as described in the User's Manual
                               section, "Unattended Mode Overview".
             Alt-X             Allows you to exit the program and return to
                               DOS.  If BinkleyTerm was invoked with a batch
                               file, this command will cause BinkleyTerm to
                               exit to the batch file with an errorlevel of
                               1.  The batch file must trap this errorlevel,
                               and exit accordingly.
                               Note that this function DOES leave the DTR
                               (data terminal ready) line on the modem
                               "high."



     BinkleyTerm 2.60 Reference Manual                      Page  92


             Keystroke         Function
             ---------         --------
             Alt-Y             Used primarily for Point operations, this
                               function initiates a mail session with the
                               host.  This is designed ONLY to work with the
                               system listed as your Boss node in the
                               configuration file.
                               Issuing this keystroke invokes a temporary
                               mailer mode, and BinkleyTerm attempts to dial
                               the Boss system to exchange mail.  Mail
                               handling must be set-up as described in the
                               User's Manual section, "Unattended Mode
                               Overview".
                               If mail is waiting to be sent to the Boss, or
                               if mail is waiting on the Boss system for
                               pickup, it will be sent during the mail
                               session.
             PgDn              This allows you to download a file from the
                               host with which you are connected.  You are
                               prompted for the desired protocol to use, and
                               for the required file information, if needed
                               (protocol dependent).  If you have the
                               'Download' statement properly implemented in
                               the configuration file, the downloaded files
                               will be placed in the directory specified. 
                               Otherwise, the file will be saved to the
                               current directory.
             PgUp              This allows you to send a file to the remote
                               host.  You are prompted for the desired
                               protocol to use for the transfer, as well as
                               the file information.  You may specify a
                               complete drive, path and filename using
                               standard DOS conventions, e.g.,
                               C:\PATH\FILENAME.ARC.
                               When a batch protocol is used (SEAlink,
                               Telink, or Zmodem), wildcards are allowed in
                               the filename.

                             UNATTENDED MODE KEYSTROKES

             While in Unattended Mode, several keystrokes are available that
             perform various functions, such as manual polling, call forcing,
             Command Shells, and so on.

           Keystroke           Function
           ---------           ---------
           F1 through F10      These keys cause BinkleyTerm to exit with an
                               errorlevel of 10 times the function key number
                               pressed.  In other words, F1 causes an
                               errorlevel 10 exit, F7 would cause an
                               errorlevel 70 exit.  Your batch file is used
                               to capture and process these errorlevels.
           Alt-F1 through      These keystrokes invoke user-defined Command
           Alt-F9              Shells, to execute programs or utilities as
                               desired.  Refer to the section "Configuration
                               File" for additional information.



     BinkleyTerm 2.60 Reference Manual                      Page  93


           Keystroke           Function
           ---------           ---------
           Alt-F10             This key causes BinkleyTerm to display a brief
                               help screen, listing the various keystrokes
                               available to you in the current operating
                               mode.
           Alt-A               Sends answer string to the modem
           Alt-B               Forces a screen blank to occur.  Any system
                               activity or a press of the space bar will
                               reactivate the screen display.
           Alt-C               Causes information in the Unattended Mode
                               "Today at a Glance" window to be "zeroed" out.
                                The information is NOT stored to the
                               BINKLEY.DAY file prior to being zeroed.
           Alt-E               This invokes your message editor/reader, as
                               designated by the configuration file parameter
                               'Reader.'  Refer to the section "Configuration
                               File" for more information.
           Alt-G               Allows the generation of an outbound file
                               request.  When executed, this command will
                               pop-up a window on the screen where you will
                               be prompted to provide information appropriate
                               to creating a file request.
                               Note: An outbound directory must pre-exist for
                               the Zone (and, optionally, Domain) of nodes
                               you are calling.
           Alt-I               Re-initializes the modem (equivalent to Alt-
                               T/Alt-U in previous BinkleyTerm versions). 
                               Also causes BinkleyTerm to re-read the
                               outbound mail holding area.
           Alt-J               This causes BinkleyTerm to exit to DOS and
                               stay resident (Command Shell).  This is
                               probably the most efficient method to perform
                               a quick DOS command "on the fly."  Enter
                               "EXIT" at the DOS prompt to return to
                               BinkleyTerm.  BinkleyTerm will automatically
                               return to the directory it was run from when
                               returning from DOS.
           Alt-K               Allows you to kill all mail for a particular
                               node.  When executed, you will be prompted for
                               confirmation.
           Alt-M               This keystroke allows you to perform a manual
                               mail polling operation.  You will be prompted
                               for a FidoNet node address in the form
                               <net>/<node>.  You may also enter a Sysop name
                               if a SYSOP.NDX (or FIDOUSER.LST for the older
                               Version6 Nodelist) is available to BinkleyTerm
                               in the nodelist directory.  Refer to the
                               User's Manual section "Nodelist" for more
                               information.
                               BinkleyTerm will then dial the system, without
                               regard to event schedules, or any flags,
                               (i.e., repeatedly without pauses until
                               successful) and attempt to transact mail with
                               the remote system. This is sometimes termed a
                               "demon" poll.



     BinkleyTerm 2.60 Reference Manual                      Page  94


           Keystroke           Function
           ---------           ---------
           Alt-P               Poll a node. Pop-up window appears for you to
                               enter the address.
                               This creates an empty Poll attach (.CLO) which
                               causes dialling at the usual intervals set by
                               the 'T' flag, not repeatedly like Alt-M
                               Note: An outbound directory must pre-exist for
                               the Zone (and, optionally, Domain) of nodes
                               you are calling.
           Alt-R               This forces BinkleyTerm to restart the first
                               event that should execute at the current time,
                               not including forced events.
           Alt-S               Allows the generation of an outbound file
                               attach.  When executed, this command will pop-
                               up a window on the screen where you will be
                               prompted to provide information appropriate to
                               creating a file attach.
           Alt-T               This is used to shift to Terminal Mode on the
                               fly.  By using the Alt-U command of the
                               Terminal Mode, you can flip back and forth
                               between Terminal Mode and Unattended Mode.
           Alt-Q               This tells BinkleyTerm to quit the current
                               event, and start the next event that covers
                               the current time period.  If there is no such
                               event, Event 0 (the default non-event) will be
                               started.  For all practical purposes, nothing
                               happens during event 0, however, BinkleyTerm
                               will still accept incoming mail.  The events
                               can be restarted by the Alt-R command.
           Alt-W               This command causes the screen to be redrawn
                               with current information.  This is handy for
                               situations such as multi- tasking that may
                               have caused the BinkleyTerm screen to become
                               "trashed."
           Alt-X               This allows you to exit BinkleyTerm with
                               errorlevel 1.  If you are using a batch file,
                               it must capture and act upon the errorlevel
                               properly by terminating the batch file.  Refer
                               to the User's Manual section "Control" for
                               additional information.
           Alt-Y               Polls the boss node (same as Alt-Y in Terminal
                               Mode).
           Alt-Z               Zoom the outbound window. See "ZOOMED OUTBOUND
                               WINDOW KEYSTROKES" on page 95 for details of
                               this window.
           C                   Means "Call out please", if there is anything
                               waiting to go. If there is something that
                               would not ordinarily be sent during the
                               current event, this command will not cause it
                               to be sent.  Use a manual poll for immediate
                               sending to any system under any circumstances.
                               Note that BinkleyTerm automatically checks the
                               outbound area approximately once every 10
                               minutes; the automated equivalent of this
                               command.



     BinkleyTerm 2.60 Reference Manual                      Page  95


           Keystroke           Function
           ---------           ---------
           Space               This key may be used to abort polls and to un-
                               blank the screen (when the 'ScreenBlank'
                               option has been enabled).  This key is ignored
                               when pressed during BinkleyTerm idle time
                               (waiting for calls)



     BinkleyTerm 2.60 Reference Manual                      Page  96



                          ZOOMED OUTBOUND WINDOW KEYSTROKES


           Keystroke           Function
           ------------        ----------
           A                   Re-addresses mail by changing the address on
                               the cursor line, using pop-up window for
                               entry.
           C D H or N          Change the status of the mail currently shown
                               on the cursor line.
           I                   Reset the Dial Tries counter for the node
                               shown on the cursor line. You are asked to
                               confirm.
           R                   Kill requests from node shown by cursor line.
           K                   Kill all mail to node shown by cursor line.
           T                   Stop Mail to node shown by cursor line.
           G                   Get (Request) files from the node shown by the
                               cursor line, allowing requesting multiple
                               files from that node.
           Alt-G               Get (Request) files (pop-up window requests
                               the address then filename then password if
                               any)
           S                   Send files to node shown by cursor line,
                               allowing entry of multiple files to send to
                               that node.
           Alt-S               Send files (pop-up window requests address
                               then filename).
           P                   Create a Poll for the node shown by cursor
                               line.
           Alt-P               Poll a node (Pop-up window allows address
                               entry).
           Arrow keys          Up/Dn arrow keys move the cursor line.
           Page up/dn          Scroll the display.
           Home/End keys       Move to start/end of display.
           Esc                 Cancel the current command if any and return
                               window display to normal.
             Display also reverts after about 1 min if no keys pressed.



     BinkleyTerm 2.60 Reference Manual                       Page 97  



                MODIFICATION/TRANSLATION OF BINKLEYTERM INTERNAL TEXT

             BinkleyTerm now allows you to generate your own translations or
             modifications of much of the BinkleyTerm internal text. 

             Enclosed with this release is a file named ENGLISH.TXT, which is
             the raw English language text created by the authors, and
             BINKLEY.LNG which is the compiled binary representation of
             ENGLISH.TXT for BinkleyTerm's use.

             To create your own translation of BinkleyTerm's text strings, copy
             the ENGLISH.TXT file to a file of your choice for editing. Use a
             standard ASCII flat text file editor (such as DOS EDLIN or your
             favorite word processor in non- document mode) to edit the file for
             your needs.  The strings should in most cases be self-explanatory.
             BTLNG now supports `\s' for embedded spaces.
             When finished editing the file, use the included language compiler,
             BTLNG.EXE, to compile the text into binary format for BinkleyTerm's
             use.  The command line for BTLNG.EXE is as follows:

                         BTLNG <source_file> <output_file>

             For example, to compile the ENGLISH.TXT file, use the following
             command:

                         BTLNG ENGLISH.TXT BINKLEY.LNG

             The binary language file must be named BINKLEY.LNG in order for
             BinkleyTerm to recognize it.

             Persons who are qualified (bilingual and sufficiently experienced
             or educated) to translate ENGLISH.TXT into foreign languages are
             encouraged to do so and to make your translations available to
             others through appropriate means.

             BinkleyTerm now works internally with function codes, rather than
             scan codes.  This means that ALL keyboard behavior can be modified
             in the ENGLISH.TXT file.  Examples are included in that file to
             illustrate how this is accomplished.  Any key combination you wish
             remapped should have the original and remapped scan codes preceded
             by the capital letter "U" for Unattended mode, "T" for Terminal
             mode, or "A" for Ansi escape sequences.  The file should then be
             recompiled into a language file using BTLNG.EXE

             Replace the original BINKLEY.LNG file with your newly compiled
             revision, and your keyboard remappings will take effect.

             A new operating-system conditional switch has been added to
             BTLNG.EXE, the language file compiler:
             ?DOS at the beginning of a line will tell BTLNG to compile the line
             if it's being run under DOS. 
             ?OS2 at the beginning of a line will tell BTLNG to compile the line
             if it's being run under OS/2.
             ?WNT at the beginning or a line will tell BTLNG to compile the line
             if it's the Win32 version.

