Comparison of UUCP and C-Kermit
By Peter Eichhorn
Some words about our company, assyst. If you like, you can have a look
at our Website:
assyst Gesellschaft für Automatisierung, Software und Systeme mbH
Kirchheim bei München, Germany
Since assyst was established in 1985, it has developed from a
four-person enterprise to a company with a total turnover of 40 million DM and
Originally it was conceived as a pure service company, but soon
assyst started developing its own systems.
Our main objective is development and sales of automation systems for the
sewing industry. Our most important product area is complete CAD/CAM systems
and system components that can be integrated into the network of a CIM system.
assyst's potential customers are companies processing all kinds of
textile materials. Of course, these are especially the apparel and upholstery
Until 1993 (before I joined the company), only uucp and cu were used to do
data transfer over modem lines, because they didn't know about C-Kermit.
In 1994, I joined the company and introduced C-Kermit starting with version
4E(072) (HP's default C-Kermit version for HP-UX 7.x - 9.x; HP-UX 10.x comes
with C-Kermit 5A(190)). Since that time, the whole support group stopped
working with cu/uucp and moved over to C-Kermit within only a few weeks.
Today, only C-Kermit is used for daily interactive support work. cu is used
only to check if basic modem functions works, and uucp is now used only for
our e-mail system and for automatic data exchange between some customers IF
there modem connection works without any problems AND when the data may arrive
within the next few days or the next week!
Problems with uucp include:
What have we done so far:
- uucp handles only positive dial result messages from the modem, normally
only "CONNECT", and can't act on any normal negative messages like "BUSY",
"ERROR", "DIAL LOCKED" etc. This means that frequently you have to wait until
uucp times out before you can start a new call, and this can take several
- uucp cannot be interrupted during the dialing process. If you dial the
wrong system, or if the other modem is switched off, or, or, or. . . , you
have always to wait several minutes until uucp times out. If you have someone
who needs help urgently on the phone at the same time, you can only talk
about the weather or something else in the meantime.
- If anything changes in the whole dialup process (at the local site, local
PBX, remote PBX, remote line,...), you have always to find out the new way to
login and must update uucp's Systems file at each callin host. It can
sometimes take days to find a working login entry. Remember, uucp works not
only in USA! Here in Eastern Europe, or in China, etc, the modem line
behavior may change each day, and each day you might have to discover a new
login string for uucp!
- Thus uucp has in total for the whole dialing process too much delay
for any productive interactive work.
- In an HP-UX cluster, cu/uucp works only on the root server. There is no
way for uucp to use any serial line of a cluster node. C-Kermit works on each
type of a serial connection (direct, terminal server, X-Terminal),
connected to the server or to any client.
- If you need to get some specific files with uucp you need the modem three
times to finish your work. First login with cu and collect your data, then
logout and start uucp to transfer your data, and finally login again and
cleanup your temporary directory. This works only if you have your own modem
and own modem line. If not, like we had in the last few years, our users had
to wait three days and more to get there data and finish their work.
With C-Kermit, that's not a problem anymore!
- If you are logged in and some data is missing, you have to start your
modem also three times to get the missing data over to the right place. cu's
take and put feature is not error correcting, therefore you can't use it for
- For large data files only uucp's g-protocol works satisfactorily (under
HP-UX). But if you use high-speed modems the performance goes down if you
increase the connect speed. We made a test with a 7-bit file, 575283 bytes in
size, the HP patch shell archive file (share file) PHCO_9228. With a 14400
bps V.32bis connection, uucp needs 712 seconds to send, and a with 28800 bps
V.34 connection, 950-1299 seconds. C-Kermit needs 338 seconds for 14400 and
169 seconds for 28800 for the same file. This is a ratio of 2.1 or 7.68
(better) for C-Kermit! Bingo. I think, that the uucp problem in this case
comes from the used 64 char packet size and only 9 sliding windows.
- Generally, cu and uucp are very unhandy for interactive support over modem
lines. It takes too long to redial if you can not connect directly. You
cannot really switch between the remote and local site, and you cannot send or
receive data (especially binary data) while in connect mode.
- If the lines goes down or becomes bad, you don't have a resend/reget
feature and you have to wait till you get a better line. Also you don't have
a chance to adjust the packet and/or window size. So on very bad lines, you
don't have a chance to get anything through with uucp.
- uucp's error messages are not very clear about the true nature of the
problem. Maybe you can imagine how much work it is if you have a uucp problem
between two customers A and B (and you are C), where you cannot sit directly
in front of one or (better) both remote systems. Sometimes it takes days to
discover the problem.
- uucp's maximum serial speed is 38400 baud.
- We converted all our 728 customer cluster systems to work mainly with
C-Kermit and only as backup to work with uucp, if we like to add them to our
e-mail system. This has been done for HP-UX 6.5 through 10.20.
- C-Kermit lock files work's fine together with uucp/cu. Also you can
directly use uucp's Dialcodes file for dialing with C-Kermit! Really nice and
very helpful. You only need to update one dialcode file for both.
- All our support people use now only C-Kermit for their daily work. They
use it also for sending and receiving large amounts of data over modem, X.25,
LAN, ISDN, and a mix of these connections.
- If anybody needs to send or receive any kind of data quickly, they want to
do it with C-Kermit, because they know it will work well and very fast.
- Not one of the old uucp users, who used uucp over several years, wants to
go back to uucp for their daily support work. Sometimes, if they try to fool
me, I threaten to switch off C-Kermit :-)
- It's very useful to have scripts, macros, or command files at the local
site, which are doing their job at the remote site with all of C-Kermit's
REMOTE command features in client/server mode. Therefore there is no need to
transfer it first to the other site, just start it at the local site and let
them work at the remote site. Very, very handy. C-Kermit's client/server
REMOTE commands are the most powerful C-Kermit tools for us.
- On a very bad line, where you can't type in three characters without three
errors, the REMOTE commands are doing a great and SECURE job. Only the vi
editor doesn't work this way. But this is not a big problem. In a case like
this, we would receive the file first, made the changes locally, and send it
back without any errors. This way is often faster then waiting until any error
corrections work on the modem lines.
- We are providing hardware and application support for more then 700
systems in over 40 countries, with nearly no system administrators at the
remote site. With remote users, who know only their application very well
(what's UNIX, pipe, uucp? Some new BigMc's to eat?) and who cannot speak or
read any English messages (except the English, American, and only a few other
users). With C-Kermit we are able to log into there systems within a few
seconds, just in the time they say "Hello, I have a problem ...". And we are
able to do system support nearly like sitting in front of each of the 700
servers with more then 4000 clients.
- With C-Kermit we can install megabytes of new software, which is faster
and in total cheaper then putting it on tape and posting it.
- C-Kermit is our main and Number One tool for the daily support work
all over the world. We send and receive megabytes of data each day, too.
- Some of us tried in the past a mixture of uucp, cu, C-Kermit and
u/x/y/zmodem, but all of them returned to C-Kermit as there only and daily
UUCP vs C-Kermit / Columbia University / firstname.lastname@example.org / 15 May 1997