Comparison of UUCP and C-Kermit

By Peter Eichhorn
assyst Gesellschaft für Automatisierung, Software und Systeme mbH
Kirchheim bei München, Germany

May 1997

    http://www.assyst-intl.com

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 150 employees.

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 industries.

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:

• 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 minutes!
• 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 critical work.
• 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 support tool.