**** * * * ******* TM
* * * * *
* * * * ** * * * *** * * * *** * ** *** **
**** * ** * * * * * * * * * * * ** * * *
* * * * * *** * **** * * * **** * * * *
* * * * * * * * * * * * * * * * *
**** * * * * * * **** **** * **** * * * *
*
Version 2.30 - User's Guide * September 4, 1989
***
A Freely Available FidoNet Compatible Electronic
Mail Interface and Dumb Terminal Package
Software Written by Vince Perriello and Bob Hartman
Documentation Written by Alan D. Applegate
Copyright (C) 1988, 1989 Bit Bucket Software, Co.
A Delaware Corporation
All Rights Reserved
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.
BinkleyTerm Version 2.30 - User's Guide - Page 2
TABLE OF CONTENTS
Section 1 - General Information 4
How to Use This Manual 4
Acknowledgements 5
Kudos 6
Forward 7
Introduction 8
General Requirements 9
Memory Requirements 9
Modem Requirements 10
Section 2 - Operation as a Terminal Communications Program 11
Terminal Mode Overview 11
VT-100 Emulation 12
External Protocols 12
Section 3 - Operation as a Automated Electronic Mailer 13
Unattended Mode Overview 13
The BinkleyTerm Concept 14
How BinkleyTerm Handles Mail 14
Idea #1 14
Idea #2 15
Idea #3 15
Idea #4 15
A Sample Message, Start to Finish 17
The Concept of Cost 18
Alternative Method 18
Windowed Interface 19
Current Settings 19
Today at a Glance 19
Pending Outbound Mail 20
Recent Activity 21
Transfer Status 21
Control 21
Errorlevels and Batch Files 22
What is an Errorlevel? 23
What Errorlevels BinkleyTerm Produces 24
Making Errorlevels Work for You 26
Errorlevels, Batch Files and ExtrnMail 26
Errorlevels, Batch Files and Housekeeping 26
DOS Shell Keys 26
Using Errorlevels 27
What Now? 27
Errorlevel and Batch File Hints and Kinks 28
Environment Variable 30
Configuration File 30
BTCTL 30
Nodelist 31
FIDOUSER.LST 31
Version 5 Nodelist 32
Version 6 Nodelist 32
BinkleyTerm Version 2.30 - User's Guide - Page 3
QuickBBS Nodelist 32
TBBS Nodelist 33
Nodelist Support Information 33
Zone Support 34
Multiple Network Operation 35
Security 35
Prot 36
Known 36
Default 36
Security - Session Passwording 36
Security - Secured Inbound File Areas 37
Security - Controlling File Requests 38
Security - Response File Templates 39
BBS Interface 39
BBS Exit 39
BBS Spawn 40
BBS Batch 40
BBS Batch Method Flowchart 42
Banner 42
External Mail Programs 43
User-Selected BBS Functionality 43
File Requests 45
Update Requests 47
Request Response Files 48
Function Requests 49
$ Function Requests 49
+ Function Requests 50
Function Request Notes 50
A Word About Point Networks 51
Section 4 - Problem Solving 52
BinkleyTerm Support 52
Troubleshooting 52
Baud Rate Locking Trouble 52
Outward Dial Aborting 52
False Call Collision Reports 53
FOSSIL Driver Compatibility Problems 53
BinkleyTerm Will Not Recognize Node Address 53
TBBS Difficulty - BinkleyTerm Runtime Errors 53
DOS Shells Not Working Correctly 53
Zone Support Does Not Operate Correctly 54
Date Rollover Problem 54
Glossary 54
BinkleyTerm Version 2.30 - User's Guide - Page 4
+-------------+
| +---------+ |
| | Section | | BinkleyTerm User's Guide
| | 1 | | GENERAL INFORMATION
| +---------+ |
+-------------+
HOW TO USE THIS MANUAL
The documentation for BinkleyTerm is supplied in two parts.
The User's Guide (named 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 toward the end of the User's Guide.
Concepts and terminology that may be of interest to experienced
users and new users alike are covered in the Reference Guide
(named BT_REF.DOC) an alphabetically arranged manual separate
from the User's Guide.
For inquiries, questions or comments regarding BinkleyTerm,
please refer to the User's Guide section "BinkleyTerm Support."
Some material in the section "How BinkleyTerm Handles Mail" is
excerpted from MATRIX.DOC, and is Copyright (C) 1987 Wynn Wagner
III, All Rights Reserved. Used by permission.
Some material in the section "Control" was written by Ron
McKenzie, and is Copyright (C) 1989 Ron McKenzie, All Rights
Reserved. Used by permission.
BinkleyTerm Version 2.30 - User's Guide - Page 5
ACKNOWLEDGEMENTS
The following names are either trademarks, registered trademarks,
and/or the efforts of the person and/or company named:
Fido, FidoNet - Tom Jennings, Fido Software
MS-DOS, Microsoft C - Microsoft Corporation
IBM, PC-DOS - International Business Machines Corporation
Opus-CBCS, ZedZap, YooHoo, WaZOO, OpusNode - Wynn Wagner III
ARC, SEAdog, SEAlink, XlatList, ARCmail, GroupMail - Thom
Henderson, System Enhancement Associates, Inc.
VT-100, DEC, DEC Rainbow, VAX, VMS - Digital Equipment
Corporation
FANSI-CONSOLE - Hersey Micro Consulting
Hayes - Hayes Microcomputer Products Corporation
Zmodem - Chuck Forsberg, Omen Technologies, Inc.
ConfMail, ParseLst, oMMM, Opus!Comm - Bob Hartman, Spark
Software, Inc.
oMMM - BS Software, Marshall Presnell, Jim Nutt
msged - Jim Nutt
XlaxNode - Scott Samet
Heath/Zenith - Heath/Zenith Electronics, Inc.
Sanyo - Sanyo Electric Co. (Japan) Ltd.
DoubleDOS - SoftLogic Solutions, Inc.
DESQview - Quarterdeck Office Systems, Inc.
Telix - Colin Sampaleanu, Exis Inc.
Sirius - Bob Klahn, Micro Solutions
OOPS - Tom Kashuba
AMAX - Alan Applegate
Dutchie - Henk Wevers
PC Pursuit - GTE/Telenet
EchoMail - Jeff Rush
ProComm - Datastorm Technologies, Inc.
Qmodem - The Forbin Project
TBBS - Phil Becker, eSoft, Inc.
QuickBBS - Adam Hudson
X00 - Ray Gwinn, RENEX Corporation
DECCOMM - Vince Perriello, VEP Software
Atari, ST - Atari, Inc.
Commodore, Amiga - Commodore International
USRobotics, HST - USRobotics, Inc.
RBBS-PC - Capital PC Users Group, Thomas J. Mack
FrontDoor - Joaquim Homrighausen
D'Bridge - Chris Irwin
Every effort has been made to identify and give credit for
trademarks mentioned in this documentation. Any failure to
mention a particular trademark in the above list that may be
found in the text, or failure to give proper credit for a
particular trademark, constitutes merely an oversight and should
not be construed as intentional, or in any way a claim of rights
to the trademark.
PLEASE NOTE! Throughout this documentation, the mention of any
BinkleyTerm Version 2.30 - User's Guide - Page 6
particular software package or system should not be construed as
an endorsement of any kind on the part of the authors.
KUDOS
A number of people have been involved in the creation,
development and testing of this program, or have contributed to
it in one way or another.
Tom Jennings, of course, gets credit for creating the beast that
brought us all together and defining the basic method of mail
transfer that we still use. Wynn Wagner gets our thanks for
releasing source code for his file transfer routines and sending
some of his WaZOO source code as well for inclusion. Thom
Henderson gets a humble tip of the hat for SEAdog, the
prototypical mail-only front-end which was the basis for our
front-end design, and for SEAlink, his extension of Xmodem/Telink
which doubled the speed of network mail transfers overnight.
Chuck Forsberg of Omen Technologies gets our thanks for
developing and implementing the original Zmodem protocol.
Then there are the guys who have put to the test everything the
authors thought would be worthwhile, the BinkleyTerm Beta Test
Team, members both past and present. Without you, who knows what
we'd have wound up with.
BinkleyTerm Version 2.30 - User's Guide - Page 7
FORWARD
There is no question that BinkleyTerm is an extremely powerful
communications tool. We also make no secret of the fact that
BinkleyTerm 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 in every possible environment. BinkleyTerm
can run on a number of personal computer platforms - a total of
several thousand brands and models. Hundreds of different modems
can be used. It works with several operating environments such
as DESQview and DoubleDOS. 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 Atari ST, Commodore Amiga and VAX/VMS based
systems. 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
version of BinkleyTerm provided by the original authors - that
which runs in the PC-DOS/MS-DOS environment.
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 have configured it for an environment similar to yours.
We estimate that several thousand people around the world are
BinkleyTerm users, and someone close to you in your network no
doubt runs BinkleyTerm. With an architecture as open as that of
BinkleyTerm, your best source of information is someone who has
the benefit of time and experience configuring it. 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.
BinkleyTerm Version 2.30 - User's Guide - Page 8
INTRODUCTION
BinkleyTerm 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 and Opus-
CBCS. It also offers easy-to-use event scheduling, single
keystroke spawning to other programs (DOS shell), excellent
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 the on-line session to a flat text file or
printer, support for baud rates of 300 to 38,400 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 is one of several software packages to utilize the
FOSSIL standard communications driver. This standard allows for
consistent console (keyboard and screen) and communications port
I/O operations. By using a FOSSIL driver, BinkleyTerm is capable
of running on practically any MS-DOS/PC-DOS capable machine, even
those that are not 100% IBM hardware compatible.
BinkleyTerm endeavors to provide you with the widest possible
variety of advanced features, combined with solid and efficient
operation in a wide range of hardware environments.
BinkleyTerm Version 2.30 - User's Guide - Page 9
GENERAL REQUIREMENTS
- A personal computer running MS-DOS or PC-DOS, with at
least 256k of available RAM.
- MS-DOS or PC-DOS, Version 2.10 or greater, Version 3.20 or
higher preferred.
- An auto-dial, auto-answer modem; should be mostly "Hayes
compatible." See "Modem Requirements" below.
- A FOSSIL driver designed for your particular hardware.
- One 360k floppy disk drive (Terminal Mode).
- At least two 360k floppy disk drives, more space and/or
hard disk recommended (Unattended Mode).
- Basic knowledge of computer-based telecommunications,
without which you would have no need for BinkleyTerm.
Please note that when using BinkleyTerm as a front-end mailer for
a BBS system, a hard disk is required. The more space you have
for such an operation, the better off you'll be.
You will also need various utilities and adjunct programs, which
vary with your application.
MEMORY REQUIREMENTS
BinkleyTerm requires approximately 185k of RAM in any operational
mode with the non-overlay version (BTBIG.EXE) and somewhat less
for overlay version (BT.EXE). When used for Unattended Mode,
additional memory sufficient to hold the nodelist index file
(usually NODELIST.IDX) will also be required. Keep in mind that
a small amount of overhead will also be required to accommodate a
FOSSIL driver, as well as a VFOSSIL if one is used. At least a
512k system is recommended when using DOS shells, or when
BinkleyTerm is used in a multi-tasking environment. BinkleyTerm
should, however, be completely functional even on a system with
only 256k of RAM.
BinkleyTerm is not currently capable of taking direct advantage
of extended (AT style) or expanded (EEMS, EMS 4.0) memory, and
having such memory installed will not be of direct benefit to
BinkleyTerm. Some multi-taskers, such as DESQview, are able to
take advantage of such memory to BinkleyTerm's ultimate benefit.
Please note, however, that when using the 'SwapDir' configuration
file statement, a RAM disk with at 150k of available space is
highly recommended for efficient operation. Typically RAM disks
can be placed in extended or expanded memory. Refer to the
Reference Guide section "Configuration File" for details on the
'SwapDir' statement and its use.
BinkleyTerm Version 2.30 - User's Guide - Page 10
When used as a front end mailer for a BBS system, 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.
MODEM REQUIREMENTS
A modem that is generally "Hayes compatible" is required for
BinkleyTerm operation. Such modems are typically referred to as
"smart" modems. Most popular, late model modems you're apt to
own meet this requirement. Since you configure the various modem
command strings, the modem 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 smart modems are capable of returning VERBAL (full words) or
NUMERIC (numbers only) response codes; the modem must be
configured in such a way as to use the VERBAL codes ONLY.
BinkleyTerm can be operative if the modem supports just one modem
response string - CONNECT. (See below for qualifications
required of the CONNECT string.)
BinkleyTerm has been programmed to handle and respond
appropriately to the following modem response strings: NO
ANSWER, BUSY, RING, VOICE, NO DIAL TONE, NO DIALTONE, ERROR, NO
CARRIER, DIAL TONE and DIALING.
The following response strings are recognized, but are ignored:
RRING, 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 in the same
manner as a "NO CARRIER" response.
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 should be CONNECT 1200
for a 1200 baud connection, CONNECT 2400 for a 2400 baud
connection, and so on, up to the maximum supported speed.
Note also that BinkleyTerm recognizes the response CONNECT 1275
for split-speed modems.
If you are experiencing modem difficulties, try one or all of the
following configuration file statements: 'SlowModem', 'SameRing'
and/or 'NoCollide'. Additionally, not all modems are capable of
using the 'Answer' statement and its related modem configuration.
Explanations of all these statements can be found in the
Reference Guide section, "Configuration File."
BinkleyTerm Version 2.30 - User's Guide - Page 11
+-------------+
| +---------+ |
| | Section | | BinkleyTerm User's Guide
| | 2 | | OPERATION AS A TERMINAL COMMUNICATIONS PROGRAM
| +---------+ |
+-------------+
TERMINAL MODE OVERVIEW
This section describes the installation and operation of
BinkleyTerm in the Terminal Mode.
BinkleyTerm's Terminal Mode offers functionality similar to that
provided by programs such as Telix, ProComm or Qmodem. You can
use your computer and modem to call out to on-line services and
electronic bulletin board systems (BBS).
BinkleyTerm offers a full selection of file transfer protocols
for use in exchanging files with remote systems. Also offered is
optional VT-100 terminal emulation, an open architecture for
adding additional file transfer protocols, support for high speed
modems up to 38,400 baud, session logging to a flat file or
printer, and more.
BinkleyTerm also features Zmodem Auto-Downloads. Once the
transfer begins at the remote host, BinkleyTerm will detect the
unique Zmodem start-of-transfer signal, and will immediately go
into Zmodem download mode. If for some reason the Auto-Download
does not occur, a Zmodem download can always be initiated
manually.
To install and operate BinkleyTerm for use exclusively in
Terminal Mode, follow these steps.
- Prepare disk media. Create a sub-directory on your hard
disk, or format a single diskette.
- Move the software to the newly prepared media.
- With a standard text editor, or with DOS' EDLIN command,
edit the sample configuration file, BINKLEY.CFG, included in
the distribution archive or diskette. The parameters needed
are outlined in the file itself on comment lines, or you may
refer to the Reference Guide for more information.
- Obtain and properly install a FOSSIL driver in accordance
with the directions included with your driver. (Refer to
the Glossary for more information on FOSSIL drivers.)
- Invoke BinkleyTerm (enter 'BT' on the command line).
- Press Alt-F10 for a brief help screen.
The various keystrokes available in Terminal Mode are covered in
BinkleyTerm Version 2.30 - User's Guide - Page 12
detail in the Reference Guide.
VT-100 EMULATION
VT-100 terminal emulation is provided optionally by BinkleyTerm.
Outward keystrokes are always active with the VT-100 keypad
mapping (as shown in the Reference Guide). However, incoming
screen control codes require ANSI X3.64 support, such as that
provided in firmware on a DEC Rainbow computer.
For users of IBM PC computers and compatibles, external ANSI
support is required, as provided by FANSI-CONSOLE, a separately
available utility. Load FANSI-CONSOLE in accordance with its
directions prior to running BinkleyTerm for full VT-100 terminal
emulation.
EXTERNAL PROTOCOLS
BinkleyTerm provides a rich selection of file transfer protocols,
hard coded for ease of use and efficient operation. On occasion
however, other protocols may also be desired.
BinkleyTerm supports special external file transfer programs that
conform to the standard used by Opus-CBCS. External file
transfer protocols MUST identify themselves as being compatible
with Opus-CBCS in order to work with BinkleyTerm. Such protocols
are often available from Opus-CBCS systems.
Protocols currently available include WXmodem, Kermit and others.
To use such an external protocol, add a 'Protocol' statement to
your configuration file along with the required path information,
as illustrated in the Reference Guide section "Configuration
File."
Some of the Opus-CBCS compatible protocols are specially designed
and optimized for BBS use, and may not be operable in
BinkleyTerm's Terminal Mode. Check the individual package for
information, or test the performance of the package on your own.
"True" external protocols, those that are designed to be accessed
by any communications program via a DOS shell, can also be used
with BinkleyTerm. BinkleyTerm provides a DOS shell command that
can be invoked during a communications session. An external
protocol of this type can then be executed from the DOS command
line, or from a batch file, depending on your situation.
External protocols such as Jmodem and BiModem can be accessed in
this manner.
BinkleyTerm Version 2.30 - User's Guide - Page 13
+-------------+
| +---------+ |
| | Section | | BinkleyTerm User's Guide
| | 3 | | OPERATION AS AN AUTOMATED ELECTRONIC MAILER
| +---------+ |
+-------------+
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 programs such as SEAdog, Dutchie,
FrontDoor, D'Bridge 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 of the connection to a BBS system.
Due to the complexity and widely varying combinations of hardware
and software, only a generalized, broad explanation of the
installation procedure can be given.
- Prepare your disk media. Normally, this would involve
selecting and/or creating a hard disk sub-directory.
- Move BinkleyTerm and the distribution files to this new
directory.
- Using any standard text editor, make the necessary changes
to the configuration file included with the distribution
archive or package. Refer to the Reference Manual section
"Configuration File" for more information.
- Run the BTCTL program included in the distribution
package.
- Obtain and install a FOSSIL driver. Refer to the Glossary
for more information.
- Obtain the necessary utilities and programs for packing
and unpacking mail. Install them in accordance with the
instructions included with each package.
- If you're a fully qualified FidoNet node (not a Point),
obtain a current nodelist. Process it into usable form.
- Make the appropriate changes to an existing batch file
used to start your BBS. If the installation is completely
new, or if your BBS does not use a batch file, create one.
Refer to the section "Control" for more information.
BinkleyTerm Version 2.30 - User's Guide - Page 14
- Start your system. Test a remote call if possible.
- Alt-F10 displays a brief help file of commands available
in Unattended Mode.
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.
For mail handling, you might use programs such as ConfMail and
oMMM to process mail, along with programs such as Sirius or msged
to read and enter messages, or allow your users to do so in a BBS
installation such as Opus-CBCS or Fido. Some BBS packages, such
as TBBS and QuickBBS come complete with their own proprietary
packing and unpacking software. Finding the utilities and
programs needed to work with your system is your responsibility.
HOW BINKLEYTERM HANDLES MAIL
Sending outbound mail with BinkleyTerm is fairly simple. The
concept of mail handling with BinkleyTerm is the same concept
that Opus-CBCS uses. If you're already familiar with Opus, then
BinkleyTerm will fall into place easily. If you are a complete
neophyte, this section is intended to give you an understanding
of the concept.
Idea #1
Mail events are less important than they are with other mailing
methods and systems. With BinkleyTerm's events, you paint with a
wide brush telling the system what to do with 'classes' of remote
systems.
BinkleyTerm Version 2.30 - User's Guide - Page 15
When systems handled mail only at specific times, routing and
times were of great importance. Because more and more systems
can process mail at any time, the idea of a schedule becomes less
important. The item of prime importance with BinkleyTerm is
COST. We are going to try and relieve you of the tedious details
of scheduling, and concentrate on doing things for the least
cost. More on this later.
Idea #2
Another new idea deals with the way that packets are created.
If you have used other mailer systems, you're probably used to
seeing packets generated several times. With some programs,
packets are built every time a mail schedule starts. As a
result, one message may be put into a packet several times.
With BinkleyTerm, packets are built once by an external mail
packing program. Most often, this is a program called oMMM.
They may be remarked and rerouted once they're built, but they
are physically built only once, and placed in a special sub-
directory called the outbound holding area.
NOTE: oMMM stands for Opus Matrix Message Masher, and was
originally designed for use with the Opus-CBCS system as its
packer. BinkleyTerm is able to use oMMM because it chose to
implement the holding area in a compatible (although not
identical) way. oMMM may not have to be used at all; in some
cases, the mail packing program for your particular environment
may handle oMMM-like functions internally.
Idea #3
BinkleyTerm uses 'Continuous Mail.' If you are already using a
program that supports 'Crash Mail' then you understand a little
of what Continuous Mail does. Continuous Mail differs from Crash
Mail in a couple of areas.
In other mailer systems, you would mark a message as 'Crash'
meaning that you wanted this message to go out NOW. These mailer
programs would shut down human caller access to the BBS and try
like heck to get the message through.
BinkleyTerm uses Continuous Mail, meaning that this is a message
going to a system that can accept mail at any time of day.
BinkleyTerm makes no frantic attempts to dial out, rather it will
try and deliver the message between callers.
Idea #4
The driving forces of outbound traffic are file names!
You'll have a special sub-directory set aside just for packets,
compressed mail packets and other network files. This sub-
BinkleyTerm Version 2.30 - User's Guide - Page 16
directory belongs to BinkleyTerm, which will maintain the
directory for you. It's a good idea not to play with this area
unless you know exactly what you're doing.
Note also that when zoned operation is active (BinkleyTerm
default) there are separate outbound areas for each zone. The
default outbound area (for your zone) and one additional area for
each other zone you deal with. The names of these additional
areas are simply the outbound area name, with a three-digit
extension that is the zone number in hexadecimal with leading
zeroes. See "Zone Support" for information.
The file names of the packets tell BinkleyTerm how to treat the
different packets. Here's a typical packet name:
00680024.OUT
That says that the packet is for 0068/0024 (in hexadecimal) or
104/36 in more familiar terms. The ".OUT" means it is a Normal
packet.
Other packet extensions include:
.HUT . . . Hold this packet for pickup by the remote system.
.CUT . . . The other system can receive Continuous Mail.
.DUT . . . Direct, meaning the other system can NOT receive
Continuous Mail.
One nice thing is that you can manually change the file extension
if you need to, or you can use fancy utilities such as AMAX to do
this sort of thing for you on your command.
For the remainder of this section, we'll assume that you'll be
using oMMM as your mail packer. As mentioned previously, you may
be using another program that has oMMM-like functionality; it
depends on your environment.
The oMMM program knows about these extensions and creates them
based on information you put into the oMMM control file. You'll
have statements like this:
NormHold 124/102
Any messages you enter to 124/102 would be turned into a .HUT
packet file, placed into the outbound area, and BinkleyTerm would
hold that packet for 124/102 to call and pick it up.
Files are also sent through FidoNet compatible networks. oMMM
builds and maintains a file that tells BinkleyTerm what files to
send (or hold) for whom. A typical 'file attach' file might be
named:
00680024.FLO
BinkleyTerm Version 2.30 - User's Guide - Page 17
This would designate a that there is a file waiting to be sent to
0068/0024 (in hexadecimal) or 104/36 in more familiar terms. The
".FLO" says it is a Normal file attach. File attach files are
also called 'flow files' - named after the .FLO file extension.
Other flow file extensions are:
.HLO . . . Hold these files for pickup by the remote system.
.CLO . . . The other system can receive Continuous Mail.
.DLO . . . Direct, meaning the other system can NOT receive
Continuous Mail.
A flow file is just a text file. It contains a list of files
that are to be sent to another system:
#c:\binkley\outbound\0000fc9c.mo1
^c:\myfiles\wizzle.doc
c:\pascal\notes.doc
The '#' prior to a flow file entry says to truncate the file to
zero-length after successfully sending the file to the remote
system. This is normally only employed when sending compressed
mail (archived mail) to the remote. The '^' prior to a flow file
entry says to delete the file after sending.
The oMMM program will put messages into archives for you.
Details on how this is done can be found in the oMMM
documentation. The point is that oMMM combines the functionality
of "generating packets" with that of programs like ARCmail.
A Sample Message, Start to Finish
So here's a practical example. Say I enter a message to Rod
Lamping at 104/610. I mark the message as KILL/SENT when I enter
it. I also enter the message designating a file to attach to
Rod, named C:\FILE\REQ\FOOBAR.ARC.
I then enter a message in an EchoMail conference. My conference
host is Phil Kaiser at 104/904, for whom I hold my mail for
pickup.
Among other things, I have two lines in my oMMM control file:
NormCM 104/610
OneHold 104/904
'NormCM' tells oMMM to mark the message as Continuous Mail (since
Rod runs a mailer 24 hours a day). 'OneHold' tells oMMM to
archive the mail to 104/904, and mark it Hold-for-Pickup. Refer
to the oMMM documentation for the full set of available oMMM
control file statements.
First, my EchoMail utilities are run to turn EchoMail messages
into Normal packets, and place them in the outbound area for
BinkleyTerm Version 2.30 - User's Guide - Page 18
processing by oMMM. Next, I execute oMMM. It first scans the
NetMail message area (where I entered my message to Rod) and
turns new messages there into Normal packets, and if there are
files attached, it creates Normal flow files. oMMM's second step
is to use its control file, and apply the statements in the file
against the mail in the outbound area that is marked as Normal.
Since I have Rod's board listed as NormCM, oMMM renames the file
extension of the Normal packet and flow file for Rod to .CUT and
.CLO respectively, for Continuous Mail. Since I have Phil's
board listed as OneHold, first oMMM archives the packets to Phil,
then creates a flow file with a file extension of .HLO for Hold-
for-Pickup.
I would then have the following in my outbound area:
00680262.CUT Message to Rod
00680262.CLO Flow File to Rod
00680388.HLO Flow File to Phil
0000FC9C.MO1 Archived Message to Phil
For more information on how oMMM works, refer to the oMMM
documentation.
The Concept of Cost
As mentioned earlier, 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 send toll calls during nighttime
house. 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 toll calls, and removed for events during which
toll calls are cheapest. More about this is in the Reference
Manual section, "Scheduling Events."
Alternative Method
Randy Bush of 1:105/6 has assembled a package called MOOO which
allows the Dutchie mail packer to be used with BinkleyTerm. This
will allow routing commands familiar to grizzled FidoNet veterans
to be used with BinkleyTerm.
BinkleyTerm Version 2.30 - User's Guide - Page 19
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.
If a Video FOSSIL (VFOSSIL) is installed, the windowing
operations can take place much faster than they would without
one. It is recommended that a VFOSSIL be used with BinkleyTerm.
Some more recent VFOSSIL implementations may also allow
BinkleyTerm to be used on EGA and VGA systems in extended text
modes of 132 columns by 43 lines. The mode switching must be
performed by the utility software that accompanied your video
card prior to invoking BinkleyTerm.
There are five information windows displayed on-screen.
Current Settings
This window contains various information about your system,
including the current date and time, current event, port and
current baud rate, status and multi-tasker type, if any.
The current event line features a number, and a list of event
flags. The number corresponds to which entry in the BinkleyTerm
configuration file contains the line that covers the current
event. The first 'Event' statement in the configuration file
would be event 1, the second would be event 2, and so on. The
flags are letters that are a subset of those used with event
scheduling. Here is a list of letters that may be found in this
window:
C Continuous Mail Only Event
L Local Only Event
N Do Not Accept Inbound File Requests
R Receive Only Event
B BBS Use Allowed
D Dynamic Event
K Do Not Send to #CM Nodes
Note that not all event flags will be displayed in the window.
For complete details and use information, see "Scheduling Events"
in the Reference Guide.
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 first line, "BBS/Mail," lists how many bbs calls and mail
BinkleyTerm Version 2.30 - User's Guide - Page 20
calls have come in, separated by a slash. For example, 2/15
would indicate 2 BBS calls and 15 mail calls since midnight.
The second line, "Calls Out," lists the number of dial attempts
that have been made by your system, successful or otherwise.
The third line, "Good/Cost," shows how many successful outward
connects have been made and the cumulative cost of all the
successful calls, separated by a slash. For example, 3/100 would
indicate that 3 successful outbound calls have been placed, and
that together, they cost 100 units (in the United States, units
are cents, which would mean that the cost was 100 cents or
$1.00). The cost is calculated based on the cost shown in your
compiled nodelist files; the cost shown there is assumed to be a
per-minute value in calculating a per-call cost.
The fourth line, "Files I/O," shows how many files (packets,
compressed mail or other incoming files) have been received and
sent, separated by a slash. For example, 12/3 would indicate
that 12 files have been received, and 3 have been sent.
Finally, the fifth line indicates the type of last call. If the
last call was incoming, the display will indicate whether the
call was a BBS call, external mail call, or the node address will
be displayed if it was a mail call. If the last successful call
was outgoing, the node address will be displayed.
Pending Outbound Mail
This window displays a list of systems for whom mail is pending,
along with related information. The window can be scrolled using
PgUp, PgDn, Home, End, Up-Arrow and Down-Arrow keys. The top
line of the window lists the node that is being called, or was
just called. The second line lists the node that will be called
next.
Various information about the mail for the various nodes is also
displayed. The columns are marked by a single letter. The
column letters and their meaning are:
C Continuous Mail
H Hold-for-Pickup Mail
D Direct Mail
N Normal Mail
R File and/or Update Request
S Status
The symbol shown under the C, H, D, N and R columns is:
* Mail of This Type Pending
BinkleyTerm Version 2.30 - User's Guide - Page 21
The symbols shown under the S column are:
x Too Many Bad Connects (Undialable)
# Already Called, But Mail Still Pending
- Cannot Call During This Event
! Node Not Found in Nodelist
When BinkleyTerm is making an outbound call, the node you are
calling is highlighted in the Pending Outbound Mail window. This
allows you to know which node has been called, even after the
pertinent information has scrolled out of the Recent Activity
window (described below). This feature can also be helpful in
determining whether an active mail session was initiated by you,
or was started by an incoming call.
The outbound area is re-scanned for new additions under the
following circumstances:
- After a keyboard shell has been invoked
- After 'AfterMail' is run (if designated)
- After 'Packer' is run (if designated)
- After message editor (Alt-E) has been run
- After 10 minutes of no activity
Note the 'AfterMail', 'Packer' and 'Reader' (message editor) are
designated in the configuration file. Refer to the Reference
Guide section "Configuration File" for additional information.
Recent Activity
This window is similar to the main section of previous
BinkleyTerm displays, in that it gives various information about
what the system is currently doing, or has just done. This
includes identification of the remote system, the type of
connection, what files were transferred, etc.
Any feedback available about the current or recent activity of
the system is shown in this window.
Transfer Status
This window gives particulars about current file transfers that
may be taking place if a connection is active. For WaZOO/ZedZap
connections, this includes filename and the number of bytes
transferred; for other connections, the number of blocks
transferred may be given.
CONTROL
In Unattended Mode, BinkleyTerm is normally used with batch files
that control system operation. You'll have a batch file used to
invoke BinkleyTerm and invoke system utilities such mail
processors.
BinkleyTerm Version 2.30 - User's Guide - Page 22
Since BinkleyTerm can be used in such a wide variety of
situations, there is not a particular "correct" or "incorrect"
way to configure BinkleyTerm. The remainder of this section
explains some of the operational theory and methods behind batch
processing as it applies to BinkleyTerm.
If you are adding BinkleyTerm to an existing FidoNet compatible
BBS system, chances are excellent that you are already familiar
with batch files and the various tricks that they must typically
perform in a FidoNet environment.
If advanced batch processing is beyond your scope, it is highly
recommended that you review your DOS manual, or the numerous
third-party DOS usage guides for information to get you started.
One of the fundamentals of using batch files with BinkleyTerm is
the concept of the 'errorlevel.' This DOS environment variable
is set to a given value when a program completes execution. A
batch file can detect and act upon the value, branching to
various parts of the batch file. This section provides many good
tips and ideas for errorlevel and batch file processing. Also
consult your DOS manual for additional information.
A practical application might be after BinkleyTerm receives mail.
BinkleyTerm would exit to the batch file, setting the errorlevel
to a predetermined value. The batch file detects the value, and
branches to a section in the batch file where mail unpacking
programs are invoked. The batch file would then be restarted,
invoking BinkleyTerm to again wait for or send mail.
NOTE: The remainder of the "Control" section was
written by Ron McKenzie of 1:104/45.1. My gracious
thanks to him for the insights presented here, and for
the time he contributed to its composition. This
section was sorely needed (and requested) by many
BinkleyTerm users.
- Alan D. Applegate
Errorlevels and Batch Files
Errorlevels present a difficult hurdle to the new user of
BinkleyTerm, especially those with no experience operating a BBS
or a Point. In addition, BinkleyTerm's great flexibility
confuses some Sysops. Few things are "fixed" or "cast in
concrete." This section attempts to draw together pertinent
information from many sources relating to errorlevels and their
use in crafting a batch file to operate a BBS or a Point. Also
presented are some accumulated bits of wisdom gathered by the
author in the course of creating his own Point.
This section looks at what errorlevels are, which errorlevels are
returned by BinkleyTerm, distinguishes between those errorlevel
values set by BinkleyTerm and by the user, shows how you use
BinkleyTerm Version 2.30 - User's Guide - Page 23
errorlevels in your batch file and, finally, offers some hints
and shortcuts.
What is an "Errorlevel?"
An errorlevel is a numeric value which a program may "return"
when it terminates. The name is misleading because the value
returned is really an exit code, rather than an indication of an
error per se. It distinguishes different types of normal exits,
in addition to denoting an abnormal condition on exit. The
software's creator (or, in some instances, the program's user)
sets the value(s).
Errorlevels permit the user to craft a batch (.BAT) file, using
DOS batch commands such as IF and GOTO, to logically organize the
BBS or Point operating process. Automagically, this batch file
determines which tasks need be performed and in what order. It
branches between tasks based on the exit code generated by each
program and on the program logic created by the Sysop.
For example, an editor might return the following:
Exit
Code Condition
---- ----------------------------
3 EchoMail and NetMail Created
2 EchoMail Only Created
1 NetMail Only Created
0 No Mail Created
For another example, the ConfMail mail processing program returns
the following errorlevels in the Import mode:
Exit
Code Condition
---- ----------------------------
2 Severe Error in Processing
1 Messages Were Imported
0 No Messages Imported
Branching or jumping within the batch files is facilitated with
the use of labels. A label is used to identify a particular
block within the batch file. For example, you might choose to
label a portion of your batch file "nodelist" because that
particular section of the file handles nodelist processing.
Labels are designated with a colon, followed by the label name.
You may wish to identify the top of the file with a label to make
re-starting the batch file as easy as using a GOTO statement.
Here is a short example of the use of labels:
:start
myprog -p1
BinkleyTerm Version 2.30 - User's Guide - Page 24
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
Note that the top of the file is identified by a label named
"start" and that other sections are labeled as well. The batch
file starts out by invoking a program called MYPROG. Once MYPROG
exits, the errorlevel values determine where in the file that
control will be passed. One errorlevel references another label
that in turn will cause a program named PROC to be run. Another
branch goes back to the top of the file, and yet another goes to
the end of the file. The PROC program also gives errorlevels
that are processed by the batch file.
Errorlevels and associated batch processing commands permit
tailoring the batch file and bypassing of unnecessary processing
steps, saving substantial amounts of time, which, in turn,
translates into more time for user-access and other processes.
(There is NEVER too much time.)
What Errorlevels BinkleyTerm Produces
BinkleyTerm returns errorlevels in four general cases:
Sysop-Initiated
Fx keys, Escape and Alt-X
Sysop-Defined
E1=, E2= and E3= exits used with event scheduling, and
external mail program exits
Caller-Initiated
A non-mail call returns the baud rate code
System-Generated
BinkleyTerm cannot find itself in the nodelist
What errorlevels (exit codes) does BinkleyTerm return?
Many values are "hard coded" in BinkleyTerm or are provided in
the sample files included in the distribution package. However,
only some of the values have "fixed" definitions.
BinkleyTerm Version 2.30 - User's Guide - Page 25
Error-
Level Means Caused By
--------- -------------- ----------------------------------
1 Exit Alt-X Keypress
3 300 bps Call Non-Mail Call at 300 Baud
10 E1= Exit ** F1 Keypress *
12 1200 bps Call Non-Mail Call at 1200 Baud
20 E2= Exit ** F2 Keypress *
24 2400 bps Call Non-Mail Call at 2400 Baud
30 E3= Exit ** F3 Keypress *
40 ** F4 Keypress
48 4800 bps Call Non-Mail Call at 4800 Baud
50 ** F5 Keypress
60 ** F6 Keypress
70 ** F7 Keypress
80 ** F8 Keypress
90 ** F9 Keypress
96 9600 bps Call Non-Mail Call at 9600 Baud
99 ExtrnMail External Mail String Received *****
100 ** F10 Keypress
128 38400 bps Call Non-Mail Call at 38,400 Baud ****
192 19200 bps Call Non-Mail Call at 19,200 Baud
254 Error Address Not Found in Nodelist ***
255 Error Microsoft C Produced Error
* As shipped; the sample BINKLEY.EVT event file included in
the distribution package uses errorlevels 10, 20 and 30 for
E1=, E2= and E3= exits respectively. Thus pressing F1, F2
or F3 has the same effect as BinkleyTerm making an E1=, E2=
or E3= exit. Exits are defined as:
E1= Beginning of Event
E2= Mail Received
E3= Compressed Mail Received
** All F-key exits have user-defined functionality.
*** BinkleyTerm will exit with errorlevel 254 when it cannot
find its own address in the nodelist. Other conditions
checked are:
- Non-Zero Zone Number Designated
- Non-Zero Net Number Designated
- System Name Designated
- Sysop Name Designated
- Outbound (Hold) Area Designated
- Inbound Area Designated
If any of these parameters are not designated or are
improperly designated as noted, then an errorlevel 254 exit
is performed. These parameters are designated in the
configuration file.
**** Errorlevel values allowed by DOS are from 0 to 255.
BinkleyTerm Version 2.30 - User's Guide - Page 26
Therefore, the value of a 38,400 baud exit "wraps" around to
equal 128, instead of 384.
***** The external mail program functionality features
configurable exit values, but the default value is 99.
Making Errorlevels Work For You
You, the user, define ALL errorlevels associated with the E1=,
E2= and E3= exits, setting them in BINKLEY.EVT. You 'program' a
specific task to occur at the beginning of a selected BinkleyTerm
"event" (time interval) by selecting a unique "E1=" 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;
further, you may execute a given task at different times on
different days, if so desired, depending on the way a particular
event is configured. Similarly, by having a variety of E2= and
E3= codes, you can use different mail unpacking routines
throughout the day or week. Refer to the section "Scheduling
Events" in the Reference Guide for details.
You customize the operation of your BBS or Point to meet your
specific needs and those of your "customers".
Errorlevels, Batch Files and ExtrnMail
This BinkleyTerm option is intended for invocation of an external
mail handling program, possibly an alternate mailer, upon
reception of a user-defined string of characters. It can also be
used to set-up multiple BBS installations, allowing a user to
specify which BBS he or she wants. This is covered in detail in
the sections "External Mail Programs" and "User-Selected BBS
Functionality" elsewhere in this manual.
Errorlevels, Batch Files and Housekeeping
Another common application of exits and exit values is for
housekeeping. For example, the author set up his Point system to
do daily housekeeping (deleting and renumbering of the message
base) daily at 8:00am. Twice a day, at 4:00am and 11:00pm, his
Point polls his BossNode. Each Saturday, the Point requests the
current NODEDIFF from the BossNode and, then, on Sunday,
processes the weekly NODELIST. A distinct E1= errorlevel handles
each task.
Thus, only you can prevent chaos and create an orderly
functioning batch file for your BBS or Point. Be vigilant, and
avoid re-using the same errorlevel for several different tasks.
DOS Shell Keys
There are also 9 programmable DOS shell exits which are invoked
BinkleyTerm Version 2.30 - User's Guide - Page 27
by using Alt-Fx key combinations. You enable and set these up in
the configuration file. Look for 'Shell' near the end of the
sample BINKLEY.CFG file included with BinkleyTerm, and refer to
the section "Configuration File," the command 'Shell' in the
Reference Guide.
These shells produce NO errorlevels but are mentioned because
they are an alternate and/or additional solution to creating
Sysop controllable exit/task options. When configured, these
shell keys invoke a new copy of the command processor,
COMMAND.COM. You may not want to use these as they consume extra
memory for the 2nd copy of COMMAND.COM.
Using Errorlevels
How do you use errorlevels? By testing for their existence with
the batch file statement:
IF ERRORLEVEL n GOTO xxx
Where:
n is a numeric value
xxx is a label within the batch file
Bear in mind the following Rules:
The "IF ERRORLEVEL ... " statements must follow immediately
after the program they test.
"IF ERRORLEVEL n" returns true for any value GREATER THAN or
EQUAL TO "n", therefore,
Test errorlevels in descending numerical sequence, and,
Trap unwanted exit codes so that a step will be executed if,
and only if, the desired errorlevel is encountered.
In this excerpt from a batch file, the "Start_BT" label refers to
a section that loads BinkleyTerm:
IF ERRORLEVEL 21 GOTO Start_BT <- Traps 21 to etc. *
IF ERRORLEVEL 20 GOTO OpenMail <- Branch & Open Mail
IF ERRORLEVEL 11 GOTO Start_BT <- Traps 11 to 19 *
IF ERRORLEVEL 10 GOTO Start_BT <- "Non-Event"
IF ERRORLEVEL 3 GOTO Start_BT <- Traps 3 to 9 *
IF ERRORLEVEL 2 GOTO Bad_Exit <- Nodelist Entry Error
IF ERRORLEVEL 1 GOTO Exit_BT <- Branch to 'Exit'
* Invalid responses are 'trapped', BinkleyTerm restarts.
What Now?
Look at some "good" examples which demonstrate automating
BinkleyTerm Version 2.30 - User's Guide - Page 28
processes using batch files and errorlevels. In particular, look
at the samples provided by Bob Hartman and Alan Applegate for
BinkleyTerm (available from 1:104/36), or samples that existing
BinkleyTerm Sysops may be able to provide you. Then, make up
your own batch file to control a process. Or, take one of the
samples and modify it for your specific needs. Have fun! Hack
away!
Consult the documentation for each of your application programs,
determine whether or not it produces errorlevels, and how you can
take advantage of them.
Errorlevel and Batch File Hints and Kinks
When looking at sample batch files, note carefully how each
author organized the program logic in his batch file. Here are
some reminders.
A batch file loses 'control' if it merely invokes another batch
file (e.g. you execute a second batch file within the first);
instead, "shell out" to DOS from the first batch file by invoking
another copy of COMMAND.COM. Using the /C switch closes that
second command processor when the second batch file finishes.
Consult your DOS reference materials for more information on this
point.
Examples:
COMMAND.COM /C Pak_Mail.BAT
or:
%comspec% /C Pak_Mail.BAT
This is true for all MS-DOS versions up to and including 3.2.
MS-DOS/PC-DOS 3.3 introduced the batch command CALL which
overcomes this limitation, when it is used. Refer to your DOS
manual.
Sometimes, your batch file must "remember" what it is doing. You
can accomplish this by "setting" an environment variable, for
example:
SET PROC=UNATTENDED
Your batch file can then determine its "logic path" or invoke
other programs using statements such as:
IF %PROC% == UNATTENDED GOTO xxx
or:
IF %PROC% == UNATTENDED BT UNATTENDED
BinkleyTerm Version 2.30 - User's Guide - Page 29
or:
IF %PROC% == UNATTENDED %comspec% /C Pak_Mail.BAT
In the above examples, the program follows a certain logic path
and performs specific tasks when it's in the unattended mode.
Verify that you have sufficient environment space for any
variables which you want to "store" in it. Review the section
concerning the SHELL entry for CONFIG.SYS in your DOS reference
material. This will explain how to enlarge the environment space
if that is needed. The exact adjustments which you may need to
make are dependent upon your version of MS-DOS/PC-DOS, and
several other factors such as memory use, size of DOS paths and
so on.
You can also pass a variable into a batch file when you invoke a
program. For example, the author's POINT.BAT batch file
immediately comes up in the Unattended Mode if you invoke it
with:
POINT -u (or, POINT -U)
POINT.BAT then leapfrogs directly into unattended mode using the
following statements:
IF %1 == -u SET PROC=UNATTENDED
IF %1 == -u GOTO Start_BT
...
:Start_BT
IF %PROC% == TERM BT <-Terminal Mode
IF NOT %PROC% == TERM BT %PROC% <-Other Modes
Finally, use of errorlevels is not always necessary. Some
programs provide an alternative which may meet your needs.
For example, ConfMail and some editors produce an ".OUT" file
containing the name of each EchoMail area for which mail has been
received or created. Thus, test for the existence of the .OUT
file rather than testing the errorlevels and, thereby, simplify
the logical branching in your batch (.BAT) file. For example:
if exist AREAS.OUT ConfMail Export ... -F AREAS.OUT
if exist AREAS.OUT del AREAS.OUT
or:
if exist ECHO.OUT ConfMail Maint ... -F ECHO.OUT
if exist ECHO.OUT ReplyLnk -F ECHO.OUT
if exist ECHO.OUT del ECHO.OUT
The point here is that such an .OUT file can be used by several
programs serially, as in the last example, and thus, avoid using
BinkleyTerm Version 2.30 - User's Guide - Page 30
errorlevel driven logic. Further, it can continue working for
you after you have "lost" your errorlevel by running another
program.
Environment Variable
In environments where multiple drives and paths are used, it is
generally a good idea to set a DOS environment variable named
BINKLEY. BinkleyTerm can then use this variable to determine
where its configuration file is located, should it not be located
in the current directory.
Place in your AUTOEXEC.BAT file (or in the batch file that starts
BinkleyTerm) the line:
SET BINKLEY=C:\PATH
Where C:\PATH is the drive designator and complete path name
where the configuration file is located.
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 DOS' own EDLIN. The Reference Guide contains a complete
listing of all BinkleyTerm configuration statements and their
proper use.
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.
When you first install BinkleyTerm, or if you change your address
('Address'), inbound files area ('NetFiles'), outbound files area
('Hold'), or NetMail message area ('NetMail') as specified in the
configuration file, you must run a special program included with
the distribution package called "BTCTL".
BTCTL
BTCTL is used to create two files based on information in the
BinkleyTerm configuration file. First, it produces MAIL.SYS, a
Fido-compatible system file used by many mail processing
programs. Second, it produces BINKLEY.PRM, a file used by oMMM,
a mail packer nearly always used with BinkleyTerm.
Note! BTCTL needs to be run only under the circumstances
mentioned above. BTCTL DOES NOT need to be run for minor changes
BinkleyTerm Version 2.30 - User's Guide - Page 31
to the file that DO NOT include address, inbound file path,
outbound file path or NetMail message path.
NODELIST
The listing of FidoNet compatible systems in your network is
called a 'nodelist.' Once a current nodelist is obtained, it can
be kept up-to-date by using so-called NODEDIFF files that are
distributed weekly within the network.
The nodelist and update files are distributed in 'raw' form.
Adjunct software must be used to process and compile the raw
nodelist and NODEDIFF files into a form usable by BinkleyTerm.
From now on, when we refer to "nodelist" we're referring to the
compiled, ready-to-use nodelist data files, not the raw nodelist
file as distributed within the network.
BinkleyTerm is capable of using a variety of compiled nodelist
formats. If you do not already have a BinkleyTerm-compatible
format that you desire to use, the primary formats supported by
BinkleyTerm are the Opus 'Version 5' nodelist, used by Opus-CBCS
1.03b and below, and the Opus 'Version 6' nodelist, used by Opus
1.10 and above.
THE VERSION 5 NODELIST SHOULD BE CONSIDERED OBSOLETE. THE
VERSION 6 FORMAT OR THE QUICKBBS FORMAT (DISCUSSED LATER) ARE THE
PREFERRED FORMATS FOR BINKLEYTERM, AS SEVERAL IMPORTANT FEATURES
ARE UNAVAILABLE WITHOUT THEM.
Point installations do not need a nodelist at all if they don't
care to have one, simply by using all of the following
configuration file statements:
- BossPhone
- BossPwd
- PrivateNet
- Address
Of course, this requires establishing a session password with
your boss (as designated by the 'BossPwd' statement). With this
method, Terminal Mode must be used to poll the boss using the
Alt-Y keystroke, as Unattended Mode will not operate without a
nodelist available. Refer to appropriate sections of the manual
for additional information.
FIDOUSER.LST
The nodelist processing software is also used to produce
FIDOUSER.LST, a list of Sysop names and node address that
BinkleyTerm can use when dialing out. When this file is
available to BinkleyTerm, you can enter a Sysop name in place of
a node address whenever prompted to enter a node address. This
applies to both Unattended and Terminal Modes, while polling or
dialing a system.
BinkleyTerm Version 2.30 - User's Guide - Page 32
FIDOUSER.LST should be kept in the same sub-directory as the
compiled nodelist files are kept.
Version 5 Nodelist
Although this nodelist format is the BinkleyTerm default (for
backward compatibility), it is considered obsolete for use with
the current version of BinkleyTerm.
If you are running a Fido 11w or Opus 1.0x system, BinkleyTerm
can support this nodelist format, but it is highly recommended
that you produce both a Version 5 and a Version 6 nodelist for
your system; the former for your BBS software, and the latter for
use by BinkleyTerm. Again, the Version 5 nodelist is considered
obsolete, and should not be used unless absolutely necessary.
Version 6 Nodelist
Using the Version 6 nodelist allows BinkleyTerm to have more
information at its fingertips, specifically, whether a given node
in the nodelist supports 'Continuous Mail.' Some nodelist
processors are also able to put modem type information into a
compiled Version 6 nodelist. The extended information in a
Version 6 nodelist allows for automatic determination of this
information, resulting in fewer errors that result from attempts
to manually compensate for such variables.
The Version 6 nodelist is a relatively new format. Nodelist
processor commands mentioned in this section apply only to
ParseLst, a commonly available nodelist processing package. You
will be able to locate ParseLst from systems that normally carry
Opus or BinkleyTerm. Other nodelist processors may also support
this format, and their specific commands may vary.
Make certain that you also make the necessary changes to your
configuration file. Add the 'NewNodelist' statement, and change
your event schedules to be compatible as well. Refer to the
Reference Guide for additional information.
Please note that the index files for the Version 5 and Version 6
nodelists ARE IDENTICAL. Therefore, you may use BOTH lists
SIMULTANEOUSLY. This is helpful in installations where Opus-CBCS
1.0x or Fido 11w is used under BinkleyTerm.
With ParseLst, you'll need to use the following statements in the
ParseLst configuration file in order to process a nodelist for
BinkleyTerm's use: UseZone, Complete, and Version6. Don't
forget to use 'NewNodelist' in BinkleyTerm's configuration file.
QuickBBS Nodelist
BinkleyTerm also supports the QuickBBS Version 2.0x nodelist.
This nodelist format is equivalent in functionality to the
BinkleyTerm Version 2.30 - User's Guide - Page 33
Version 6 nodelist described above, including automatic
determination of whether a node can accept Continuous Mail.
In order for the QuickBBS nodelist to be used with BinkleyTerm,
it MUST be processed by ParseLst Version 1.01 or higher. At this
writing, Qnode, the nodelist processor included with QuickBBS,
does not support the extended information BinkleyTerm requires
from the nodelist. ParseLst will insure that the information is
included, as well as provide complete compatibility with
QuickBBS. Other nodelist processors, such as XlaxNode, should
also be able to produce a QuickBBS nodelist that contains the
necessary information for BinkleyTerm to function properly.
To use this format, add the statement 'QuickNodelist' to your
configuration file. Refer to the Reference Guide for additional
information.
TBBS Nodelist
BinkleyTerm can use the nodelist format supported by TBBS. In
order to obtain additional information about the various nodes in
the list, BinkleyTerm requires an adjunct file, NODELIST.EXT.
The nodelist is first processed normally for TBBS. Then,
ParseLst is used to produce NODELIST.EXT and NODELIST.IDX from
the raw nodelist. These files are then used together by
BinkleyTerm to provide full functionality as described above for
the Version 6 nodelist. This includes automatic determination of
whether a node can accept Continuous Mail.
PLEASE NOTE! The TBBS format DOES NOT provide sufficient
information to allow BinkleyTerm's zone support to be active. If
you use this format, YOU MUST ALSO USE the 'NoZones' statement in
your configuration file. Refer to the section "Zone Support" for
additional information.
To use this format, add the statement 'TBBSNodelist' to your
configuration file. Refer to the Reference Guide for additional
information. Also refer to the ParseLst documentation for more
information about compiling NODELIST.EXT.
Nodelist Support Information
The authors of BinkleyTerm are willing to consider supporting
additional nodelist formats. To facilitate the support of your
nodelist format, the following information is required:
1. C language structure definition for the format. (Pascal
is acceptable too, but C is preferred.)
2. Definitions of any of the fields in the format. In
particular, bit fields must be defined, and the contents of
any field that is not obvious must be given.
BinkleyTerm Version 2.30 - User's Guide - Page 34
3. Compiler and instructions for generating the given
nodelist format.
4. Examples of C code to look-up a given
zone:net/node.point number in the nodelist. (Note that any
code used will be given out for free in source form, so this
should not be taken lightly.)
5. A phone number and hours when the author can be reached
if there are issues that need to be resolved.
6. IMPORTANT! A good reason why we should include the
format.
7. IMPORTANT! If this is for BinkleyTerm front-ending for
a certain type of BBS, the author should include
configuration files, batch files, etc. that will be
necessary for others to use BinkleyTerm and his BBS. This
will save us a lot of work tracking these things down in the
long run.
If all of this information is forwarded to 1:132/101, 1:141/491
or 1:104/36 we can get back to the author within a week or two to
tell them whether the format will be in the next release.
ZONE SUPPORT
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 endeavors 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
BinkleyTerm Version 2.30 - User's Guide - Page 35
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.
Your mail packer also needs to support the discrete outbound
areas for multiple zones. oMMM versions greater than 1.30
support them, as well as the MOOO package. oMMM is commonly
available wherever BinkleyTerm or Opus-CBCS files are available.
MOOO is also available from many such locations.
MULTIPLE NETWORK OPERATION
Operation of a system within multiple networks is becoming
increasingly popular. Normally, networks such as AlterNet,
EggNet, RBBS-Net 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 and 4) 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.
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."
BinkleyTerm Version 2.30 - User's Guide - Page 36
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.
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.
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
favored" situations, since you generally know the other person at
the other end (a pre-requisite to establishing a password).
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.
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.
Security - 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
BinkleyTerm Version 2.30 - User's Guide - Page 37
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
'BossPwd' configuration file option, and choose a password. Make
sure your Boss also uses the same password.
For other types of systems, password information is kept in the
nodelist data file. ParseLst (and some other nodelist
processors) can easily add a password to a nodelist entry during
processing. Refer to the documentation for your nodelist
processor.
When talking with other BinkleyTerm, Opus or compatible systems
that use the YooHoo session negotiation method, 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).
Security - 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,
BinkleyTerm Version 2.30 - User's Guide - Page 38
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.
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.
Security - 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'
Known ABOUT 'KnownAbout'
BinkleyTerm Version 2.30 - User's Guide - Page 39
AVAIL 'KnownAvail'
OKFILE 'KnownReqList'
Maximum 'KnownReqLim'
Default ABOUT 'About'
AVAIL 'Avail'
OKFILE 'Okfile'
Maximum 'MaxReq'
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.
Security - 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'
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).
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
BinkleyTerm Version 2.30 - User's Guide - Page 40
with the required information. The batch file should recycle and
restart BinkleyTerm once BBS use is terminated.
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>
SPAWNBBS.BAT 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, and <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).
The batch file can use the parameters passed to it with standard
DOS conventions. %1 designates the first parameter (baud rate in
this case), %2 the second parameter (port number), and so on.
Opus might be started from SPAWNBBS.BAT with this command line:
opus bbs -b%1 -p%2 -t%3
Refer to the documentation for your particular BBS for the
command line information that can be passed to the BBS.
The primary disadvantage of the 'BBS Spawn' option is that
BinkleyTerm stays memory resident while the BBS operates. This
could cause memory availability problems on some systems. Be
certain to check the memory requirements of your BBS software.
If you choose to use the 'SwapDir' configuration file option, the
'BBS Spawn' option will be workable. Using 'SwapDir' causes
BinkleyTerm to leave only a small kernel of itself in memory when
performing DOS shells, making available substantially more memory
than would otherwise be available. Refer to the Reference Guide
section "Configuration File" for additional information.
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
BinkleyTerm Version 2.30 - User's Guide - Page 41
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.
BinkleyTerm Version 2.30 - User's Guide - Page 42
BBS Batch Method Flowchart
The 'BBS Batch' method of accessing BBS software is confusing to
many BinkleyTerm users.
For further clarification, a flowchart of this method is shown
here:
+-----------------------+
| Wait for Call | <-------------+
+-----------------------+ |
| |
v |
No +-----------------------+ |
Mail <------| Human Caller? | |
+-----------------------+ |
Yes | |
v |
300 +-----------------------+ 1200 |
+------| Baud Rate |------+ |
| +-----------------------+ | |
| 2400 | | 9600 | |
+--------+ | | +--------+ |
| | | | |
v v v v |
+-----------------------+ |
| Invoke BBSBATCH.BAT | |
+-----------------------+ |
| |
v |
+-----------------------+ |
| Invoke SPAWNBBS.BAT | |
| w/ Parameters | |
+-----------------------+ |
| |
v |
+-----------------------+ |
| Invoke BBS System | |
| w/ Parameters | |
+-----------------------+ |
| |
+---------------------------+
Banner
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.
BinkleyTerm Version 2.30 - User's Guide - Page 43
EXTERNAL MAIL PROGRAMS
BinkleyTerm can be used with external mail programs, such as
UUCP.
When an 'ExtrnMail' statement is used in the configuration file,
BinkleyTerm will answer the phone and wait for a YooHoo or TSYNC
(the start of a mail session) or a string you designate with the
'ExtrnMail' option. When the designated string is received from
the remote system, BinkleyTerm will send the string associated
with the 'MailNote' configuration file option (if any), then will
physically write a batch file called MAILBAT.BAT to the disk, and
exit the start-up batch file with an errorlevel as given with the
'ExtrnMail' statement, or with errorlevel 99 if none was given.
MAILBAT.BAT contains a single line:
EXTMAIL <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-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
BinkleyTerm Version 2.30 - User's Guide - Page 44
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).
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.
BinkleyTerm Version 2.30 - User's Guide - Page 45
In EXTMAIL.BAT (where the BBS systems are invoked), the top of
the batch file should make a determination as to which choice was
given by the user. One of the parameters on the command line
when EXTMAIL.BAT is invoked by MAILBAT.BAT is the errorlevel
which corresponds to the choice the user gave (as designated by
an 'ExtrnMail' statement in the configuration file).
A section of the batch file might look like this:
if %4 == 130 goto bbs1
if %4 == 140 goto bbs2
if %4 == 150 goto bbs3
The fourth parameter given on the command line is the errorlevel
value, and is reference by "%4" as shown. For example, if the
errorlevel that corresponds to the choice was 130, then batch
file execution would jump to the "bbs1" label, and invoke a
particular BBS program.
Please note that the default is for a user to press the "escape"
key to enter the BBS. One of the BBS systems should be setup as
the default system as described in the section "BBS Interface."
Should a user press "escape," or if the time limit to make a
response should expire, the default BBS would be invoked.
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.
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 one of the many
utilities designed for the purpose, such as AMAX, Please, oGet,
tGet, etc. Any Opus-compatible file request builder can be used
with BinkleyTerm. You may also manually build file requests.
They are a single-line flat ASCII text file, and are named in the
same manner as packets (refer to the section "How BinkleyTerm
Handles Mail" for information on the naming convention) and have
a file extension of .REQ. Outgoing requests NEVER should have a
drive and path designation; only the file name. The remote
system handles the drives and paths.
BinkleyTerm Version 2.30 - User's Guide - Page 46
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.
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 BEXE_150.ARC 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.
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
BinkleyTerm Version 2.30 - User's Guide - Page 47
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. Of course, it could also be
manually created.
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, 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 item that applies to file requests is the
'MaxReq' statement contained in the configuration file. A
quantity is given with the statement which allows you to
designate the maximum number of files that will be sent 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."
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.
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
BinkleyTerm Version 2.30 - User's Guide - Page 48
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, the oMMM mail packer (version 1.30 or higher)
and the AMAX outbound utility (version 2.10 or higher) both
support the creation of update requests in the manner that
BinkleyTerm requires. Refer to the documentation for those
programs for additional information on creating update requests.
Certainly other utilities will eventually have this ability as
well.
Please note that in order for update requests to work, the remote
system must have the file you want updated available for regular
file request. You cannot update a file that would not otherwise
be available for file request from the remote system.
REQUEST RESPONSE FILES
Incoming file and update requests are not always successful.
BinkleyTerm supports the ability to dynamically generate a
"response file." This file is a plain text file, 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.
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.
BinkleyTerm Version 2.30 - User's Guide - Page 49
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.
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.
$ 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
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
BinkleyTerm Version 2.30 - User's Guide - Page 50
See "Function Request Notes" below for additional function
request information.
+ 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.
Function Request Notes
If a function request triggers a program or batch file to build a
file attach (flow) file, then BinkleyTerm will process the file
attach during the current session. In other words, if a file
attach is generated during a function request, then the file(s)
shown in the file attach will be sent during the current session.
Note that the normal logic for the handling of .HLO (Hold file
attaches) still applies; i.e., file(s) designated within a .HLO
file will be sent only when the destination node polls for pick-
up.
BinkleyTerm Version 2.30 - User's Guide - Page 51
A WORD ABOUT POINT NETWORKS
BinkleyTerm is well suited to the task of being a "boss" (or host
system) of a point network. 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 at
this time, certain "kludges" must be used in order to handle a
point network.
Essentially, the process involves using a private network
address, and assigning node numbers to the points under the boss.
For example, 1:104/36.17 (point #17 off of node 104/36) might
actually be assigned 1052/17 for the purpose of transacting mail
with the boss. For reference purposes the point is 1:104/36.17,
but mail is actually held for 1052/17 to pick-up, and the point
must call as 1052/17.
Often times, private point addresses will make their way into
EchoMail "SEEN-BY" lines. This could cause problems down the
line if another system uses the same private address. For this
reason, IT IS RECOMMENDED THAT YOUR PRIVATE NETWORK ADDRESS BE
ASSIGNED BY THE INTERNATIONAL COORDINATOR. The International
Coordinator requests that you adhere to this recommendation, and
contact him directly for a private network number assignment. As
a boss node, you may then use the network address to assign your
points their own node address in the private net for the purpose
of transacting mail.
The International Coordinator can be reached at 1:1/0.
To receive a private net number, the information that follows is
needed. All information will be held in confidence, but is
needed in case the International Coordinator needs to get a hold
of the private net administrator. As soon as this information is
received, the International Coordinator will issue a private net
number:
- Name of the Private Network Administrator
- Name of the Private Network (if any)
- Mailing Address
- Voice Phone
- Data Phone
- FidoNet Node (if any)
- Alternate E-Mail Addresses (i.e., Usenet, Bitnet, MCI
Mail, Telex, etc., if any)
Your cooperation in obtaining an assigned private network number
for use on point networks will help ensure network integrity.
BinkleyTerm Version 2.30 - User's Guide - Page 52
+-------------+
| +---------+ |
| | Section | | BinkleyTerm User's Guide
| | 4 | | PROBLEM SOLVING
| +---------+ |
+-------------+
BINKLEYTERM SUPPORT
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 EchoMail Conference.
This conference is carried worldwide via FidoNet. Contact your
EchoMail Coordinator or Hub 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.
A secondary source of support is provided by BinkleyTerm HELP,
Shawn Stoddard, at FidoNet 1:1/102.0. If you have an urgent
question, or are unable to hook into the BINKLEY EchoMail
Conference, send a NetMail message to BinkleyTerm HELP. Replies
are issued as time and resources allow, so please be patient.
TROUBLESHOOTING
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
EchoMail conference, or contact BinkleyTerm HELP at 1:1/102.
Baud Rate Locking Trouble
Do not use BinkleyTerm's 'LockBaud' configuration file statement.
Lock the baud rate of your FOSSIL instead.
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'
BinkleyTerm Version 2.30 - User's Guide - Page 53
statement, you are essentially telling BinkleyTerm to send TWO
carriage returns, yours, plus the default. With most modems,
this will immediately abort the dialing 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.
False Call Collision Reports
In some installations, BinkleyTerm may abort the dialing 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.
FOSSIL Driver Compatibility Problems
The two most popular FOSSIL drivers in use with BinkleyTerm are
Ray Gwinn's X00 and Bob Hartman's OpusComm, both of which are for
the IBM PC and close compatibles. If one of the drivers fails to
work correctly in your installation, please try the other.
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.
TBBS Difficulty - BinkleyTerm Runtime Errors
When used with TBBS, BinkleyTerm must be renamed MAILER.EXE.
Since BT.EXE uses overlays to provide more efficient memory
usage, it CANNOT be renamed. TBBS users should be certain to use
BTBIG.EXE, the non-overlay version, on their systems, renaming it
to MAILER.EXE before use.
Some TBBS Sysops have patched TBBS.EXE to invoke BT.EXE, which
allows them to use the overlaid version. While if this is done
correctly it will probably cause no problems, we cannot recommend
this course of action.
DOS Shell Not Working Correctly
BinkleyTerm is developed under Microsoft C. The MSC routines do
not use COMSPEC to find COMMAND.COM, which is needed to perform a
DOS shell or child process. COMMAND.COM must be found on the DOS
path. Refer to your DOS documentation for information and
BinkleyTerm Version 2.30 - User's Guide - Page 54
instructions regarding COMSPEC, and the SET PATH command.
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.
Date Rollover Problem
BinkleyTerm keeps schedule information in binary form in a file
named BINKLEY.SCD. If for some reason the file is newer than the
current date and time, BinkleyTerm will report "Date Rollover
Problem?" as this condition is usually indicative of a problem
with DOS rolling the date over at midnight properly. If there
appears to be no difficulty with date rollover, delete the
BINKLEY.SCD file, and allow BinkleyTerm to contruct a new one the
next time it is invoked. A date rollover problem sometimes does
exist with certain versions of DOS. If the problem persists, a
DOS upgrade may be indicated.
GLOSSARY
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.
BinkleyTerm Version 2.30 - User's Guide - Page 55
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.
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 pre-scheduled 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.
DTR
See "Data Terminal Ready."
Dutchie
A FidoNet mailer written by Henk Wevers.
Dynamic Event
A system event (see "Event") that stops when particular
BinkleyTerm Version 2.30 - User's Guide - Page 56
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.
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 pre-configured 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.
FOSSIL Driver
FOSSIL is an acronym for Fido/Opus/SEAdog Standard Interface
Layer. Since not all computers capable of running MS-DOS
are hardware compatible with the IBM PC, communications
software typically written for the IBM PC may not operate on
machines such as the DEC Rainbow, Sanyo 555 or Heath/Zenith
100.
The FOSSIL provides a consistent manner for a communications
BinkleyTerm Version 2.30 - User's Guide - Page 57
program to access the communications ports, keyboard and
screen. The FOSSIL is typically installed at boot-time,
either as a device driver or as a program. The driver MUST
be installed prior to running any FOSSIL compatible
software, BinkleyTerm included, or an error message will be
generated, and the program will abort.
FOSSIL drivers are normally available from systems that
distribute Opus-CBCS and/or BinkleyTerm software. Examples
of FOSSIL drivers are: OpusComm by Bob Hartman for the IBM
PC and close compatibles, X00 by Ray Gwinn for the IBM PC
and compatibles, and DECCOMM by Vince Perriello for the DEC
Rainbow.
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.
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.
BinkleyTerm Version 2.30 - User's Guide - Page 58
msged
An Opus/Fido compatible message reader/editor by Jim Nutt.
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.
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.
BinkleyTerm Version 2.30 - User's Guide - Page 59
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 pre-determined 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.
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.
Scan
Usually associated with EchoMail processing, "scanning" is
the process of taking new messages from a form usable by a
BinkleyTerm Version 2.30 - User's Guide - Page 60
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.
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.
BinkleyTerm Version 2.30 - User's Guide - Page 61
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.
VFOSSIL (Video FOSSIL Driver)
A standard resident driver that allows a software program to
access display hardware in a consistent manner regardless of
hardware compatibility. This is an extension of the FOSSIL
driver, and may not be supported by all FOSSIL drivers at
this time. A VFOSSIL allows much faster access to the video
display hardware than a FOSSIL driver alone would support.
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.
YooHoo
A method of mail transfer session negotiation which
determines if the remote system is capable of handling
BinkleyTerm Version 2.30 - User's Guide - Page 62
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.'
Comments
Post a Comment