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 . 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 . 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/40@fidonet.org The Anonymous BBS Fussville, WI 414-251-2580