I

Inter Change
Connectivity Option Module
I
 Interchange Version 1.1

Connectivity Option Module

For TBBS Version 2.3M

Installation and User Manual

Copyright © 1995 by Philip L. Becker, Ltd.

All Rights Reserved

THIS SOFTWARE IS NOT FOR SALE
eSoft, Inc. does not “sell” Interchange. It sells only the media it is contained
on. It licenses you the use of the software only under the following license terms
and conditions.

License Agreement
Carefully read the following terms and conditions. Use of this
product constitutes your acceptance of the terms and conditions,
and your agreement to abide by them subject to paragraph 7 below.

1. This is an end-user license. You, the original purchaser, are

granted this license for the use of the Interchange software under
the terms stated in this agreement. You may not assign or transfer
the software or this license to any other person without the express
written consent of eSoft, Inc. Any attempt to sublicense, assign, or
transfer any of the rights, duties, or obligations hereunder is void.
eSoft, Inc. does allow you to transfer this license under the condi­
tions outlined on your registration form. This procedure consti­
tutes express written consent under this provision if it is followed
properly.

2. The Interchange software is copyrighted material. Once you have

paid the required single copy license fee, you may use the software
as long as you like provided you do not violate the copyright or any
of the following conditions.

3. Single CPU License. You may use the software on any computer
for which it is designed so long as it is not in use on more than one
computer at the same time. You must pay for additional licenses
if you want to use this software on more than one computer at the
same time. You may install the software on more than one com­
puter, as long as the same program is not in use at the same time
on more than one computer.

4. Backup Copies. You may make as many backup copies of the

software as you require to avoid loss. You are responsible for all
backup copies you make, and must assure they do not result in any
use of the software which would conflict with the provisions of
paragraph 2 above.

iii
5. Software Modification. You may not make any changes or modi­
fications to the Licensed software not expressly authorized by
eSoft, Inc., Phihp L. Becker, Ltd. or their agents. This includes but
is not limited to disassembly and reverse engineering the software.
The single exception granted under this Ecense is the changing of
text strings in the programs for customized presentation.

6. Federal Government. This Software is Commercial Computer

Software under the Federal Government Acquisition Regulations
and agency supplements to them. The Software is provided to the
Federal Government and its agencies only under the Restricted
Rights Provisions of the Federal Acquisition Regulations apphca-
ble to commercial computer software developed at private expense
and not in the pubhc domain.

7. You may refuse to abide by this license by returning all materials

within 30 days, along with a written statement that you have kept
no copies of the software or documentation. This statment must be
signed by you and becomes a legally binding statement that you
have indeed destroyed any backup copies you may have made in
those thirty days. If you keep the materials beyond the 30 day
period, or refuse to assure that you have not kept any copies of the
software or its documentation, then you are fully bound by this
agreement.

8. Limitation of Liability. In no case shall the Liability of eSoft, Inc.

or Philip L. Becker, Ltd. exceed the Ecense fees paid for the right
to use this software or One Hundred Dollars ($100.00), whichever
is greater.

9. This agreement may not be modified except by a written instru­

ment signed by eSoft, Inc. This Ecense constitutes the entire agree­
ment and understanding between you and eSoft, Inc., and
supersedes any prior agreement or understanding whether oral or
written relating to the subject of this License.

iv
Table of Contents

An Introduction to Interchange................................... .1
Installation of Interchange.......................................... .4
Adding Interchange to a Menu.................................... .6
Opt Data Switches........................................................ .6
Interchange Applications............................................. .9
Types of Lines Support by Interchange....................... .11
Interchange Console Display....................................... .11
Monitoring InterChange Lines..................................... .12
Introduction to Interchange Scripting......................... .13
The Interchange Script Language............................... .14
Script Commands......................................................... .16
Script Debugging....................................................... . .27
Insertion Parameters.................................................... .28
Using Door Programs With Interchange..................... .30
Setting Up “Door” Slave Machines.............................. .30
Calling Doors From InterChange................................ .32
Running Direct Screen Write DOS Programs as Doors .33
Using DESQview on “Door” Slave Machines.............. 33
How Drop File Templates Work.................................. 34
External Events on Slave Machines.............................. 36

V
vi
An Introduction to Interchange
Interchange is a powerful, easy-to-use data switch option for TBBS. At first it
may be difficult to appreciate the full capabilities of Interchange, but with use
you’ll find many applications for its functionality. This introduction is designed
to help get you “on-board” with the three operating modes that Interchange
offers. With this understanding, you’ll be able to quickly put Interchange to use.

Local Console Terminal Program

This mode of Interchange operation is for your use (as sysop) only. It allows
you to logon to the local console, access Interchange, and use one of the lines
on TBBS to dial out to another system. It’s like having a terminal program you
can run at your TBBS machine - while the system stays running. You can use
any idle line on TBBS (except hard-wired lines configured as “Autobaud”).

The local console terminal program has the basic functions of any terminal
program, including a dialing directory, uploading and downloading to and from
the local TBBS hard disk, keyboard macros, and scripting. The only limitation
is that you cannot select data bit or parity settings (that’s set in CEDIT as part
of the line’s configuration).

Data Switch
In this mode InterChange allows a user who is logged on to TBBS to connect to
another line. It’s much like a “software patch cord.” Once the connection is
made data flows between the two lines until the session is ended. Interchange
may be invoked in the data switch mode either manually (i.e., the user selects
and manages the connection process) or with a “startup script” that can super­
vise the initial connection.

Most non-sysop use of the data switch mode will be performed with a start-up
script. This allows you to have a menu selection in TBBS (for example) acquire
an idle line from a particular group, either dial (if a modem) or connect (if
hard-wired) to the desired “other system.” The script could also perform the
logon to that system if desired. After the session is established, the script
“throws the switch” and patches the two lines together as though the TBBS caller
had dialed the other system directly.

Once the data switch is connected, TBBS is “out of the loop” and to the caller
it looks as though the other system is directly connected to him until the “end
of session” criteria is met. There are several options for what ends the connec­
tion, depending on how the session was made. A script can make the connection
process either visible or invisible to the caller who invoked the menu selection.

1
In data switch mode, Interchange will often be used with a modem to call a
remote system and connect the TBBS user to that system. Applications for this
mode are limitless - any system which can be accessed by a dial-up modem can
be accessed through Interchange. In essence, Interchange allows your TBBS
system to function as an outbound modem pool.

InterChange can also connect users outward through a hard-wired serial line.
Anything you can attach to TBBS through an asynchronous serial connection
can be accessed this way. Application examples include allowing access to an
adjacent UNIX system for e-mail, telnet or ftp sessions; access to a mainframe
computer database; access to another BBS running adjacent to the TBBS system
- any system which can be reached through a hard-wired serial connection.

Ghost Mode Terminal Program

In this mode, Interchange is invoked (with a specified script) on a line as a ghost
task and uses that line as a scripted terminal program. Do you currently use a
terminal program (such as Procomm) during an external event to dial out and
get files? This mode of InterChange can replace that function. Under script
control, Interchange can be scheduled to “come ahve” on a line, dial out, and
perform functions such as file pick-up - while TBBS stays online and available
to callers.

Potential applications include dialing out on a scheduled basis to pick-up the

latest issue of USA Today Decisionline, Eeeek Bits, or any other online publi­
cation; dialing out on a regular basis to get database updates from a remote BBS
or computer service - any application that involves the unattended dialing of a
remote system under Interchange script language control.

Understanding Interchange’s Limitations

Interchange is a pure data switch product. It works on the analogy of a master
and slave line which it connects together. The “master” line invokes the Inter­
change session. The “slave” is the line which is used to dial or connect
outwardly to another system. In the local console terminal program, the local
console is the master and the line you dial out on is the slave. In data switch
mode, the user online to TBBS is the master, and the line dialed out on is the
slave. In ghost mode, things are slightly different - in most cases the master and
slave lines are the same (but can optionally be different lines too). In any case,
every Interchange session logically has a master and a slave.

InterChange may not be able to do some of the things it might at first seem like
it should. For example, InterChange cannot be used for Unking chat systems
together. Although it seems like a simple InterChange appUcation, in reahty
chat Unkage doesn’t have a master - once a connection was estabhshed, the
master would in effect disappear forming a transparent, background linkage.
2
Interchange must always have a controlling master, and therefore couldn’t be
used for chat linkage.

Many people have wondered if Interchange could be used to hook together a

TDBS application at two different sites for transparent data sharing between a
program running at both ends. Again, this is something that Interchange is not
capable of. Although this scenario might appear to have a master and a slave,
it doesn’t because Interchange would have to give up control to the TDBS
program. So in this scenario, the TDBS application would have to function as
a master, but that’s not possible because the master must be Interchange.

Interchange can be used to connect outward on a TBBS 2.3 TIPX “line.” In

this case, the name of the TIPX server that TBBS will try to connect to is given
in CEDIT, and when the line is grabbed by Interchange, a TIPX connection
will be attempted as part of the GRAB process.

When planning Interchange applications, remember that Interchange must be

the master and that two parts of TBBS cannot rim on the same line at the same
time.

3
Installation of Interchange
To install the Interchange option module, copy the file ICHG.EXE from the
Interchange release disk into the TBBS sub-directory on your disk. Then add
the following command line switch to your MLTBBS command line:

/O:ICHG

If you already have option modules installed on your TBBS (such as TDBS or
SYSOM) then make certain then simply add the reference to Interchange at
the end of the fist, like so:

/O:TDBSOM,SYSOM,ICHG

This will install the option module. The extra memory required for the Inter­
change option module is:

OM CODE memory = 52,352 bytes

OM UDATA memory = 31,776 bytes/user conventional or 32k/user EMS

The OM CODE memory must fit in the 640k conventional memory on your
computer, while part or all of the OM UDATA memory may go in either
conventional or EMS memory. The total extra memory required may be calcu­
lated as 48,152 + (31,776*users).

For example if you have 5 lines configured in CEDIT, there are really 6 users
(the console is a user too) and thus the memory required to install InterChange
on a 5-line TBBS is:

48,152 + (31,776*6) = 238,808 bytes.

The 48,152 bytes of OM CODE memory MUST be in conventional memory.

The 190,656 bytes of OM UDATA memory may be in conventional or EMS
memory.

OM UDATA memory is shared with other option modules, such as TDBS,

SYSOM, etc. The size of the OM UDATA memory will be no larger than the
largest size requested by any option module you have installed. The illustration
at the top of the next page shows this concept:

4
 SYSOM

Interchange

TDBS

QSO

i r
0 16 32 48 kbytes of OM UDATA Memory

The largest amount of OM UDATA memory required

by any one option module is the maximum
amount needed by all combined.

If you have a large number of option modules installed, and you have sufficient
quantities of EMS memory available, and TBBS still fails to load due to an “out
of memory” error, you may need to implement option module code stacking. On
386 and 486 based PCs which implement true LIM 4.0 EMS memory (via
QEMM, 386Max or the MS-DOS utilities HIMEM.SYSZEMM386.EXE) you
can “stack” option module code into EMS memory. To do this, simply change
the TBBS command line switch from /O: to /OX: like so:

/OX:TIMS,TDBSOM,SYSOM,QSO,ICHG

With option module code stacking, the amount of conventional memory used
for option module code is no larger than the largest single option module you
have (usually TDBS). No matter how many option modules you install, no
additional conventional memory will be used (the modules will be loaded into
EMS memory instead). The following illustration shows this concept:

■g
•K

W
: Relocated to
3
EMS Memory
s
S
v
o

Upper Memory

DOS TBBS OM« 8

e
640k 384k
—
5
Adding Interchange to a Menu
When the Interchange option module is installed, a new command type be­
comes available for use in menus. This command is like any other TBBS menu
command and may be used in any menu as you wish. The new command is:

TYPE=210

There are several Opt Data switches available which control InterChange
start-up behavior, and they are described below.

As with all TBBS commands, the Type 210 command may be used in as many
different menu entries and in as many different forms as you wish. All normal
TBBS security occurs via the PRIV = and A1-A4 flags on the menu entries.

Opt Data Switches

Interchange supports several switches which can be placed on the Opt Data
line of the calling menu. The use of these switches allows you to invoke
Interchange with options which will control its behavior. In most applications
of Interchange, you’ll use one or more of the following switches:

OPTDATA= [<script>] [/P:<phone>] [/L[G]:<lines>] [/E:<n>]

[/C] [/I:<secs>]

The meaning of the various switches is as follows:

< script >

Example: dialhost.scr

This optional switch, if present, is the filename of a start-up script. If the path
is not specified, the current directory and the SET TBBSPATH = directory list
are searched to locate it.

/L:< lines >

/LG: < lines >
Example: /L:1,5-10,17

These optional .switches represent a line usage restriction specification which

lists the only lines which are available to use as a slave for this invocation. Line
numbers are separated by commas. A range of lines may be designated by using
a hyphen (-) between two numbers.

6
If/LG: is used, the lines will be automatically tried in order and the entry aborted
if none are available. The lines listed will be “preferred” in the order they are
listed.

If /L: is used, then the normal manual select screen will only allow selection of
the specified lines.

/E:<n>
Example: /E: AA

This optional switch defines the “escape” character to exit terminal mode when
Interchange is being used as a data switch. A user can exit terminal mode by
pressing this character three times in succession. ~ A through ~ Z may be used
to specify a control character; otherwise a single printable character can be
specified. The default is a hyphen (-).

/C
This optional switch sets Interchange to automatically exit to TBBS when the
slave line’s CD changes from high to low (i.e. the session is ended by the remote).
Without this switch Interchange remains connected on loss of carrier.

/I:<secs>
Example: /l:120

This optional switch defines an inactivity timeout when a slave line is attached
in either data switch mode or console terminal program mode. If no data moves
through the connection for the specified number of seconds, the attached line
(slave) is automatically released. If /C is also specified Interchange also exits.

ZQ
Example: /Q

This optional switch inhibits display of the Interchange start-up message. This
switch also inhibits the status line on the local console.

/P<n>:"<string>"
Example: /P2: "foobar"

This optional parameter allows you to set the value of a parameter, Pl through
P9. < n > indicates which parameter. The parameter is set to the contents of
< string >. Parameters are referenced within a script using the insertion pa­
rameters %P1% through %P9%. A parameter is 32 characters maximum.
Parameters are used to pass information into a script from the Opt Data line.

7
zs
Example: /s

This optional parameter sets InterChange to run in “single run” mode. In this
mode InterChange will always exit completely if a startup script exits. If there
is no startup script, then InterChange will exit instead of returning to the line
selection menu allowing only one Interchange session per menu call.

/X:"< string >"

Example: /X:"session disconnectedAMAJ"

This optional parameter allows you to set an exit condition to be set based on
data received from the remote. The data being looked for is designated by
< string >. If this string is received, InterChange will react the same as if carrier
were lost on the slave and /C were specified (i.e., it will fully exit Interchange).

NOTE: For InterChange to detect the specified string, it must be matched

exactly (i.e., upper and lower case do count) and it must be followed by 1 second
with no data. You must include any trailing carriage returns and/or line feeds
in the string explicitly (using for carriage return, and ~ J for linefeed).

An exit string specified on a SESSION script command will disable the /X: exit
string for the duration of the SESSION command. A SESSION command with
no string specified will act as if the /X string were specified on the SESSION
command.

Interchange Applications
Interchange can be used for a variety of connectivity applications. To help get
you started thinking about how you can apply InterChange in your situation, we
offer the following examples.

Get an Online Publication (USA Today, etc.)

Online publications are increasingly popular among BBS sysops and users alike.
One of the oldest is USA Today Decisionline, distributed each weekday by
Boardwatch Magazine through their BBS. For a fee, sysops can download USA
Today and post it on their BBS for reading by callers.

Before Interchange, the only way for most TBBS sysops to retrieve a copy of
USA Today was to shut-down TBBS, run Procomm (or some other communi­
cations software) and, using a script, call the host BBS and download the file.
Now, with Interchange, TBBS doesn’t have to come offline at all. At a pre­
scheduled time using a TBBS ghost event, Interchange can be triggered to
8
“come alive” on a TBBS line, rim a script, and collect the latest issue - all
unattended with TBBS remaining online for callers.

Access to Outside CPU

There are many situations where you might have wished that TBBS could
connect a user to some sort of outside computer, such as a mainframe, mini­
computer, or even another PC, to run programs or perform transaction process­
ing of some sort. With InterChange, it’s now possible to connect a TBBS user
to another computer easily through a modem or other asynchronous serial
connection.

For example, you may wish your callers to be able to connect through a UNIX
machine to another site via Internet. With InterChange, you could write a script
which picks-up a line, dials a UNIX host, logs on, issues a “telnet” command to
access another site, then releases the caller once a connection is established.
The user need never know that there are three computer systems connected
together to provide the caller with the functions he wants - through Interchange
script automation, the entire process is transparent to the user.

Outdial Modem Pool

Interchange can also be used to provide a convenient modem pool to a business
or other organization. For example, a company runs a TBBS system for cus­
tomer support, and connects service representatives around the office to the
TBBS system through hard-wired serial connections. With Interchange in­
stalled, representatives can now easily access a modem on the TBBS system for
outdial use. Before Interchange, each representative had to have their own
dedicated telephone line and modem at their PC. Pooling modems with TBBS
and Interchange is much more cost effective, and allows “load sharing” of the
modems and phone lines, further reducing the number required for the job (and
of course reducing costs, too).

Make Your Morning Coffee

Making coffee in the morning can be so inconvenient. While still half-asleep,
you carefully measure the coffee and water, spilling things and making a mess.
With Interchange and a few other components, you can automate this process
and have TBBS and Interchange make your morning coffee for you.

First, the coffee pot is connected to an X-10 Powerhouse appliance module (also
available at Radio Shack under the “Plug ’n’ Power” name). Next, an X-10
telephone access unit is connected to a telephone line in your home. Using a
ghost event, Interchange “comes alive” on a line at the proper time, dials the
X-10 access unit, and using touch-tone sequences instructs the access unit to

9
turn the appliance module on. Within minutes, fresh coffee! All you have to do
is make sure you load the coffee pot with coffee and water before you go to bed.

Summary
As you can see, Interchange is a flexible connectivity option which addresses a
wide variety of applications, from the practical to the bizarre. If you feel you’ve
come up with an interesting and unique application for InterChange, let us
know. We’re always interested in knowing how you’re using our products.

10
Types of Lines Support by Interchange
Interchange supports the local console and any type of outside line for master
operation, including modems and hard-wired connections. (The “master” is the
user logged onto TBBS who starts an Interchange session.) For slaves, Inter­
change supports modem, hard-wired and TIPX lines, except those configured
as “Autobaud” in CEDIT. (The “slave” is the line Interchange will perform the
outward connection on.)

To use a hard-wired line as a slave, it must be configured as one of the “Fixed”

selections in CEDIT (under the field labeled “Modem”) and the data rate must
be locked at the designated speed on the remote system to which Interchange
will connect.

Interchange Console Display

Use of Interchange will be reflected on the TBBS local console. In data switch
mode, the master line will show as a normal TBBS user with the FCN field
showing “Ichng.” If a slave is in use, that line’s status fields will show as follows:

Caller/Status: InterChange Ghost

BPS: Speed of current connection. Initially this will show as

“Ghst” but as calls are made the speed will reflect the
last connection made.

Menu and FCN: Menu will show “For” and FCN will show “LN xx” to
designate the line that is the “master” for this slave line.

In ghost line script mode, the status fields will show as follows:

Caller/Status: Interchange Ghost

BPS: Speed of current connection. Initially this will show as

“Ghst” but as calls are made the speed will reflect the
last connection made.

Menu: This field will be blank.

FCN: This field will show “Auto” indicating the Interchange

ghost is automatically executing from a script.

11
Monitoring Interchange Lines
From the TBBS local console you are able to monitor line activity. When
monitoring InterChange master and slave lines, however, there are some limi­
tations you need to be aware of. They are:
• Monitoring lines from the console terminal program mode is not
possible, since you occupying the local console when you use
Interchange in this mode.
• Monitoring lines when Interchange is running in data switch mode will
show on the status line of the screen only that Interchange is active.
On a master line, it will indicate which line, if any, is the slave. On a
slave line, it will indicate which line is the master. You are not able to
monitor the data stream which is passing through Interchange.
• If you monitor a ghost task running InterChange, you will see each
non-comment script line prefixed with its line number from within the
script itself. You will also see the progress status display for any file
transfers that are occurring as the result of a SEND or RECEIVE script
command. NOTE: In ghost mode, InterChange can only execute a
script through to its end. This monitoring mode allows you to follow
the progress of the script and can be useful in debugging script
problems. For further information on script troubleshooting, refer to
the section “Script Debugging” later in this manual.

12
Introduction to Interchange Scripting
Interchange demonstrates its greatest value when it is operated with a script.
A script allows InterChange to automate all or part of an Interchange session.
There are two types of Interchange scripts:
• Start-up script. This type of script is designated on the Opt Data line
of the menu entry which invokes Interchange. This is the most
commonly used type of Interchange script.
• User script. This type of script is invoked one of two ways, both of which
are done from the local console terminal mode only; by pressing Alt-S
and designating a script name, or by selecting a dialing directory entry
which has a script associated with it. User scripts cannot be invoked
from data switch mode or from ghost mode.
The behavior of scripts follows some general rules you should understand before
you begin writing and using scripts. These rules are:
• A script ends execution when control “falls out the bottom” of the script
(execution runs to the end of the script without the flow being
interrupted or redirected elsewhere in the script). A script exits also
when an END command is reached within the script itself. All other
exits constitute an abnormal script abort due to an error.
• If a start-up script aborts or exits, and there is no line connected when
this occurs, InterChange will shut-down (returning control to TBBS).
If the script exits normally (and does not abort), and there is a line
connected at the time, then InterChange will enter manual terminal
mode using the connected line. A script abort will always cause an
immediate Interchange shut-down. (If Interchange shuts down when
operating in ghost mode, TBBS releases the line(s) Interchange was
using in conjunction with the affected connection.)
• A user script invoked in conjunction with a dialing directory entry will
be automatically started once carrier is established with the dialed
system. From this moment forward, script operation and behavior is
identical to a user script which was invoked using the Alt-S command
from local console terminal program mode.
• A user script will always enter manual terminal mode when the script
either aborts or exits normally.
• If a user script aborts, an abort dialog box will appear listing the line
number at which the script aborted for debugging purposes.

13
The Interchange Script Language
The Interchange script language is a powerful collection of commands that
allows you to assemble scripts that perform a variety of functions. We recom­
mend that you study the language carefully before writing any scripts so you can
become familiar with its capabilities and how various features are implemented.

InterChange scripts have relatively few structural or syntactic rules. There are
some, however, and they are outlined here:
• No script line may be longer than 255 characters.
• Any line on which the first non-blank character is not a colon (:) or a
letter A through Z is treated as commentary and is ignored. Lines that
are completely blank are allowed, and are also treated as commentary.
• All branch labels may be optionally preceded by the keyword GOTO
for easier human reading.
• Script files may be of any size, and labels may be placed on any line
within the script. A label is defined by a colon (:) as the first non-blank
character of the line. The remainder of the line is the label (no leading
or embedded blanks are allowed). Labels may be up to 20 characters
in length, and must begin with a letter A through Z. Any number of
labels may be used in an Interchange script. Examples of labels are:

: PART_1
:END

• AH script commands begin with a verb. The first character of the verb
is always a letter A through Z. The number of blanks between
parameters or prior to a verb on the line is not significant.
• Script commands and labels are NOT case sensitive. The contents of
a < string > parameter (described below) IS case sensitive.

14
The following notation is used in the sections which follow where we define the
various script commands:

< string >

Indicates a string which is delimited by either single or double quotation marks.
This type of string also honors the following translation notation:
• If the string is delimited by double quotes, then the single quote is
simply a literal character. A double quote may be indicated by two
double quotes in succession.
• If the string is delimited by single quotes, then the double quote is
simply a literal character. A single quote may be indicated by two single
quotes in succession.
• A through ~ Z indicates the corresponding control character (e.g.,
M is carriage return, J is line feed, ~ A is Ctrl-A, etc.).
• ~ ~ indicates a single carat character.
< label >
Indicates a 1 to 20 character long label. No embedded blanks are allowed, and
the first character of a label must be a letter A to Z. The rest of the label name
may consist of any printable characters. Label names are not case sensitive.

<seconds>
Indicates a decimal number of seconds in the range of 0 (zero) to 65,535.

<bps>
Indicates a bps (baud) rate. Bps rates must be one of the following: 110,150,
300, 600, 1200, 2400, 4800, 9600, 19200 or 38400 specified exactly, with no
embedded commas or spaces.

<line>
Indicates a TBBS line number, in the range of 0 (zero) to 64.

<pattern_var>
Indicates a single digit, 1 through 8, to designate which WAIT string matching
variable slot is being referenced.

<when_var>
Indicates a single digit, 1 through 8, to designate which WHEN string matching
variable slot is being referenced.

15
Script Commands
This section lists the various commands available to you in the Interchange
script language.

Commands marked with an asterisk (*) will abort the execution of the script
unless a slave fine has a connection established. In other words, Interchange
must be presently connected to a remote system or script execution aborts.

Commands marked with a plus sign ( + ) may be executed at any point in the
script unless otherwise noted with the particular command.

+ ABORT [<start_time> <stop_time>]

Example: ABORT 08:00 17:00

This command causes the script to abort execution immediately. If the optional
< start time > and < stop time > parameters are used, execution aborts only
if the day of day falls between the designated times. The time parameters are
provided in 24-hour (military) format, expressed as

+ ACCEPT [< string >] TOS<n>|N<n> [<length>]

Example: ACCEPT "Enter your name: " TO S3 3 0

This command allows you to obtain input from the user running the script. The
optional < string > parameter is a prompt which is displayed prior to waiting
for input. S<n> designates a string variable, from SI through S9, which will
be used to store the data entered by the user. Numeric input can be obtained
by designating a numeric variable, N1 through N9. The optional < length >
parameter is a number of characters allowed for a string variable; the default is
40. (The < length > parameter is ignored for numeric input.)

* BAUD [<bps>]

Example: BAUD 9 6 00

This command allows you to set the port speed to the specified bps rate. If the
< bps > parameter is omitted, then Interchange will set the port speed to the
line’s default speed as set in CEDIT.

16
+ CALC <nv1> = <nv2|nlit2> <op> <nv3|nlit3>

Examples: CALC N5 = N1 + N2
CALC N5 = N5+100
CALC N6 = 100*N7

This command allows you to perform simple math with numeric values.

The < nvl > parameter is a numeric variable which will receive the result, from
N1 to N9. The < nv21 nlit2 > parameter is either a numeric variable N1 through
N9, or a numeric literal value. The < op > parameter is a math operation; +
for addition, - for subtraction, / for division or * for multiplication. Finally, the
< nv31 nlit3 > parameter is the second argument of the math operation itself.

* CARRIER [< label>]

Example: CARRIER GOTCARR

This command allows you to detect and branch script execution based on the
presence of or lack of carrier. “Carrier” is the status of the CD (carrier detect)
signal on the slave’s serial port. The assumption is the carrier is present when
a call is connected, and carrier is not present when a call is not connected.

When this command is used, execution of the script will continue if carrier is
present or will abort execution if it is not. If the optional < label > parameter
is used, script execution will jump to the designated label if carrier is present,
or “fall through” if it is not.

+ DELAY < seconds> [< label>]

Example: DELAY 30 GONOW

This command causes script execution to delay itself for the specified number
of seconds. After the specified time elapses, execution will continue. If the
optional < label > parameter is provided, execution of the script jumps to the
designated label after the delay is completed.

* DIAL < phone >

Example: DIAL 1-303-699-8222 (dialnormally)

Example: DIAL DP1-303-699-8222 (pulse dial)

This command causes Interchange to dial the modem connected to the cur­
rently selected slave line. The phone number which Interchange dials can be
17
designated using a /Pn: < phone > switch on the Opt Data on the menu entry
which invoked Interchange, or can be specified explicitly by using the
< phone > parameter. If the number is passed intothe script via a parameter,
then the %Pn% insertion parameter is used for the < phone > option.

Examples:

DIAL %P3%

This command dials the phone number passed into the script via the
/P3:< string > parameter.

DIAL 1-303-699-8222

This command dials the eSoft support BBS phone number.

If the first character of the phone number is numeric, then “ATDT” is added to
the beginning of the number to cause the modem to dial. If the first character
of the phone number is not numeric, then Interchange assumes that the prefix
is part of the string, and only adds “AT” to the beginning.

+ ECHO ON | OFF

Example: ECHO ON

This command controls whether incoming serial data from the remote system
is echoed to the screen of the master line during the WAIT and WAITFOR
commands. The default is ECHO ON when the script is invoked. If you set
ECHO OFF, then the data coming from the remote connection will not appear
on the master line’s screen, allowing automated logons and the like to be
shielded from the user’s view.

+ END

This command causes a normal script termination. It is functionally identical

to simply “falling out the bottom” of the script itself.

+ ERASE <filespec> | < wildcard >

This command will erase either the specified file, or all files which match the
wildcard specification. A fully qualified specification is required, including
drive and path. Note: No error is generated if no file matches the specification.

18
* FORMAT 8N117E1

This command allows setting 7/E/l data format within a script. The default is
8/N/l, and only needs to be used to cancel out a previous 7/E/l.

+ GOTO < label >

Example: goto retry

This command causes script execution to jump to the point in the script
identified by the designated label. If the label does not exist, script execution is
aborted.

+ GRAB <line> [< label >]

Example: grab 1,5-10,17 failed

This command instructs Interchange to “grab” an open line for use as a slave.
The < line > parameter is either a single TBBS line number or a range of lines.
Line ranges are individual line numbers separated by commas, or a contiguous
range of lines indicated by a dash, or a combination of both. (See the example
above.) InterChange searches the list of designated line(s) for an available line.
The list is tried in the order specified until all lines have been tried.

The optional < label > parameter designates a label for script execution to jump
to if the GRAB command fails to connect to a line. If the < label > parameter
is not used, the script execution aborts immediately upon failure of the GRAB
command.

NOTE: If a line is currently “grabbed,” then a GRAB command will automat­

ically issue a RELEASE command to disconnect the existing line before at­
tempting to connect to a new one.

* HANGUP

Example: HANGUP

This command causes InterChange to lower the DTR line on the connected
slave. On modem based slave connections, this will terminate the call which is
connected to the slave, i.e., hangup the phone.

NOTE: This command does NOT release the slave line, it only disconnects any
call from that line. The RELEASE command is used to totally disconnect from
the slave line and return it to TBBS for other use.
19
* IF [NOT] < pattern_var > [GOTO] < label >
IF [NO[T]] < logical > [GOTO] < label >
IF [NOT] <var1> <op> <var2|lit2> [GOTO] <label>

Examples:
IF NO CARRIER DO_DIAL
IF NO PORT GOTO GRAB_LINE
IF LINE 3 DO_LINE3
IF RELIABLE WE_ARE_REL
IF BPS 2400 D0_2400
IF FAILED GOTO XFER_BAD
IF NOT FAILED XFER GOOD
IF 5 PATTERN 5
IF NOT 1 PAT_NOT_1
IF N1 < N2 PART3
IF S7 = "AUSTRIA" GOTO GOT IT

This command allows script execution to jump to the point in the script desig­
nated by < label > if certain conditions are met. If the condition is not met, then
execution continues with the following script line. The optional NOT condition
reverses the action of the IF command, branching only when the specified
condition is NOT met, and continuing forward if it is met.

The first mode of the IF command uses a < pattern_var > parameter which is
the number of a pattern defined with the PATTERN command. You can test
whether a particular pattern was (or was not) matched, and branch conditionally
on its status.

The second mode of the IF command uses a < logical > parameter, which is
one of the following keywords:

PORT Branches if a serial port is connected.

RELIABLE Branches if port has a “reHable” connection.
CARRIER Branches if port has CD signal active.
LINE xx Branches if port is on TBBS line number xx.
BPS xxxx Branches if bps (baud) rate matches xxxx. >
FAILED Branches if the last file transfer (SEND or RECEIVE)
was aborted.
ANSI Branches if user has ANSI support configured.
EXIST <file> Branches if a file, whose name is designated by the < file >
parameter, can be located on disk. The < file > parameter
if a full file specification, drive, path and filename. Wild­
cards can be designated, but only the presence of a single
occurrence of a match is verified.

20
The third mode allows comparisons of numeric or string variables. The
< varl > parameter designates the first variable to compare, N1 through N9 or
SI through S9. The < op > parameter is the type of comparison (operator).
The < var2| nlit2 > is the second variable or a literal, numeric or string, which
is to be compared with. If the condition is met, then script execution transfers
to the specified label; otherwise it continues with the next script command in
sequence. The keyword NOT reverses this action. You cannot compare strings
to numbers directly (see note below). The following operands are valid:

Equal > Greater than

< Less than # Not equal
<> Not equal >< Not equal
>= Less than or equal => Less than or equal
< = Greater than or equal =< Greater than or equal

NOTE: A numeric variable may be compared to a string variable by using

insertion parameters as follows:

IF SI = "%N2%" GOTO MATCH

+ LOG OPEN | APPEND <filespec>

LOG CLOSE
LOG SCRIPT ON | OFF
LOG SESSION ON | OFF
LOG < string >

This command allows you to create and control a log file for s script. The OPEN
or APPEND options initiate access to a LOG file, with OPEN creating an empty
file, while append will add to a file if it exists or creates it if it doesn’t. If any log
file is currently open, it is closed by the OPEN or APPEND command.

The LOG CLOSE command closes any open log. Logs are also closed by
another LOG OPEN or APPEND command, and at the end of the script’s
execution.

LOG SCRIPT turns the logging of script commands on or off.

LOG SESSION turns on or off the logging of the data received by the master in
a SESSION command. Note: Interchange has no idea what the purpose of any
type of data is, and thus all received data is logged. This means that if a file
download, etc. is done, the binary bytes are all written to the log file!

LOG < string > writes the specified string (containd in either single or double
quotes) to the currently open log file.
21
+ LOOP N < n > < label >

Example: LOOP N2 RETRY

This command allows you to setup simple counter loops in a script. The < n>
parameter is one of the numeric variables 1 through 9. The LOOP command
will subtract 1 from the specified numeric variable. If the variable is greater than
zero after being decremented, then the script will GOTO the specified
< label >. The following example shows this concept:

SET N1 = 5
:RETRY
DIAL 555-1212
IF CARRIER GOOD_CALL
LOOP N1 RETRY
MESSAGE "Couldn't connect in 5 tries."
END
:GOOD CALL

+ MESSAGE < string >

Example: MESSAGE "Connecting to remote, one moment..."

This command displays a message on the master’s screen. A carriage return

and linefeed are automatically added to the end of the string. This command is
ignored if the script is executed as a ghost script.

+ PATTERN < pattern_var > [< string >]

PATTERN CLEAR

Example: PATTERN 2 "word:"

This command allows you to store or clear a search pattern variable. When the
optional < string > parameter is used, the designated string is stored to the
pattern variable designated by the < pattemvar > pattern slot for later use by
a WAIT command. The maximum length of the < string > is 20 characters.

If the < string > parameter is omitted, the < pattem var > is cleared. All
existing pattern variables can be cleared by using PATTERN CLEAR.

22
+ PAUSE [< string >]

Example: PAUSE "Press any key to continue."

This command displays the contents of the optional < string > parameter to the
master’s screen, the wait for a key press. If the < string > parameter is absent,
then no display is made, but the script waits for the operator to press a key. This
command is ignored if the script is executed as a ghost script.

* RAWXM1T < string >

Example: RAWXMIT "P5"

This command sends < string > to the remote without any translation. See also
“XMIT” below.

+ RECEIVE < protocol > [< file/path > ]

Example:
RECEIVE ZMODEM C:\ICHG\FILES
RECEIVE XMODEM C:\ICHG\FILES\FOOBAR.TXT

This command allows Interchange to receive files via protocol file transfer from
the remote system (i.e., download from the remote). This script command is
only legal when Interchange has been invoked as a ghost on a line which has a
port, and no slave line has been connected.

The < protocol > parameter specifies the file transfer protocol to be used. The
following keywords are allowed: XMODEM, 1KXMODEM, YMODEM,
YMODEMG, SEALINK, KERMIT, SUPERKERMIT and ZMODEM.

The < file/path > parameter is either a path alone, or a full path and filename
depending on the protocol selected. For single file protocols (XMODEM,
1KXMODEM and ASCII) the full DOS filename, including drive and path,
should be given. For multi-file protocols, the DOS drive and path where the
received files should be placed is specified.

NOTE: If no drive and/or path are designated, the default download path set
by the sysop user when using Interchange from the console is used. You are
strongly encouraged not to depend on this default.

23
* RELEASE

This command causes Interchange to release the currently “grabbed” line, i.e.,
the slave. If there is no line currently connected the script will abort.

+ RETURN Rn [= < string >]

Example: RETURN R3="Returned string"

For TBBS 2.3, this command will return the specified string (or an empty string
if no string is specified) to the indicated TBBS "Return parameter" R1 through
R9. This command allows a script to return information for use within TBBS.

* SCAN Sn [<time>] [[GOTO] <label>]

Example: scan si 3 0 goto scan_fail

This command causes Interchange to take received characters, beginning with

the next received non-blank character, and build a text parameter of the data
up to the next blank, end-of-line, comma, or semi-colon. This parameter is then
placed into the specified string variable SI to S9. If < time> is specified, then
enough data must be received to complete the SCAN within the specified
number of seconds. If < time > is absent, 40 seconds is the tims limit by default.
If < label > is present, the script will transfer to the specified lable if the SCAN
does not complete in the allotted time. If < label > is absent, the script will
abort if a SCAN times out.

+ SEND < protocol > <filespec>

Example: SEND ZMODEM D:\DBOUT\KANGA.ARJ

This command allows Interchange to transmit files via protocol file transfer
from the remote system (i.e., upload to the remote). This script command is
only legal when Interchange has been invoked as a ghost on a line which has a
port, and no slave line has been connected. The < protocol > parameter
specifies the file transfer protocol to be used. The following keywords are
allowed: ASCII, RASCH, XMODEM, 1KXMODEM, YMODEM,
YMODEMG, SEALINK, KERMIT, SUPERKERMIT and ZMODEM. The
< filespec > is the full drive, path and filename of the file to upload. Wildcards
are legal if a batch protocol is selected.

Note: RASCH (raw ASCII) sends both LF and CR, while ASCII sends only the
CR for each line.

24
+ SETSn|Nn = < value >

Example: SET S2 = "Your name is %NAME%"

SET N7 = 1024
SET N1 = -1,525,231
SET S3

This command allows you to set a variable. There are nine (9) string variables,
SI through S9, and nine (9) separate numeric variables, N1 through N9. When
a script begins, all string variables are set to null (no value), and all numeric
variables are set to zero (0).

String variables can contain up to 80 characters each. Numeric variables can

hold a 32-bit, signed number. Variables are output through the use of insertion
parameters; %S1% through %S9% for string variables, and %N1% through
%N9% for numeric variables.

Strings are set by referencing a string within quotation marks. Numbers are set
by designated the numeric value, commas permitted, and with a leading hyphen
(-) for negative values.

* SESSION [< string >]

Example: SESSION "Host Disconnectin'*J"

This command instructs Interchange to enter a captive terminal mode session.

In this mode, the user interacts directly with the remote system, and the
execution of the script is temporarily suspended. The script execution will
continue with the next line of the script when either the user exits terminal mode,
or when CD changes from ON to OFF.

If the optional < string > is specified, it indicates a string that if received from
the remote end will terminate a session. The maximum length of the < string >
parameter is 30 characters. NOTE: Detection of < string > during a SESSION
command behaves the same as loss of carrier. That is, if /C is not specified then
only the SESSION is terminated and the script continues with the next command
line. If /C is specified, then the script ends and InterChange exits completely.

NOTE: For Interchange to detect the specified string, it must be matched

exactly (i.e., upper and lower case do count) and it must be followed by 1 second
with no data. You must include any trailing carriage returns and/or line feeds
explicitly, using ~ M for carriage return and ~ J for linefeed.

25
 + TIMER [< seconds >]

Example: TIMER 6 0

This command sets a master script countdown timer to the value provided with
the < seconds > parameter. If this timer expires the script will abort. If the
< seconds > parameter is missing, any previously active master timer is reset
(i.e., turned off).

* WAIT [< seconds >] [< label >]

Example: WAIT 6 0 WAIT EXP

This command instructs InterChange to wait for a multiple pattern match.

Incoming characters are examined for a match on all active pattern strings
(configured with the PATTERN script command), and execution will resume
with the next line in the script file if a pattern match occurs within the specified
number of seconds. The IF command may be used to determine which pattern
string was matched if more than one PATTERN is active.

The < seconds > parameter indicates how long WAIT will search for a pattern
match without finding one. If < seconds > is not specified, then 40 seconds is
the default WAIT search time limit.

The < label > parameter indicates where execution transfers if there is no
PATTERN string match within the specified time limit. If < label > is not
present, then the script aborts if no PATTERN string match occurs within the
search time limit.

* WAITFOR < string > [< seconds >] [< label >]

Example: WAITFOR sword: 9 0 PW_FAIL

This command provides a simplified way to wait for a single PATTERN string.
The WAITFOR command is 100% equivalent to the following:

PATTERN CLEAR
PATTERN 1 <string>
WAIT [<seconds>] [<label>]

WAITFOR will pyamine the input data stream for the specified number of
seconds (or 40 seconds if the < seconds > parameter is omitted) looking for a
match to < string >. If a match is found, execution will continue with the
following line of the script. If the time expires without a match, then execution

26
will transfer to the < label > or the script will abort if no < label > parameter
was specified.

NOTE: This match will show as true on an IF 1 < label > test, and the
< string > will remain active as PATTERN 1 < string >. PATTERN strings 2
through 8 are reset to inactive by a WAITFOR command.

*WHEN <when_var> [< string > [XMIT] <resp_string>]

WHEN CLEAR

Examples:
WHEN 1 "-More-" XMIT ""M"
Send carriage return if a “more” prompt occurs during
a WAIT command.
WHEN 2 "Read Now(Y/N)?" XMIT "N"
Send “N” if a “read now” prompt occurs during a WAIT
command.

This command defines an automatic response for up to 8 patterns. If the

< string > pattern occurs during a WAIT for WAITFOR command, the
< resp_string > string is automatically sent.

The < whenvar > parameter specifies which of the 8 WHEN pattern variables
is being referenced. WHEN pattern variables are separate from the normal
PATTERN variables used for WAIT command searches. (PATTERN vari­
ables are defined by the PATTERN or WAITFOR commands.)

If the < string > and < resp_string > parameters are absent, then the specified
WHEN pattern is reset (i.e., made inactive). A WHEN CLEAR command
resets all WHEN pattern variables to inactive status.

The keyword XMIT is optional, and is provided for readability and clarity in the
design of your script.

The action of a WHEN command is transparent to the WAIT process. If the

same < string > is active as both a PATTERN and a WHEN, then the PAT­
TERN has priority, i.e., the WAIT will end if that PATTERN is encountered in
the data stream, and the WHEN response will not occur. If the PATTERN is
later reset, then the WHEN will again become active.

Maximum length of both < string > and <resp_string> is 20 characters (each).

27
* XMIT < string >

Example: XMIT "Phil;Becker;;Mypass*M"

This command allows you to transmit a stream of characters designated by

< string > to the remote. The XMIT command “translates” the following
characters:

Character Translation
‘ (accent) l/20th second delay
~ (tilde) 1 second delay
(carat) Character that follows is a control character
~ Send a single carat

28
Script Debugging
For the purposes of debugging script execution problems, InterChange provides
three tools.

The first is intended for debugging scripts used in ghost mode. From the TBBS
local console, simply monitor the line which is running Interchange in ghost
mode. You will see each non-comment line of script code as it’s begin executed,
prefixed by the line number of the code from the script itself. The line numbers
are editor line numbers, so blank lines are counted. Note that if a file transfer
is taking place you’ll see the upload or download status in lieu of the script code.

The second tool is the execution of the script from local console terminal mode.
You’ll be able to visually see the effects of the script as it runs from this mode.
If the script aborts, Interchange displays a dialog box which indicates the line
number of the code where the abort occurred. This way, you’ll know precisely
where your script logic needs attention.

The final tool is the LOG command. TO see the script in action, so you can fully
debug it, use the following commands:

LOG OPEN < filespec >

LOG SCRIPT ON

These two commands will cause the script execution to be logged in the specified
file. In that log you will see the line nubmer on which each command ran (so
you can see the script move from the master to the slave and back as needed to
execute) as well as the script line nubmer and the script line image of each script
line executed. In addition, if a script aborts, the reason is given such as syntax
error, timer expired, etc., along with the line number that caused the script to
abort.

29
Insertion Parameters
InterChange supports all standard TBBS insertion parameters, documented in
Chapter 2 of the TBBS reference manual.

NOTE: Parameters which report userlog information always return the values
from the master line’s userlog record:

InterChange adds the following insertion parameters which are allowed in

scripts:

%SLINE% Reports current script line number

%Sn% Reports value of string variable “n” (1 through 9)
%Nn% Reports value of number variable “n” (1 through 9)

30
Using Door Programs with Interchange
A door kit is supplied on your Interchange release disk in the subdirectory
DOORS. This kit makes it possible for you to use slave computers in conjunc­
tion with Interchange to execute the many “door” programs which have been
written for one-copy-per-node BBS software. In order to execute door pro­
grams, you will need one or more “slave” computers hooked to lines on your
TBBS (using null modem adapters). The Interchange door kit contains the files
and TDOOR host program which go on your slave machine(s) as well as two
sample InterChange scripts to use on the TBBS machine to invoke the doors
from TBBS.

Setting Up Door Slave Machines

Each of your door slave computers must be set up using the TDOOR host
program as follows:

1. Create a directory on the slave machine to hold TDOOR, the

RUNDOOR.BAT file and one or more *.TDT drop file templates along with
a .BAT file for each door you install. For example this directory might be named
C:\DOOR

2. Place the following files in this directory on the slave machine(s):

TDOOR.COM
RUNDOOR.BAT
DOOR.TDT
DORINFO1.TDT

3. Install one or more door programs on the slave machine(s) per the door
program’s installation instructions. Normally each door will go in its own
subdirectory. In the TDOOR directory (the directory created in step 1 above)
you must add a batch file for each door you install. The name of this batch file
is the name TBBS will know the door by. For example if you are installing a
door named POKER, then this file would be named POKER.BAT. This batch
file should contain the following commands:

CD\<doorpath>
<doorinvoke>
CD\<tdoorpath>
RUNDOOR %1 %2

< doorpath > is the subdirectory where the door was installed.
31
< doorinvoke > is the command to run the door program

< tdoorpath > is the directory you created in step 1.

Example:

Assume the following: TDOOR.COM is in directory C:\DOOR and the door

program is named POKER and is installed in the directory
C.\GAME\POKER. In this case the POKER.BAT door batch file (which must
be placed in the C:\DOOR directory) would contain:

CD\GAME\POKER
POKER
CD\DOOR
RUNDOOR %1 %2

4. Finally, you invoke the door handler on each slave machine (from the
autoexec.bat file) with the commands:

CD\DOOR
RUNDOOR <com> <speed>

< com > is either COMI, COM2, COM3, or COM4. Or it may designate a non­
standard port/IRQ combination by being of the form C<hex>/<num>
Where < hex > is a three or four digit hex com port base address and < num >
is the IRQ number 2-7.

< speed > is the com port speed in bits per second and is one of the following:
300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, or 115200. Note: Typing
TDOOR with no params will give the proper usage.

Example: RUNDOOR COM1 19200

NOTE: The temptation is to connect door computers at 38,400bps to achieve

the best performance. For this to work your slave machine must have 16550
UARTS and also the door program’s communication routines must support
16550 UARTS. Not all door programs will do this. Remember, a door program
does it’s own communications, and you are at the mercy of the communications
code in the door program itself. You may have to use a lower line speed with
some doors to avoid data loss. Also be certain that you have set RTS/CTS = Y
in CEDIT for all of the TBBS lines you use to connect to door slave machines!

32
Calling Doors from Interchange
Once the slave computer(s) are set up as above, then you need to add an
Interchange menu item to run a script to invoke the door. Two example
Interchange scripts are included in the door kit. RUNDOOR.SCR runs a
single door which is specified in the Opt Data call using the /P2:"door" param­
eter. The other script DOORMENU.SCR creates a menu of door programs
which the caller may select from and runs the chosen door program.

To use RUNDOOR.SCR to run the poker program add a menu item as follows:

TYPE=210
Opt Data=RUNDOOR.SCR /P2:"POKER" /Pl:"%TIMELEFT%" /Q /S
/C

Likewise the DOORMENU.SCR script may be invoked as follows:

TYPE=210
Opt Data=DOORMENU.SCR /Pl:"%TIMELEFT%" /Q /S /C

You should then edit DOORMENU.SCR to change the menu to reflect the
door programs you are actually using. Note: If you omit the
/P1:"%TIMELEFT%" parameter, the user will be given maximum time in the
door.

Using TIPX to Connect to Doors

You can use TIPX to connect to doors, by installing the TIPXI14 driver on the
slave machine in FOSSIL mode. Then set up TDOOR and the door programs
themselves to use a FOSSIL driver. On the TIPXI14 driver, use the /S: < name >
command line option to give the door slave a name which you then put in the
INIT string entry for the outbound line(s) in TBBS which you will grab with
Interchange across the Ethernet IPX connection to run the slave door.

Multiple machines may be set up with TIPXI14 servers which have the same
name, in which case they will form a “hunt group.” When InterChange grabs
outward to that TIPX server name, the next non-busy machine with the same
name will be connected.

33
Running Direct Screen Write DOS Programs as Doors

As supplied, the TDOOR door kit can only run remotely programs which are
specifically written to be online doors. However, you may purchase a special
interface program called DOORWAY which will allow you to run nearly any
DOS application as a remote door using Interchange. This program is available
from:

TriMark Engineering
406 Monitor Lane
Knoxville, TN 37922
(615) 966-3667

The documentation that comes with DOORWAY will explain how to configure
it for each application, but essentially you run DOORWAY as the DOOR
program from the TDOOR batch file, and DOORWAY in turn runs the
program you choose. For example a TDOOR batch file to run Louts 1-2-3 using
DOORWAY might be named 123.BAT and look like:

CD\DOORWAY
COPY C:\DOOR\DOOR.SYS
DOORWAY SYS /B:M /NCD /O:T /V:D /CD /P: \ 123\ 123 .EXE
CD\DOOR
RUNDOOR %1 %2

You would then call TDOOR to run the “123” door and Lotus would become
available remotely. With the addition of the DOORWAY program, you can run
nearly any DOS program at all as a remote door using InterChange.

Using DESQview on “Door” Slave Machines

TDOOR is fully DESQview aware, and you may run multiple door tasks on a
single slave machine. TDOOR will automatically detect that it is running in a
DESQview setting. Door systems which use multi-taskers are inherently less
stable than those which use one computer per slave node, and thus reliability
may be compromised by this technique.

34
How Drop File Templates Work

When a door call is invoked, TDOOR will search its directory for door template
files (.TDT files). For each template file it finds, TDOOR will generate a drop
file based on the information that was sent across from Interchange. The format
of a drop file template is as follows:

The first active line in the template must be of the form:

FILE: name.ext

This line defines the name.ext of the drop file which TDOOR should create from
this template. Example:

FILE: DOOR.SYS

means this template will create a drop file named DOOR.SYS. Blank lines prior
to the FILE: line are ignored. At any point in a template where a double
semi-colon is encountered, the line is assumed to end. Trailing blanks are
deleted from all lines.

Each line following the FILE: line represents one line which should be gener­
ated in the drop file. All characters are output as specified in the drop file except
for parameter specifications. Parameter specifications are of the form %0
through %9 and %A through %Z. Parameters %Y and %Z are special and
always represent the com port and the bps rate that TDOOR was invoked with.
%Y = com port and %Z = speed.

The remaining parameters are sent on the door request command from the
Interchange script. This command line has the form:

TBBS: DOOR parml parm2 ....<CR>

DOOR is the name of the door batch file TDOOR should run while parml,
parm2, etc. are information which you want to pass to build drop files. A
parameter may be enclosed in single or double quotes if it will include blanks.
If a parameter is not enclosed in quotes, it ends with the first blank. In the drop
file template “parml” is referenced as %1, “parm2” as %2 etc. Parameter %0
will give the DOOR name.

There are two “parameter modifiers” as follows: If a param callout is followed

with an asterisk (*) the the param is assumed to be a number in the range
0-65536. This number will be multiplied by 60 and inserted as the parameter

35
expansion. This allows minutes to be sent as the param to be inserted in a drop
file as seconds.

Example: %2*

This will insert parameter 2*60 into the drop file. If a param callout is followed
by an exclamation mark (!), then the characters in the parameter up to the first
blank (or the end of the parameter) are removed before the parameter is
inserted. This allows a last name to be extracted from a full name parameter
for example. Multiple (!) characters may be used to strip more than one
argument from the front of a parameter.

Example: %3!

Will delete characters up to the first blank and all blanks up to the next non-blank
character. If parameter 3 was the string “Parti Part2 Part3” then the string that
%3! would produce would be “Part2 Part3.” By extension the parameter call
%3!! would produce the string “Part3.”

36
External Events on Slave Machines
If you require periodic maintenance on your slave door computers, you may use
TDOOR to schedule external events. To create one or more external events for
TDOOR, you must create an ASCII file named TDOOR.EVT. This file contains
a list of the events you wish TDOOR to execute in the following format:

EVENT <lvl> <time> [<days>]

< Ivl > is the errorlevel of the event. This is a number from 2 to 255 (level 1 is
the execution exit for a door call).

< time > is the time of day in the format HH:MM that the event should occur.

< days > This optional parameter is a list of the days of the week that the event
should take place. The list is composed of the following three letter abbrevia­
tions separated by commas: Mon, Tue, Wed, Thu, Fri, Sat, Sun. Also the word
ALL may be used. The default if this parameter is not present is ALL.

Examples:

Event 5 23:00
Event 2102:00 Mon,Wed

You may place comment lines in the TDOOR.EVT file by preceding them with
a semi-colon. Blank lines are also allowed. Invalid lines are ignored and treated
as commentary.

NOTE: If an event time occurs when TDOOR is not active but is running a door
for TBBS, then the event will occur the next time TDOOR runs.

37
38
 Soft
eSoft, Incorporated

15200 E. Girard Ave.

Suite 3000

Aurora, CO 80014

(303) 699-6565

8110636