home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Crawly Crypt Collection 1
/
crawlyvol1.bin
/
bbs
/
bt313a
/
docs
/
bt_user.asc
< prev
next >
Wrap
Text File
|
1992-08-27
|
117KB
|
3,301 lines
BinkleyTerm ST 3.00 - User Guide
**** * * * ******* TM
* * * * *
* * * * ** * * * *** * * * *** * ** *** **
**** * ** * * * * * * * * * * * ** * * *
* * * * * *** * **** * * * **** * * * *
* * * * * * * * * * * * * * * * *
**** * * * * * * **** **** * **** * * * *
*
Version 3.00 ST - User Guide * November 30th 1991
***
A Freely Available FidoNet Compatible Electronic
Mail Interface and Dumb Terminal Package
Software Written by Vince Perriello and Bob Hartman
Atari-ST version by STeven Green.
User Guide written by STeVeN Green
Based on Documentation Written by Alan D. Applegate
Documentation Recompiled by Robert Elsinga
This document Copyright (C) 1991, Steven Green.
Portions of the documentation (C) 1988,1989 Bit Bucket Software, Co.
Software Copyright (C) 1988,1989,1990,1991 Bit Bucket Software, Co.
A Delaware Corporation
All Rights Reserved
Portions of the software (C) 1990,1991 Steven Green
Terms and Conditions Contained Separately
Bit Bucket Software, Co.
427-3 Amherst St., Suite 232
Nashua, NH 03063
"BinkleyTerm" and "Freely Available"
are trademarks of Bit Bucket Software, Co.
User Guide - Page 1
BinkleyTerm ST 3.00 - User Guide
Contents
1. General Information........................................... 4
1.1 How to use this manual? 4
1.2 Acknowledgements 4
1.3 Background 4
1.4 Forward 5
1.5 Introduction 6
1.6 Hardware and Software Requirements 7
1.6.1 Memory Requirements
1.6.2 Modem Requirements
2. Operation as a Terminal Communications Program................ 9
2.1 Terminal Mode Overview 9
2.2 Installation 9
3. Operation as an automated Electronic Mailer...................10
3.1 Unattended Mode Overview 10
3.2 Installation 11
3.3 The BinkleyTerm Concept 12
3.4 How BinkleyTerm handles mail 12
3.5 The Concept of Cost 15
3.6 Windowed Interface 15
3.6.1 Current Settings
3.6.2 Today at a Glance
3.6.3 Pending Outbound Mail
3.6.4 Recent Activity
3.6.5 Transfer Status
3.7 Controlling BinkleyTerm with Batch Files 17
3.7.1 Errorlevels
3.7.2 What errorlevels BinkleyTerm Produces
3.7.3 A bit more about errorlevels
3.7.4 Shell commands
3.7.5 Environment Variables
3.8 Configuration File 22
3.9 Nodelist 22
3.10 Fidouser.lst 23
3.11 Multiple Zones and Domains 23
3.12 Point Systems 24
3.13 Security 25
3.13.1 Prot
3.13.2 Known
3.13.3 Default
3.13.4 Session Passwording
3.13.5 Secured Inbound File Areas
3.13.6 Controlling File Requests
3.13.7 Response File Templates
3.14 BBS Interface 30
3.14.1 BBS Exit
3.14.2 BBS Spawn
3.14.3 BBS Batch
3.14.4 What this really means?
User Guide - Page 2
BinkleyTerm ST 3.00 - User Guide
3.15 External Mail Programs 32
3.16 User Selected BBS Functionality 33
3.17 File Requests 34
3.17.1 Update Requests
3.17.2 Request Response Files
3.18 Function Requests 38
3.18.1 $ Function Requests
3.18.2 + Function Requests
3.18.2 Function Requests Notes
4. Utilities to use with BinkleyTerm-ST..........................41
4.1 Mail Processing 41
4.2 BinkleyTerm shells 42
4.3 CLI/Shells 42
4.4 BBS Software and Utilities 42
4.5 Nodelist Processing 43
4.6 Other Utilities 43
5. BinkleyTerm Support and Problem Solving.......................44
5.1 Trouble Shooting 44
5.1.1 Baud Rate Locking Trouble
5.1.2 Outward Dial aborting
5.1.3 False Call Collision Reports
5.1.4 BinkleyTerm Will Not Recognize Node Addresses
5.1.5 Zone Support Does Not Operate Correctly
6. Glossary......................................................47
User Guide - Page 3
BinkleyTerm ST 3.00 - User Guide
1. General Information
1.1 How to use this Manual?
The documentation for BinkleyTerm is supplied in two parts:
- The User's Guide (BT_USER.DOC) explains how to install BinkleyTerm.
It also describes basic operational procedures. New users may find
some concepts or terminology unfamiliar; a glossary is provided
towards the end of the User's Guide.
- The Reference guide (BT_REF.DOC) is an alphabetically arranged manual
listing all configuration commands and other information that may be
of interest to experienced users and new users alike.
For inquiries, questions or comments regarding BinkleyTerm, please refer
to the User's Guide section "BinkleyTerm Support".
Some portions of the User's Guide are from the original BinkleyTerm 2.30
User's Guide and are Copyright (C) Bit Bucket Software, Co. and Alan D.
Applegate.
1.2 Acknowledgements
Many trademarks, registered trademarks and references to other people's
copyrighted works are referred to in this document. It would be very
lengthy and tedious to list them all. Failure to identify a particular
trademark in this document is not intended in any way to be a claim of
rights to the trademark.
Please note that throughout this documentation, the mention of any
particular software package or system should not be construed as an
endorsement of any kind on the part of the authors.
1.3 Background
BinkleyTerm-ST began life in Spring 1990, as a faithful port from the PC
version of BinkleyTerm 2.40. It was well received within the ST
community and became one of the top two popular FidoNet compatible
mailers for the ST ("The Box" of course being the other one). Users
soon started suggesting new features that they would like to see, many
of which have been implemented. Some of these features include the
EMSI protocol, file requesting limits by time, multiple point and zone
addressing, etc. There are still many more to be implemented in future
versions.
As a result the Atari version is now quite a bit different from the PC
version and some of its new features are yet to be seen in the latest PC
version (2.50).
User Guide - Page 4
BinkleyTerm ST 3.00 - User Guide
1.4 Forward
There is no question that BinkleyTerm-ST is an extremely powerful
communications tool. We have also made no secret of the fact that
BinkleyTerm-ST is an extremely complex communications tool.
A set of documentation the size of an unabridged dictionary (about 150mm
thick or so) would still not address every possible use of BinkleyTerm-
ST in every possible environment. BinkleyTerm-ST will work on several
models of computer and hundred's of different modems. In addition
BinkleyTerm is designed with an open architecture, so it can be used
with several BBS packages, nodelist processors, mail processors, editors
and so on. BinkleyTerm "ports" have been made for entirely different
platforms such as the PC, Amiga, Archimedes, Vax, etc. You begin to get
the scope of what's involved.
This documentation attempts to cover fairly broad generalities in
configuring and operating BinkleyTerm. It cannot and will not cover all
possibilities or circumstances. Hopefully it will serve as a starting
point - a ground level from which you may grow and expand. Further,
this documentation describes only the Atari ST version 3.00 of
BinkleyTerm, earlier versions and those on other hardware platforms are
different and use different configuration options.
Most of the enjoyment of the electronic mail hobby comes from trying new
things - tweaking the system. Although BinkleyTerm is a dependable,
powerful program that is not especially difficult to get going, it does
provide ample opportunity to experiment and have fun.
Still, if you're looking for something that will meld itself into your
computer in just a few minutes and work without modification forever
more, BinkleyTerm should probably not be your first choice. In exchange
for a little complexity, we give you power and an incredible amount of
configurability and compatibility.
If you become frustrated with BinkleyTerm, call on others in your area
who are using it and ask them to help you out. Of course, you will
eventually become an expert yourself! Enjoy it, and delight in the
wonder of technology.
Alan D. Applegate
Vice President,
Bit Bucket Software, Co.
(With minor editing by STeVeN Green)
User Guide - Page 5
BinkleyTerm ST 3.00 - User Guide
1.5 Introduction
BinkleyTerm-ST is an advanced, state-of the-art telecommunications tool.
It is primarily designed for the semi-automated sending and receiving of
electronic mail and files within FidoNet compatible electronic mail
networks.
When used as a mailer, BinkleyTerm is designed to communicate with any
FidoNet compatible mail interface or BBS package. The program uses
standard FidoNet protocol, as well as certain modified protocols
supported by programs such as SEAdog, Opus-CBCS, D'Bridge and FrontDoor.
It also offers easy to use event scheduling, single keystroke spawning
to other programs, support for high speed modems, advanced session
recovery, inbound call collision detection, and much more.
When used as a dumb terminal, BinkleyTerm offers a rich selection of
file transfer protocols for exchanging files with a host system. The
program also offers keyboard macros, optional VT-100 emulation, echoing
of on-line session to a text file or printer, support for baud rates of
300 to 38,400 (with hardware patch to an ST) and more.
BinkleyTerm can be used as a dumb terminal program exclusively, as a
mail interface for a Point system, or as a front end mail interface for
an electronic bulletin board system (BBS).
Mail interface and dumb terminal operations can be switched in and out
with a minimum of effort providing dual functionality.
BinkleyTerm endeavours to provide you with the widest possible variety
of advanced features, combined with solid and efficient operation.
User Guide - Page 6
BinkleyTerm ST 3.00 - User Guide
1.6 Hardware and Software Requirements
- An Atari ST/STe/TT/MegaSTe with at least 300K of free RAM (a 1 Meg
machine (e.g. 1040ST) is really recommended to make full use of it).
- TOS 1.0 or greater
- An auto-dial, auto-answer modem; Hayes compatibility is recommended
(see section 1.7 "Modem requirements" below).
- A single sided disk drive (terminal mode)
- A double sided disk drive (for point systems that don't need a
nodelist)
- A Hard disk for Nodes and point systems that use a nodelist. The
bigger the better!!!
- Basic knowledge of computer based telecommunications.
- Various utility programs depending on your application, these will be
described later.
1.6.1 Memory requirements
BinkleyTerm requires approximately 200K of RAM in any operational mode.
When used in unattended (mailer) mode additional memory sufficient to
hold the nodelist index file (usually NODELIST.IDX) is required.
A minimum of a 1 Meg machine is recommended if you are using BinkleyTerm
from within a BBS program such as ///Turbo Board, or if you wish to
spawn out to other programs from within BinkleyTerm.
When used as a front-end mailer for a BBS system such as QuickBBS-ST, it
is highly recommended that the 'BBS Batch' method of accessing your BBS
be implemented for the most efficient use of memory. Please refer to
the applicable sections of the documentation for further information.
1.6.2 Modem Requirements
A modem that is generally "Hayes compatible" is required for BinkleyTerm
operation. Most popular modems meet this requirement. Since you
configure the various modem commands, it does not need to be 100% Hayes
"AT" command set compatible, but it does need to use the "AT" style of
issuing modem commands.
Most modems are capable of returning VERBAL (full words) or NUMERIC
(numbers only) response codes; the modem must be configured for VERBAL
codes only (typically "AT V1" on most Hayes compatible modems).
BinkleyTerm has been programmed to respond to the following modem
response strings: NO ANSWER, BUSY, RING, VOICE, NO DIAL TONE, NO
DIALTONE, ERROR, NO CARRIER, DIAL TONE and DIALLING. Also the following
are recognised but ignored: RING, RINGING and RING RESPONSE.
With the exception of the CONNECT response, any other data provided by
the modem after a given response string is ignored. For example, "NO
CARRIER DETECTED" would be handled the same way as "NO CARRIER".
User Guide - Page 7
BinkleyTerm ST 3.00 - User Guide
Since BinkleyTerm uses the CONNECT string to determine connection baud
rates, the modem should be capable of sending such strings. Generally,
CONNECT is a default, and indicates a 300 baud connection. Other
possible connections are CONNECT 1200 for a 1200 baud connection, etc.
BinkleyTerm also recognises the responses CONNECT 1275 and V23.CONNECT
for split-speed modems. In addition extra information such as
/Arq, /Hst, /V32, /V42/ etc, are recognised for use with the modemtrans
feature (see the reference guide).
To obtain the correct responses from a Hayes compatible modem, you would
typically use the AT X command, e.g. "AT X4".
If you are experiencing modem difficulties then try some of the
following configuration file statements: SlowModem, SameRing, NoCollide.
Also try changing the 'answer' statement. Refer to the reference guide
to see what these do. You're best chance though of sorting it out is to
locate someone else using the same type of modem with BinkleyTerm and
ask for help.
User Guide - Page 8
BinkleyTerm ST 3.00 - User Guide
2. Operation as a Terminal Communications Program
2.1 Terminal Mode Overview
This section describes the installation and operation of BinkleyTerm in
Terminal mode.
BinkleyTerm's Terminal mode offers functionality similar to other
programs such as Uniterm, Flash, Dterm, etc. You can use your computer
and modem to call out to on-line services and electronic Bulletin Board
Services (BBS).
BinkleyTerm offers a wide selection of file transfer protocols for
exchanging files with remote systems (uploading and downloading),
including Xmodem, Ymodem and Zmodem. This includes Zmodem auto-detect
and Zmodem error-recovery.
2.2 Installation
- Create a new folder on your hard disk or format a blank disk.
- Copy the following files into the folder or onto the disk:
BT.TTP
BINKLEY.CFG
BINKLEY.LNG
- Using a text editor (e.g. Tempus or MicroEmacs) or word processor in
ASCII mode (e.g. 1st Word), edit BINKLEY.CFG to reflect the way your
system is setup. Refer to the comments included in the provided
BINKLEY.CFG and the Reference Guide. In particular you should make
sure that the "Unattended" line is deleted or commented out. You may
also need to create a DOWNLOAD directory depending on what you set
the "DownLoad" line to in BINKLEY.CFG.
- Double click on BT.TTP and press return at the TTP dialogue box.
- Press the Help key for a brief help screen.
User Guide - Page 9
BinkleyTerm ST 3.00 - User Guide
3. Operation as an automated Electronic Mailer
3.1 Unattended Mode Overview
This section describes the installation and use of BinkleyTerm in
Unattended mode. This mode is used when BinkleyTerm is to function as a
front-end mail interface, whether in a BBS or "Point" environment. The
glossary provides information on BBS and Point systems.
BinkleyTerm, in this operational mode, provides functionality similar to
that provided by The Box, and by programs such as FrontDoor and D'Bridge
on the PC, and by Trapdoor on the Amiga, and other FidoNet compatible
mailers. BinkleyTerm answers the telephone, and exchanges mail with
other compatible mail interface packages, or in the case of a human
caller, passes control to a BBS system.
User Guide - Page 10
BinkleyTerm ST 3.00 - User Guide
3.2 Installation
Due to the complexity and widely varying setups, only a generalised
broad installation procedure is given here. For more information you
will need to read the reference guide and maybe ask for help from other
systems running BinkleyTerm.
The use of a BinkleyTerm shell program such as BTS (Part of the ACS
package) or Avalon will simplify the installation. You should refer to
the instructions included with these utilities. These utilities and
others that can be used with BinkleyTerm will be described later in this
User Guide.
- Create a new folder on your hard disk or format a blank disk.
- Copy all the files from this distribution into the new folder or
disk.
- Using a text editor (e.g. Tempus, MicroEmacs or STedi) or a word
processor in ASCII mode (e.g. 1st Word), edit the file BINKLEY.CFG.
Refer to the comments in the provided BINKLEY.CFG and to the
reference guide for guidance.
- Create any folders that you have specified in BINKLEY.CFG, these will
include:
Netfile
Hold
DownLoad
Nodelist
- Obtain and setup any necessary utilities for packing and unpacking
mail. Install them as explained in the instructions with these
packages.
- Obtain a current nodelist and process it (e.g. with ParselST). This
is not required if you are a point system and have setup BINKLEY.CFG
correctly.
- Edit BINKLEY.EVT according to how you wish your system to run. (Refer
to the reference guide for information).
- Set up any batch files or shell programs to control how BinkleyTerm
is to work.
- Start your system. Test a remote call if possible.
- Pressing the Help key will display a brief help file of commands
available in unattended mode.
Setting up can be quite a complex procedure, it is best if you read all
the documentation thoroughly, obtain some example configuration files
from someone else with a similar setup, don't be afraid to experiment
and set it up a bit at a time.
User Guide - Page 11
BinkleyTerm ST 3.00 - User Guide
3.3 The BinkleyTerm Concept
It is important to remember that BinkleyTerm is a mailer program with a
completely open architecture. As such, BinkleyTerm can be operated with
a tremendous variety of BBS systems, mail packing and unpacking
programs, and accessories.
BinkleyTerm will answer the telephone and respond to another mail
program. Mail will be placed in an incoming files area. If the caller
is human, control is passed entirely to the BBS program, if one is
installed. It is the responsibility of third-party software to unpack
the mail received, and add it to your message base.
On the outward side, BinkleyTerm uses an outbound holding area to hold
outward mail. It is the responsibility of third-party packing software
to pack new messages into the required format, and place them in the
outbound area.
BinkleyTerm neither packs nor unpacks mail. Allowing this
functionality to be provided by other software allows BinkleyTerm to be
compatible with practically any BBS software, regardless of message base
structure. Some of the other utilities that can be used with
BinkleyTerm will be described later on in this document.
3.4 How BinkleyTerm handles mail
Understanding a bit about how BinkleyTerm handles outbound mail may help
you to understand how to use it better. It will not matter if you don't
understand everything in this section, but reading it quickly now and
then referring to it later if you have a problem may help you if you get
stuck.
The driving forces of outbound traffic are filenames.
You will have set up some special folders for outbound packets using the
"Hold" configuration line in BINKLEY.CFG. If you are using multi-zones
then you will have several folders, one for each zone, and if you are
using Domains then you will also have separate directories for each zone
within each domain. See the reference guide for information.
User Guide - Page 12
BinkleyTerm ST 3.00 - User Guide
Example, if you are in Zone 2 and in BINKLEY.CFG, you have the lines
Hold c:\bt\hold
Domain Fidonet.org FidoNet nodelist
Domain nest.ftn nest nestlist
Domain Lifenet.ftn lifenet lifelist
Then you will have the folders:
c:\bt\hold Default folder for zone 2 (Europe)
c:\bt\hold.001 Zone 1 (North America)
c:\bt\hold.003 Zone 3 (Australasia)
c:\bt\hold.004 Zone 4
c:\bt\hold.005 Zone 5
c:\bt\hold.006 Zone 6 (East Asia)
c:\bt\nest.05a NeST zone 90 (Note "5A" is 90 in base 16)
c:\bt\lifenet.04d LifeNet zone 77 ("4D" is 77 in base 16)
Your mail exporting program will place netmail packets, compressed mail
packets and other network files in these folders for BinkleyTerm to
send.
The filenames of the packets tell BinkleyTerm how to treat the different
packets. A typical packet might have the name:
00FC0019.OUT
This tells BinkleyTerm that it is intended for node 252/25.
(00FC/0019 in Hexadecimal). The ".OUT" extension means that it is an
uncompressed netmail packet.
Packet extensions are:
.HUT Uncompressed packet, to be left on Hold for the other system
to pick up.
.CUT Uncompressed packet to be sent to another system using Crash
or Continuous mail (i.e. it should be sent immediately).
.DUT Uncompressed packet to be sent Direct. Exactly when it can
be sent is controlled using BinkleyTerm's event file
BINKLEY.EVT.
.OUT Normal uncompressed packet, treated identically to DUT.
Some utilities will change the extensions for you at different times of
the day so that you only send mail at particular times. Refer to the
instructions about "Routing" in the documentation for your mail
exporter.
User Guide - Page 13
BinkleyTerm ST 3.00 - User Guide
Files and compressed mail can be sent using File attach or FLO files.
These have a similar naming convention to the .OUT files:
.FLO Normal flow file
.HLO Flow file on Hold
.CLO Crash or Continuous flow file
.DLO Direct flow file
A flow file is an ASCII text file listing the files to be sent to
another system. Each filename may also have a special character
preceding it. Example,
#c:\bt\hold\0000fc9c.mo1
^c:\myfiles\wizzle.doc
c:\pascal\notes.doc
The '#' tells BinkleyTerm to truncate the file after it is sent, i.e.
set it to zero bytes length. This option is sometimes used for archived
mail to prevent duplicate filenames.
'^' tells BinkleyTerm to delete the file after it is sent. This is also
used for compressed mail to avoid filling up your outbound areas, as
well as for temporary files (e.g. TIC files).
Other special characters include
';' A comment. BinkleyTerm ignores the rest of the line.
'~' File has already been sent. BinkleyTerm sets this as it sends
each file so that if the session is aborted it doesn't send the
same files on the next call!
When using IOS another file-type for compressed mail is used, these are:
.OAT Normal Archived Packet
.HAT Held Archived packet
.DAT Direct Archived packet
.CAT Crash/Continuous Archived Packet.
The Archived mail address is encoded differently to allow for point
addressing. This takes the form:
aaabbbcc.OAT
aaa = The Net encoded as base 36.
bbb = Node in base 36
cc = Point in base 36.
e.g. a packet for 252/25.10 would be called:
07000P0A.OAT
(070 = 252 in base 36, 00P = 25, 0A = 10).
The advantages of this format is that it enables points to call points
from other point networks directly instead of having to go through their
boss. Another advantage is that you don't need to use FLO files,
resulting in less clutter in the outbound folders and less time for
BinkleyTerm to find the files. Future versions of BinkleyTerm-ST will
extend this format to include file requests and unarchived mail.
User Guide - Page 14
BinkleyTerm ST 3.00 - User Guide
3.5 The Concept of Cost
One of the prime considerations with BinkleyTerm is sending mail for the
least cost. Cost is, of course, determined by the nodelist entry. With
a properly compiled nodelist, local FidoNet nodes have '0' in the cost
field for their nodelist entry (assuming local calls are free of
charge). Other entries have cost fields that realistically reflect the
actual cost of sending mail to a particular node.
In most areas, it is cheapest to call during the evening or nighttime.
Therefore, BinkleyTerm is normally set-up to send such mail only during
nighttime hours.
The 'L' flag used when scheduling events designates 'local only.'
As already mentioned, nodes with a '0' cost field are assumed to be
local. When the flag is applied to an event, only local calls are made.
The 'L' flag should be used whenever it costs the most money to make
calls, and removed for events during which calls are cheapest. More
about this is in the Reference Manual section, "Scheduling Events."
3.6 Windowed Interface
BinkleyTerm features a windowed user interface. The windowed interface
provides "at-a-glance" convenience for watching mail sessions in
progress, as well as determining what activity has taken place with the
system recently.
There are 5 important windows displayed on the screen.
3.6.1 Current Settings
This window contains various information about your system, including
the current data and time, current event, current baud rate, status and
amount of free memory.
The current event line features a number and a list of event flags. The
number corresponds to which entry in the BinkleyTerm event file
BINKLEY.EVT covers the current event. 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:
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 Continuous/Crash Mail.
See the section "Scheduling Events" in the Reference Guide for more
information about these flags.
User Guide - Page 15
BinkleyTerm ST 3.00 - User Guide
3.6.2 Today at a Glance
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 1st line, "BBS/Mail", lists how many BBS calls, mail calls and
external mailer calls have come in separated by a slash '/'. For
example 2/15/1 would indicate 2 BBS callers, 15 mailer calls and 1
external mailer call (an external mailer could be a UUCP mailer, a FoReM
FNET mailer, etc).
The 2nd line, "Calls Out", lists the number of dial attempts that have
been made by your system, successful or otherwise.
The 3rd line, "Good/Cost", shows how many successful calls have been
made and the cumulative cost of them all. For example, 3/100 would
indicate 3 successful calls, which have cost 100 units (if you have set
up the cost table correctly [in ParselST.cfg or BINKLEY.CFG] then this
should correspond to actual currency, e.g. cents in America, pence in
UK). The cost calculation assumes that the amounts given in your cost
table are in cost-per-minute.
The 4th Line, "Files I/O", shows how many files have been received and
sent, e.g. 12/3 indicates that you have received 12 files and sent 3.
Finally the 5th line indicates the last session. If it was another
FidoNet mailer then the other system's address will be displayed,
otherwise it might indicate that it was a BBS caller or external mailer.
3.6.3 Pending Outbound Mail
This window displays a list of systems for whom mail is waiting along
with related information. The window can be scrolled using the cursor
arrow keys.
Up Up one line
Down Down one line
Shift-Up Up a page
Shift-Dn Down a page
Home To top
The nodes are sorted in numerical order, but systems that are waiting to
be called are listed first.
The actual information displayed depends on whether you have the
"NiceOutbound" configuration command in BINKLEY.CFG (this can be toggled
by pressing Alt-F).
User Guide - Page 16
BinkleyTerm ST 3.00 - User Guide
With NiceOutBound disabled then all you get is the system name and flags
indicating the status of mail for that system:
C Crash/Continuous
H Hold
D Direct
N Normal
R File Request
- System will not be called during this event.
There may instead be a message:
NoConn BinkleyTerm could not connect to this system
Tried BinkleyTerm has called, but mail is still waiting.
UnKnown System is not in NodeList
When NiceOutbound is enabled then the number of files, size and age of
the files are displayed. The disadvantage of using this option is that
it can take BinkleyTerm some time to scan all the outbound folders for
this information.
Pressing Alt-Z zooms the pending Outbound Window to fill up the screen,
where even more information is displayed, including the number of calls
made to each system.
3.6.4 Recent Activity
This window displays information about what BinkleyTerm is doing, as it
happens. This information will also be written to the log file
depending on the current "LogLevel" setting.
3.6.5 Transfer Status
During file transfers, this window displays information about the
transfer, such as the filename and how many bytes have been sent.
3.7 Controlling BinkleyTerm with Batch Files
Point systems or mail-only nodes may be able to use a Graphical shell
program such as BTS (part of the ACS package) or Avalon. These are GEM
based programs that let you set up and control BinkleyTerm. You should
refer to the documentation provided with these programs for more
information and you can probably skip the rest of this section.
BBS systems and more complex nodes will need to use batch files to
control BinkleyTerm's operation. Typically these will be used to run
BinkleyTerm, load up the BBS for human callers, run mail processing
utilities after a call, etc.
You will first of all need to find a CLI or shell program. There are
two types of CLIs: MSDOS style and Unix style. Some people prefer one
or the other. If you are using FoReM or ///Turbo-board then there is
an MSDOS style shell built into the BBS. Users of other BBS systems
(e.g. QuickBBS) must use a separate CLI. Example CLIs that may be used
include:
Pcommand : Very basic MSDOS style CLI.
Craft : Very good commercial Unix style shell.
User Guide - Page 17
BinkleyTerm ST 3.00 - User Guide
There are others that may possibly be used, but I don't have experience
of using them with a BBS. Basically any shell or CLI that will run
batch or script files, has conditional flow control and supports
errorlevels and environment variables should work. You should probably
ask someone near you what they use.
If you are not familiar with CLIs and Shells then it is highly
recommended that you find someone nearby to provide you with their batch
files.
3.7.1 Errorlevels
One of the basic concepts of using batch files to control BinkleyTerm is
that of errorlevels. An errorlevel is simply a numerical value that a
program may "return" when it terminates. A better term might be an exit
code, as it does not necessarily mean that there has been an error if
it set!
Batch and script files can make use of the errorlevel to decide what to
do next.
If you are using an MSDOS style shell (e.g. PCOMMAND or ///Turbo board's
built-in shell) then you can use batch files such as:
:start
myprog -p1
IF ERRORLEVEL 2 goto process
IF ERRORLEVEL 1 goto start
IF ERRORLEVEL 0 goto end
:process
proc -c -d1
IF ERRORLEVEL 1 goto start
IF ERRORLEVEL 0 goto end
:end
I'm sure you can work out what this batch file will do. If not refer to
the documentation that came with your CLI or shell. What will happen is
that the program "myprog" is executed, and then when it exits control
will pass to a different part of the batch file depending on the exit
code.
User Guide - Page 18
BinkleyTerm ST 3.00 - User Guide
If you are using a Unix style shell then you should refer to the
documentation that comes with it. A typical method of getting the
errorlevel is from the variable $status, e.g. the above example as a
Craft script file might be something like:
while ( 1 )
myprog -p1
switch ( $status )
case 2:
proc -c -d1
if ( $status == 0 ) exit
breaksw
case 0:
exit
endsw
end
3.7.2 What errorlevels BinkleyTerm Produces
There are 4 general types of errorlevel:
Sysop-Initiated
Function keys and Alt-X.
Pressing a function key causes BinkleyTerm to exit with a value of 10
times the function key number. e.g. F1 returns 10, F2 return 20,
etc, F10 returns 100.
Alt-X causes a value of 1 to be returned.
Sysop-Defined
En= exits used with event scheduling (See reference Guide), external
mail exits (see "ExtrnMail" in the reference guide),
Caller-Initiated
A non-mail caller returns the baud rate divided by 100 (e.g. 300 baud
returns 3, 2400 baud returns 24, etc). NOTE: Some MSDOS style shells
may restrict errorlevels to between 0..255 in which case 38400 baud
returns 128 (384-256) instead of 384.
System-Generated
BinkleyTerm cannot run for some reason (e.g. it cannot find itself in
the nodelist).
User Guide - Page 19
BinkleyTerm ST 3.00 - User Guide
The following errorlevels are hard coded into BinkleyTerm, but the
others may be defined by yourself using the configuration files:
Error-
Level Means Caused By
-------- ----------------- -----------------------------------------
1 Exit Alt-X Keypress
3 300 bps Call Non-mail call at 300 Baud
10 ** F1 key pressed
12 1200 bps Call Non-mail call at 1200 baud
20 ** F2 key pressed
24 2400 bps Call Non-Mail call at 2400 baud
30 ** F3 key pressed
40 ** F4 key pressed
48 4800 bps Call Non-Mail call at 4800 baud
50 ** F5 key pressed
60 ** F6 key pressed
70 ** F7 key pressed
72 7200 bps Call non-Mail call at 7200 baud
80 ** F8 key pressed
90 ** F9 key pressed
96 9600 bps Call Non-Mail call at 9600 baud
99 ExtrnMail Default External mailer return code
100 ** F10 key pressed
120 12000 bps Call Non-Mail call at 12000 baud
128* 38400 bps Call Non-Mail call at 38400 baud
144 14400 bps Call Non-Mail call at 14400 baud
192 19200 bps Call Non-Mail call at 19200 baud
254 Error Address not found in NodeList
-2* Error Address not found in NodeList
255* Error General error
-1* Error General error
384* 38400 bps Call Non-Mail call at 38400 baud
* Some shells may only allow errorlevels between 0 and 255. In these
cases values greater than 255 will be logically ANDed with 255, thus
-1 becomes 255, -2 becomes 254 and 384 becomes 128 (384-256). Refer
to your shell's documentation to find out if this happens. The Craft
Shell will return the full value (i.e. 384 for 38400 baud), but I
don't know about any others.
** The functionality of function keys is entirely up to you.
3.7.3 A bit more about errorlevels
By using the En= errorlevels associated with BinkleyTerm's event
handling, you can control how your system works. If you want something
to happen a particular time each day, then select a unique "E1=" exit
code for that task. The task can be set to occur periodically
throughout each day, once-per-day, once-a-week or on selected days
within the week. Similarly by having a variety of E2= and E3= codes,
you can use different mail unpacking routines at different times. Refer
to the section "Scheduling Events" in the Reference Guide for details.
User Guide - Page 20
BinkleyTerm ST 3.00 - User Guide
The 10 F-keys errorlevels can be quite handy to run often used
utilities, e.g. to run an editor, Binkley-Shell or to load NeoDesk.
The external mailer option is intended for invocation of an external
mail handling program such as a UUCP mailer or the FoReM FNET mailer.
It is invoked by receiving a predefined string of characters. It can
also be used to set up multiple BBS installations, allowing which BBS
is loaded to be selected by the user. This is covered in more detail in
the sections "External Mail Programs" and "User Selected BBS
functionality" elsewhere in this document.
3.7.4 Shell Commands
Shell commands are programs or batch files that are run from within
BinkleyTerm. These include 10 shell commands invoked by pressing Alt-
Function keys, and defined using the "Shell" command in BINKLEY.CFG, as
well as the "Editor", "Packer", "Aftermail" and "Cleaner" commands.
The behaviour of shell commands depends on what type of shell you are
using. If the command is the full pathname of an executable program
(i.e. it ends in .PRG, .TOS or .TTP) then it will be executed directly
by GEMDos. Otherwise, if you are using a resident shell that can be
called through the shell_p vector at 0x4f6, then your command will be
executed directly by the shell (Craft and Gulam will work like this).
If your shell sets the COMSPEC or SHELL environment variables then the
shell will be invoked as either "$COMSPEC /c commandline" or "$SHELL -c
commandline".
Because shell commands are executed from within BinkleyTerm, there will
be less memory available than when using errorlevels.
3.7.5 Environment Variables
Environment variables should be set up in your startup batch file.
Refer to the section about environment variables in the reference guide.
In particular it is a good idea to set BINKLEY to point to where
BinkleyTerm's data files are located and also RXBUF and TXBUF. The
COMSPEC and SHELL variables are normally defined by the shell program,
so you shouldn't need to set these yourself. Different shells define
these in different manners, refer to your documentation for more details
about setting environment variables.
e.g.
set BINKLEY = f:\bt
set RXBUF = 8192
set TXBUF = 512
or alternatively:
setenv BINKLEY f:\bt
User Guide - Page 21
BinkleyTerm ST 3.00 - User Guide
3.8 Configuration File
Most BinkleyTerm parameters are set through a configuration file.
By default, the configuration file is named BINKLEY.CFG, and is expected
to be available unless a different configuration file is specified on
the command line.
A sample BINKLEY.CFG files is included with the distribution package.
You can edit the file with any plain text editor such as Tempus,
MicroEmacs or Craft's STedi; or with a word processor in ASCII mode such
as 1st Word. The Reference Guide contains a complete listing of all
BinkleyTerm configuration statements and their proper use. It is
recommended that you read through each statement's description and
decide if you need it or not.
BinkleyTerm directly uses the raw configuration file, and each time the
program in invoked, BinkleyTerm will scan and process the file, setting
internal values to those that you have selected.
3.9 NodeList
The FidoNet Nodelist is the glue that holds FidoNet together. It is
vitally important that all nodes keep up to date with the latest
nodelist. Most of the FidoNet coordinator positions are there for the
purpose mainly of updating and distributing the nodelist. Because the
nodelist is very big (just over 1 Megabyte with about 12000 systems at
the time of writing) it is not practical to distribute the entire
nodelist every time it is changed, so a "NodeDiff" file is distributed
each week, which contains instructions for updating from last week's
list to the current one. It is the duty of your Net Coordinator to make
sure that this is available to you every week. It is very important that
you process the list every week and don't miss out on any of the diff
files.
The nodelist and nodediff's are referred to as "raw" nodelists as they
are simply ASCII files. Most mailers and mail processing software
require it to be processed (or compiled) into binary form so that
entries can be accessed more easily.
BinkleyTerm is capable of using a variety of compiled nodelist formats,
but as far as the ST is concerned, the only useful format is the Version
6 format. To select this you must make sure that the line "NewNodeList"
is included in BINKLEY.CFG and that your nodelist processor produces
this format. At the time of writing, the only nodelist processor
available for the ST that works with BinkleyTerm-ST is ParselST.
However in future versions of BinkleyTerm-ST there will be support for
other nodelist processors.
Point systems do not require a nodelist at all as long as their bosses
phone number and password are included in BINKLEY.CFG. See the section
on "Point Systems" later in this document. There is also a suite of
programs available for points called FIDO24 (because it was designed for
REGION 24 [Germany] point systems), which can help points install
smaller nodelists.
User Guide - Page 22
BinkleyTerm ST 3.00 - User Guide
3.10 FidoUser.LST
The nodelist processor may also be used to produce FIDOUSER.LST, a list
of sysop names and node addresses, that BinkleyTerm can use when
dialling out. When this file is available to BinkleyTerm (in the
nodelist folder), then at most places where you can type in a node
number you can instead type in a sysop's name. This applies to both
Unattended and Terminal Modes, while polling or dialling a system.
3.11 Multiple Zones and Domains
Zones are a high-level addressing scheme devised for use within FidoNet.
In a full FidoNet address, such a 1:104/36.0, '1' would be the zone,
'104' the net, '36' the node number, and '0' the point number.
Currently, zone addressing is not supported within the FidoNet message
or packet structure, allowing software such as BinkleyTerm to provide
only "kludged" support of zones. BinkleyTerm offers such support, and
endeavours to make it as seamless as possible.
If for some reason you do not wish zone support to be active, place the
statement 'NoZones' in your configuration file. This will cause
BinkleyTerm to essentially "turn off" zone support. If you intend not
to use zone support, then use the 'NoZones' configuration file
statement.
If you have not used the 'NoZones' statement, BinkleyTerm will assume
that a full, zone-based nodelist is available for its use. For
information on how to properly compile a nodelist for BinkleyTerm, refer
to the section "Nodelist" for more information.
When attempting to send mail to nodes in other zones, BinkleyTerm will
assume that mail for other zones will be held in separate outbound areas
by zone number. For example, if your outbound mail directory is
C:\BT\OUTBOUND, mail for your zone will be held there. However, mail
for nodes in zone 2 would be expected in C:\BT\OUTBOUND.002, mail for
zone 3 would be expected in C:\BT\OUTBOUND.003, and so on. This example
is for zone 1.
The zone number for which your default outbound directory applies is
determined by the FIRST appearance of the 'Address' statement in your
configuration file. Subsequent 'Address' statements identify your
alternate identities within other zones (and/or networks). For example,
if the first 'Address' statement designates an address in zone 2, then
the outbound area designated by the 'Hold' statement in your
configuration file is the default, and mail to other zones would require
their own distinct outbound areas with extensions that match the zone
number.
The multi-zone outbound areas are in hexadecimal. For example, the
outbound area for zone 10 would be C:\BT\OUTBOUND\.00A. Using this
method, it is possible to support up to 4,095 zones.
User Guide - Page 23
BinkleyTerm ST 3.00 - User Guide
Operation of a system within multiple networks is becoming increasingly
popular. Normally, networks such as NeST, LifeNet, ChatNet and so on
are implemented as separate zones. To facilitate operation of a
BinkleyTerm system within multiple networks, you may specify a separate
system address, each with a different zone.
For example, if you wish to use a different address for FidoNet
(currently zones 1, 2, 3, 4, 5 and 6) and for two alternative networks,
you might have the following in your configuration file:
Address 1:1010/89.0
Address 9:569/999.0
Address 11:334/1.0
If your system connects with a system in zone 9, your system will
identify itself as 9:569/999. If connected with a zone 11 system, it
will identify itself as 11:334/1. The first 'Address' statement is the
default, and callers in zone 1 (and any zones other than 1, 9 and 11 -
those specified with 'Address' statements) would find your system
identified as 1:1010/89.
Domain addressing adds yet another level of addressing to specify
different networks. Within each network, zones and nets can all be
specified without conflict to identical zones and nets in other
networks.
Domain support in BinkleyTerm requires that you use separate nodelist
files for different domains. BinkleyTerm can now be used much more
effectively in multiple network installations, assuming it is configured
correctly.
A full address with a domain is written like 1:234/56.7@fidonet.org,
where "fidonet.org" is the domain. Other FidoNet compatible domains tend
to have the extension ".ftn", e.g. "alternet.ftn".
To use domains you must use the "Domain" command in BINKLEY.CFG as
described in the reference manual. To process separate nodelists you
will have to patch a copy of parselST.TOS to read and write different
filenames. All of the nodelists must be kept in BinkleyTerm's nodelist
folder and you must create the neccessary outbound folders.
My advice is to only use Domain's if you have a good reason to. A lot
of mail processing software does not work properly with it, and it can
be quite tricky to set it up.
3.12 Point Systems
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. Since point
addressing is not part of the FidoNet standard, certain "Kludges" must
be used in order to handle a point network.
User Guide - Page 24
BinkleyTerm ST 3.00 - User Guide
First of all you must find your "fakenet" address. Point systems should
ask their boss. A node should theoretically ask the international
coordinator to assign one, but in practice you can just make one up.
For example I use 25225 (based on my node address of 252/25). In fact
many mailers don't even use fakenet addresses any more and the complete
4D address is passed in the session handshake, but you will still need
to define your fakenet address.
Once you have your fakenet address then you must place it after your
address in BINKLEY.CFG,
e.g. for a node
Address 2:252/25 25225
and for a point:
Address 2:252/25.10 25225
where 10 is the point number assigned to you.
What happens here is that in some mail sessions the addresses may be
replaced by 25225/10 and 25225/0.
If you are a point and you don't want to use a nodelist then you must
also add your boss's phone number after the fakenet address, e.g.
Address 2:252/25.10 25225 0793-849044
and define your session password with the KEY statement, e.g.
Key !PASSWORD 2:252/25
It is possible to be a point in more than one system by simply defining
more addresses, e.g.
Address 2:252/25.10 25225 0793-849044
Address 2:250/123.31 25023 061-429-9803
Key !PWD1 2:252/25
Key !PWD2 2:250/123
Actually a lot is possible using the Key statement and it is now
possible for one point to directly poll another point in a different net
if required. Please read about the "Key" statement in the Reference
Guide.
3.13 Security
In the ideal world, we would not need locks, police, or jails; there
wouldn't be crime. But we don't live in an ideal world, and for this
reason, BinkleyTerm offers a selection of features that are intended to
offer your system a certain level of security against "electronic mail
crime."
The existence of security features is not intended to evoke fear.
Chances are excellent that you will have no need for security features
in most cases. But just as high crime areas see more locks and iron
gates than low-crime areas, the choice of how much security to put in
place is up to you, and is based on your needs and experience.
User Guide - Page 25
BinkleyTerm ST 3.00 - User Guide
BinkleyTerm's internal security is based on a simple principle.
With the exception of session passwording, for each secured feature (all
of which are specified within the configuration file), there is a
default statement. When you implement no security features, the default
statement is used to specify a particular feature's configuration.
3.13.1 Prot
When security is implemented, however, two more statements are used in
addition to the default. One type of statement, known as "Prot" for
"protected," describes a group of systems with which you have
implemented session passwording. These links are "protected" by
passwords.
When session passwording is implemented, unless a password is matched
when connecting to a protected system, a mail session is aborted.
"Protected" or "Prot" systems are the top-level, or "most favoured"
situations, since you generally know the other person at the other end
(a prerequisite to establishing a password).
3.13.2 Known
The second type of statement is called "Known" and describes systems
that are listed in the nodelist ("known" to you) but with whom you have
not established a session password. These are links with listed
systems, but links that are not password protected. This group
represents the middle-level of security.
3.13.3 Default
When you use a Prot and/or a Known security feature, then the default
statements all take on a new meaning - that of unknown systems. The
defaults are used for links that are not in the nodelist, and therefore,
cannot have a session password established. 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.
3.13.4 Session Passwording
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, passwording can be automatic. Simply use the
'Key' configuration file option, and choose a password. Make sure your
Boss also uses the same password.
User Guide - Page 26
BinkleyTerm ST 3.00 - User Guide
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 during processing. Refer to the
documentation for your nodelist processor. Or you can use the 'Key'
configuration option to save having to recompile the nodelist!
When talking with other systems that use the YooHoo or EMSI session
negotiation methods, full, two-way protection is available. The systems
connect and exchange the password when the YooHoo takes place. 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 SEAdog and compatible systems, password matching
takes place only when you are picking up mail from the remote system.
You may send to a SEAdog 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 place the call (as stated above, the idea is that
you know who you're calling, not who's calling you).
3.13.5 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 passwording, 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.
User Guide - Page 27
BinkleyTerm ST 3.00 - User Guide
The following list shows the various security levels and the
configuration file statements that define their respective inbound
paths:
Prot 'ProtInbound'
Known 'KnownInbound'
Default 'NetFile'
In a typical installation secured in this manner, mail will
automatically be 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 FSC-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.
Secured inbound file areas simply provide another, extra measure of
handling potential security problems associated with the reception of
"rogue" or "planted" mail.
3.13.6 Controlling File Requests
BinkleyTerm offers a method of establishing limitations on file requests
received from systems 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 section "File Requests."
The following table lists these possibilities, the file types (as
described in the section "File Requests") and the respective
configuration file statement used:
Prot ABOUT 'ProtAbout'
AVAIL 'ProtAvail'
OKFILE 'ProtReqList'
Maximum 'ProtReqLim'
Maximum 'ProtMaxBytes'
Maximum 'ProtMaxTime'
Known ABOUT 'KnownAbout'
AVAIL 'KnownAvail'
OKFILE 'KnownReqList'
Maximum 'KnownReqLim'
Maximum 'KnowMaxBytes'
Maximum 'KnownMaxTime'
User Guide - Page 28
BinkleyTerm ST 3.00 - User Guide
Default ABOUT 'About'
AVAIL 'Avail'
OKFILE 'Okfile'
Maximum 'MaxReq'
Maximum 'MaxBytes'
Maximum 'Maxtime'
Essentially, the default files and configuration file statements
described in the section "File Requests" are used for all file requests
by default unless a higher "Known" or "Prot" statement is used.
Note that all file request controls apply to update requests and
function requests as well.
3.13.7 Response File Templates
Refer to the section "Request Response Files" for information on their
operation and use.
It is possible to designate separate response file templates for each of
the three security levels. Generally, you won't want or need to do this
unless security controls on file requests have been implemented.
The security levels and their respective configuration files statements
for secured response file templates are:
Prot 'ProtReqTpl'
Known 'KnownReqTpl'
Default 'ReqTemplate'
User Guide - Page 29
BinkleyTerm ST 3.00 - User Guide
3.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 you use is determined
by a configuration file statement (refer to the Reference Guide for
details).
3.14.1 BBS Exit
The 'BBS Exit' option will cause BinkleyTerm to exit to the start-up
batch file with an errorlevel of the baud rate divided by 100 upon
receipt of a non-mail call. For example, a 300 baud caller exits to the
batch file with an errorlevel of 3, a 2400 baud caller at errorlevel 24.
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 required
information. The batch file should recycle and restart BinkleyTerm once
BBS use is terminated.
3.14.2 BBS Spawn
The 'BBS Spawn' option causes BinkleyTerm to stay resident when a caller
accesses the BBS. BinkleyTerm will execute the following command as a
child process:
spawnbbs <baud> <port> <time> <modem_info>
This is only of use if you have a resident shell and plenty of spare
memory.
SPAWNBBS
is the name of a batch file you create.
<baud>
is the baud rate of the connection,
<port>
is the communications port number used for the call
<time>
is the number of minutes to the next non-BBS-allowed event (as
designated in your configuration file event schedules).
<modem_info>
is intended primarily for RBBS-PC installations where extended modem
connect information may be desired. For example, USRobotics HST
modems might issue the connect message "CONNECT 9600/ARQ" in which
case the <modem_info> parameter would be "/Arq" indicating a
"reliable" connection. Note that in this parameter, only the first
letter of each "word" will be capitalized (as shown in the example).
User Guide - Page 30
BinkleyTerm ST 3.00 - User Guide
3.14.3 BBS Batch
The 'BBS Batch' option uses the best of both of 'BBS Exit' and 'BBS
Spawn.'
BinkleyTerm still exits to the start-up batch file, but prior to
exiting, BinkleyTerm physically writes to the disk a batch file named
BBSBATCH.BAT, which contains a single line. An example of the contents
of this file might be:
spawnbbs 2400 1 47 /Arq
The information is the baud rate, port number and time in minutes to the
next non-BBS event. In this case, there is a 2400 baud caller, on COM
port 1, with 47 minutes remaining to the next non-BBS event, and a modem
information string of /Arq.
After writing this file, BinkleyTerm exits as does the 'BBS Exit'
option, with an errorlevel of the baud rate of the caller divided by
100.
The start-up batch file should simply start execution of
BBSBATCH.BAT by adding the line "bbsbatch" to the file, and jumping to
the line whenever a human caller is on-line. In other words, regardless
of the baud rate of the caller, BBSBATCH.BAT should be invoked.
Once invoked, BBSBATCH.BAT will invoke SPAWNBBS.BAT with the
necessary parameters that include the baud rate, port number, and minute
to the next non-BBS event. SPAWNBBS.BAT would physically invoke the BBS
with the proper command lines. When use of the BBS is complete, this
batch file should re-invoke the BinkleyTerm start-up batch file.
Using this 'BBS Batch' method of accessing the BBS, BinkleyTerm can
still provide all the information of the 'BBS Spawn' method, without the
necessity of staying resident.
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.
3.14.4 What this really means?
All these batch files and things were designed with the PC in mind, on
the ST without a standard CLI, things are a little different.
When using ///Turbo-board, you should use the 'BBS Batch' method and a
batch file called FIDOMAIL.BAT. For errorlevels representing human
callers you should copy BBSBATCH.BAT that BinkleyTerm writes out into
//Turbo's own Batch folder and then simply exit to allow ///Turbo to
take over. Example batch files may be found included in the FidoDoor
package and probably from the ///Turbo support BBS.
User Guide - Page 31
BinkleyTerm ST 3.00 - User Guide
When using QuickBBS-ST you would normally use the 'BBS Exit' method.
More information and example batch files are included in the QuickBBS
manual.
3.15 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, TSYNC or EMSI
startup sequence (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 <baud> <port> <time> <errorlevel> <modem_info>
Where <baud> is the baud rate of the caller, <port> is the COM port
number, and <time> is the time in seconds to the next non-BBS event,
<errorlevel> is the errorlevel number used to exit the original batch
file, and <modem_info> is extended modem connect information.
<errorlevel> will be the same as that given with the 'ExtrnMail'
statement in the configuration file, or "99" if none was given.
<modem_info> is intended primarily for RBBS-PC installations where
extended modem connect information may be desired. For example,
USRobotics HST modems might issue the connect message "CONNECT 9600/ARQ"
in which case the <modem_info> parameter would be "/Arq" indicating a
"reliable" connection. Note that in this parameter, only the first
letter of each "word" will be capitalized (as shown in the example).
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.
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.
User Guide - Page 32
BinkleyTerm ST 3.00 - User Guide
3.16 User Selected BBS Functionality
An additional use for the external mail functionality described in the
previous section would be to allow 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.
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 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
Make your selection by letter...
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.
The string "Make your selection by letter..." is NOT contained in
BINKLEY.BAN, but rather, 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 the Reference Guide section
"Configuration File" for information).
User Guide - Page 33
BinkleyTerm ST 3.00 - User Guide
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 (MSDos style) 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. 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.
3.17 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.
To generate an outgoing file request, use the option from within BTS or
the LED editor. You may also generate file requests by pressing Alt-G
(Get file) in BinkleyTerm's unattended mode. Or you may even manually
build one yourself. They are simple ASCII text files named in the same
way as for packets with a .REQ extension. Each line contains the name
of the file you want. Note that outgoing requests should NEVER contain
the drive and path of the file, only the filename.
The .REQ file is placed in your outbound holding area.
BinkleyTerm will handle .REQ files in the same manner as it does Normal
packets (unless an 'X' flag is applied to an event), but you can also
manually poll to send the request immediately.
User Guide - Page 34
BinkleyTerm ST 3.00 - User Guide
Incoming requests are controlled and affected by four files, each of
which are designated in the configuration file.
The first file, OKFILE, is a machine-read listing of files, complete
with drive and path, that you will allow to be sent to remote systems
via file request. The file is designated with the 'Okfile' statement in
the configuration file. Wildcards are allowed, and nearly always used.
When an incoming request is received, the request is checked against the
OKFILE to see if you permit the file to be sent.
The OKFILE also allows you to implement "magic filenames" which are
words used to represent a file. If someone requests "BINKLEY" from you,
for example, you could set-up your OKFILE in such a way as to send
BTST241A.LZH in return. This frees the person making the request from
having to know the exact filename of the file he wants. This is
generally used by systems which are software distribution points, hubs,
and so on.
Password protection may also be implemented with the OKFILE, making a
password required in order to receive a particular file or group of
files.
A sample OKFILE:
b:\aprog.ARC
c:\file\stuff\*.*
c:\file\programs\wlc*.txt
c:\file\private\*.* !mypass
@BINKLEY c:\file\dist\bexe_150.arc
@MYEDIT !outpass c:\file\private\editmax.arc
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.
Note that in all cases, a password (if any) is always the second
argument in an OKFILE entry.
User Guide - Page 35
BinkleyTerm ST 3.00 - User Guide
The next special file is the AVAIL file, and is designated by the
'Avail' statement in the configuration file. When someone requests the
magic filename "FILES" BinkleyTerm will send this file. It is a list of
the files you have available for request, in human readable form. This
is a flat ASCII text file, and should feature the name of the file, and
usually its size in bytes and a short description of the file. There
are utilities available that can construct this file automatically based
on your BBS system's internal listings (e.g. Fibu for QuickBBS-ST and
TiNF for ///Turbo). Of course, it could also be manually created. Most
systems that have a large selection of Freq'able files, archive the
AVAIL file rather than send it as ASCII. I use LHarc and call the file
02520025.LZH, other systems use ARC (the only official FidoNet Archiver)
and use the Hex naming convention used by the packets, e.g.
00FC0019.ARC. Other people simply send back ALLFILES.ARC or something
similar.
The next special file is called the ABOUT file, and is designated by the
'About' statement in the configuration file. When someone makes a
request for the magic filename "ABOUT" or when someone makes an invalid
WaZOO file request (and you haven't set up any Request templates), 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. Again, this is a flat
ASCII text file in human-readable form.
The ABOUT file is sent only on failed WaZOO requests. The file is NOT
sent on failed Bark requests.
Finally, the last items that apply to file requests are the 'MaxReq',
'MaxBytes' and 'MaxTime' statements contained in the configuration file.
A quantity is given with the statements which allow you to designate the
maximum number of files, maximum number of bytes and maximum time to
allow sending files during one file request session. Refer to the
Reference Guide section "Configuration File" for more information.
It is possible to limit incoming file requests based on some basic
criteria. For information, refer to the section "Security - Controlling
File Requests."
3.17.1 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, DOS 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 he or she desires.
User Guide - Page 36
BinkleyTerm ST 3.00 - User Guide
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 newly defined
WaZOO update request for use other BinkleyTerm systems, or other mailers
that support WaZOO update requests.
Update requests are most commonly used now to handle GroupMail, a new
method of sharing 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 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.
At this writing, I don't think there are any Atari packages that support
update requests.
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.
3.17.2 Request Response Files
Incoming file and update requests are not always successful.
BinkleyTerm supports the ability to dynamically generate a "response
file." This file is either sent back as a Netmail to the SysOp of the
remote system or if you have the line SendRSP as a plain text file with
a .RSP extension. The response file is built "on-the-fly" during a
session, and sent in response to a failed (or optionally, a successful)
file or update request. If you choose to implement request response
files, the "about" file designated in your configuration file will no
longer be sent. See "File Requests" for more information.
Note that 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. See "File Requests"
or the Reference Guide section "Configuration File" for more
information.
The content of the response file is configured by you with a template
file. The template file name is designated by the 'ReqTemplate'
configuration file statement. As with file requests, you can also
implement security controls with the request templates. See "Security -
Response File Templates" for more details.
User Guide - Page 37
BinkleyTerm ST 3.00 - User Guide
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 are named similar to outbound packets or request files.
They are <net><node>.RSP, where <net> is a net number, and <node> is a
node number. Both <net> and <node> are four-digit hexadecimal number
with leading zeroes.
A sample response file template, SAMPLE.TPL, is included with the
BinkleyTerm distribution package. Use this sample as a starting point
for your own response file template.
The complete list of possible verbs for use in the response file can be
found in the section "Response File Template" in the Reference Guide.
3.18 Function Requests
Two additional special entries may be included in the OKFILE that
operate similar to magic filenames. Called "magic" function requests,
they allow an incoming request to trigger the operation of a program.
3.18.1 $ 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,
two arguments which correspond to the net and node number of the calling
system can be sent if desired by adding "%d %d" to the end of the OKFILE
entry. For example:
$INFO INFO.BAT %d %d
If an incoming file request is for "INFO" then the program INFO.BAT
would be executed, and it would receive two command line arguments that
correspond to the net and node number respectively. For instance, if
141/491 requested "INFO" then the following would be issued to DOS for
execution:
INFO.BAT 141 491
User Guide - Page 38
BinkleyTerm ST 3.00 - User Guide
Another example of such an OKFILE entry would be:
$CLEANUP !mypass CLEANUP.BAT %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" was used, and
would cause a hexadecimal representation of the net and node number to
be sent as command line arguments to the program being executed. In our
example, if 104/36 requests "CLEANUP" with a password of "mypass" then
the following would be sent to DOS for execution:
CLEANUP.BAT 68 24
See "Function Request Notes" below for additional function request
information.
3.18.2 + 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> 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 141/491 contained the line:
GETREV !mypass BT 1.50
Then the following would be passed to DOS for execution:
GETREV !mypass BT 1.50 1 141 491
A program called GETREV would be executed, and would need to process or
filter the command line as needed. 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.
User Guide - Page 39
BinkleyTerm ST 3.00 - User Guide
3.18.3 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.
User Guide - Page 40
BinkleyTerm ST 3.00 - User Guide
4. Utilities to use with BinkleyTerm-ST
I can not hope to list all of the available utilities, and you would be
well advised to FREQ the files list from one of the larger ST based
boards near you and see what is available and also to ask other SysOps
what they would recommend.
Note that the mention of any software here does not mean that I am
endorsing the use of the software. I am merely trying to provide a
guide to what is available in one place. If anyone has suggestions for
other utilities to mention here then please send me a paragraph about it
(See BinkleyTerm support). The intention is only to mention those
utilities that are for particular use with BinkleyTerm rather than
general purpose BBS utilities.
4.1 Mail Processing
Mail processing can be split into several steps:
Import Takes incoming packets from the netfile folder(s) and
puts them into the appropriate message areas.
Scan Scans echomail areas and creates messages for all the
systems that messages should be sent to.
Export Copies messages from the netmail areas (and extra export
areas) into the outbound folders. Compressing echomail
is also included in this stage.
Pack Marking old messages as deleted and repacking the message
areas. This is also sometimes called Renumbering
Some packages combine all these into one operation, whereas others
keep them as separate utilities. Some of the available mail
processing utilities for the Atari ST include:
ACS (Area Cleaner Software). This includes 4 separate programs:
come_in, tidy_up, go_out and BTS. Includes AreaFix and FileFix.
Can be used for points and nodes. Shareware. Contact Roland Bohn
2:241/5811
IOS (Input/Output/Scan). This includes all of the mail processing
functions in one program and as a result is very fast as well as
providing some advanced features not found in other utilities.
Can be used by points and nodes. Contact Johan Ansems 2:280/3.
ECU and Llegada. Mail processing for point systems. All
documentation is currently available only in German. Contact
Heinz Ozwirk 2:249/6.8
The Box Utilities. These provide a comprehensive set of utilities
comprising separate programs (Import, ComScan, pack) designed to
be used with The Box mailer. Unfortunately the outbound folders
of the box use different naming conventions, so it must be used
with the conversion programs BINK2TB and TB2BINK. Contact Jac
Kersing 2:286/203.
User Guide - Page 41
BinkleyTerm ST 3.00 - User Guide
4.2 BinkleyTerm shells
These provide an easy way to edit your configuration, set up session
and generally provide an easy to use environment for operating
BinkleyTerm for Point Systems. These include:
BTS (part of the ACS package described under mail processing
utilities)
Avalon, documentation is available only in German. Contact
Stephan Slabihoud 2:245/8.13
4.3 CLI/Shells
Pcommand is probably the most commonly used. But it is quite old,
buggy and lacking in features. You will not be able to use any of
the shell or spawn commands with this. Should be available from any
ST based system.
Craft is a commercial Unix style shell. Its probably a bit expensive
to buy just to run a BBS from, but if you already have it then it is
the best.
There are others (Gulam, GAK-CLI, Mupfel, NeoDesk CLI, etc), but I
have not used them with BinkleyTerm. If anyone has experience of
using other shells with BinkleyTerm then please write a paragraph and
send it to me (see BinkleyTerm support).
4.4 BBS software and Utilities
QuickBBS-ST, Works well with BinkleyTerm, using the same message base
format as most of the mail processing utilities. Contact Theo Runia
2:282/301.
///Turbo-board, Uses its own message base format, but can be used
with BinkleyTerm by using other utilities. Contact John Miller +1-
416-274-1225.
FidoDoor, a doors program to allow users of ///Turbo or FoReM systems
access to QuickBBS format message areas. Contact Bryan Hall
PhidoZap, similar to FidoDoor but designed for Express BBS (will work
with ///Turbo).
FiFo, converts messages between ///Turbo format message areas and
QuickBBS format. Contact STeVeN Green 2:252/25.
User Guide - Page 42
BinkleyTerm ST 3.00 - User Guide
4.5 Nodelist Processing
ParselST is currently the only choice. Other processors are being
developed and support will be added to future versions of
BinkleyTerm-ST.
Fido24, suite of utilities for point systems to help them process cut
down nodelists and pointlists. Contact Guenther Paczia, 2:241/4407.7
NLupdate, some of the functionality of Fido24. Contact Joerg Spilker
2:245/52.8.
4.6 Other Utilities
LED: Editor for FidoNet messages. Highly recommended. Contact
Roland Bohn (see ACS above).
AreaFix, for allowing points and other systems to automatically join
and leave echomail areas. Contact ???
EchoFix, alternative to AreaFix. Contact ???
Hatch and STick, for implementing File Networks. Contact Joop
Koopman 2:281/202
FiBu, generates file lists for QuickBBS. Contact Theo Runia
2:282/301.
TiNF is Not Fibu (and TiNF-T2), does the same as FiBu but for
///Turbo-board systems. Contact STeVeN Green 2:252/25
FilesBBS, converts between QuickBBS-ST format FILES.BBS and ///Turbo-
board-1's file directories. Contact Steven Green 2:252/25
TNT, same as FilesBBS but for ///Turbo-2. Contact Iain Paton
2:259/5.
FSCAN, statistics and log file summaries. Contact Daron Brewood
2:250/123.
SEE_FIDO, for playing Space Empire over FidoNet. Contact Phil
Gadsby, 2:250/128.
User Guide - Page 43
BinkleyTerm ST 3.00 - User Guide
5. BinkleyTerm Support and Problem Solving
Since BinkleyTerm is a product which is "free for the asking" you cannot
expect a toll-free software support line (as much as we may want to
provide you with one).
The primary means of support is the BINKLEY.ST EchoMail Conference.
This conference is carried worldwide by Atari ST based systems within
FidoNet. Contact a nearby ST board for information on hooking into the
conference, or finding a system that you can use to participate in the
conference. The conference is monitored and read by the BinkleyTerm
authors and beta testers.
If you have any bug reports or suggestions then you can send them
directly to me at:
STeVeN Green
FidoNet 2:252/25
NeST 90:1004/1004
BBS: +44-793-849044
But if you are just having general problems then it will be quicker to
ask someone closer to you or in one of the Fido-ST related echoes.
German Support Node is:
Bernd Renzing
FidoNet 2:245/52@fidonet.org
NeST 90:6000/104
BBS: +49-2307-40486
If anyone would like to volunteer to become a national support help node
then please contact Steven Green at 2:252/25.
5.1 Trouble Shooting
3,000 pages of documentation would not entirely eliminate the potential
for problems with the installation and operation of BinkleyTerm. Due to
the wide variety of hardware and software configurations that
BinkleyTerm may be used with, as well as the varying levels of
experience of the BinkleyTerm user, problems will sometimes occur. This
section attempts to present common problems and possible solutions.
If there is not a solution to your problem presented here, please read
over the appropriate sections of the manual again. If you still are
having difficulty, place a message in the BINKLEY.ST echomail area,
contact another system using BinkleyTerm-ST or netmail Steven Green at
2:252/25.
User Guide - Page 44
BinkleyTerm ST 3.00 - User Guide
5.1.1 Baud Rate Locking Trouble
Do not use BinkleyTerm's 'LockBaud' configuration file statement. Use
the 'STLockBaud' command instead. If you have patched you MFP to handle
38400 baud then you should add the line 'Hard38400' into BINKLEY.CFG.
To use a high speed modem, you would usually lock the baud rate (using
AT&B1 on a Courier HST/V32) and then use the configuration options:
Baud 19200
STLockBaud
5.1.2 Outward Dial aborting
Many people installing BinkleyTerm mistakenly use the 'Suffix' option in
their configuration file. Unlike most communications programs,
BinkleyTerm by default adds a carriage return to the end of the dial
string. 'Suffix' is used to add instructions to the end of the phone
number, but BEFORE the carriage return. By adding a carriage return
code (pipe symbol, |) with the 'Suffix' statement, you are essentially
telling BinkleyTerm to send TWO carriage returns, yours, plus the
default. With most modems, this will immediately abort the dialling
process before it even gets started.
In nearly all installations, the 'Suffix' statement WILL BE COMMENTED
OUT. If deleting the 'Suffix' statement does not fix the problem, you
may also try adding the 'NoCollide' and/or 'SlowModem' statements to the
configuration file. Refer to the Reference Guide section "Configuration
File" for more details.
5.1.3 False Call Collision Reports
In some installations, BinkleyTerm may abort the dialling process due to
an incoming call, even when there is no incoming call. This is probably
due to the modem reporting "RING" on both incoming and outgoing calls.
Use the 'SameRing' configuration file option to partially disable the
call collision feature; use the 'NoCollide' option to totally disable
the feature.
5.1.4 BinkleyTerm Will Not Recognize Node Addresses
You have not compiled the nodelist correctly. Use ParseLst to compile a
fully-zoned Version 6 nodelist for your system. To do this, make sure
the following statements exist within your ParseLst configuration file:
UseZone, Complete (or Gated), and Version6.
User Guide - Page 45
BinkleyTerm ST 3.00 - User Guide
5.1.5 Zone Support Does Not Operate Correctly
Chances are excellent that you have not compiled the nodelist correctly.
Although the actual entries for nodes in other zones do not need to be
included in the compiled nodelist files, what are called "zone
identifiers" DO need to be included in order for zone support to work.
See the section "Nodelist" for more information on correct compilation
of a nodelist. Another item to check is that outbound areas are created
for the other zones to which you want to send mail. See "Zone Support"
for information on how outbound areas for other zones are constructed.
User Guide - Page 46
BinkleyTerm ST 3.00 - User Guide
6. Glossary
ACS
Area Cleaner Software. A set of mail processing
utilities and BinkleyTerm shell by Roland Bohn.
AMAX
The name of a BinkleyTerm utility by Alan Applegate that
handles various outbound mail manipulation functions.
ARCmail
Simply archived mail packets, processed with an ARC-
compatible utility. Typically used to forward EchoMail
messages due to the file compression inherent in the
archiving process. Naming conventions correspond to a
generally accepted method. See 'Mail Packet.'
BBS
An electronic bulletin board system. A method of
communicating and sharing files with others by computer.
Typically operated by hobbyists, free-of-charge.
Carrier Detect
A serial port line that is brought "high" (raised, given a
"true" logical value) when carrier is present on the line,
e.g., when the modem is connected to another modem.
The modem raises and lowers this line.
CD
See "Carrier Detect."
Compressed Mail
Mail that has been compressed or "archived" with any one of
several archiving utilities. Such mail is also known as
ARCmail, ZOOmail, PAKmail, etc., depending on which
archiving utility was used to compress the mail.
ConfMail
The name of a mail processing program by Bob Hartman for use
in the Opus or Fido environments, or any other environment
that uses a compatible message base.
User Guide - Page 47
BinkleyTerm ST 3.00 - User Guide
Continuous Mail
A capability of a particular system to accept mail at any
time of day, as opposed to being required to accept it only
during certain prescheduled times.
D'Bridge
A commercial FidoNet mailer written by Chris Irwin.
Data Terminal Ready
A serial port line that is brought "high" (raised, given a
"true" logical value) when the local terminal is ready for
communications. A serial device (in our case a modem)
connected to the serial port uses this line to detect
whether the terminal (your PC and BinkleyTerm) are ready for
communications activities. Normally, bringing the line
"low" (lowering, giving a "false" logical value) causes a
modem to disconnect from the telephone line.
BinkleyTerm raises and lowers this line.
Domain
A "layer" of addressing to allow use of alternative
networks.
DTR
See "Data Terminal Ready."
Dutchie
A FidoNet mailer written by Henk Wevers.
Dynamic Event
A system event (see "Event") that stops when particular
conditions (lack of mail of a certain type to be sent) are
met.
EchoMail
A system devised by Jeff Rush for the automated sharing of
message areas between systems, whereby messages are "echoed"
from one system to another. Also known as conferences or
EchoMail conferences.
User Guide - Page 48
BinkleyTerm ST 3.00 - User Guide
EMSI
A session handshake protocol developed by Johaquim
Homrighausen and Chris Irwin. Amongst its advantages
are its ability to send mail for many alternative
addresses (aka) in the same session, its machine
independence and its expandability.
Errorlevel
The name of a DOS environment variable; contains a value
returned by a program on exit that indicates a certain pre-
defined condition.
Event
A system occurrence at a preconfigured time, day-of-the-
week, and/or date. Normally system limitations such as when
to dial long distance are dependent on system events.
Fido
The original implementation of FidoNet and FidoNet protocol;
a BBS software package.
FidoNet
The name of the original network that used FidoNet protocol,
as designed by Tom Jennings.
FidoNet Protocol
A method of electronic mail transfer designed by Tom
Jennings, as documented in the Fido Technical Standards
Committee document FSC-0001.
File Request
The ability and associated methods of using extended FidoNet
protocol to obtain a particular file automatically from one
FidoNet system to another.
FoReM
An Atari ST Bulletin Board System created by Matt
Singer. Similar to ///Turbo-board.
IOS
Input/Output/Scan. Mail processing software by Rinaldo
Visscher.
User Guide - Page 49
BinkleyTerm ST 3.00 - User Guide
FrontDoor
A FidoNet mailer written by Joaquim Homrighausen.
FSC001
In BinkleyTerm, an abbreviation that indicates that a mail
session corresponding to the FSC-0001 standard is in use.
FSC-0001 is a standards document written by the FidoNet
Technical Standards Committee.
GroupMail
A method of sharing message areas devised by System
Enhancement Associates, Inc., similar to EchoMail, except
that responsibility for obtaining mail is placed on the
receiving system, not the sending system as with EchoMail.
Based on usage of update requests.
Hold Area
See "Outbound Area."
Inbound Area
Also known as the "NetFiles" area, this is a special sub-
directory set aside for the acceptance of incoming mail or
files from other network systems.
Janus
A Bidirectional file transfer protocol developed for
BinkleyTerm 2.40 by Bit Bucket Software, Co.
Mail Packet
A unit of mail as defined in the FidoNet Technical Standards
Committee document FSC-0001.
Mailer
A program that acts as a FidoNet-compatible mail handler,
using FidoNet protocol. Normally, a mailer answers the
phone, accepts and/or sends mail, and possibly passes human
callers on to a BBS.
Msged
An Opus/Fido compatible message reader/editor by Jim Nutt.
User Guide - Page 50
BinkleyTerm ST 3.00 - User Guide
NeST
An alternative FidoNet compatible Network for Atari ST
based systems. Contact Daron Brewood at
2:250/123@fidonet.org for information.
Net
A subset of a FidoNet compatible network, usually a
collection of nodes within a metropolitan area.
NetFiles
Files received from other systems in the network; also a
special sub-directory set aside for the reception of such
files.
NetMail
Person-to-person mail sent through the network.
Network
As it applies to BinkleyTerm, a collection of nodes that are
FidoNet compatible, such as the FidoNet network itself, or
others such as EggNet, AlterNet, RBBS-Net, etc.
Also, a division of a full network. See "Net" above.
Node
A FidoNet compatible system, represented by a node address,
and listed in a nodelist.
Nodelist
A listing of FidoNet nodes.
oMMM
A packing program (packer) originally designed for Opus-
CBCS, but now widely used with BinkleyTerm.
Opus-CBCS
"The Opus Computer Based Conversation System," a BBS
designed by Wynn Wagner III. Uses ".MSG" message base
(compatible with Fido BBS program). Contains built-in
FidoNet compatible mailer.
User Guide - Page 51
BinkleyTerm ST 3.00 - User Guide
Outbound Area
Also known as the "Hold Area," this is a special sub-
directory set aside specifically for holding mail waiting to
be sent to or picked-up by its destination.
Packer
A program that processes mail entered on a system, and
prepares it for sending by the mailer.
Packet
Within FidoNet, a message unit conforming to FSC-0001
specifications.
With file transfer protocols, a block, or "piece" of the
file transfer. Normally a predetermined size in bytes.
Point
A point is an extension of a regular, fully qualified
FidoNet node. The term is derived from the node address
format, 1:104/36.2 for example, where 1 is a zone, 104 a
net, 36 a node, and 2 is the point.
Primarily, Points are intended to provide an method of
participating in EchoMail conferences in an off-line state.
The conferences are packed and held for the Point system by
the Boss, a system which carries the desired conference(s)
and is willing to route them to the Point. The Point system
'polls' the Boss for the conferences, which are unpacked and
read off-line on the Point system. Responses are packed and
sent to Boss in much the same manner as is done by regular
FidoNet nodes.
Generally, Points never interact with regular nodes, only
with their Boss, since Point systems are not listed in the
FidoNet nodelist.
QuickBBS
A BBS program designed by Adam Hudson, which uses
configurable menuing and a database-style message base.
Requires mail processing software designed specifically for
its message format. The Atari ST version is by Jon Webb.
Region
A subset of a FidoNet compatible network, a collection of
nodes within a broad geographical area. With regard to
FidoNet addressing, a region is handled the same way as a
network. With regard to operational infrastructure, this is
a higher level than a net.
User Guide - Page 52
BinkleyTerm ST 3.00 - User Guide
Scan
Usually associated with EchoMail processing, "scanning" is
the process of taking new messages from a form usable by a
BBS program or message editor and preparing them for sending
via the network by placing them in standard packet and/or
compressed mail format.
SEAdog
A commercial FidoNet mailer by System Enhancement
Associates, Inc.
SEAlink
A variant of Xmodem, a robust file transfer protocol
featuring sliding windows, good error trapping and extended
file information. Superior to Xmodem for use on difficult
or satellite connected links.
Sirius
An Opus/Fido compatible message reader/editor by Bob Klahn.
Sysop
System operator; the person who operates a BBS, and/or the
operator of a FidoNet node.
TBBS
A commercial BBS software package by eSoft, Inc.
Telink
An Xmodem variant, a file transfer protocol that is
essentially Xmodem with a file information packet.
Terminal Mode
A BinkleyTerm mode within which the software may be used for
manual, direct connections with remote modem-equipped
computers.
Toss
Usually associated with EchoMail processing, "tossing" is
the process of unpacking compressed mail into a form usable
by a particular BBS program or message editor.
User Guide - Page 53
BinkleyTerm ST 3.00 - User Guide
TSYNC
A signal sent to a FidoNet system from another FidoNet
system attempting to pass mail traffic. TSYNC is
essentially a "handshake" between the sending and receiving
systems to synchronize the mail session.
///Turbo-Board
A BBS system created by Bill Miller, based on the FoReM
Bulletin Board System.
Unattended Mode
A BinkleyTerm mode within which FidoNet electronic mail may
be sent or received.
Undialable
A term for nodes which will no longer be called
automatically by the system until manually reset. The
result of excessive unsuccessful connections with the remote
system in an attempt to send mail.
Unpacker
A mail processing program that takes mail as received
(compressed mail and/or packets) and places it into a form
usable by a given type of BBS program or message editor.
Update Request
The ability and associated methods of requesting only a
newer copy of a file located on one FidoNet system, if a
newer copy exists, from another FidoNet system, using
extended FidoNet protocol.
WaZOO
An open architecture method of electronic mail transfer
designed by Wynn Wagner, and originally used with Opus-CBCS.
Various protocols can be used under WaZOO, including ZedZap,
a slightly modified Zmodem, and DietIFNA, a SEAlink method.
See 'YooHoo.'
Xmodem
One of the first of its type, a file transfer protocol
designed by Ward Christensen. Although technologically
behind other newer, more robust protocols, Xmodem is the
most widely supported and implemented file transfer protocol
in dial-up use.
User Guide - Page 54
BinkleyTerm ST 3.00 - User Guide
YooHoo
A method of mail transfer session negotiation which
determines if the remote system is capable of handling
WaZOO. FidoNet systems that do not support WaZOO will
simply disregard the YooHoo; systems capable of supporting
it will answer affirmatively, and a WaZOO session will be
initiated. See 'WaZOO.' YooHoo is defined in the Fido
Technical Standards Committee document FSC-0005.
Zmodem
A robust streaming file transfer protocol featuring advanced
error recovery techniques, variable packet sizing, good
error detection and extended file information. Extremely
efficient, yet complex. Highly effective with difficult
connections.
Zone
A large geographical sub-division in the network, the
highest level of the accepted FidoNet addressing scheme.
Broad areas such as continents are given zone designations.
Also used to specify a particular alternate network.
ZOOmail
Simply archived mail packets, processed with the ZOO
utility. Typically used to forward EchoMail messages due to
the file compression inherent in the archiving process.
Naming conventions correspond to a generally accepted
method. See 'Mail Packet.'
User Guide - Page 55