P r o t o _ R A 2 . 0 1 Release Version 10/17/93 12:49 pm NOTE: Major changes from 1.11! Includes PROTOCOL.111 to keep some older protocols that I have dropped available for experimentation for those so inclined. 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. Both use GSZ.EXE, so if you prefer DSZ.COM, you will have to make those changes. PROTOCOL.111 is largely for instruction and information; do NOT use it as is, as some things have changed for 2.01. PROTOCOL.201 must be renamed to PROTOCOL.RA and edited for your system setup before use as well. 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 should work running single node, or multinode. They require a complete path if not in the current directory 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 /DORINFO 1 in version 1.60 and up, there is not enough room for a long path, so I have as an example \RA\ only. Please see the discussion of SET DSZLOG in the DSZ discussion, as it applies to all protocols that use the DSZ style logging. 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 3.10 Public Gamma version, which works fine with RA 2.01. 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/1.11/2.01. 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 CEXYZ, TXZModem and VirtualZmodem (in PROTOCOL.201) 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. Note that this log MUST be set to write in the current node directory. For multinode, you can use the %TASK% variable to do this. If you use DOS and not 4DOS, you have to reserve the space in the environment in your autoexec.bat: SET TASK=1 SET DSZLOG=C:/RA/NODE1/DSZ.LOG Now, in the batch file that starts up the node, pass the node to it: RUNRA 1 The appropriate lines in RUNRA.BAT would be at the top, and be like this: SET TASK=%TASK% SET DSZLOG=C:/RA/NODE%TASK%/DSZ.LOG With 4DOS, there is no need to reserve the environment space. 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. Set it to C:MPT.LOG (or whatever drive you have your BBS directory on), and go! 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! Use the general procedure describing SET DSZLOG above, setting it to the node's directory. Also, you will have to patch it to log so that RA can tell DL from UL from errors. Here is how: Use a Hex editor, and search for 00002. When you find it (and NOT 000002!), look back for the string T%7, and change T to t. Now, look for 000002, and change the T to E where you see T%7. Last, look for 00001, and be sure the T%7 above it still says T. Save your changes. You can also freq a patched copy from my board as TASYRA.ZIP. 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.60 and up must be used, 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. Version 1.60 and 2.00+ correct this problem. 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 and 2.00 fix 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. This is a bit tricky, though, as the usual trick of C: will not work, as you must have a trailing backslash in the SZCONFIG data, or SZModem will not only not find dorinfo1.def, it will not find the other config data! Use C:.\ for the path, as that seems to work fine. The examples given in the sample PROTOCOL.200 files use this new version; for other added commandline options, 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 path of the log and xfer files in the protocol setup and in PROTOCOL.RA. The xfer list file can be DL.TXT with the path, or some other; the commandline overrides the protocol's set xfer list name. I use DL.TXT, myself. Use C:DL.TXT and C:SKHST.LOG, and it will work fine. 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 - ONLY IN PROTOCOL.111 Not reliable for RA 2.01, because of the logging problems (see below). I have retained this for information only. 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 - ONLY IN PROTOCOL.111 This no longer works with RA 2.01. Since it logs both sends and recieves with the SAME letter, RA does not distinquish between the two when checking for bidirectional protocols! I have left this in for informational purposes, in case the author corrects this problem. 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:HYP.LOG I) TXZmodem Straightforward setup, nice screen display, and works fine passing an upload directory. The only thing you will need to do is hex edit the executable to change the TXZLOG to DSZLOG, as explained in the documentation for the protocol, or get a patched copy from someone else. The author does NOT wish such patched copies posted for download as his original archive. A nice way to get zmodem (other than the internal version) in RA. J) Visual Zmodem A beta version of this protocol, lacking the promised Kermit functions, is available. This is a nice graphic X/Y/Zmodem driver, very simple to install, which works fine. K) Kermit (Visual Z implementation) Included in the PROTOCOL.200, this will not work with the present beta version. The setup is here for future use. L) Hydra This works perfectly in RA's external protocols setup, and the 1.03 version works fine in FileDoor as well. The .cfg file defaults are fine, except you may wish to specify the locked (DTE) rate, and RTS/CTS handshaking by default, to shorten the commandline to what will fit in PROTOCOL.RA. You may also wish to try NOFOSSIL in the .cfg if you use v1.08 Hydracom so that you can avoid the large 4k FOSSIL buffers otherwise required. This is how the version is set up in this example. Note well the use of ! rather than # in the DL command line. Also note that you might want to specify an alternate upload area in your FILES.RA for all areas for bidirectional protocols like this. The h and H of the 1.03 & 1.08 Hydracom are used for the dl/ul keywords. You will have to change those to H and R if you have v1.00, and that version will NOT work with FileDoor! Specify the path to the log as C:HYDRA.LOG to ensure it writes to the current directory. While my setup works perfectly for me, Arjen Lentz, the author, recommends a slightly different setup, so I will include that as well: In RACONFIG: External protocols: ÕÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ External protocol 1 ¸ ³ ³ ³ Name Hydra ³ ³ Key H ³ ³ Ext ctl file No ³ ³ Batch Yes ³ ³ Status Always available ³ ³ Log file DSZ.LOG ³ ³ Control file BATCH ³ ³ DL command line *C /C C:\RA\HYDRA\RA_HYDRA.BAT *P *B ! @BATCH *M ³ ³ UL command line *C /C C:\RA\HYDRA\RA_HYDRA.BAT *P *B # *M ³ ³ DL ctl string @ ³ ³ UL ctl string ³ ³ DL log keyword h ³ ³ UL log keyword H ³ ³ Log name word 10 ³ ³ Log desc word 0 ³ ³ ³ ÔÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ; C:\RA\HYDRA\RA_HYDRA.BAT: ============= @C:\RA\HYDRA\HYDRACOM.EXE port %1 lin %2 res DSZ.LOG rec %3 send %4 ============= For the upload command the /F switch must be used in your menu. If you want all uploads to be put in 1 area, put the area number in RACONFIG; Manager; File areas, en DON'T use the method of forcing the number of the area by putting it as optional data on the menu upload command, because that won't work together with the ! and # parameters on the external protocol command line. M) HS/Link The command line given works fine, with no need for a separate .cfg file generated by HSCONFIG. The same notes apply to this regarding the ! on the DL command line and alternate upload areas as for Hydra, the other bidirectional protocol in this example. N) CE-XYZ The included example uses the ZedZap variant. Be aware that this variant will NOT work properly if the receiving end is using normal Zmodem; it does work fine with itself, FrontDoor's terminal, and any other ZedZap able variant I have tested. The general notes on setting up DSZ apply to CE-XYZ as well. 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. BiModem is very complicated to add securely to a bbs package, so it has not been implemented. Standalone programs exist to run it, and FileDoor and others also support it. 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. If you intend to run FileDoor as well as the RA externals, you will have a big problem if your upload directories are on the same drive as your bbs, and you use the setups here. The various protocols that are configured to write to C: will write to the current dir rather than the node directory. Perhaps you can assign a dir to a drive, but it is likely more reliable to simply use a separate partition for uploads in FileDoor. This applies to MPt, SKHST, Hydra, and SZModem, at least. 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