Category : Communication (modem) tools and utilities
Archive   : KERMUTIL.ZIP
Filename : TSKERM.POS

Output of file : TSKERM.POS contained in archive : KERMUTIL.ZIP
I have collected here with the kind permission of the authors some
interestings posting and email concerning MsKermit and related file
transfer problems and principles. My sincere thanks to Russ, Kenneth,
James, Kevin, Joe, Christine, et al.
All the best, Timo

From [email protected] Sun Nov 12 19:08:07 1989
From: Russell Herman
To: [email protected]
Subject: Re: Kermit file transfers made easy
Message-Id: <[email protected]>
Date: Sun, 12 Nov 89 12:05:53 EST

I may have the solution to your zmodem problems! I have a similar situation
with a pair of back-to-back async dataswitches between me sitting here at home
and the SUN 3/180 running SUNOS3.5 at work. After struggling and some hints
from Forsberg, I got everything working by invoking sz at the host with the
inclusion of '-l 1024'. This forces zmodem to use a dumber version of its
protocol that ACKs each packet before sending the next. The problem I
encountered was essentially flow control. By the time my XOFF drifted
upstream, my intermediaries were filled up with packets I wasn't ready to
swallow. Everything went totally out of sync by that point. Some
configuration peculiarities make it unnecessary for me to worry about
this when I'm uploading from the PC, although I guess the problem could
really cut both ways.

There is a slight performance hit. Over a 2400 baud modem I get about
210 cps instead of 220, and over a 9600 direct wire 800 cps vs 900
(just done as an experiment, there's no need to use -l over a wire
unless perhaps a PC can't keep up in some weird fashion).

I did use kermit before figuring out this solution. But why dig with a
teaspoon when you can dig with a shovel?

Russ Herman
INTERNET: [email protected] UUCP: ..uunet!utai!me!rwh

Article 2645 of
>From: [email protected] (Usenet file owner)
Subject: Re: Kermit file transfers made easy
Keywords: kermit, scripts
Message-ID: <[email protected]>
Date: 12 Nov 89 04:29:40 GMT
References: <[email protected]>
Reply-To: [email protected] (Kenneth J. Hendrickson)
Organization: Michigan State University
Lines: 19

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

In the rare case that original ideas Kenneth J. Hendrickson N8DGN
are found here, I am responsible. Owen W328, E. Lansing, MI 48825
Internet: [email protected] UUCP: ...!uunet!frith!hendrick

Article 2648 of
>From: [email protected] (James Webster Birdsall)
Subject: Re: Kermit file transfers made easy
Keywords: kermit, scripts
Message-ID: <[email protected]>
Date: 12 Nov 89 18:41:45 GMT
References: <[email protected]> <[email protected]>
Reply-To: [email protected] (James Webster Birdsall)
Organization: Princeton University, NJ
Lines: 28

In article <[email protected]> [email protected] (Kenneth J. Hendrickson)
>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 [email protected] [email protected]
...allegra!princeton!phoenix!jwbirdsa Compu$erve: 71261,1731
"For it is the doom of men that they forget." -- Merlin

Article 2652 of
>From: [email protected]
Subject: Re: Kermit file transfers made easy
Message-ID: <[email protected]>
Date: 12 Nov 89 19:02:00 GMT
References: <[email protected]>
Lines: 23

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: [email protected]
CSNet: CUMMINGS%[email protected]
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..."

Article 2727 of
>From: [email protected] (Joe Doupnik)
Subject: Kermit file transfers, a remark.
Message-ID: <[email protected]>
Date: 18 Nov 89 22:23:38 GMT
Lines: 17

There is a natural misconception regarding Kermit and 7 or 8 bit file
transfers. Kermit uses 8 bit transfers if parity is none, otherwise it uses
7 bits and encoding for the eighth bit. Even under Unix C Kermit runs the
communications line in full 8-bit mode during file transfers, if at all
possible, even though the conversational parts use the normal Unix parity.
Each Kermit determines the local parity situation and the width of the
transfer is negotiated between them at file transfer time.
I might add in passing that the Kermit protocol permits run length
encoding naturally, most Kermits support it, to help compress many files.
Not the same as the full blown archive compression schemes. If a communications
channel is 7 bits wide then archive style compression of text files may yield
a slower transmission than the original text files because of escaping all
the new eighth bits. The Kermit protocol also makes provision for cooperating
Kermits to use very advanced compression methods, but to date no release
Kermit uses those methods.
Joe D.

Article 2728 of
>From: [email protected] (Joe Doupnik)
Subject: More on Kermit file transfers.
Message-ID: <[email protected]>
Date: 18 Nov 89 22:34:05 GMT
Lines: 16

Perhaps I could add a small word on the common subject of slowness of
Kermit file transfers. The first is the protocol was designed to work between
dissimilar hosts, through their frontends or other channels. These situations
assume that most control characters do not survive the trip, that only
printable characters stand a chance, and that the file systems at each end are
probably vastly different. Robustness under these trying conditions requires
mechanisms built into the protocol. Second, my personal experience has
indicated that transfer speed is frequently dominated by the skill of the
programmer rather than the inherent protocol. Third, the status display of
programs does consume a fair fraction of the transfer time. The simpler or
more hardware dependent it is then the faster things move.
Btw, in the forthcoming release of MS Kermit the terminal emulator
is up to the DEC VT320++ level, and file transfers can be done with sliding
windows (even long packets in the windows).
Joe D.

From [email protected] Tue Nov 21 11:08:57 1989
Date: Mon, 20 Nov 89 14:35 MDT
From: Joe Doupnik
Subject: Re: Kermit file transfers, a remark.
To: [email protected]
X-Vms-To: IN%"[email protected]"

Yes, indeed. Please feel free to use any parts. I normally do not
submit times to comp.* but this occassion seemed free of the normal
emotional overtones.
There is a fuller discussion of issues in the Kermit Digest, also
listed by Usenet, and you can subscribe to it via Email to Info-Kermit-
[email protected] (or to [email protected] or even to
[email protected]). That way you can see and contribute to the
ongoing discussions.
Joe D.

Thu 21-12-1989: Here we have some more MsKermit postings and email with the
kind permissions of the authors.

Article 11893 of
>From: [email protected] (Dion Hollenbeck)
Subject: Re: Binary file transfers with MS Kermit
Message-ID: <[email protected]>
Date: 11 Dec 89 15:36:46 GMT
References: <[email protected]>
Sender: [email protected]
Lines: 20

>From article <[email protected]>, by [email protected] (Joe Doupnik):
> MS Kermit has no explicit command to do text or binary transfers
> because it needs none: the DOS file system does not distinguish the cases.
> However, the host (the other end) may well distinguish and the host Kermit
> may need to be told SET FILE TYPE BINARY at it's own command prompt.
> P.S. You ought to upgrade from MSK 2.29 (early paleolithic) to 2.32/A, or
> wait a month and get version 3.0 for much better performance and more
> goodies.
> Joe D.

Not true. Both the standalone Kermit I have and the implementation in
Procomm, both have the ability to set file type to BINARY and for a
darn good reason. In text mode, the first ^Z encountered will tell
DOS end of file. In binary mode, this will not happen and the
transfer will proceed by length alone.
Dion Hollenbeck (619) 455-5590 x2814
Megatek Corporation, 9645 Scranton Road, San Diego, CA 92121

uunet!megatek!hollen or [email protected]

Article 12041 of
>From: [email protected] (Joe Doupnik)
Subject: Re: Re: Binary file transfers with MS Kermit
Message-ID: <[email protected]>
Date: 13 Dec 89 03:26:34 GMT
Lines: 37

Binary mode and Control-Z are separate problems. MS Kermit provides
a command specifically to deal with Control-Z, and it does not have a SET
Having said that in nice upper case let me squirm around a little!
Version 3.0 of MS Kermit (due out shortly...) does have SET FILE TYPE BINARY,
and a bunch more like it. The implementation is to permit translation of
text files to other character sets using a standard character set on the
wire. TYPE BINARY says send the file verbatim and include in the file
attributes packets the notation that the local user is doing so. TYPE TEXT
says it's ok to translate ends of records to CR/LF, and more. Well, MS DOS
has no concept of records and CR/LF thus translates to CR/LF. The "and
more" part says to let the user say SET FILE CHARACTER-SET {choice of many}
and that would make sense only if the file were text. Again the attributes
packets note that this is what the file sender intends, and thus lets the
file receiver match up.
All this is for MS Kermit, and has nothing to do with Procomm or
other products implementing the Kermit protocol. There is no question
however that the fancier aspects of SET FILE exist on PCs only in MS Kermit
(for now, because this stuff was just recently invented and I'm just
implementing it). 2.32/A is the latest release, Jan 89, and 3.0 is due
out this month (fingers crossed).
So, MS DOS has no distinction between text and binary files, period.
Applications can do as they please with bit patterns. The file sender is
the one needing to be commanded by SET FILE TYPE BINARY and for MS Kermit
that need not (and can't until v 3.0) be done. Only file senders emit
attributes packets which is where information like this gets across the wires.
As a matter of small interest, packet formation is the same whether
or not the file is binary or text. On hosts having a concept of records they
have to stick in a CR/LF for text files, or not for binary files. On MS DOS
its all the same no matter what. 7 or 8 bit characters can be sent on the
wire and the 8 bit kind will be encoded to 7 bits if one side says Please
do (normally only if the useless Parity bit is on). Thus, the Kermit protocol
provides a virtual 8 bit channel.
I hope this clarifies a commonly misunderstood topic, and one that
is important to us.
Joe D.

Date: Tue, 19 Dec 89 18:09 MDT
From: Joe Doupnik
Subject: Re: Kermit (was Re: X,Y,Z modem for UNIX Sys V)
To: [email protected]
X-Vms-To: in%"[email protected]"
X-VMS-News: comp.sources.wanted:387

> From: [email protected] (Timo Salmi LASK)
> Subject:Re: Kermit (was Re: X,Y,Z modem for UNIX Sys V)
> Date: 10 Dec 89 12:59:16 GMT
> Message-ID:<[email protected]>

> In article <[email protected]> [email protected] (Roy M. Silvernail) writes:
>>I just did some time trials for a project. On a 168k file, Kermit took
>>25:50, PCI dosserv interface took 14:00 and Zmodem 12:10, using a 2400
>>bps link. Zmodem has an ASCII mode, as well, that will translate
>>newlines to CR/LF for MS-DOS machines.
>>Zmodem is my favorite protocol overall. (and I never use Kermit unless
>>forced by circumstance;-)
> And this is about as it should. As far as I understand Kermit
> protocol only uses the 7-bit half of each bit in the transfers, and
> thus looses out in speed. On the balance, over difficult transfer
> circumstances kermit often is the only protocol that gets through.
> This is a classical case of different tools for different
> circumstances.

Not quite. 7 bits are used only if parity is active, otherwise
Kermit uses an 8 bit channel. Benchmarks are funny things aren't they.
No one is sure what's being measured.
Joe D.

Sun 18-Feb-90 : Here we have more MsKermit postings and email with the
kind permissions of the authors.

From: Joe Doupnik
Subject: Re: Binary file transfers with MS Kermit
To: [email protected]
Date: Wed, 13 Dec 89 09:22 MDT

Yes, indeed. The postings from here may be copied and redistributed
as you wish.
Telix? I don't recall seeing that name here in the States, though
Procomm Plus does reside in my archives as a comparison (with Crosstalk
and SmartComm, etc).
If you do establish a reposting site for communications programs
that would be a great thing for your region. Trying to ftp programs from
this side of the Atlantic is not always so easy for European persons.
I'm getting near the end of the development cycle on MS Kermit: including
a graphics screen to disk file dump facility (using TIFF v5 specifications)
this week. The To-Do list is actually getting shorter and shorter.
While on the subject of new things in Kermit, there will be features
present to support a number of different IBM PC Code Pages as the "native"
character set, for both terminal emulation and file transfer. There is also
a user-definable table to act as a replacement for particular Code Page
during file transfers. What this means is a lot of explaining to people how
they can use the facilities; the experiences of many people need to be
published so we can all have a better idea of what can be done now and what
might be done better next time.
Joe D.

From: Joe Doupnik
Subject: RE: TSKERM23.ARC MsKermit utilities update
To: [email protected]
Date: Sat, 23 Dec 89 12:18 MDT

Thanks for they update. I've just sent copies of your message to
several people this morning. Your work is much appreciated, more than you
may realize.
Happy Holidays,
Joe D.

From: Joe Doupnik
Subject: RE: MsKermit 3.0 beta, urgent feedback
To: [email protected]
Date: Sat, 13 Jan 90 18:35 MDT

Just got back from a several day business trip (and the mail queue
is unbelievable!). The Finnish character set information is that specified
by Digital as a National Replacement Character set. In it both caret and
tilde are replaced by umlated u's, as strange as that may seem.
I'll see if I can squeeze in a few minutes to get tskerm23.arc file
for reviewing here.
Thanks for the quick feedback,
Joe D.

From: [email protected] (Christine Gianone)
Subject: MS-DOS Kermit 3.0 Questions and Answers
Date: 18 Jan 90 18:12:11 GMT

Here are the questions that came up most frequently during the MS-DOS Kermit
3.0 beta testing period:

Q - I tried using the Latin-1 (or DEC-MCS) terminal character set, but I
didn't get any special characters on my screen, only incorrect ASCII
characters where the special characters should be.

A - To see 8-bit text characters, you need an 8-bit no-parity connection to
the host, and you must tell MS-DOS Kermit to SET DISPLAY 8 (7 is the
default). In the 7-bit environment, you can still use an 8-bit character
set if your host sends shift-in/shift-out codes (but see MSKERM.BWR).
Otherwise you must use one of Kermit's 7-bit "national replacement
character sets" (Italian, Norwegian, etc), in which brackets, vertical
bars, etc, are replaced by national characters.

Q - If none of Kermit's built-in terminal character is suitable for my
language or computing environment, what can I do?

A - Put a lot of SET KEY and SET TRANSLATE INPUT commands in your
MSKERMIT.INI file. These commands override Kermit's built-in
translations of outbound and inbound characters, respectively. Also
remember to SET TRANSLATE INPUT ON. Using these mechanisms, you can
construct an entirely new terminal character set.

Q - Word-11 or other DEC PDP-11 or VAX/VMS applications do not seem to work
right with 3.0. Screens are fractured, etc.

A - Kermit's new VT320 terminal emulation is noticed DEC by operating systems
like VMS 5.0 or later, causing them to send 8-bit control sequences which
are ignored by MS-DOS Kermit unless you SET DISPLAY 8. SET DISPLAY 7 is
still the default, for compatibility with earlier releases.

Q - If Kermit does VT340 graphics, how come my SAS graphs don't come out
right if I tell SAS that I have a VT340?

A - Kermit implements many VT340 graphics features, including colors and
sixels, but not DEC's REGIS graphics language, which is what SAS uses.
There are no current plans to implement REGIS, which is huge. The
VT340 features which are supported by Kermit can be used to best
advantage with host-resident versions of WordPerfect (4.2 and 5.0) on

Q - Why do I have to SET FILE TYPE TEXT and SET FILE TYPE BINARY with 3.0
when I didn't have to do this in previous versions?

A - During file transfer, version 3.0 does two things that previous versions
didn't do: text file character set conversion, and conveying and using
the file type given in the file attribute packet. If you want to
approximate the old mode of operation, in which you did not have to (and
indeed could not) give SET FILE TYPE commands, you can SET TRANSFER
CHARACTER-SET TRANSPARENT (this is the default anyway) and SET ATTRIBUTE

From: Keith Petersen
Subject: MS Kermit 3.0 problem with DSZ
To: Chuck Forsberg <[email protected]>
Date: Sat, 27 Jan 1990 08:51 MST

Chuck, I saw your posting in the newsgroup. The push
command is not necessary to run DSZ from MS-Kermit. I use the "run"
command to do that: run dsz t

It works fine and does not suffer from the XOFF problem.


  3 Responses to “Category : Communication (modem) tools and utilities
Archive   : KERMUTIL.ZIP
Filename : TSKERM.POS

  1. Very nice! Thank you for this wonderful archive. I wonder why I found it only now. Long live the BBS file archives!

  2. This is so awesome! 😀 I’d be cool if you could download an entire archive of this at once, though.

  3. But one thing that puzzles me is the “mtswslnkmcjklsdlsbdmMICROSOFT” string. There is an article about it here. It is definitely worth a read: