ts@chyde.uwasa.fi (Timo Salmi LASK) (11/12/89)
I have been using Telix, Procomm Plus, and MsKermit successfully for terminal emulation for quite awhile. All these programs have their strengths and weaknesses, and to some extent they are complementary to each other. Which telecommunication program to use is dependent on the circumstances. The strengths of MsKermit are in its flexibility of terminal emulation, and the robustness of its kermit file transfer protocol. For example in VT102 emulation I have definitely achieved the most satisfactory results with MsKermit. Of these three communication programs it is the only one that has never caused me unacceptable problems in emulating VT102, nor in translating the Scandinavian keys. With MsKermit version 2.32A the keyboard keys of a PC can be made to simulate true VT102 terminal layout very closely. See MSK232AT.INI in my tskerm21.arc package for an example of configuring such a keyboard. Kermit file transfers are far from convenient. Kermit file transfer is rather slow, and it is very awkward to use. Whenever possible, I prefer to use the z-modem file-transfers which are inbuilt in Telix, and external for Procomm Plus. Unfortunately, I have encountered situations where using MsKermit's kermit file transfer is the only option that works. This occurs under two different circumstances. First, the host machine (such as our VAX) may not have any other file transfer protocol. Second, with some modems the mainframe <--> PC file transfers z-modem simply fails. This is aggravating. Because of these problems in file transfers I decided to do something about the clumsiness of MsKermit's file transfers. So, I wrote scripts that fully automate both sending and receiving files between a Unix host (which has C-Kermit) and the PC (which has MsKermit 2.32A). I have included these scripts is my MsKermit utilities collection tskerm21.arc. Incidentally, Procomm Plus users, who do not already have my Procomm utilities and advice collection, might be interested to take a look at the tspfon29.arc package. The files are available by anonymous ftp as usual. ................................................................... Prof. Timo Salmi (Site 128.214.12.3) School of Business Studies, University of Vaasa, SF-65101, Finland Internet: ts@chyde.uwasa.fi Funet: vakk::salmi Bitnet: salmi@finfun ................................................................... TSKERM21.ARC MsKermit utilities by Timo Salmi Filename Comment Date Time CRC -------- -------------------------------- ---- ---- --- GETBIN.CMD Automatic file transfer to PC 11-11-89 17:54:14 45E6 GETTEXT.CMD Automatic file transfer to PC 11-11-89 17:54:08 5D6C KERM.BAT A simple batch for MsKermit 2.32 02-11-89 12:10:04 3862 MSE.BAT Alternative boot, colors, harddk 04-08-89 07:48:46 E8D4 MSK.BAT Selective boot for MsKermit 2.32 04-08-89 07:53:48 8C97 MSK230AT.INI Standard VT102 keyboard driver 08-12-88 05:09:20 CA73 MSK230KP.INI VT102 keypad simulating Facit 08-12-88 05:09:40 EF58 MSK230QL.INI VT102 keypad simulating QL QCODE 08-12-88 05:10:56 E8A0 MSK231AT.INI Procomm-like VT102 AT keyboard 11-09-88 12:25:32 BE73 MSK231ZN.INI VT102 for Zenith Z-181 and XTs 04-28-89 15:58:28 E470 MSK232AT.INI VT102 keyboard for MsKermit 2.32 04-08-89 08:00:42 B507 MSK232ZN.INI VT102 for Zenith + MsKermit 2.32 05-02-89 23:59:58 93F0 MSZ.BAT This I use on my laptop 04-08-89 08:24:30 0C1C PUTBIN.CMD Automatic file transfer from PC 11-11-89 17:54:00 9487 PUTTEXT.CMD Automatic file transfer from PC 11-11-89 17:53:52 2EEA SAMPLE.CLL Autodialing! with MsKermit 08-12-88 22:23:28 9388 TIMELOG.EXE For logging program usage 08-14-88 16:48:22 8A51 TSKERM.INF Document 11-11-89 17:29:04 38BE TSKERM.NWS News announcements about tskerm 11-11-89 17:55:20 918B TSPROG.INF List of PD programs from T.Salmi 10-28-89 16:59:24 D436 VAASA.INF Info: Finland, Vaasa, U of Vaasa 06-23-89 08:30:08 88AB ---- ------ ------ ----- 0021 86462 46264 47%
usenet@cps3xx.UUCP (Usenet file owner) (11/12/89)
Kermit uses only 7-bit ascii characters for its file tranfer protocol. If you send files with 8-bit characters (binary files like .EXE, .ARC, .ZOO, .ZIP, etc.), Kermit uses quoting, where a special character is used to flag a byte with the eighth bit set. If you send binary files this way, it effectively doubles the size of the file. In order to go faster, I recommend using arc -i on your Unix system, then uuencoding the file. Uuencode makes the file about 33% larger, but arc can achieve compression ratios of 50%+. Transfer the file, and then perform the reverse process on your pc. The -i option for arc does the \n MSDOS <-> Unix translation. PKXARC can be made compatible with arc by using the -oct switch. This helps on text files a little bit, and on binary files a whole bunch! In the rare case that original ideas Kenneth J. Hendrickson N8DGN are found here, I am responsible. Owen W328, E. Lansing, MI 48825 Internet: hendrick@frith.egr.msu.edu UUCP: ...!uunet!frith!hendrick
jwbirdsa@phoenix.Princeton.EDU (James Webster Birdsall) (11/13/89)
In article <5351@cps3xx.UUCP> hendrick@frith.UUCP (Kenneth J. Hendrickson) writes: >Kermit uses only 7-bit ascii characters for its file tranfer protocol. >If you send files with 8-bit characters (binary files like .EXE, .ARC, >.ZOO, .ZIP, etc.), Kermit uses quoting, where a special character is >used to flag a byte with the eighth bit set. If you send binary files >this way, it effectively doubles the size of the file. Correction: Kermit uses the full width of whatever communication line it has available. On a 7-bit line, it can send text straight and binaries by quoting (which drops the speed by a lot -- it's usually faster to uuencode and download as text). On an 8-bit line, it can send binaries straight. [Your mileage may vary. I'm using MS-Kermit (in the various versions since 2.29) and C-Kermit (version whatever) on assorted UNIX boxes.] When I did CPS measurements (CPS of the original file, not the uuencoded version, if appropriate), I found that 8-bit was the fastest for binaries, followed by 7-bit text of uuencoded file, followed by 7-bit quoted binary. Boosting the packet size to the max of 1000 helped throughput a lot as well (if you've got dirty lines, this may not be true -- around here, the lines are very clean and I get maybe one resend every other month). -- James W. Birdsall jwbirdsa@phoenix.Princeton.EDU jwbirdsa@pucc.BITNET ...allegra!princeton!phoenix!jwbirdsa Compu$erve: 71261,1731 "For it is the doom of men that they forget." -- Merlin
CUMMINGS@S55.Prime.COM (11/13/89)
Jim Birdsall is right. Look at the following examples. Consider first that
a binary files has statistically 50% bytes with leading zeroes and 50%
bytes with leading ones (varies from file to file, but statistaclly
right). That means that transferring a binary file on a 7 bit ASCII
connection will cause 50% of the bytes to be quoted. Equivalent of
increasing the file size by 50%. UUENCODEing is a 3 byte-to-4 byte encoding
of your binary text. It increases your file size by 33.3% (regardless of
the percentage of bytes beginning with 1's or 0's!). Obviously transferring
a binary file over an 8-bit line has no penalty (0% file growth!).
============================================================================
Kevin J. Cummings Prime Computer Inc.
20 Briarwood Road 500 Old Connecticut Path
Framingham, Mass. Framingham, Mass.
InterNet: CUMMINGS@S55.Prime.COM
CSNet: CUMMINGS%S55.Prime.COM@RELAY.CS.NET
UUCP: {uunet, csnet-relay}!S55.Prime.COM!CUMMINGS
Std. Disclaimer: "Mr. McKittrick, after careful consideration, I've come
to the conclusion that your new defense system SUCKS..."
============================================================================