ftp.wwiv.com/ftp.wwiv.com.zip/ftp.wwiv.com/pub/BBS/PR_RA110.ZIP/PROTO_RA.TXT

Text File | 1991-11-05 | 15KB | 335 lines

                P r o t o _ R A   1 . 1 0

Tue  11-05-1991  17:10:56

This is a compendium on the use of external protocols with
RemoteAccess.  With this are sample PROTOCOL.RA that must
be modified for use with your system.  One using DSZ.COM is
named PROTOCOL.DSZ and another using GSZ.EXE is named
PROTOCOL.GSZ.  Rename the one which you want to use to
PROTOCOL.RA before modifying it for your system.  All
protocols must be set up first according to their own
documentation.  Any special notes are included below, but
the basic thing to remember is that you MUST set up the
protocol to write a log file, and it must (of course) be the
same name as the log file used in PROTOCOL.RA.

The PROTOCOL.RA samples assume you are running single node,
with all protocols in the system directory.  They require a
complete path if elsewhere, or (of course) if you run
multinode.  With a few changes in commands, all will have
enough space to fit the path in, with the exception of
SZModem.  Since it MUST have the /CFGPATH parameter with
version 1.50, and /DORINFO 1 in version 1.60, there is not
enough room for any path, except for c:\ with 1.60 <grin> .

Note that these are set for locked bps (mine is at 38400),
and must be edited for other systems.  TEST ALL PROTOCOLS;
what works on one system may not work on another, and vice
versa!

I have also included a sample .cfg file for FileDoor 2.03.

1) Protocols that work with BPS locked at 38400:

 A) DSZ, GSZ

These work in all modes, except (in RA 1.01) for single file
protocol modes (Xmodem and derivatives) for uploads.  This
problem is due to RA passing only the path as # on the
command line, and is fixed in RA 1.10.

The only difference between DSZ and GSZ is the name of the
executable (DSZ.COM or DSZ.EXE versus GSZ.EXE) and that for
display speed you may want to add pV1 just before the
protocol command (e.g., pV1 sz).  GSZ.EXE and DSZ.COM
support file sharing; DSZ.EXE does not.  DSZ.EXE and GSZ.EXE
support up to a 16k pB buffer command, while DSZ.COM is
limited to 4k.  My recommendation is to use the default
unless, as Chuck Forsberg says, you are bloody well sure you
need the pB command!

They will also only work for uploads if you have them
registered, as the unregistered versions will not accept a
received file into a pathed directory.  See PCZ and ZSX
below for alternatives if you do not have a registered copy
of DSZ and/or GSZ.

You must set DSZLOG in your environment as well, and use the
log for PROTOCOL.RA.

Some special modes are not practical, but will work.  These
are the modes that DSZ uses only to recieve.  Among these
are ro (Overthruster), rx -g (Xmodem-k-g) and rb -g
(Ymodem-g).  This also includes rc (Xmodem CRC/Xmodem-k
CRC), but rx will also receive CRC.  Now, the thing to do is
use the more generic form to send, and assume the receiver
knows he must use the proper form to get the protocol
desired.  For ro, use sx; for rx -g use sx -k; for rb -g,
use sb -k.  An example for Xmodem Overthruster, with the
proper windowing for packet-switched networks, is included.

Another oddball is Zmodem compressed, as it is set on the
SENDING side with sz -Z.  Use the standard rz to receive.

 B) MPt (formerly Puma)

Works just fine, but you must set the DSZ-type log in
MPTSET.  I suggest using MPT.LOG myself, to separate it
from DSZ.  No real other comments!

 C) TASY

You must set TLOG in your environment, and use version 4.19
of TASY.  This is a error correcting connection protocol
only, and should be so set.  Later versions do not seem to
work right, and earlier ones had no log.  Seems very fast!

 D) SZModem

READ THE DOCS and set this one up only after you have them
mastered!  It will use whatever you have set for DSZLOG in
the environment, and the /CFGPATH must point to where the
szmodem.cfg resides.  1.42 and up are the best to use, as
they work more as they should in regards to the /cfgpath and
DSZ environmental variables.  SZModem as of version 1.50
still uses only uppercase Z to indicate transfers in either
direction, rather than the correct z for send and Z for
receive.

Occasional modems or conditions will result in status
Unknown transfers, which return no transfer.  Perhaps the
author will reverse this and assume success rather than
failure on such transfers in the future, as for the most
part they ARE successful, and users will be able to leech a
file or two as is once in a while <grin>.

SZModem 1.60, just released, fixes the DSZ.LOG problem.  It
also stores all config data in the executable.  The
dorinfo1.def processing, though, has to be specified on the
commandline, though the path is set in the configuration.
For multinode, this may well allow such use, as the default
dir will be the place SZModem will look for the dorinfo1.def
file.  The examples given in the sample PROTOCOL.?SZ files
use this new version; for other version's commandlines, see
the FileDoor.Cfg (though you will have to eliminate the
/FIDOAREA for lack of room).

 E) SKHST

Though SuperK will also work, this is easier to set up and
has new features to make it work a LOT better as a BBS
protocol.  If you do not register, it will die after 30
days.  DO REGISTER it, but if you need more time, you can
reinstall after deleting a hidden file in the root dir of
your hard disk that it creates (name looks like ascii
garbage).

The single modes will not work for ULs in RA 1.01 for the
same reason as some DSZ modes, the # character not passing
the path AND filename to the protocol.  Fixed in RA 1.10.

With version 1.06, SKHST will try on the receiving end to
match the batch mode send of the remote.  This means if they
make a mistake and use the wrong mode, it will still receive
the file.  Since it cannot match the other way, you still
need the sending modes you want to support.  I recommend the
modes I have in PROTOCOL.RA as they support the ProComm
brain-dead WXModem (whoever heard of a window of 1 block?),
and the old SuperK batch modes.

YOU MUST set up SKHST to NOT delete its transfer file!  The
default is to delete it, and since RA tries to delete it as
well, this does not work well!  If you have SHARE loaded,
you will get a violation and a crash.  Also be sure to set
the full path of the log and xfer files in the protocol
setup and in PROTOCOL.RA.  The xfer list file can be
XFER.TXT with the path, or some other; the commandline
overrides the protocol's set xfer list name.  I use
XFER.TXT, myself.

By the way, the Jmodem mode of SKHST does not work for me,
for whatever reason, neither in FileDoor nor in RA's
externals.  If it did, it could replace the "real" Jmodem
that does not write a log and thus cannot be used at
present.

 F) PCZ

The freeware PCZ works well, with some limitations.  The
zmodem mode will accept a DL path, unlike unregistered DSZ.
There is no Ymodem-g or Xmodem-k-g mode, but it does include
an implementation of SEAlink in addition to xmodem,
xmodem-1k, and ymodem.

Do not use the DIRXX setting, at least not with the 4.09.90
version of PCZ.  The commandline does not reliably override
the set command.  Do use the Set PCZLOG variable, and use
normal DOS methods (e.g., set pczlog=c:\ra\pcz.log).  Locked
at 38400, the internal flow control seems to break down with
the lower speeds, so the F (fossil) setting is needed.  You
should then, if the fossil is locked, pass the DCE as *b to
the protocol so the time calculations are correct.  You may
wish to advise your users of this as well, and tell them to
load BNU and lock the port, run PCZ, and unload BNU, if they
run at 38400.

The only other problem is that the logging PCZ does is
ambiguous to RA's scanning method.  If an aborted transfer
takes place with exactly 1 error, RA will find the 1 for the
logged error, assume the xfer went ok, report it as
complete, and then find the day of the week as the filename.
No harm done, but rather confusing to the user.  The author
is being made aware of this, and either it will be fixed or
perhaps RA can scan for a string including spaces (1  sz for
a zmodem send, for example) in a future version to make it
unambiguous.

One other note concerns PCZ's errorlevel generation, not
directly of concern for PROTOCOL.RA use.  The zmodem and
ymodem (not sure about xmodem and xmodem-1k) work correctly,
but the SEAlink seems to always return an errorlevel of 1
(failure).  This has to do with its correctly sending the
EOF, but not the EOT, I believe, or not responding correctly
to the receiving end.  The SEAlink implemention also does
not include SLO (SEAlink Overdrive) and is not very reliable
at 9600 DCE rates.  However, it is MORE reliable than ZSX at
2400 and below, especially with a non-error correcting
connection.  I have used it therefore for SEAlink.  I have
also used it for Super_Z, a variant similar to DSZ's
MobyTurbo, a faster zmodem than usual CRC32 is.

 G) ZSX

ZSX includes xmodem, xmodem-1k, ymodem, ymodem-g, zmodem,
SEAlink, and SLO (SEAlink Overdrive).  It is not crippled in
any way, and uses the fossil for all communications.  It
uses the DSZLOG environmental variable.  All modes use the
lowercase protocol letter to log success (that is, s for
SEAlink and SLO, z for zmodem, g for ymodem-g, etc.).  The
limitations I have found to date are that it will not accept
the new v.32bis rates as the speed parameter (since it uses
the locked fossil, there is really no reason this must be
this way, and perhaps will be changed in the future) and it
sometimes sends some characters to the remote after a
tranfer is complete, so the user may find themselves not
where they thought once in a while ;-)

For whatever reason, it does NOT seem to work well at lower
speeds without error correction in SEAlink mode, at least
not when locked at 38400 bps.  The SLO mode, on the other
hand, works ok, except at 2400/ARQ on uploads.  Thus, I have
used it for SLO, but disabled it in the samples.  It *may*
work just fine on another system, though!

The other modes do not seem to share the SEAlink problems,
although my testing has been somewhat limited.  Have fun!

Registration is a postcard to the author.  If you cannot
register DSZ, this is a viable alternative as well!

 H) Hyperprotocol

An odd log file is created by Hyperprotocol, but it can be
read by RA in most cases.  The actual outcome is in TWO
"words", the first and last, so aborts may not always be
recognized by RA.  The bigger problem is that it can only be
used to upload to a specific directory, as RA replaces #
with the upload directory WITH a trailing backslash, and
this confuses Hyperp, which will lock up the machine at
times.  IF you only use a single upload directory, this will
work fine; otherwise, wait until Hilgraeve fixes it!  The
latest I know about, 1.1f, has this problem.  You must have
an option file like HYP.OPT for it to work, in the same dir
as the hyper.exe:

DISPLAY:OFF
HANDSHAKE:RTS/CTS
LOGFILE:C:\RA\HYP.LOG


2) Random notes on a lot of other protocols:

Protocols that do not write a log will not work.  Perhaps
this can be added to RA at some time, to use errorlevel 0
for success and 1 for failure in lieu of a log file.  Some
good ones are in this group, including Jmodem.  Translink
and HyperDrive would appear also to work if I can find
versions with bugs fixed (the former limits the path an
filename to about 16 characters, the latter I cannot find a
whole copy!).  These all work with 38400 locking as well.

Tmodem, the X, Y, Z, and Zmax cousins of Tmodem, and Zyrion
all are to avoided, in my opinion.  They will work at 38400
locked, and do write log files.  However, (except Zyrion)
they all ask for an odd -b parameter.  This seems to be the
DCE rather than the DTE, which must be set in the
environment with a set COMx= command.  With v.32bis CONNECT
codes, this breaks down.  They seem to demand 9600 as the
"baud" rate, which is neither the DTE of 38400 nor the DCE
of 14400.  Appeals for explanation and help have netted
nothing, and I am a registered Tmodem user.  In addition,
Tmodem has several incompatible versions (under 2.0,
2.0-3.x, 5.0-6.3, 6.4, and now 7.0, NONE of which work with
any others outside their own group), and now that is
extended to the X, Y, Z, and Zmax versions as well.  In
versions under 7.0, the log is written in the default
directory only, which could present problems.  The basic
support does not exist unless registered, and if you
register, the support consists of telling you it works fine
with Isis/Osiris (being as nice as I can be here!).

rC-Modem does not work at 38400, or any locked BPS, as far
as I can tell.  NModem does not either, but I am not too
sure if it works at all.  I have been unable to get it to
work, in any case.

PC-Kermit barely works as 19200, dies at 38400, and does not
write a log.  Megalink works at 19200, not at 38400, and
also does not write a log.  Clink works fine at 38400, but
does not write a log, and will not accept a path to receive
a file, making it useless even if errorlevel support is
added someday.  It does work with FileDoor, though, if you
do not have philosophical objections to running it at all!

Punter does not work locked, not write a log.  Quicktran is
the same, and is terribly slow with archived files anyway.

The old Friel Imodem is not even supported by Qmodem any
more, so I suggest you do the same!  Odds are it does not
work locked at 38400, and I know it does not write a log
file.  It also is slower for error correcting transfers than
other g protocols.

MSKermit is an OK terminal package, but a horror to use as
an external protocol.  It likes to claim the comm ports as
its own, a bad thing when running under a BBS!

I have not tried all the Opus specific protocols, but see
little there to get excited about.  For the sake of
completeness, I will do it someday.  I have tested oKermit
1.04, which would not work for me at all, though Peter
Janssen runs it.

While not an exhaustive list of protocols, I think this
reflects most of those available today.  I think the
internal RA external protocol support could easily work with
all reliable protocols with the addition, some day, of
errorlevel support to the logfile support it has now.

I hope this is of use to someone!  Comments, additions, and
all are welcome.  Hopefully this can be the beginning of an
ongoing project to provide protocol installation information
for RA.

The files herein contained are only guaranteed to occupy
diskspace, and blah blah (usual disclaimer).

Bob R.
1:154/[e-mail]
The Anonymous BBS
Fussville, WI
414-251-2580