KERMIT - Error Free File Transfers with Non-Alpha Computers by Bob Rubendunst, Soft Machines If you have ever needed to transfer files between your Alpha Micro and some other brand of computer, you know that file transfers between unlike brands of computers are NOT easy. Most communications packages, like my DYALOG product, provide a way to send and receive information with other brands of computers. However, because the non-Alpha equipment probably does not support the same file transfer protocol, the file transfer can be spoiled by telephone line noise, particularly on longer distance link-ups. A file transfer protocol is a process with its only goal being the sure communication of information from one point to another. Just as different programmers can write different programs to solve the same problem, different protocols can both communicate the same information, but in entirely different formats. There are many reasons why file transfer protocols are different between brands of computers and even for products that run on the same machine. Standards in the computer industry have been slow to develop because of the speed at which the computer market moves. Telecommunications is exploding as people find new, slick solutions to old and new problems. Both software and hardware vendors frequently exhibit the "NOT INVENTED HERE" philosophy of "Well, if we didn't do it, it must not be any good". It takes much more time and many more resources to develop a file transfer protocol than to just market the program that uses it. Also, writing a proprietary product locks in a vendor's customer base. All of these things have stifled the development of a standard. One standard that did develop was the XMODEM protocol in the CP/M computer field. It was developed by Ward Christensen of the famous Chicago area Computer Bulletin Board System. While XMODEM worked fine for CP/M systems, it was not well suited to other kinds of computers, and it was not defined well enough to guarantee compatibility between different implementations of XMODEM. This summer, I discovered KERMIT through a conversation with a client. KERMIT is a universal protocol that was developed at Columbia University to allow the various micro computers at Columbia to trade files with their big mainframe computers. Bill Catchings and Frank da Cruz of Columbia developed this protocol in 1981, with the help of other colleagues at Columbia and other research facilities. Columbia has been nurturing it since that time. KERMIT is named after the famous reporter, Kermit the Frog, on the MUPPET SHOW. The name Kermit is used by permission of Henson Associates., Inc. At the beginning of a file transfer, the local and remote KERMITs tell each other what they expect and can handle in the way of communications. This enables KERMITs to communicate with a wide variety of computers. KERMIT is a great protocol because it is very flexible and well structured. Even the manner in which improvements are added to the protocol has been done in such a way that future versions of KERMIT will be fully compatible with older versions. KERMIT is a good concept beautifully executed. KERMIT sends files from one computer to another by breaking down the procedures and the data in the file into packets. KERMIT sends packets one at a time, and then waits for the remote KERMIT to acknowledge that it has correctly received a procedure or data packet. The acknowledgement will only be sent if a check field contained inside each packet is correct. In this way, errors can be detected and packets can be re-sent until the packets are transported without error from system to system. To make sure that as many people as possible should enjoy the benefits of KERMIT, Columbia's policy on distributing KERMIT is that KERMIT must not, and should never, become a commercial product, sold for profit. Its goal is to promote communication and sharing, and KERMIT itself should be freely shared, and not sold. I am donating KERMIT to AMUS. The donation will consist of source code and documentation for Alpha-Kermit, which I have developed from a C language version of KERMIT that I obtained from Columbia this fall. I am giving all members of AMUS permission to use KERMIT for free, provided that they follow the non-profit guidelines that Columbia has established. I will also give AMUS versions of KERMIT for IBM, DEC, Radio Shack, CP/M and Apple computers that I obtained from Columbia. I also invite YOU to add additional features to Alpha-KERMIT. I would suggest that motivated individuals leave some announcement of their plans on the AMUS bulletin board to prevent unnecessary duplication of effort. The reasons for donation are simple. There is a real need for a universal file transfer method, so that information can be shared. Being the lazy sort (aren't all programmers lazy?), I'd rather write one program everybody in the AMUS community could use instead of fifty. Also, it's a good way to say thank you to all of the people in the AMUS community. If you are puzzled as to why I am giving away KERMIT when I sell DYALOG, I think that KERMIT will enhance the market by generating more interest in telecommunications. Here then, is a description of how to use all of the commands that Alpha-KERMIT has. How to Use Alpha-KERMIT To use KERMIT, you must have a copy of KERMIT.LIT on your DSK0:[1,4] account. (You may have to create this program file by running the M68 program on KERMIT.M68.) You must also be running AMOSL version 1.2 or later. Currently, there is no version of Alpha-KERMIT for the older WD-16 version of AMOS. You must know the name of the TRMDEF you wish to use with KERMIT. For example, the TRMDEF for your modem may be called MODEM1. Enter the KERMIT command, followed by the name of the TRMDEF you wish to communicate with. For example: KERMIT MODEM1 is the command line you would enter to communicate using the MODEM1 TRMDEF on your system. If the TRMDEF you have chosen is currently in use by another job, you will see this error message: ?TRMDEF is assigned to another job. If the TRMDEF is available for use, you will see the prompt: Alpha-KERMIT > which means that KERMIT is awaiting your next command. Currently, the commands are: AMOS - drop back to AMOS temporarily. CONNECT - converse with the modem or remote computer. EXIT - finish your Alpha-KERMIT session. HELP - display helpful information. RECEIVE - receive a file from the remote KERMIT. SEND - send a file to the remote KERMIT. SET - change a KERMIT parameter. SHOW - display the parameters in use now. Here is brief description of what each command does: AMOS is used to temporarily leave KERMIT so that you can TYPE a file, or get a directory listing. You must re-enter KERMIT to end the communications session and free the communications channel for other users. AMOS takes no arguments. CONNECT is executed when you want to send and receive characters between your CRT and the modem or the remote computer. If you are using a "smart" modem, you can send the modem the commands to dial the remote computer. When CONNECT is executed, it shows you the key you need to press to end the CONNECT session. When the CONNECT session ends, you may enter another KERMIT command. CONNECT takes no arguments. EXIT is the command you execute to end your KERMIT session. This frees the communications TRMDEF so that others can use it. EXIT takes no arguments. RECEIVE is used to receive a file from a remote computer. Before using the receive command, you must make sure that the remote computer has executed the TRANSMIT command. If you are operating KERMIT at the remote site, you must enter the TRANSMIT command during a CONNECT session, then press the ESCAPE key to enter the KERMIT command mode. You may then enter the RECEIVE command. You may enter the name of the file as it is to appear on your system. If you just enter RECEIVE, the filename specified by the remote KERMIT will be used as the filename. SEND is used to send a file to a remote KERMIT. Before issuing the SEND command, you must make sure that the remote KERMIT has been given the RECEIVE command. (You do this by using the CONNECT command, and then "escaping" back to the Kermit prompt. SEND requires the name of the local file you wish to send to the remote system. SET is used to change options concerning the communications. SET requires an argument, which consists of the name of the option you want to change, followed by a logical operator. The argument may be YES or NO, TRUE or FALSE, or 1 or 2, depending on the option you are changing. If you are not sure of the required logical operator for an option, enter SET, and the option you wish to change, and the valid logical operators will be displayed for you to choose from. SET BELL ON dings the bell every time the KERMIT prompt is displayed. SET BINQUOTE allows you to change the binary quote character. The binary quote character allows binary file transfers over seven bit data lines. You must specify the new binary quote character. Normally, KERMIT uses & as the binary quote character. SET BLOCKCHECK 1 sets KERMIT for 1 byte checksums, the default. SET BLOCKCHECK 2 sets KERMIT for 2 byte checksums. SET DEBUG ON Turns on display of packet operation. SET DEBUG OFF Suppresses packet operation display. SET DUPLEX ON Allows full duplex operation. SET DUPLEX OFF Allows half-duplex operation. SET ENDLINE lets you change the default end of packet character from carriage return to something else. SET ESCAPE lets you change the character that you must press to leave the CONNECT command. For example, SET ESCAPE ^G would change the ESCAPE character to a control-G. This defaults to a caret symbol. SET RETRIES lets you change the number of packet retries attempted before KERMIT aborts a file transfer. The default is ten tries. SET TIMEOUT changes the number of seconds that elapse before a packet is re-transmitted. SHOW displays all of the options that can be adjusted in KERMIT, plus some additional parameters about the current communications session. For a more complete description of Alpha KERMIT, see the file KERMIT.DOC on the AMUS computer. It has been adapted from other KERMIT manuals from Columbia University. So far, I have used Alpha KERMIT to communicate with IBM-PC and Alpha Workstations. Thousands of medical records have been moved to a new computer using KERMIT. Here is a benchmark for comparing how quickly Alpha-KERMIT can send files from one location to another. The file sent is AMOSL.MON version 1.2(96), if you want to compare it to another communications package. I have compared it to DYALOG here. File: DSK0:AMOSL.MON[1,4] version 1.2(96) Size: 27222 bytes, binary file Baud rate: 2400 baud Transfer times for AMOSL.MON[1,4] DYALOG 2.0 : 126 seconds, effective baud rate of 2160 Alpha-KERMIT : 263 seconds, effective baud rate of 1135 As you can see, KERMIT is not very fast. Nor can it send random files. But KERMIT is fantastic for sending files to machines previously untouchable. I wish to thank Columbia University and the other people who have donated KERMIT programs to Columbia. Thanks to Barry Hamilton for reading the mag tape from Columbia. Enjoy! Glossary JCB - Job Control Block. Used to access & control job related resources TCB - Terminal control block. Used to access & control terminal resources Kermit Packet Types Type Name Function ---- ------------ ----------------------------------------------------- S Send-Init Sends local Kermit Parameters to remote Kermit Y Acknowledge Receiver verifies reception of packet Y (Acknowledge) Returns Kermit parameters to instigating Kermit F File Header Contains name of file to be transferred D File Data Contains a portion of the data file contents Z End of File Signals receiver that all data file contents sent B Break Signals receiver to conclude file transfer (batch) N Negative Ack. Signal that receiver didn't get or like last packet E Fatal Error Signal that other Kermit cannot proceed normally ALPHA MICRO KERMIT Program: Bob Rubendunst (Soft Machines) Language: M68 (Alpha Micro 68000 assembler) Documentation: Karen Bojda (Soft Machines) Version: 2.0(24) Date: March 16, 1994 Alpha-Kermit capabilities at a glance: Local operation: Yes Remote operation: Yes Login scripts: No Transfer text files: Yes Transfer binary files: Yes Wildcard send: Yes File transfer interruption: No Filename collision avoidance: No Can time out: Yes 8th bit prefixing: Yes Repeat count prefixing: No Alternate block checks: Yes Terminal emulation: Yes (Dumb or native terminal) Communications settings: Duplex XON/XOFF: No Transmit BREAK: No IBM mainframe communications: No Transaction logging: No Session logging: No Debug Logging: No Packet logging: No Act as server: No Talk to server: No Advanced server functions: No Local file management: No Command/Init files: No Key redifinition/macros: No File attributes packets: No Command macros: No Raw file transmit: No Long packets: No Sliding windows: No