Kermit News Number 5, June 1993

The new generation of Kermit communications software offers improved efficiency, networking capabilities, automation features, and an understanding of national and international character sets. Together, the three major Kermit software programs--MS-DOS Kermit, C-Kermit, and IBM Mainframe Kermit--form a high-quality, powerful, and fully interopable suite of communication programs for the industry's most popular computers.

Credit Cards Accepted

It's KermitWare!

While MS-DOS Kermit's pricey competitors focus on frills like sound effects, elaborate startup screens, and technicolor pop-up exploding menus that consume your PC's memory, disk, and processor capacity, MS-DOS Kermit stresses substance: fast, reliable, high-quality terminal emulation and file transfer in a wide variety of communication, computing, and language environments. Small size and efficient operation. Easy setup and configuration. Powerful, easy-to-use key mapping, macros, and script programming. And low cost.

Now MS-DOS Kermit extends its reach even further with more terminal emulations, more communication methods, faster file transfer, and more languages.

Version 3.13 of MS-DOS Kermit for the IBM PC, PS/2, and compatibles is now available. It was prepared by Professor Joe R. Doupnik of the Center for Atmospheric and Space Sciences and Department of Electrical Engineering of Utah State University in Logan, Utah, USA, in cooperation with Columbia University in New York City and Waterloo University in Ontario, Canada.

Built-in TCP/IP Networking

Why add TCP/IP to Kermit? Until now, people who use both network and serial connections have had to switch between a TCP/IP TELNET program (which doesn't support serial connections) and Kermit (which didn't support TELNET connections). No more! Now you you can use all of Kermit's powerful features in the TCP/IP environment in place of TELNET and FTP, exactly as you use them now on serial connections: script programming, modem dialing scripts (when dialing out from TCP/IP terminal servers), flexible key mapping, keyboard and command macros, fast and accurate text and graphics terminal emulation, and international character-set translation in both file transfer and terminal emulation.

Perhaps most important of all, now you can have a single application program, a single configuration file, and a common user interface for both serial and network communication.

Kermit's TCP/IP and TELNET support works over Ethernet- or SLIP-class packet drivers available from your network board vendor or from us, as well as over ODI network drivers or on a serial port via Novell's new SLIP_PPP ODI driver, and also (via a "shim," which we also supply) over NDIS drivers.

Other Networks

Compare MS-DOS Kermit with commercial PC communication software packages. How many of them support such a wide array of networks? And how many offer this support at no extra cost?

Character Sets for Many Languages

Character-set conversion is essential in the international market. Different computers use different encodings for the "special characters" found in these languages; Kermit software can reconcile the differences.

Now MS-DOS Kermit also handles Eastern European languages like Czech, Polish, Romanian, and Hungarian. And languages written in the Cyrillic alphabet such as Russian, Bulgarian, Byelorussian, and Ukrainian. It handles Hebrew too, including right-to-left screen writing and a full range of Hebrew VT100 and VT420 terminal features. MS-DOS Kermit 3.13 can even convert Japanese Kanji character sets during file transfer.

MS-DOS Kermit can transfer text files written in over 30 different languages with other computers, even when they use completely different encodings, if the other computer is equipped with a Kermit program that uses this technique. IBM mainframe Kermit and C-Kermit 5A do. This is a unique feature of the Kermit file transfer protocol, and you won't find it in any other communications software.

Terminal Emulation

The new release includes other text and graphics terminal emulation improvements, too: 132-column compressed text and horizontal scrolling in VT terminal emulation on EGA and VGA video adapters; a compose key for entering accented letters; screen rollback buffers and graphics images are now stored in expanded memory (EMS), if available, allowing thousands of rollback screens while freeing conventional memory for other uses. Terminal emulations offered by MS-DOS Kermit now include:

• DEC VT52, VT100, VT102, VT220, VT320
• DEC Sixel Color Graphics
• DG DASHER D463, D470 Text and Graphics
• Heath/Zenith 19
• Tektronix 4014 Graphics with extensions
• NONE (for external console drivers, e.g. ANSI)

Faster File Transfer

• Portability and consistency across hundreds of hardware and software platforms
• Efficient terminal connection and file transfer
• International appeal
• Automation features
• Network support

Portability

C-Kermit's modular design has promoted its adaptation to a diverse collection of computers and communication methods, making it a premiere example of open and portable software. C-Kermit's user interface is easy to learn and use, helpful to the novice without getting in the way of the expert, and consistent throughout a wide range of operating systems and hardware platforms. Users of many types of computers now have a single software package to meet both serial and network communication needs.

UNIX C-Kermit

John F. Chandler
Harvard/Smithsonian Center for Astrophysics
Cambridge, Massachusetts

There have been several new releases of IBM mainframe Kermit-370 since version 4.2 was announced in the last issue of Kermit News. Most notable among these is a brand-new version for CICS, which can be used under either MVS or DOS/VSE. The new releases run on all the major operating systems found on the IBM System/370 (390, 9000) architecture, including XA and ESA:

CICS Kermit 4.2.4

For CICS versions 1.6-2.1 under MVS, DOS/VSE, and probably also VM (this has not yet been tested), supporting the full range of linemode and fullscreen environments that are supported by the other Kermit-370 versions.

TSO Kermit 4.2.4

For MVS/TSO, MVS/XA/TSO, and MVS/ROSCOE/ETSO.

CMS Kermit 4.2.5

For VM/CMS, VM/ESA/CMS, VM/XA/CMS, VM/HPO/CMS, VM/IS/CMS, and VM/SP3-SP6.

MUSIC Kermit 4.2.3

For the MUSIC/SP operating system, with MUSIC specifics by Pierre Goyette of McGill University.

Major new features include:

Acorn Archimedes Kermit

Apple II Kermit 3.87

BTOS / CTOS Kermit 2.00

This new version adds some of the capabilities of MS-DOS Kermit 3.x and C-Kermit 5A, particularly script programming features (INPUT, OUTPUT, IF, ASK, GOTO, variables, etc), and includes a built-in VT101 terminal emulator. January 1993. Tape C.

Chinese DOS Kermit

Commodore 64/128 Kermit

CP/M-80 Kermit 4.11

Features added since version 4.09 (January 1988) include: new filename collision options: BACKUP, DISCARD, OVERWRITE, RENAME; an option to keep or discard incompletely received files; many new REMOTE commands for communicating with Kermit servers; a RENAME command; improved interruption of TAKE, TYPE, and PRINT commands in progress; many bug fixes.

Support was added for the Microbee family of computers (56K, 64K, 128K and 256K) manufactured by Microbee Systems, Ltd, of Australia, by Russell Lang of Monash University, Australia, and for the Ampro Little Board from Jay S. Rouman of Mt. Pleasant, MI, USA. April 1991. Tape A.

DEC PDP-8 and PDP-12

Gould/SEL MPX Kermit 2.3

Hewlett Packard 3000 MPE Kermit

A second version of the same program, but written in the C language, was received from Tony in June 1993. Tape D.

Honeywell DPS-6 Kermit 2.01

IBM CS-9000 Kermit

Luxor Computers

Protocol fixes for ABC80 and ABC800 from Jorgen Westman of ABC-Klubben. ABC800/802/806 CP/M systems updated to version 4.11, with support added for FACIT DTC and DTC2 Luxor clones, from Mikael Johansson of ABC-Klubben. July 1990. Tape C.

NCR 9800 VE/IVS and VE/MCS

Separate variations are provided for the IVS and MCS environments. The program is written in C, based on C-Kermit 4E with features selected depending on VRX system capabilities. July 1990. Tape D.

Pecan Kermit 1.1

Binary transfers now work in both SFS and AFS implementations. Incorrect reporting of file creation time in attribute packet fixed. July 1990. Tape C.

Prime Kermit 8.15

Other new features include: ability to send BYE, FINISH, SEND, GET, and selected REMOTE commands to Kermit servers; script programming features, including new INPUT, OUTPUT, PAUSE, and CLEAR commands; problems with multiple file transfers with a specific file type are corrected.

There are also improvements in sliding windows and other Kermit file transfer protocol features; the exact file length is now sent in the attributes packet; an alternate initialization filename is specifiable on the command line; pound-sign conversion is correctly handled. April 1993. Tape D.

TurboDOS Kermit

UNISYS (Burroughs) A-Series Kermit 1.041

Max Evarts, Kermit Distribution
Columbia University, New York City

The Kermit Distribution and Support office has seen many changes since the last issue of Kermit News. In June 1990 Ken Suh moved on to law school and Andy Newcomb took his place. Many of you who have called us over the past few years already know Andy.

New Services

In response to the growing demand for telephone service, we are putting in a call-processing system. If all lines are busy, you will have options to get the information you need from our voice menu or hold to speak to one of us. The system separates order-related calls and technical calls so those of you with a quick ordering question will not have to wait while we debug a software problem.

Technical Support Hints

• Make sure you have the current documentation for your Kermit software; if we are on the phone reading the manual to you, we cannot be helping someone who has a more difficult Kermit problem.
• Know the versions of all the Kermit programs involved before you call; most Kermit programs print the version number when they start up.
• Expect us to ask you to upgrade your Kermit software if you are far behind the times; we can only support up-to-date versions.
• Try to be in a position where you can reproduce your problem while you are on the phone.
• We do not support implementations of the Kermit file transfer protocol that are part of other communications packages.

Our technical support service is a free, but limited, resource. Usually, only one person is available at a time to handle tech support calls; please be considerate of the many other callers--help us to help as many Kermit users as we can.

Frank da Cruz

In the early 1980s, the first generation of Kermit software used the basic Kermit protocol: stop-and-wait exchange of short packets. The basic protocol is easily implemented and highly robust, and led to its rapid proliferation to hundreds of hardware and software platforms where it proved a success in transferring files under even the most difficult conditions.

The new generation of Kermit software improves on the original robust qualities and dramatically boosts performance without sacrificing compatibility with the earlier generation. Protocol capabilities are negotiated automatically so the newest, most advanced versions can still exchange files with the earliest or most minimal versions.

Kermit's performance features include long packets, sliding windows, control-prefixing selection, locking shifts, and compression. The first three have the potential for causing problems, and are not used unless you ask for them. This article describes Kermit's performance features and tests them against other popular protocols. The results might surprise you.

Longer packets reduce the ratio of protocol overhead to actual data, increasing the potential file transfer efficiency (the ratio of file characters transferred per second to the actual connection speed) from 86% (for 94-byte packets) to 95% (with 2500-byte packets). When conditions deteriorate on the connection, the packet length is automatically adjusted.

Original, basic Kermit was a stop-and-wait protocol because it had to work on half-duplex as well as full-duplex connections. But connections through satellites or packet-switched networks can have delays that seriously impede the efficiency of a stop-and-wait packet protocol. For example, suppose packets are 90 bytes = 900 bits long, and there is a one-second transmission delay. For one packet and its response, the round-trip delay is 2 seconds. At 300 bits per second (bps), the 3 seconds required to transmit the packet plus the 2-second delay make 5 seconds, so throughput is 180 bps, 60% efficiency. At 9600 bps, it takes only 1/10 second to transmit the same packet, but the delay is still 2 seconds. Throughput is only 428 bps, 4.5% efficiency. When connections have delays, efficiency can be improved by lengthening the packets, but only if the connection is clean. On a noisy connection, longer packets are more likely to be damaged in transmission and take longer to retransmit.

On full-duplex connections, the new generation of Kermit software (IBM mainframe Kermit excluded, which always has a half-duplex connection) can transmit packets in a steady stream, processing the acknowledgements later as they arrive, thus eliminating the effects of transmission delays, and also eliminating the overhead of the acknowledgements themselves, since they are "on the wire" at the same time as the data packets and therefore don't take up any extra transmission time. This technique is called sliding windows, because multiple packets are kept in a buffer (window) that "slides" forward whenever the oldest packet in the window is acknowledged.

Using 94-byte packets without sliding windows on a connection that has a 1-second delay results (according to actual measurements) in an efficiency of about 8%. Raising the packet length to 1500 on the same connection increases the efficiency to 63%. Using sliding windows on the same connection raises the efficiency to 82-90%, depending on the packet length.

To see a dramatic speed improvement using MS-DOS Kermit 3.13 and/or C-Kermit 5A, simply give these commands to each Kermit before file transfer:

  SET WINDOW 3
  SET RECEIVE PACKET-LENGTH 1000

Analysis of large volumes of both textual and binary data shows an average compression of 15-20%. Dramatic savings are achieved in certain types of files, including tabular text (or any other type of text with lots of repeated characters) and executable programs containing large amounts of pre-zeroed data.

On some connections it is safe to transmit certain control characters "bare," without prefixing or encoding. "Unprefixing" of control characters can speed up the transfer of binary files, particularly precompressed files, which tend to contain a lot of bytes in the control range. MS-DOS Kermit 3.13 and C-Kermit 5A(189) give you the ability to specify which control characters are to be prefixed and which are not. In the benchmarks on pages 7 and -SPEEDY, only three control characters are prefixed:

  SET CONTROL UNPREFIXED ALL
  SET CONTROL PREFIXED 0 1 129

On 8-bit connections, Kermit transfers 8-bit data with no additional overhead. On 7-bit connections, which are quite common--these are the connections that use even, odd, mark, or space parity, often without the user's knowledge--8-bit data is encoded using a single-shift technique, a prefix character for each byte whose 8th bit is 1, similar to holding down the Shift key on your keyboard for each 8-bit character. This allows Kermit to work where most other protocols fail. The amount of prefixing ranges from 0% up to 100%, depending on the type of file.

Locking shifts are supported by MS-DOS Kermit 3.13, C-Kermit 5A, and IBM Mainframe Kermit 4.2.4, and are negotiated automatically when parity is in use (including when parity is detected automatically). They reduce the 8th-bit prefixing penalty anywhere from 0% to 100%, depending on the groupings of the 8-bit characters within the file.

So Why the Bad Reputation?

Table 1:  Kermit Implementations Compared

              Window Packet Time Speed
PC Software    Size  Length secs  cps  Effic. Remarks

 Telix           1     94   131   1052   55%  Long packets and s/w not avail
 MTEZ            1     94   119   1158   60%  Long packets and s/w not avail
 Smartcom III    1     94   113   1220   64%  Long packets and s/w not avail
 PROCOMM PLUS   14   1000    77   1790   93%  Window size not selectable
 Zstem 340       2   1000    74   1863   97%  Maximum window size 2
 MS-DOS Kermit   3   1000    72   1915   99%  Full control-character prefixing
 MS-DOS Kermit   3   1000    69   1999  104%  Only 0, 1, and 129 prefixed

If you thought Kermit file transfer was slow, you were probably not using real Kermit software!

  MS-DOS Kermit 3.13     Columbia University, New York, NY, USA
  MTEZ 1.16              MagicSoft, Inc., Lombard, IL, USA
  PROCOMM PLUS 2.0       Datastorm Technologies, Inc., Columbia, MO, USA
  Smartcom III 1.0A      Hayes Microcomputer Products, Inc, Norcross, GA, US
  Telix 3.21             deltaComm Development, Cary, NC, USA
  Zstem 340 1.0.4        KEA Systems Ltd., Burnaby, BC, Canada

Kermit and X-Y-ZMODEM

  ASCII Text:    IKCKER.DOC 137901 bytes  Our original ASCII text file
  UNIX Binary:   uuencode    24576 bytes  A Sun SPARC binary executable program
  PC Binary:     KERMIT.EXE 197928 bytes  An MS-DOS binary executable program
  Precompressed: KERMIT.ZIP 238584 bytes  A compressed ZIP archive

Table 2 shows the figures for transferring all four files with each of the four protocols on same direct connection used for Table 1. In this and the following tables, the secs column shows the elapsed time of transfer in seconds, the cps column shows actual file characters transferred per second, and the eff column shows the percent efficiency (file characters per second divided by the connection speed).

Table 2:  X- Y- and ZMODEM vs Kermit on a 19200-bps Direct Connection

              XMODEM          YMODEM          ZMODEM           KERMIT
File Type     secs  cps  eff  secs  cps  eff  secs  cps  eff   secs  cps  eff 

ASCII Text      89 1549  81%    76 1814  95%    73 1889  98%     69 1999 104%
UNIX Binary     15 1638  85%    13 1890  98%    13 1890  98%      9 2648 138%
PC Binary      127 1558  81%   109 1816  95%   107 1850  96%    100 1979 103%
Precompressed  153 1559  81%   133 1794  93%   130 1835  96%    129 1849  96%

Table 3 shows the results for a local-call dialup connection using Telebit T3000 modems, V.32bis modulation (14400 bps), V.42 error correction, V.42bis compression, RTS/CTS hardware flow control, and an interface speed of 57600 bps. The efficiencies in this table are based on the modem's 14400-bps connection speed, and therefore also reflect the modem's compression methods.

Table 3:  X- Y- and ZMODEM vs Kermit with High-Speed Modems

              XMODEM          YMODEM          ZMODEM           KERMIT
File Type     secs  cps  eff  secs  cps  eff  secs  cps  eff   secs  cps  eff 

ASCII Text     221  624 43%     79 1746 121%    42 3283 228%     39 3535 246%
UNIX Binary     32  768 53%     13 1890 131%    15 1638 114%      3 8192 569%
PC Binary      346  572 40%    129 1534 106%    83 2385 166%     80 2474 172%
Precompressed  500  477 33%    208 1147  79%   149 1601 111%    148 1612 112%

Lieutenant Colonel John F. J. Allen, MBE
Royal Logistic Corps, UK Army, Andover, Hampshire, UK

Once the political decision was taken for British participation in the United Nations relief mission to the former Yugoslavia, preparations for deployment began in earnest. For the Army Logistic (G4) area, this meant the responsibility for supply and equipment management support to the United Kingdom force deployed in Bosnia.

Accountability and total asset visibility of consumables, stores, and spares would be vital to the UN mission in the relief areas. The requirement became evident: to establish a system of adequate controls for asset tracking and in-transit visibility from point of despatch in the base area to the receiving distribution point in theatre--a logistic-support asset-tracking system. With such a plethora of commercial systems available, neither the hardware or software solutions were insurmountable. But selection of communications and file transfer protocols would require careful consideration.

No current computer system specifically addressed storage and distribution commodity tracking, although progress was being made in a number of related areas that would integrate in later years to provide in-transit visibility of assets. Provision was made within the ICL 3900 Series mainframe-based Stores System accessed through an online information system, and other operational and administrative information systems, to link demands to issues, and track containers in the logistic pipeline.

No further visibility was currently available beyond this. Future fourth-generation information systems were also under development, but those components that would link issues to freight consignments to support asset tracking were not to be in service in the immediate future.

Our aim was therefore to produce an overarching mantle system in support of humanitarian missions in Bosnia, based upon a central data repository with information access points across the supply and distribution chain. The system would address the requirement of the British contingent on United Nations relief work, presenting visibility of items from source to destination. It would achieve the resupply operation as economically as possible and with a more effective, efficient method of control.

The system presupposed a central distribution point in the Theatre of Operations and the despatch of items for the relief operation to the forward areas in the former Yugoslavia from single points of departure in the Base or Forward Depots in the United Kingdom and Germany.

The asset tracking system would require a database using data captured at issuing depots and at various points in the distribution chain. Data on commodity visibility would then be drawn from the system, through communications links at the source, transit points and destination, with the ability to generate reports and produce meaningful data on location, content, quantity and status.

The solution, within the limitations of the time permitted, was found by developing an operational prototype, followed by a two-phase development, from initial research and development undertaken within the aegis of a peripheral peacetime project. Project VITAL (Visibility In Transit Asset Logging), was therefore highjacked and harnessed to our needs in support of the UN operation.

Procedures were put in place to enable information gathering and to advance and modify relevant aspects in the prototype development to satisfy the urgent operational requirement. At this stage, after comparison with proprietary commercial software, Kermit was identified as the proper solution to our file transfer, network protocol, and terminal emulation needs, linking the entire spectrum of the project operation, from mainframe, minicomputer, PCs, to handheld devices and barcode readers.

Once the decision was made to proceed, funding was negotiated and development proceeded in two distinct phases: (1) the basic system that can be put in place quickly, and (2) aspects of the system that would require more investigation and analysis.

PC access points to the system, using IBM-compatible 386 SX PCs with printers and necessary software, were installed at multiple locations along the supply and distribution chain to the forward bases that had been established in Bosnia.

The profile of the system envisaged a central computerised repository of commodity and transit data, hosted on a UNIX-based ICL DRS 6000 machine, drawn from existing logistic information systems, this information being accessed and supplemented at nodal points along the logistic pipeline, and at operational or logistic Command and Control (C@+<2>) Headquarters, using Kermit and data communication links to provide the required visibility.

The heart of the system is a relational database, situated at the Directorate of Logistic Information Systems, in the county of Oxfordshire, that draws information from the Stores System mainframe, and data from the VITAL input devices.

The system is linked on a network by line or Hayes-compatible modems through national and international ISDN telephone and through INMARSAT-C satellite communications, through the British Isles commercial communication hub in Cornwall in the South West of England. Each access point has a PC, enabling each station to interface to the data repository through the network.

Handheld Tandy-Grid (US model 2350) electronic palm-pad data input devices with inductive pen contact and character recognition on touch-sensitive screens, again using MS-DOS Kermit loaded on SUN RAM disks, are in use along the logistic pipeline, allowing electronic download of data through the PCs, or direct over the communications links, to the central database, and data retrieval, screen and report printing at each access point.

Verification is carried out on-line with Kermit file transfer and terminal emulation, to the stores system to complete the loop on the status of the commodities. The system is able to operate in either direction.

The system tracks the progress of commodities, as single items or as part of larger consignments, along the pipeline, by air, road, rail, or sea routes, and may also be applied to postal despatch of items. Items are identified through a designator code, to combine with transit information, to allow visibility of progression along the pipeline through to the troops deployed on relief convoy work.

The development software to support the immediate urgent operational requirement was in service during November 1992, with Phase 1 work complete in December 1992. Communications links and user software were successfully tested over line and satellite and the prototype system went live in December 1992, with Phase 2 completion due in 1993. Links for air freight are being developed and have been established with the Royal Air Force (RAF) and civil airline air cargo systems.

We hear daily of the huge amounts of food and aid brought into the besieged areas of the former Yugoslavia, and we have a successful system, proven in an operational environment, that has now come of age. Further developments will see direct satellite communication to and from relief convoy escort vehicles, and integrated information and communications systems--and at their heart lies Kermit.

The verdict: We have been most impressed with Kermit in all its forms, especially with the support, versatility, the ease of use, and lack of problems. We were not previously aware of its potential and capabilities, but now we are adapting it in several other systems and extending its use amongst diverse information areas.

A very big thank you to the Kermit team at Columbia University in New York City, who most generously cooperated on the project, giving consultancy during a whistle-stop visit to New York, including rapid development of prototype scripts for automated connection establishment, authentication, and data transfer, and their continued help desk support and further software upgrades.

The author, Lieutenant Colonel John F. J. Allen, MBE, is a career officer in the UK Army in the newly formed Royal Logistic Corps, responsible for Logistic Support Information Systems Policy and Strategy currently serving at the Ministry of Defence Logistic Headquarters in the South of England.

Gisbert W. Selke
Ermekeilstraße 28
D-5300 Bonn 1, Germany

• Re-unification of East and West,
• the advent of umlaut-preserving file transfer,
• and a German MS-DOS Kermit book.

While there is no direct causal connection between any two of these, they are not altogether unrelated either; so let's look at each of them in turn.

First, re-unification. After nearly 50 years, the Iron Curtain that separated the Western 75% of the population from the Eastern 25% has at last been taken down. Everyone will have read in the papers about this, so we won't go into the details here; just let me say that it feels great to be able to see my relatives drüben (over there) whenever I want.

Apart from my personal feelings, however, there is one aspect that has, in fact, to do with computing and, more specifically, with Kermit: the computer market, both private and business, is a hot spot in the region commonly referred to as the "5 neue Länder" (or 5NL, for short, although Americans might prefer the colloquial "Neufünfland").

And so is the telecommunications market. While telephones have been hard to come by previously, the German PTT is bustling to bring the telephone net up to standard, for which there is an enormous need.

Together, these factors have created high demand for computer communications. The 5NL universities have joined the Internet, and private mailboxes (BBS's) are mushrooming. For many purposes, telefax is the service used heavily between the two parts of Germany, but there are also many companies that have to exchange data between their Western head offices and their Eastern branches (note the asymmetry here!).

Since currently the Eastern phone net is still in deplorable shape in many places, a reliable, yet fast file transfer protocol is needed. Of course, it should be easily adjustable to take advantage of improving conditions; it should be able to handle those funny characters (like ä and ß) that Germans seem to like so much; and implementations should be easy to handle, since you wouldn't want to employ a computer scientist just for this purpose.

Sounds familiar? Yes, there we are: Kermit fits the bill nicely. So, somewhat unexpectedly, we have a whole new market for Kermit software. And this extends to other parts of Eastern Europe as well: since I'm giving a hand with Kermit promulgation on this side of the Atlantic, I have noticed a considerable demand for Kermit software from Poland, Czechoslovakia, and even as far as Kazakhstan, when it still was a part of the Soviet Union.

Kermit and German Text

For decades, computers have been made by English-speaking people for English-speaking people. But German, like many other languages, has special characters that do not fit into standard 7-bit ASCII code (which, after all, is the American Standard Code for Information Interchange).

So, various manufacturers have looked for ways to circumvent this. One way of doing this -- with the ISO's blessings -- was to scrap the braces, brackets and so forth and use their character positions for the umlaute. This was widely accepted; but what if you needed those braces?

Your beautiful C programme, when printed on a germanicized printer, might look like this:

  if ((a==1) öö (a==9)) ä
       printf("Grüße aus KölnÖn");
  ü

  if ((a==1) || (a==9)) {
      printf("Gr}~e aus K|ln\n");
  }

Not what you intended, either... And no way around it. With the advent of the IBM-compatible PC, a different standard emerged, which at least preserved normal ASCII as well as many European special characters. The Macintosh, of course, was different. And of late, Windows has yet another conception of the special characters. You are not, of course, surprised to hear that MS-Windows NT is almost entirely unlike the others.

As time went by, we gained some proficiency in deciphering on the fly. Depending on the machine you'd work with, you'd know what key (or sequence of keys) to type to get the desired letter. What, however, if you had to exchange files between different platforms? Let me recall one early day in the WIdO (Wissenschaftliches Institut der Ortskrankenkassen), where we had been running a Modcomp MAX IV as a host computer for years, and the first PCs arrived and were wired up as terminals over the serial line. Boy, were we happy to have found MS-DOS Kermit 2.28 to transfer files in the first place! But then we sent an ordinary (or so it seemed) text file from a PC to the host. For the greater part, all went well; but some characters were missing, and strange runs of repeated characters could be found in places.

The explanation turned out to be simple: characters with their eighth bit set were a special MAX code used for a simple run-length encoding. Annoying, yes; and although it was easy to write a programme to convert the umlaute to braces and brackets, Murphy's Law tells us that you would forget to use this filter on none but the largest files...

Today, all this is gone. Using MS-DOS Kermit, I can easily configure my "terminal" to display braces as umlaute: SET TERM CHAR GERMAN! Or, to show them as braces, SET TERM CHAR LATIN1, as would be used with a host employing an ISO 8859-1 character set (which, incidentally, is also used by MS-Windows). Our secretaries no longer have to remember to hit '[' when they want 'Ä' to be printed -- some progress! Or, when I connect to an IBM VM/CMS mainframe (an EBCDIC machine), accidentally hitting one of the umlaute on my PC keyboard tended to wreak havoc on the connection. Nowadays, I have a few commands like:

  SET KEY Ä Ae

File transfer, too, is no longer a problem. On our UNIX host, we use C-Kermit; sending a file to the MAX host, we can SET FILE CHAR LATIN1, SET TRANSFER CHAR ASCII, and SET LANGUAGE GERMAN, and all the umlaute are converted automatically to braces, etc., on the fly. As I write this, the old MAX IV host is being taken down and replaced by a MAX 32; and here's another advantage for us: no more serial links at 9600 or 19200 bits per second, for now we've got an Ethernet! And, surprise, Kermit supports LANs, too; no need to change to any other Telnet terminal emulation programme, no need to give up Kermit's speed, easy configurability and robustness.

There was even a story about a user who wanted to convert a German text file from PC standard to the newer Windows standard. So he started Windows, ran MS-DOS Kermit in two different windows, hooked up COM1 and COM2 with a null-modem cable, SET this, SET that, and off he went, communicating with himself, so to speak, but transliterating the file in the process. This story was related at a Rhineland Karnival session, so take it for what it's worth...

Kermit auf Deutsch

Fortunately, Chris Gianone had written an excellent book on MS-DOS Kermit; not just a manual, but a gentle introduction into terminal emulation and file transfer. While she was taking this book to its second edition, covering all the new features since MS-DOS Kermit 3.0, she was looking for foreign-language publishers as well. And we made it -- a publisher known for high-quality magazines and books on all aspects of computers and electronics proved to be interested, indeed. Nearly in parallel to Chris's writing the second edition, I prepared the German translation, so the German book appeared on the market barely three weeks later than the American original. The representative of the American publisher couldn't quite conceal his astonishment when presented with the German translation at the October 1991 Frankfurt Book Fair, and our German editor took some pride in this -- rightly so! By the way, all the queries and last-minute corrections between Chris and myself were done using Kermit software (making Kermit a recursive application?).

At 69 marks, MS-DOS-Kermit -- das universelle Kommunikationsprogramm includes the official Kermit distribution disk with all the text files translated into German. To my knowledge, this is the first book on the German market to cover computer communications at this scope, and the sales figures show that it fills a need: it is selling well, so get your copy before they are sold out! -- OK, don't panic... the second printing has just hit town. (Which shows that the book is more successful than had been anticipated by the publishers themselves.)

Hold the presses! Here we go again: Frank da Cruz and Chris Gianone have collaborated on a magnificent book on C-Kermit. C-Kermit runs on an amazing variety of machines whose least common denominator is just the existence of a C compiler. It's a natural for all those UNIX machines, of course; but it also runs on... no, wait, I'm not going to bore you with a list several pages long. Why not browse your friendly local book-seller's shelves? You say you're living in Austria (the one without kangaroos) and you don't exactly fancy manuals in English? No problem: the German translation is underway right now, and you'll be able to pick it up at the Frankfurt Book Fair in early October. And, lest I forget: if, by "manual", you mean "dreary and unreadable," you're dead wrong. Were it otherwise, I wouldn't have translated it. I can't stand boring books.

Let me mention a final point that is often overlooked. Kermit software has the greatest user support I have ever seen. This shows in fast response to (even minor) complaints, in lots of care spent on the fine points, and, of course, in the concern given to the non-standard user. Among these, I count the non-English speakers, but also those with visual, auditory or physical challenges. This concern does not go without saying in today's computer market; and, speaking for the non-English people at least, I'd like to say thanks to Frank da Cruz (who started it all, and who spends a lot of time on C-Kermit), to Chris Gianone (who keeps it all running and whose book is terrific) and to Joe Doupnik, whose programming skills I won't even mention, but whose wit and understanding have proven invaluable over all those years since I first got in touch with MS-DOS Kermit version 2.28.

Quanfang Zhang and Jijiao Zheng
Department of Computer Science and Engineering
Zhejiang University, Hangzhou, China

Today, Kermit has spread all over the world and has been implemented in many computer systems. Quietly, it arrived in China and was adapted to many Chinese-version operating systems. You can see more and more computer specialists and users using Kermit to transfer files or connect a local computer to a remote host in Chinese universities or institutes. Kermit is now a popular topic for discussion among people who are engaged in computer communications.

As teachers in the Department of Computer Science and Engineering of Zhejiang University, we are very interested in computer networks and communications. We began to study Kermit at the end of 1988, when our Computer Network Research Laboratory was entrusted with designing the Zhejiang University campus computer network (ZUnet). In the first stage of development, we planned a network system based on a PBX. We found it very difficult to design such a network because many computers, distributed in all departments and administrative offices and running many different operating systems, would be connected by ZUnet.

Fortunately, we found the article written by Frank da Cruz and Bill Catchings in BYTE magzine and realized that Kermit was just what we were looking for! After receiving tapes containing all Kermit programs and documents from Columbia University, we wrote I/O driver routines for the Data/Voice integrated communication adapter, a powerful network card used in ZUnet that handles data and voice simultaneously. Then we modified MS-DOS Kermit 2.32/A and C-Kermit 4E to make them run on ZUnet. Because CC-DOS (the Chinese version of DOS used in IBM-PC and its compatibles) is widely used in ZUnet, we also modified MS-DOS Kermit 2.32/A for Chinese DOS and named it CC-Kermit 2.32/A [On Tape C].

Kermit and Chinese DOS

We converted MS-DOS Kermit 2.32/A to CC-Kermit 2.32/A, a Chinese Kermit, which can run on MS-DOS and most versions of CC-DOS. Explanations and prompt messages are displayed in Chinese when it runs on CC-DOS. This is very important for the popularization of Kermit in China, as many users do not learn much English. When it runs on MS-DOS, CC-Kermit is the same as MS-DOS Kermit 2.32/A.

Chinese character codes are defined by Chinese Character Set for Communication and its Exchange Codes, GB2312-80. The size or resolution of a Chinese character displayed on the screen can vary. There are 16#*#16, 24#*#24, 32#*#32 and 48#*#48 dot matrices, depending on the CC-DOS and graphic adapter versions. We modified the display and keyboard input modes of Kermit for various display sizes, such as 11, 17, or 25 lines per screen.

Kermit at Zhejiang University

Kermit plays an important role in ZUnet. There are over 60 computers in ZUnet distributed in 12 buildings. ZUnet makes use of the existing telephone system; each computer is equipped a Data and Voice integrated adapter with data transfer at speeds up to 19200 bps. ZUnet is a low-cost but useful system. It provides file transfer, eletronic mail, database retrieval, terminal emulation, and remote job entry.

Users can exchange e-mail internally and with CAnet (China Academic Network), and we are connected by Kermit to a host in Beijing for international electronic mail. Computer specialists consider ZUnet an economical, useful, and efficient campus network, well-suited to universities and institutes of China.

Kermit in China

Papers about Kermit have been published in many Chinese computer magazines. including an article by us, Kermit Protocol and its Programs, presenting the background, development, running environment, functions, and protocol of Kermit, published in Chinese Data Communications, No.2, 1991.

Kermit has already played an important part in China, especially in Zhejiang University. We are sure that it will be recognized by more and more computer users and become their good friend. Kermit makes complicated things simpler and longer distances shorter. We hope to make and keep contact with other Kermit developers and work together for the development and populization of Kermit.

We would like to express our sincere thanks to Christine M. Gianone and Frank da Cruz for their protracted support and guidance to us. Without their help, our ZUnet could not have been put into working order in such a short time.

Robert Clark
Joint Computing Unit, Institute of Neurology,
University of London, Queen Square, London

The Institute of Neurology is a postgraduate medical research Institute of the University of London, closely linked with the National Hospital for Neurology and Neurosurgery and an internationally renowned centre for teaching and research in neurology and the neurosciences. The Institute of Child Health is responsible for research and teaching within the field of child health and paediatric sub-specialities, and is closely associated with the Hospital for Sick Children at Great Ormond Street. Since the two institutes are next door, a Joint Computing Unit was formed to look after the information technology needs of academics, medical researchers, clinicians, scientists, administrative and library staff. It is in this heterogeneous environment that Kermit has proved to be a most versatile and valuable tool.

Initially the predominant use of Kermit was for mainframe access via Packet / Assembler / Disassemblers (PADs) linked to Britain's X25 Joint Academic Network -- JANET. Kermit was also used extensively for micro-micro file transfers. In the days of CP/M, every machine seemed to differ with respect to disk format, and Kermit liberated data. Even when Kermit did not exist for particularly idiosyncratic machines, we still could use it for data transfers.

For example, we had to replace several dozen hard-disk Z80 machines with a multiuser operating system (TurboDOS) for which there was no Kermit [There is now! -Ed.]. Fortunately TurboDOS had a hex dump and a CP/M batch capability. We replaced dumb terminals connected to TurboDOS machines with PS/2s running Kermit. LOG SESSION was used to capture directory listings from the TurboDOS machine which were then processed to produce a BAT file with a series of dump commands. This was TRANSMITted to the TurboDOS machines into a WordStar document and saved. The BAT file was then executed and LOG SESSION was used to capture the hex dumps. A small BASIC program converted the hex back to binary. In this way several years and megabytes of medical text and data were rescued from oblivion.

Another useful role of Kermit has been in the area of data capture. Many of the departments have medical data acquisition apparatus that produce ASCII data on a serial line. Establishing the appropriate communications parameters (baud rate, number of bits, parity, etc.) is easy with Kermit, as you can make changes until you see what looks sensible on the screen. Having established parameters, Kermit then becomes a production tool, using LOG SESSION to capture data for subsequent analysis. Typical of this is our Neuropathology Department who use a light pen with digitising apparatus to trace around the inner and outer circumferences of cross-sections of cells photographed on an electron microscope. The aim of this is to determine the thickness of the cell walls, as with the progression of neurological disease, cell walls get thinner. An analysis of the distribution of the thicknesses of cell walls from a representative sample gives a prognostic indication. Kermit captures the data with LOG SESSION for subsequent analysis by statistical packages.

On a more general level, Health and Safety Regulations require all departments to check laboratory apparatus for electrical safety on an annual basis. The checking apparatus is attached to a Toshiba portable; data is captured by Kermit for subsequent print-out back at base.

In addition to research and laboratory work we use another feature of Kermit--the script capabilities--for administrative purposes. We have a number of X.25 PADS and two X.25 switches that need detailed and longwinded configurations. The configuration on these devices is held in battery-backed RAM on a loader board. From time to time these boards fail and over one hundred lines of configuration parameters must be reentered. The configurations are now kept as Kermit scripts which reduce reconfiguration from a couple of hours to a couple of minutes. In a similar way, a Kermit script running on a PC plugged in to a VAX as a console allows us to automate "standalone backups." Manually typing in standalone backup commands was a time-consuming and potentially dangerous operation as the VMS DCL procedural language is not available in standalone mode.

Kermit and AIDS Research

At birth, CD4 count is relatively high; it rises further to peak at about 6 months before tailing off slowly to adult levels. The department is currently developing age-related standards for CD4 counts using blood samples taken from children from the study who were subsequently found to be uninfected. To create the curves the data is analyzed by being "chopped" into intervals and deskewed within each interval. This transformed data is then plotted in Tektronix emulation and curves are fitted.

How does Kermit help? Developing the curves becomes an interactive, iterative modelling process. A program has been written that allows suitable intervals to be chosen and entered into a VT320 screen, standard deviations are calculated and plotted by toggling the screen into Tektronix mode; if the curve is of interest it is saved for hard-copy laser printing, the screen is then toggled back to VT320 for the next set of intervals to be entered. An example of such a curve is shown in Figure 1. The X-axis shows age in days and the Y-axis shows the CD4 count. Each curve is a centile at the 3%, 5%, 25%, 50%, 75%, 95% and 97% intervals, reading from bottom to top. Thus 50% of non-infected children should have a CD4 count of about 3.2 at age 200 days.

Figure 1 Age vs CD4 Count

These curves were recently presented at a workshop on Measurement and Use of CD4 and Other Lymphocyte and Immunophenotypic markers in Pediatric HIV Infection, organised by the National Institutes of Health in Washington DC (October 1992).

And Now, TCP/IP

Although being part of the Internet is, to say the least, exhilarating, we found products such as PC-NFS difficult to configure and the TELNET terminal emulators rather limited. The recent TCP additions to Kermit and the sheer readability of the parameters in an MSKERMIT.INI file has moved us from a situation of struggle to a situation of load and go, whereby we can bring new connections on stream in a matter of minutes. Finally, we have adapted the excellent dial-up script supplied with Kermit 3.11 to set PC e-mail lists that interface through the e-mail capability of C-Kermit on various UNIX hosts. It looks as though we will be using Kermit well into the next millennium.

Grateful acknowledgement to Angie Wade and David Dunn, Department of Epidemiology and Biostatistics, Institute of Child Health, University of London and to Peter Sacares, Statistician, Institute of Neurology, University of London.

Buz Overbeck, President
Grief Resource Foundation, Dallas, Texas, USA

Selecting software for a new nonprofit organization can be very challenging! Unlike most large corporations, whose budget allows the purchase and/or evaluation of large expensive packages, nonprofits, unless extremely well funded (a rarity), seldom have the money to buy many large packages, nor the name recognition to receive evaluation copies from vendors.

The Grief Resource Foundation falls into this category. Our funding comes from the sale of our publications and services, grants, and donations. The funding we receive is plowed back into the research and development of new services, with little left over for software. Like many nonprofits, we pay all of our bills on receipt which means we have no credit history. This alone disqualifies us from a corporate account at, say, Egghead Software, which would be very useful to us.

My fundamental approach to software selection is to find the most cost-effective solution to our applications needs. If there exists free software that will do the job, we use it. If not, we look at shareware. If only a commercial package will do, we'll write the company and ask that the package be donated. If all else fails, we'll buy it.

One application of great importance to us is telecommunications. One of our functions is to provide resources and information to health care professionals and the public. So it's crucial that we are on top of what's going on in the areas of grief, loss, death and dying specifically and the mental health care field in general.

Software selection, in this case, was easy. We chose Kermit! With Kermit we can connect to the many different online resources available, find others in our field, and exchange information with them.

Although there are shareware and commercial packages which can (probably) do the same thing, for us, Kermit is the logical choice for the following reasons:

1. Kermit is inexpensive both in terms of cost and hardware resources.
2. Kermit is what Esperanto was supposed to be. Everyone speaks it. This is really important as we connect to a variety of systems including Library Bibliographies, File Servers, Bulletin Board Systems, and Commercial Databases. In other words, at any one time we may connect to a micro, mini, or mainframe computer where Kermit is the only common denominator.
3. Kermit is now "Competitive". When I first used Kermit, I had trouble adapting it to the micro world of BBS systems due to the lack of documentation in this area. For that reason, I almost passed on Kermit for the Foundation. But then came Using MS-DOS Kermit by Christine M. Gianone. That changed everything. Here, in one place, was the answer to almost every concern I had. No more excuses.

So, we adopted Kermit. This decision allowed us to put the money budgeted for an expensive communications package to better use. Since then, we've become pretty Kermit-literate. So far, I haven't found anything that Kermit can't do or be taught to do.

And for telecommunications at the Grief Resource Foundation, Kermit is the package of choice. I only wish that other application solutions were as obvious.

The TIES That Bind

  +++ATH0

The good news: It won't happen during a Kermit file transfer. All the popular Kermit software versions, including the current releases of MS-DOS Kermit, C-Kermit, Mac Kermit, and IBM Mainframe Kermit are TIES-resistent. (Or should we say, TIES-compliant?)

Internal PC Modems

C-Kermit 5A, written by Frank da Cruz of Columbia University, is the result of a massive three-year effort that also involved countless experts in UNIX, VMS, OS/2, AOS/VS, and other operating systems and their legion variants and releases. The list of contributors to its development takes up five pages in Using C-Kermit! To list only a few:

Chris Adie (Edinburgh U, Scotland), William Bader (Software Consulting Services, Nazareth, PA), Fernando Cabral (Padrão IX, Brasília, Brazil); Joe R. Doupnik (Utah State U); Stefaan Eeckels (Statistical Office of the European Community, CEC, Luxembourg); Kristoffer Eriksson (Peridot Konsult AB, Orebro, Sweden); Marcello Frutig (Catholic U, São Paulo, Brazil); Hirofumi Fujii (Japan National Laboratory for High Energy Physics, Tokyo); William Glass; Andy Fyfe (Caltech); Eugenia Harris (Data General); Charles Hedrick (Rutgers U); Christian Hemsing (Rheinisch-Westfälisch Technische Hochschule, Aachen, Germany); Terry Kennedy (St Peter's College, Jersey City, NJ); Lawrence Kirby (Wiltshire, UK); John Klensin (MIT); Tom Kloos (Sequent Computer Systems, Inc.); Bo Kullmar (ABC-Klubben, Stockholm, Sweden); David MacKenzie (Environmental Defense Fund, U of Maryland); Fulvio Marino (Olivetti, Ivrea, Italy); Peter Mauzey (AT&T); Bruce J. Moore; Paul Placeway; Kai Uwe Rommel (Technische Universität München, Germany); Jay S. Rouman (U of Michigan); Friðrik Skulason (U of Iceland, Reykjavik); Lee Tibbert (DEC); Warren Tucker (Tridom Corp, Mountain Park, GA); Konstantin Vinogradov (ICSTI, Moscow, Russia); Eduard Vopicka (Prague School of Economics, Czechoslovakia); Stephen Walton (California State U at Northridge); Jamie Watson (Adasoft, Switzerland); Rick Watson (U of Texas); Patrick Wolfe (Kuck & Associates, Inc.).