OS/2 Shareware BBS: 2 BBS/02-BBS.zip/PTKTDOC3.ZIP/BINK_240.DOC

Text File | 1990-07-12 | 29KB | 720 lines

              Addendum to BinkleyTerm Documentation

                      Changes and Additions
                  for BinkleyTerm Version 2.40

           Copyright (C) 1990 Bit Bucket Software, Co.


INTRODUCTION

Rather than update the BinkleyTerm documentation as we have done
in the past, we are issuing this addendum file.  It is important
that you read this file thoroughly, as some of the information
herein will supersede what is shown in the manual itself.

By issuing this addendum, the printed versions of the BinkleyTerm
manual now in circulation (and still available from Bit Bucket
Software) will continue to be current (except for this addendum).
The printed manuals were produced at great expense, and it has
taken us a great deal of time to recoup our expenses.  We hope to
produce a printed manual again in the future, but for this
release, the BinkleyTerm Version 2.30 docs (printed or otherwise)
will remain current with this addendum.

The mailing address for Bit Bucket Software has changed.  If you
wish to get ahold of us by mail for any reason, our address is:

          Bit Bucket Software, Co.
          P. O. Box 460398
          Aurora, CO  80046

Please - do not write for technical support.  Support is provided
EXCLUSIVELY through the international BINKLEY EchoMail
conference.  When sending correspondence for other reasons,
please include a self-addressed stamped envelope for replies.
(Those persons not in the United States should enclose an
International Postal Reply Coupon.)

PRINTED MANUALS

As mentioned previously, printed BinkleyTerm manuals are still
available.  Pricing covers the cost of printing, processing your
request, and mailing.  The prices are as follows:

     Within the United States:
          $15.00         Manual Only
          $25.00         Manual and Disk

     Outside the United States:
          $25.00 USD     Manual Only
          $35.00 USD     Manual and Disk

All manuals will be delivered via regular mail.

               ----------------------------------
               USER'S GUIDE CHANGES AND ADDITIONS
               ----------------------------------

---------
SECTION 3   Operation as an Automated Electronic Mailer
---------

Janus Mail Protocol

     BinkleyTerm now features an experimental mail transfer
     protocol called "Janus."  It is a bi-directional, full-
     duplex protocol, and generally requires a full-duplex modem
     to work properly (USRobotics Courier HST modems, for
     example, are not full-duplex and cannot use Janus
     effectively).  Under ideal conditions, Janus allows you to
     transfer mail simultaneously in both directions with Zmodem-
     like performance.

     Due to the depth of the subject, Janus is covered completely
     in its own section toward the end of the document.

Domain Support

     BinkleyTerm now features support for "domain" addressing.
     Due to the depth of the subject, domain addressing is
     covered completely in its own section toward the end of this
     document.

Assumptions

     BinkleyTerm supports zone, net and domain assumption.  If
     you have more than one address and different zones, nets, or
     domains are designated in the configuration file, then
     BinkleyTerm will use whichever address is appropriate when
     transacting mail.

     For example, net assumption might work as follows.  If I
     have two addresses - 104/36 (primary address) and 1052/1
     (secondary address) - and someone calls from net 1052, then
     my system will identify itself at 1052/1.  In all other
     cases, my system will identify itself as 104/36 (since it's
     my primary address).  The purpose is that your system will
     identify itself as the most appropriate address depending on
     the address of the calling system.

File Requests

     BinkleyTerm will no longer 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.  As
     always, a manual poll will also allow a call to be placed.

More Connect Messages

     Support for the following connect messages has been added:

          CONNECT 75     (Giving 1200/75 bps)
          CONNECT 103    (Giving 300 bps)
          CONNECT 12     (Giving 1200 bps)
          CONNECT 212    (Giving 1200 bps)

              -------------------------------------
              REFERENCE GUIDE CHANGES AND ADDITIONS
              -------------------------------------

---------
SECTION 1   Configuring BinkleyTerm
---------

CONFIGURATION FILE

Colors <brdr> <sett> <today> <pend> <act> <txfr> <rev> <popwin>

     Identical as documented in the manual, except the addition
     of two more parameters.  The <rev> parameter designates the
     reverse video color used in the Pending Outbound window to
     mark the node you are calling.  The <popwin> parameter
     designates the color of pop-up windows (such as those
     produced with the Alt-G and Alt-S commands in Unattended
     Mode).

Flags <dir>

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

FTS-0001

     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.

JanusBaud
JanusOK

     Controls whether Janus bi-directional protocol will be used
     during WaZOO sessions.  Please refer to the complete Janus
     explanation later in this document.

KnownMaxBytes

     See 'MaxBytes' for information.

LockBaud [<lock_rate>]

     Works the same as what is documented in the manual, except
     it now accepts an optional parameter.  The <lock_rate>
     parameter tells BinkleyTerm what baud rate at which locking
     should occur.  This is useful for modems that allow a
     floating baud rate to a certain speed, then are locked at
     higher connect rates.
     Most ROM revisions of the USRobotics Courier HST 14.4k model
     and the USRobotics Courier HST Dual Standard 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.

     TO LOCK AT 19200 AND FLOAT AT SLOW SPEEDS:  Use the
     'Baud 19200' and 'LockBaud 4800' statements in your
     configuration file, and set the modem for &B0 and S27=128.

     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.

MaxBytes

     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.  NOTE:  There is a response file "Type 6"
     response now, which indicates that the caller has exceeded
     the byte limits.

NoResync

     When used, this statement will tell BinkleyTerm not to allow
     SEAlink Resync (an ability to restart failed SEAlink mail
     sessions).  Used mostly for debugging purposes; not for
     regular use.

NoSEAlink

     When used, this statement will tell BinkleyTerm not to allow
     SEAlink mail sessions at all, including SEAlink extensions
     to base FidoNet protocol (FTS-0007) and WaZOO/DietIFNA
     sessions.

NoZedZap

     When used, this statement will tell BinkleyTerm not to allow
     ZedZap (Zmodem) transfers during a WaZOO session.  It is
     primarily intended to force BinkleyTerm to use DietIFNA mode
     (SEAlink) during WaZOO sessions.  Used mostly for debugging
     purposes; not for regular use.

ProtMaxBytes

     See 'MaxBytes' for information.

ScreenBlank [<method>]

     Identical in function to what is documented in the manual,
     but now accepts an optional parameter.  The <method>
     parameter may be "Key" or "Call" and tells BinkleyTerm which
     method to use to "unblank" the display.  "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.

TaskNumber <number>

     This statement performs two functions for persons operating
     in multi-processing or multi-line environments (through a
     LAN or multi-tasker).

     First, it designates a task number for the BinkleyTerm that
     uses the configuration file that this statement appears
     inside of.  The <number> parameter must be greater than zero
     (0).

     Second, it tells BinkleyTerm to operate in "multi-processor
     smart mode."  If BinkleyTerm is transacting with a
     particular system, it will create a "xxxxyyyy.BSY" file for
     that node, named in the conventional packet form (xxxx = net
     number in hex, yyyy = node number in hex).  This file can
     serve as a flag to other BinkleyTerm tasks, or to compatible
     mail processing packages so that other tasks or processors
     will not handle any mail for the particular node until the
     ".BSY" file is gone.  Additionally, BinkleyTerm will not
     send files to any node for which there is a ".BSY" file.

TermInit  <modem_string>

     Identical in structure to the 'Init' statement, this
     statement provides a modem initialization string that
     BinkleyTerm will 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:  The 'PreInit' statement, if
     designated, will NOT be used in conjunction with this
     initialization string.

SCHEDULING EVENTS CHANGES AND ADDITIONS

Event Exits

     Event exits E4-E9 can now be followed by a three character
     string.  If that string is matched in the file 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)

     The order of exit precedence is as follows:

          E3
          E4-E9
          E2
          AfterMail

     When more than one E4-E9 exit applies, the first one is the
     one taken.

Send Only Events

     The "S" event parameter was not documented in the manual.
     It 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).

---------
SECTION 2   General Reference Information
---------


TERMINAL MODE KEYSTROKES CHANGES AND ADDITIONS

Alt-E

     Erases the display screen.

Alt-I

     Re-initializes the modem.

UNATTENDED MODE KEYSTROKES CHANGES AND ADDITIONS

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.  See 'Colors' in
     "Configuration File" for related information.

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

     Allows you to kill all mail for a particular node.  When
     executed, you will be prompted for the appropriate
     information.

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.  See 'Colors' in
     "Configuration File" for related information.

Alt-Y

     Polls the boss node (same as Alt-Y in Terminal Mode).


       --------------------------------------------------
       MISCELLANEOUS NOTABLE ITEMS ABOUT BINKLEYTERM 2.40
       --------------------------------------------------

Time Slice Release

     In situations where BinkleyTerm would normally release time
     slice when used in a multi-tasking environment, it will now
     call the MS-DOS scheduler interrupt (int 28h for the
     technical among us) when running in a straight DOS
     environment.  This will improve performance of any
     background tasks like print spoolers and networks.

Mode Switching

     When switching from Terminal Mode to Unattended Mode,
     BinkleyTerm will switch back to using the port shown in the
     configuration file (if changed while in Terminal Mode).

Multi-Taskers

     The PC-MOS operating system is now detected by BinkleyTerm
     at start-up, and if identified, time slice will be properly
     released when appropriate by BinkleyTerm to improve overall
     system performance.

Foreign Language Capabilities

     This release of BinkleyTerm 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.

     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.

Filtering Negotiation Sequences

     In some situations, incoming MNP or V.42 negotiation
     sequences would cause BinkleyTerm to improperly respond to
     incoming callers.  In this release, BinkleyTerm recognizes
     the negotiation sequences (if your modem does not filter or
     use them internally) and will properly discard them.

      ----------------------------------------------------
      DESCRIPTION AND OPERATION OF THE JANUS MAIL PROTOCOL
      ----------------------------------------------------

NOTE:  Janus is an EXPERIMENTAL protocol.  It is not at this
writing a documented FTSC standard.  BinkleyTerm 2.40 represents
the first implementation of Janus in a released software product,
and is providing its first "real world" testing.  With all of
this in mind, it is important to understand that Bit Bucket
Software cannot and does not provide any assurances or guarantees
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 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.

   +--------------------------------------------------------+
   | Bit Bucket Software cannot guarantee the performance   |
   | and applicability of Janus.  If Janus does not work    |
   | for you in your environment, please do not bombard us  |
   | with questions and comments about the protocol; simply |
   | disable Janus again (which it is by default).          |
   +--------------------------------------------------------+

                        Configuring Janus

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 acknowledgement 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 Modifications

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

IF YOU HAVE A HIGH SPEED MODEM (9600 baud or above), then you
might need to use a combination of 'JanusBaud' and 'JanusOK'
statements in your configuration file.  'JanusBaud' should be set
to the highest FULL DUPLEX baud rate you support.  The only
exception is if you have a multi-standard modem.  Use the
following as a guideline:

     Modem Type               JanusBaud Statement
     --------------           -------------------
     V.32 Only                JanusBaud 32767
     Non-V.32 Only            JanusBaud 2400
     Multi-Standard           JanusBaud 2400

NOTE:  32767 is the maximum setting for 'JanusBaud.'

If your high speed modem is single-standard, then 'JanusBaud' is
all you will probably need to use.  Multi-standard modems require
'JanusOK' 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 'JanusOK'
statement.

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

     CONNECT 9600/Arq/V32
     CONNECT 9600/V32

But a connection like this would not take advantage of Janus:

     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 Janus only on the desired connects, like this:

     JanusOK /Arq/V32
     JanusOK /V32

Make certain that you also set 'JanusBaud' no higher than 2400,
or your 'JanusOK' 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 model.  This will allow Janus 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 Janus, even though
PEP mode is not full duplex.  Throughput may not be as high as it
would be on a true full duplex connection.

         ----------------------------------------------
         DESCRIPTION AND OPERATION OF DOMAIN ADDRESSING
         ----------------------------------------------

                          Introduction

Domain addressing is a relatively new concept in FidoNet, and
represents an alternative, more complete method of designating
various networks than the zone method now commonly in use.  In
theory, domain addressing adds an additional "layer" to address
designation that represents a particular network.  Within that
network, zones and nets can all be specified without conflict to
identical zones and nets in other networks.

Domain support in BinkleyTerm requires you to use separate and
distinct nodelist files for different domains.  BinkleyTerm can
now be used much more effectively in multiple network
installations, assuming all the elements are configured properly.

                       'Address' Statement

BinkleyTerm will accept a domain designation in any 'Address'
statement in the configuration file.  A domain is a valid
Internet domain in most cases.  For example, 1:104/501 might have
the following in its configuration file:

     Address 1:104/[e-mail]

At this writing, FidoNet is the only FidoNet technology network
that is listed with Internet, but that is subject to change.
Alternative networks should be designated by their "common" name
followed by ".ftn" (for FidoNet technology network).  For
example, a node in Alternet might be designated as follows:

     Address 7:520/[e-mail]

                       'Domain' Statement

There are several elements to successful domain implementation,
in that nodelist and outbound areas change by domain.  This
information is given by you in the form of 'Domain' statements in
your configuration file.  The format of the 'Domain' statement is
as follows:

     Domain <designator> <abbreviation> [<nodelist>]

The <designator> is the actual domain name.  As shown previously,
FidoNet would be "fidonet.org" and Alternet would use
"alternet.ftn" for the designator.

The <abbreviation> is the abbreviated form of the domain name,
and is LIMITED TO EIGHT (8) CHARACTERS.  This name is passed in
the packet header during a session.  In most cases, this will be
the common name of the network, such as "fidonet" or "alternet"
in our examples.

Finally, the optional <nodelist> parameter provides the base
nodelist name to associate with this domain.  If not given, it
defaults to the same name given for the <abbreviation> parameter.
In our examples, "nodelist" would be used for FidoNet, while
"anetlist" would be used for Alternet.

Here are two complete examples of the use of the 'Domain'
statement, one for FidoNet, one for Alternet:

     Domain fidonet.org fidonet nodelist
     Domain alternet.ftn alternet anetlist

NOTE:  If you designate a domain in your 'Address' statement,
then you must also create a corresponding 'Domain' statement.

                      Outbound Area Naming

The name of the outbound area also changes according the domain.
As always, the outbound area for your primary address (including
domain) is given with the 'Hold' statement.

Outbound areas for other domains take an identical path, except
the name of the last sub-directory is changed to the
<abbreviation> parameter.  For example, if your 'Hold' statement
designates C:\BINKLEY\OUTBOUND for an outbound holding area (and
you are in FidoNet), Alternet outbound mail would be held in the
C:\BINKLEY\ALTERNET.xxx directory instead.  Note that outbound
areas for domains other than your own will ALWAYS have a zone
extension.

                         Working Example

If you're thoroughly confused at this point, possibly a working
example will help.  Assume that a configuration file has the
following:

     Hold c:\bink\outbound
     Address 1:104/[e-mail]
     Domain fidonet.org fidonet nodelist
     Domain alternet.ftn alternet anetlist
     Domain eggnet.ftn eggnet egglist

The nodelist files would be as follows:

     NODELIST.*     (for FidoNet)
     ANETLIST.*     (for Alternet)
     EGGLIST.*      (for Eggnet)

The examples of outbound holding areas are 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\alternet.007     (Alternet Zone 7)
     c:\bink\alternet.059     (Alternet Zone 89)
     c:\bink\eggnet.063       (Eggnet Zone 99)