Simtel MSDOS 1992 June/SIMTEL_0692.cdr/msdos/cis/ozbext13.arc/OZBEXT.DOC

Text File | 1989-09-19 | 37KB | 727 lines

                                    OZBEXT
                                 Version 13.2b
    An external protocol module for the CompuServe "B" and "BPlus" protocols

                           Copyright(c)1987,1988,1989
                                  Steve Sneed
                                CIS ID 71520,77


Welcome to OZBEXT!
------------------

OZBEXT is an "external protocol module", a program that allows you to add
the CompuServe "B" and "BPlus" file transfer protocols into other communi-
cations programs.  While not designed primarily as such, the program can
also be used as a (limited) stand-alone communications package for accessing
the CompuServe Information Service (CIS).

Popular file transfer protocols such as XMODEM do not function well under
CompuServe's complex packet-switching network.  The KERMIT protocol, while
operational, is very slow on CIS.  CompuServe developed the B/B+ protocols
to provide optimum performance on the network - it is the recomended method
of file transfer when using CIS.

In addition, OZBEXT supports both the ANSI/VT100 and VT52/Vidtex terminal
emulations used by CIS for attractive screen handling.  A wide range of
options, both on the command line and within the program, allow you to
configure the program to match your needs.  The program automatically
matches itself to your existing communications port configuration, meaning
you do not have to worry about setting things like baud rate and parity
when calling the program.

OZBEXT works with all major commercial and shareware/freeware communications
programs, and can be used with any comm program that can shell out to DOS
without dropping the connection.  On those programs that provide the capa-
bility, OZBEXT works best when set up as an external protocol callable from
within the program (examples are ProComm Plus, QModem, Boyan and GT-PowerComm.)

If you want or need the ability to view CompuServe's RLE and GIF graphics,
such as the radar weather maps, CB pictures, stock trends analysis, and the
over 5000 graphics images in the Graphics Trilogy forums, you will want to
get OZBEXT's sister program, OZRLE.  OZRLE provides all the capabilities of
this program plus adds the ability to view, offline or online in realtime,
the available graphics files and displays CIS provides.  In addition, OZRLE
automatically captures images viewed online to a file for later offline
viewing, saving you substantial connect-time charges.  OZRLE supports all
major IBM video hardware types, including Hercules monochrome, CGA, EGA,
MCGA, VGA, and many "Super" VGA cards.


Before we start...
------------------

Please read this documentation completely.  I know you want to get using the
program right away, but taking a few minutes now may well save you time and
money (in connect-time charges) later.  The program is very simple to use,
and for most users' configurations is fully automatic, but an ounce of pre-
vention is worth a pound of cure.  Thanks!

It is assumed throughout this document that you have a good basic under-
standing of DOS commands, batch files and batch file commands, what
"environment variables" are and how to set them.  If this is not the case,
please have a good MS-DOS tutorial book handy in case I use unfamiliar
terminology.

Help for this program is available online in the IBMNew forum on CompuServe.
Many program-specific help files written by SysOp Connie Kageyama are
available in LIBrary 2 of that forum.  Do a "DIR *.HLP" at the "!" prompt
in that library for a list of those files, or do a "BRO/KEY:HELP" at the
same prompt.  The sysops themselves are available to answer questions, and
of course I frequent the forums to help users.



The Legalese...
---------------

This program is the copyrighted work of its author, Steve Sneed.  All rights
under US copyright law are reserved.  The author hereby grants to private,
noncommercial users of this program a limited license to use, copy and
distribute the program free of charge, as long as:

a) the program and its accompanying files are not modified in any way other
   than changing the "archive format" used to store and transmit the program;

b) no charge is made for any distribution beyond a nominal disk/duplication
   fee; and

c) the distribution of the program is not done by a business, company or
   private entity whose primary business purpose is the distribution of
   public domain and/or "shareware" software, by any means magnetic or
   electronic, for profit.  Specific exclusion of this clause is hereby
   granted by the author to The First Osborne Group (FOG) and The Public
   (Software) Library.  This clause does not limit distribution by Bulletin
   Board Systems or other information services, and a fee may be charged
   for such access.

If the program is used for commercial purposes, a license from the author
is required along with payment of a $15 license fee per copy.  Multi-copy
and site licenses are available; contact the author at the address listed
at the end of this document for more information.  "Commercial purposes"
as used above is defined as use by a company or government service or
organization in an official capacity, or use by a company or individual
whereby financial profit is made from such use - for example, a stock broker
who uses the program to aquire ticker information for clients.  Specific
exclusion of this clause is hereby granted by the author to CompuServe Inc.,
Borland International, TurboPower Software, and PCMagNet.  No other rights
are in any way relinqushed by the author, and the author reserves sole right
to grant and administer licensing and distribution.

This software is provided "as-is", without warranty of any kind, including but
not limited to any warranty of mercantibility or suitability for a specific
purpose.  At no time will the author be held liable for any loss or damage,
including loss of data or time, due to any operation or use of this program,
even if the author has been informed of such loss or potential for loss.

"GIF", "GIF Format" and "Graphic Interchange Format" are Service Marks of
CompuServe Inc., an H&R Block Company.


Installing OZBEXT
-----------------

OZBEXT generally should be installed in the same location as your comm program.
If you use a hard disk, this means in the same subdirectory.  If you use more
than one comm program with OZBEXT and have different programs in different
subdirectories, be sure to place OZBEXT in a subdirectory that is on your DOS
path.

OZBEXT is delivered to the CompuServe forums in "archived" format, using the
standard ARC format utility ARCA.COM by Vern Buerg and Wayne Chin.  Some
forums (and BBS systems, if that is where you aquired this program) may re-
compile the program files into a different archive format such as the .ZIP
format, or may use a utility like LHARC to create a self-extracting program
archive.  Once you have copied the archive file or self-extractor onto your
disk, you will need to use the appropriate un-arc utility (if not a self-
extractor) to un-arc the program files back to their original runable state.
Utilities for this purpose are available in most forums on CompuServe, and on
nearly every BBS in the world.


Configuring OZBEXT
------------------

Configuration of OZBEXT is very simple.  The program uses a "standard"
internal configuration that will be correct for 90% or better of users.
The program is quite flexible, however; almost any type of special con-
figuration used on CIS is supported by the program, as well as several
options governing the way the program functions or performs.

The following list contains OZBEXT's nominal configuration.  Only if
your particular configuration differs from this list should you worry
about the various settings available.

* Uses the COM1: serial port/modem.
* Uses the chosen port's existing baud rate, parity and data/stopbits settings.
* Uses full-duplex communications.
* Provides an audible alarm at the end of a protocol transfer.
* Returns to its own internal terminal mode at the end of a transfer.
* Uses the DOS current working directory for storage of downloaded files,
  and looks in the same directory for files to upload.
* On exit, leaves the modem CarrierDetect line high and restores the port to
  the same configuration in which it was found.
* Perform no logging of transfer success.


Setting Options
---------------

If one or more of the above settings does not match your configuration, there
are two possible ways to change things.  The first, and recommended, way is
thru setting variables in the DOS environment.  The second is to use command
line parameters when executing the program.  If you are calling OZBEXT from
a program such as QModem that wants to see a batch file rather than a free-
standing program to execute, it is simpler to use the command line parameters
within the batch file (saving the DOS environment space for other programs.)
Parameters set via environment variables can be overridden via command line
options.

Below is a list of OZBEXT's environment variable names and the associated
options:
DSZPORT=?
  or
OZPORT=?         Replace ? with your commport number (1 thru 4)
OZBASE=?         Replace ? with the Base Address of your port hardware
OZIRQ=?          Replace ? with the Int Request # of your port hardware
   (NOTE: the above two variables are used *only* if your comm port resides
    at a non-standard base address and/or int request line (for example,
    PS/2 systems on COM3 or 4.)  If one is used, the other *must* be used
    as well.)
OZPATH=?         Replace ? with the full path to use for up/downloaded files
OZMAC=?          Replace ? with the full path/filename of your macros file
OZOPT=?...       Replace ? with one or more of the option letters in the
                 parameters list below.


When using command line parameters, all parameters must begin with either
a dash (-) or a forward slash (/) character.  Parameters that require qual-
ifying information (such as the port selection parameter) must have the
information immediately after the option letter with no space.  At least
one space must separate each parameter.  Below is the list of available
parameter option letters:

C{portnumber}   Select the comport.  If you use COM2, this would be "/C2".
                The default is COM1.  Ports 1 thru 4 are available.

A{baseaddress}  Specifies the non-standard base address for the chosen
                port.

I{irqnumber}    Specifies the non-standard Int Request line # for the chosen
                port.  If either the A or I parameters are used, both must
                be used.


If you are using the program as a stand-alone comm program rather than from
within another comm program (and, generally, _only_ when you use it as such),
4 other parameters are available to configure the port.  They are:

B{baudrate}     Specifies the baud rate setting at which to open the port.
                Available baud rates are 300, 1200, 2400, 4800, 9600 and
                19200.  The default is to use whatever setting the port
                currently holds.

P{parity}       Specifies the parity setting to use.  Normally either None
                or Even, but Odd, Mark and Space settings are available as
                well.  You only have to provide the first letter of the
                parity type word (so setting None parity would be "/PN".)

W{dataword}     Specifies the data word length; 5, 6, 7 or 8 databits.

S{stopbits}     Specifies the number of stop bits (almost always 1.)


The other available parameters are used to configure the way OZBEXT works.
These are the "options" settable with the OZOPT= environment variable.
They are:

X               Exit OZBEXT immediately on completion of a protocol transfer.
                The default is to return to OZBEXT's internal terminal mode
                so you can download more files or navigate to another area
                of CIS.  This option is normally only used when the program
                is being called from within another comm program's script
                file for automatic execution.

J               Log results of all transfers to OZBEXT.LOG.  The file is
                created if it does not exist.  The default is to not log
                xfers; this just allows those that want logging to have it.

D               Drop carrier on exit.  The default is to leave CarrierDetect
                high.  Using this parameter will mean that OZBEXT will break
                any existing connection on the modem when exiting - not a good
                idea when you are loading the program from within another
                comm package.

N               Turn off the audible alarm normally provided at the end of a
                protocol transfer.  The default is to provide a beeper at
                the end of a proto transfer and wait for a keypress before
                continuing.  When this switch is used, no alarm sounds and
                the program does not wait for the keypress.  (Version 13.1cd
                note: this turns off *all* noise, including the system bell
                when a ^G is received.)

Q               Automatically send an XON character on startup.  This param
                is normally only used with the CIS-specific "auto-navigator"
                programs AUTOSIG and TAPCIS, both of which send an XOFF flow
                control command to CIS when shelling out to DOS.

U               Automatically send a Ctrl-U character on startup.  Using this
                parameter means that, on startup of OZBEXT, the CIS system
                will automatically interrogate OZBEXT for its terminal-type
                and protocol-support capabilities.  This option should be
                used with caution; in a few places that you might call OZBEXT
                the sending of the Ctrl-U may confuse the CIS system or may
                abort the imput prompt that was waiting when you called OZBEXT.



O               Turns off checking for the Carrier Detect signal from the
                modem during use.  Normally OZBEXT checks for this signal
                during a protocol transfer and if the signal is lost (for
                example, when the phone line connection is broken due to
                line noise or other problem) the protocol transfer is
                automatically aborted.  Some CIS users are lucky enoough
                to be connected to the network via direct serial link; these
                links are usually a minimal 3-wire connection without CD
                support.  Users so configured should use this switch; do
                NOT use this switch if you connect to CIS via modem.

Z               Forces use of program's monochrome screen colors set.  Some
                monochrome video hardware tries to "emulate" color; on these
                video systems the normal colors used for the prompt line and
                protocol status window may be unreadable.  If you find this
                to be the case (common on some Leading Edge machines), use
                this option.

L{filespec}     Tells OZBEXT to look for and load a macros file named
                {filespec}.  OZBEXT does _not_ search the DOS path for this
                file, so you must explicitly provide any path information
                if the file is not in the DOS current working directory.

F{path}         Tells OZBEXT to put all downloaded files in the {path}
                drive and/or subdirectory, and to take all uploaded files
                from that same location.  OZBEXT verifies that the specified
                path does exist and if it does not notifies you of the error
                and reverts to the current DOS working directory.  Note that
                you can override this path by including any desired path with
                the filename when answering the "Filename for your computer:"
                prompt from CIS right before beginning the transfer.

G{numberlist}   "Go" keys list for startup.  See below.


Running OZBEXT
--------------

OZBEXT is simple to use.  Depending on what general communications software
you use, it can be made almost automatic.  Due to the wide range of different
communications programs available, no one setup will always be right for
your particular configuration.  However, following these guidelines will make
using the program simple and straightforward.

A)  If your comm program supports it, always install OZBEXT as an external
    protocol module.  Some programs or versions of programs do not support
    defined external protocol modules but do allow the definition of external
    programs (like editors.)  If this is true for your software, use that
    type of setup.  Only use OZBEXT from a "general" DOS shell if your soft-
    ware provides no other support for external programs.  Installing OZBEXT
    as an external protocol module means calling OZBEXT will be done in the
    same manner as all other protocols, giving you a consistant interface.

B)  If your program requires batch files for external protocol modules (ala
    QModem and a few others), do all parameters options on the batch file
    command line.  Here is an example batch file for QModem:

    ECHO OFF
    CLS
    OZBEXT /c2 /fA:\DNLD\TODAY /lC:\QMODEM\VT100.KEY %1 %2 %3 %4 %5 %6 %7
    CLS

    There are several things to notice here.  First, we establish the port to
    use as COM2: (/c2), then the path for downloaded files to be stored under
    (/f...), and finally the macros file to use (/l...), then we provide for
    passing other command line settings as we may need from time to time.
    Note that the files path can be on any drive.  Also note that QModem's
    VT100.KEY file redefining the keyboard to more closely emulate a true
    DEC VT100 terminal will work nicely in OZBEXT.  Finally, you can set the
    standard settings you use most of the time as environment variables, and
    then remove the /c, /f and /l parameters from the command line above but
    leave the batch variable identifiers; this way allows you to easily
    override your envirnment variable settings with command line parameters
    if a special case warrants.

    This type of setup is also recommended if you use the program from a
    "plain" DOS shell or from within AutoSIG or TAPCIS, or if you run the
    program standalone.

C)  If your communications program is like Boyan (where you can call the
    program directly), it is better to use environment variables to set
    any needed options.  This is best done in your AUTOEXEC.BAT file so
    that the variables are always set.  Programs like Boyan make it easy
    to set a single configuration but make it difficult to modify that
    configuration for special cases; make your setup flexible.

D)  In all the above cases, note that unlike most other protocol modules
    OZBEXT does not distingush between upload and download on the command
    line.  This is handled at the start of a protocol transfer by the protocol
    itself.  Therefore, you generally only need one configuration for both
    the upload and download entries in your comm program.  However, a tip here
    is that if you use different subdirectories for storing downloads and
    finding uploads, you can set up separate configurations with different
    paths on the /F option on the command line (either batch file or direct
    command methods), or set an environment variable for the files path for
    downloads and override it with a command line setting in the upload setup.



Using OZBEXT
------------

Most protocol modules, when executed, immediately enter the protocol itself.
The B protocols do not work this way.  CIS sends a special interrogation
sequence to the remote system (you) to make sure the remote can in fact do
B and/or B+ before initiating the protocol itself.  OZBEXT _must_ be loaded
and running to reply to this interrogation properly, or you may well not be
able to do the transfer.  (This is not a deficiency, it is a safety mechanism
for both CIS and you.)  Many places on CIS where you can transfer files, this
interrogation may not be done immediately prior to the protocol initiation;
often it is done when you first request a transfer but before CIS has asked
you for the filename to process and the file type (binary or ASCII.)  Because
of this you should call OZBEXT _before_ you request the transfer.  OZBEXT
comes up in terminal mode so that you can answer any pending prompts, etc.

Usually, when you shell out to OZBEXT from another comm program, there is
a prompt from CIS pending input.  There is no way OZBEXT can know what this
prompt was and therefore redisplay it (or anything else that was on the screen
when you called it) so you must remember what the prompt was and reply to
it after OZBEXT is operational.  This is no problem; just type in what you
would have had you been sitting at the prompt.  CIS never sees OZBEXT load
so it never knows you were not able to see the prompt.  (If you use the
/U or /Q options, CIS will know but won't care.)

Some users have noted that they "forget I'm in OZBEXT rather than my main
program."  OZBEXT provides a status line at the bottom of the screen at all
times to remind you.  I have tried to make sure it does not resemble too
closely the status lines provided by many other comm programs, to make this
recognition easier.   Since OZBEXT only has 1 set of colors for color video
systems and another for mono, you may want to make sure your main comm program
uses a different set of colors on its status line as a further reminder.

Many CIS users (most?) log in at 7 bits/Even parity.  OZBEXT has no problem
with this; it knows how to switch to 8 bits/No parity for the actual transfer
and back at the correct times.  HOWEVER... some serial ports and/or modems
do not handle the "flying switch" properly and will cause grief.  For this
reason I recommend you use 8 bits/No parity at all times on CIS.  To do so
you must change some of your "user profile" parameters that CIS maintains
on you.  For a complete description of what is required, see the file
LOGIN8.HLP in IBMNEW LIBrary 2.

OZBEXT provides both a clock and an online timer on its status line.  The
online timer displays and "ticks" only when a connection is established.
If you use the program standalone this timer will be accurate, but if you
call OZBEXT from another program it will only display the amount of time you
have been in OZBEXT.



Commands Within OZBEXT
----------------------

OZBEXT provides several commands while operational.  These all are used to
modify the same functions you set with command line options or environment
variables.  Generally, the letter used for a particular option setting will
be the key used with the [Alt] key to modify that option while in OZBEXT.
To see a menu of available Alt-Key commands in the program, press the [Home]
key.


Macro "QuickKeys"
-----------------

OZBEXT allows you to define up to 40 "QuickKeys" to simplify its use.  These
keys are the function keys, and the function keys used in conjunction with
[Ctrl], [Shift] and [Alt].   Each may have a string of up to 127 characters
assigned to it (a "macro".)  Macros 1 thru 10 are assigned to function keys
[F1] to [F10], macros 11 thru 20 are assigned to [Shift][F1] thru [Shift][F10],
macros 21 thru 30 go with [Ctrl][F1] thru [Ctrl][F10], and 31 thru 40 are
assigned to [Alt][F1] thru [Alt][F10].  Pressing a QuickKey causes the program
to send the macro assigned to that key out the serial port.

The definition for macro keys are stored in a flat ASCII text file.  Do not
use a word processor that inserts special control codes or other non-standard
characters to create this file, or be sure to save the file in ASCII or
"non-Document" mode.  The file is read by the program sequentially a line
at a time, each line being assigned to the next macro (line 1 goes to macro
1, line 2 to macro 2, and so forth.)  The file does not have to be 40 lines
long.  To skip a macro, insert a blank line in the file.  The default name
for this file is OZBEXT.FKS, but you can name the file anything you like as
long as you set that name to the OZMAC environment variable or set the /L
command line option to that filename.  Previous versions of OZBEXT gave a
warning if it could not find the OZBEXT.FKS file on startup and no new file
name was provided; many users found this confusing so the warning has been
removed unless OZBEXT.FKS (or the filename you specify) is found but corrupt
in some way, or if you provide an overriding filename and _that_ file is not
found.


Macro Subcommands
-----------------

OZBEXT provides further flexibility by allowing several embedded subcommands
within macros.  These subcommands allow you to insert the current port, baud
rate and parity setting, have a macro request input and then place that input
in the macro before sending, wait until a character is received, and to use a
macro to shell to DOS and execute the macro as a DOS command line.  Addition-
ally, subcommands are available to insert a carrage return in a macro and to
delay macro processing 1/2 second.  Finally, standard "carat notation" is
allowed to insert control characters in a macro.  Where found in a macro, the
subcommand is replaced with the data it specifies.



All embedded subcommands (except the CR and delay characters and the control
character notation) begin with the "at" symbol (@).  The following list
defines the available subcommand letters:

CD      Forces the macro to wait for carrier detect if a connection is not
        already established.  There is no timeout, but pressing [ESC] will
        abort the wait and continue the macro.

O       Force a DOS shell, and use the macro as a DOS command line.  This
        only works when the first 2 characters of a macro are "@O", otherwise
        they are ignored.  The macro is processed for insertion of all other
        subcommands before executing.  The macro is not sent to the port.

M       The "M" subcommand takes a second qualifying letter defining the
        specific modem parameter to be inserted in the macro.  these
        qualifiers are:

            C - insert the current port number.
            B - insert the current baud rate.
            P - insert the current parity setting.

        For example, placing "@MC" in the macro when the current port is
        COM1 would cause the subcommand to be replaced with "1".

W       The "W" subcommand takes a second qualifying character or string and
        waits until received.  This gives a very limited but useful "script"
        capability.  Example: "@W!" would wait until the "!" char was received
        (or the <esc> key is pressed) before continuing execution of the
        macro.  When waiting for more than one character (a string) you need
        to enclose the specified string in double-quote marks.  Example: to
        wait for the string "User ID:" you would use `@W"User ID:"' in the
        macro.  You can place up to 10 "Wait" commands in a macro and each
        can wait for a different character or string.

I       The "I" subcommand forces the macro to prompt you for input, and
        then insert that input in place of the subcommand.

An example macro to call the DSZ external ZModem protocol module from within
OZBEXT to upload a file to a BBS would probably contain this:

@O DSZ port @MC speed @MB sz @I

When you press the QuickKey assigned to this macro, you would first be
prompted for input.  Assuming you input "FOO.BAR", and you were using COM1
at 2400 baud, the following command line would be executed by DOS:

DSZ port 1 speed 2400 sz FOO.BAR

---

The pipe character (|) is used as a carrage-return in a macro.  The tilde
character (~) forces a one-half second delay where it is found in the
macro.  These two special characters are provided to simplify using macros
as modem command strings.  As an example, let's say you want the F1 key
to send a command to your "Hayes-compatible" modem to reset and then dial
the number of your CIS node.  Assuming the number of the node I use and the
way I normally set my modem, the following macro would be used:

ATZ|~~~~ATM3V1X4DT922-3308|



This sends the "ATZ" command to the modem with a carrage-return, waits two
seconds (so the "OK" reply from the modem can display), then sends the setup/
dial command string and a carrage-return.  Another example is the macro I
use to log on thru Tymnet:

|~~~~~~~~A@W:CIS02|@W"User ID:"70000,000|@W"Password:"my-password|

Once I get the "CONNECT 2400" from the modem, I press F2 for this macro.  It
sends a carrage-return, waits four seconds for Tymnet to give its "Please enter
your terminal identifier:" prompt and replies with the "A" nessessary, waits
for the "Please log in:" Tymnet prompt, sends the "CIS02" and carrage-return
to tell Tymnet to connect me to CIS, then waits to allow CIS to issue the "User
ID:" prompt and sends a userid and carrage-return, and finally waits for the
"Password:" prompt and sends a password.



"GO" Keys
---------

OZBEXT now allows you to tell it on the command line to execute up to 10 macros
automatically on startup.  This further enhances the ability to automate your
downloading by assigning a series of "waitfor" macros to wait for CIS prompts
and respond with filename, transfer type, etc.  The syntax for this command is:

/G#,#,#...

where "#" is the number of the macro (1 thru 40) as they are entered in the
.FKS file (*not* the FKey number!)  The macros are executed left to right in
the order they are provided.  The macros can contain any legal macro command,
including the "wait for carrier detect" and "wait for rec'd string" commands.
This functionality was added at the request of several users.  I'm working
on an automatic macro editor/generator to further ease this use.




The Protocol Window
-------------------

During a protocol transfer a window appears on screen detailing the transfer
activity.  Most things about the window are pretty self-explanitory, but one
area deserves clarification - the "Port" and "Data" percentages on the "Ef/Tm"
(Efficiency/Time) line.  The percentage displayed in the "Port" column is the
comparison of current protocol "raw" port rate to the current port baud rate
setting of the UART.  In other words, at 2400baud this figure would optimally
be 100% if we were seeing 240 bytes per second comming in the port during a
transfer.  Since CIS uses its packet-switching network and network delays of
some magnitude are inevitable, this figure will almost always be less than
100%.  Normally you can expect greater than 230 cps "raw" rates on downloads,
but uploads often fall below 200.  Connections established thru suplimental
carriers such as Tymnet may well be less.  The percentage under the "Data"
column, on the other hand, is the ratio of total data bytes received to the
protocol's average "raw" port rate.  In other words, the efficiency of the
actual data comming in the port.  This figure normally runs around 92 - 96%
for binary files and 98 - 99% for ASCII text files.  However, bad packet
resends when an error occurs and is corrected cause this figure to drop,
sometimes dramatically.  Providing both figures makes it easier for you to
decide when to abort a transfer.  If the "Port" figure is dramatically low
(usually due to a high network traffic load but can also be due to delays
caused by suplimental carrier networks), you may want to abort the transfer
and wait until network traffic had dropped so good port rates are possible.
If the "Data" figure is low (usually due to a high error-packet count), you
may want to abort and call back on another node.  To avoid confusion, just
remember that the "Port" efficiency percentage gives data on how efficient
the port is operating, while the "Data" percentage gives overall port-to-data
efficiency regardless of actual port rate or port efficiency.  The time display
under the "File" column is the time the transfer has taken so far, while the
time under the "Remaining" column is an estimate of the time it will take the
rest of the transfer to complete.  The "Remaining" time figure will vary based
on the current port rate, because it is recalculated at the end of each packet.
Oh, one other thing: while CIS users won't see it, those using this program
with a BBS running my OZRHOST protocol module on a "fast" modem (V.32, HST,
etc.) with a 9600 link and 19.2K port rate will see some gross port efficiency
percentages, like 30 - 50%.  Please remember that the _port_ is set for 19.2K
but the _port_data_ is "throttled" to 14.4K or less by the modem, and OZBEXT
computes from the port's baudrate setting, so a low port efficiency means
little or nothing under these conditions.  The data rate percentage will
reflect a realistic "net thruput" figure for any baud rate.



The program now returns DOS errorlevel codes when exiting - this allows you
to check the status of the transfer operation in a batch file or when
called from within another program.  The codes returned are:

0 - Normal program termination (and transfer successful, if applicable)
1 - User aborted transfer
2 - User performed EOA abort
3 - Proto handshake (DLE-B) failed
4 - Error handshaking direction
5 - Error handshaking file type
6 - Protocol failed (too many errors)
7 - any other error (outside of proto errors) that can cause the prog to abort




For users of previous versions...
---------------------------------

Version 13.2b has only 2 changes from version 12.xx: it is about 10K smaller
due to the fact that I no longer use the 80x87 emulation capabilities of
the Turbo Pascal 5.5 compiler (the very few floating point calculations in
older versions of the program have been changed to long integers and the
emulation code therefore removed), and a very small mod has been done to allow
"patching" the program for color configuration.  Several users have requested
this capability, so it has been added.  The program does not "patch itself";
you need to get a copy of my OZPATCOL program to patch colors in both this
program and OZRLE (version 8.8b and later.)  The patch program will not work
on earlier versions of either program.

13.2b corrects the path bugs in 13.1b.  Sorry 'bout that! <grin>


Kudos, Credits, Karma Enhancements
----------------------------------

The sysops of the IBMNet forums on CIS: Don Watkins, Connie Kageyama, Chris
Dunford and Vern Buerg.  My primary beta testers, and the greatest group
of folks around.  Ditto for Valerie Zen and Tom Potoki, sysops of the Graphics
Trilogy forums on CIS, who also help test.

Kim, Brian and Rich of TurboPower Software, for writing and maintaining the
best library of Turbo Pascal utility routines in the free world.

Russ Ranshaw ("Wiz10") and others at CIS, for providing exellent documentation
on the B+ protocols, and understandable source code for same.  Ditto to Brion
Jones of CIS for informative literature on interrogation/response sequences
and terminal reply codes.

Most importantly... you, the users.  Your questions, criticisms and sugges-
tions have helped make the program what it is.  If you like it thank yourself,
not me.


Point of Contact
----------------

I can most easily be reached via CompuServe; my ID# is 71520,77.  Please leave
questions in either IBMNEW or IBMCOM rather than EasyPlex; other users or the
sysops may well be able to give you a faster answer.  If you need to contact
me concerning registration, please do so by EasyPlex or US mail:

Steve Sneed
409 San Juanico
Santa Maria, CA.  93455

This program is not shareware in the traditional sense; I do not require
private non-commercial users to register or pay a license fee (see the section
on license requirements at the top of this document.)  If you have a burning
urge to send me money anyway... I won't turn it down. <grin>  Please make
checks payable to Steve Sneed.  Updates are only done thru CIS; I do not
notify users of updates (except for fully-licensed commercial users.)  If
you are registering for full license, please plainly state so in your
corospondence along with how you are using the program.  Site licenses and
multi-license discounts are available; please contact me for specific info.
Finally, please do not call me voice, and I cannot accept any collect calls.
I don't mind helping folks, but 7am and 11pm calls do not help my baby
daughter sleep.  Thanks.

I hope you enjoy the program!

<eof>