@L|}6CD l0C)HCC WhL/h `CmCDiD`  R@W1  c0@R !L` D  C D     )16CS R)  C)D1 p p 0 C9DI pCDL~CiCDiD` KERMIT USER GUIDE Fifth Edition } Frank da Cruz, editor Columbia University Center for Computing Activities } New York, New York 10027 1 March 1984 Co}pyright (C) 1981,1982,1983,1984 Trustees of Columbia University in the City of New York Permission is gra}nted to any individual or institution to copy or use this document and the programs described in it, except for } explicitly commercial purposes.Preface to the 5th Edition P }age 1 Preface to the 5th EditionSince the 4th Edition of the KERMIT Users Guide was produced i }n July 1983, theKERMITs have been flying thicker and faster than anyone could keep up with.Old versions have improved }, and implementations for many new systems have ap-peared. It is no longer practical to even attempt to cover all the imp }lemen-tations in a single manual. Therefore, this manual will try to describe a sortof "ideal" KERMIT program, one which }has most of the features specified in theKERMIT Protocol Manual. Most real KERMIT programs will fall short of thisdes}cription in some ways. After the main, system-independent part of themanual there are sections for several particular} KERMIT programs, emphasizingtheir differences from the ideal, at the time of this writing. The system-de-pendent porti}ons of this manual will rapidly become dated; current informationabout any particular KERMIT program can be found in the} accompanying on-linehelp or documentation files, or built-in internal help text. A LITTLE }HISTORYThe KERMIT file transfer protocol was designed at the Columbia University Cen-ter for Computing Activities (CUC}CA) in 1981-82 mainly by Bill Catchings andFrank da Cruz. Bill wrote the first two programs, one for the DECSYSTEM-20 ando}ne for a CP/M-80 microcomputer.The initial objective was to allow users of our DEC-20 and IBM timesharing sys-tems to arch}ive their files on microcomputer floppy disks. The design owesmuch to the ANSI and ISO models, and ideas were borrowed} from similar projectsat Stanford University and the University of Utah. The protocol was designedto accommodate the }"sensitive" communications front end of the full-duplexDEC-20 system as well as the peculiarities of half-duplex IBM mai}nframe com-munications. The protocol was soon implemented successfully on our IBM 4341systems under VM/CMS by Daphne T}zoar of CUCCA.Meanwhile it was becoming apparent that KERMIT was useful for more than justfile archiving; IBM PCs w}ere beginning to appear in the offices and depart-ments, and there arose a general need for file transfer among all our sys}tems.Daphne soon had prepared an IBM PC implementation.After our initial success with KERMIT, we presented it at confere}nces of usergroups like DECUS and SHARE, and we began to get requests for it from othersites. Since we had written} down a description of the protocol, some siteswrote their own implementations for new computers, or adapted one of our i}m-plementations to run on additional systems, and sent back these new versions tous so that we could share them with othe }rs. In this way, KERMIT has grown tosupport about 50 different systems; it has been sent on magnetic tape fromColumbi!}a to hundreds of sites in dozens of countries, and has reached hundredsor thousands more through various user groups and ne"}tworks.To date, contributions to the KERMIT effort have been made by individuals atthe following institutions: Steve#}ns Institute of Technology, Cornell Univer-sity, Rutgers University, Cerritos College, the University of Toronto, theU$}niversity of Tennessee at Knoxville, the University of California at Berkeley,the University of Toledo, the University of T%}exas at Austin, the University ofMichigan, Oakland University, the University of Wisconsin, University CollegeDublin, th&}e University of Washington, ABC-Klubben Stockholm, the HelsinkiUniversity of Technology, the US National Institutes of '}Health, Digital Equi-Preface to the 5th Edition Page 2pment Corporation, (}The SOURCE Telecomputing, Hewlett-Packard Laboratories, Lit-ton Data Systems, RCA Laboratories, Atari Computer, and others. )} The list growsconstantly. CUSTOMIZING THIS MANUALAlthough this manual was produced at C*}olumbia University, all attempts havebeen made to keep it free of site-specific information. However, due to thelarge n+}umber of KERMIT implementations, descriptions of each one would make themanual unnecessarily thick. Therefore, the manual,} is sent from Columbia withspecific documentation about a selection of systems. Some of these descrip-tions may not b-}e of interest at your site, while others that are may be lack-ing.Each site, upon receiving a KERMIT tape, may decide whic.}h versions of KERMITare important to it, and include the appropriate documentation in this manual.This is most convenie/}ntly done if your site has the Scribe text formatting sys-tem (from UNILOGIC Ltd in Pittsburgh PA, USA), with which this0} manual wasproduced. Scribe runs on a wide variety of systems. There are also Scribesubsets, such as Perfect Writer1} and Final Word, that run on various microcom-puters.The system-specific parts of the KERMIT User Guide are included wit2}h "@INCLUDE"statements at the end of the Scribe source file for this manual, whose filenameis USER.MSS. You may add or del3}ete @INCLUDE statements to suit your needs, andrun the result through the text formatter to produce a customized manual.No4}t all system-specific documentation is provided in .MSS (Scribe input) for-mat, since some KERMIT contributors do not have5} Scribe at their sites. In thatcase, you will either have to add Scribe formatting commands, or else enclosethe whole su6}bfile in @VERBATIM brackets.If you do not have SCRIBE, you may still use an editor to delete or add sec-tions to the fi7}nished documentation file, though the results will not be assatisfactory -- the table of contents, index, and page 8}numbers will not beautomatically adjusted.If you are running a version of KERMIT for which adequate documentation has not9}been provided (after all, this is a distributed, volunteer effort!), pleasefeel free to write some, preferably in Scribe:} input format, and send it back toColumbia so that others may benefit from it. Likewise if you produce a new im-plementati;}on of KERMIT.Ordering Information Page 3Ordering InformationThe KE<}RMIT software is free and available to all. Columbia University,however, cannot afford to distribute free software o=}n the scale required forKERMIT. Therefore, to defray our costs for media, printing, postage,materials, labor,>} and computing resources, we must request a moderate distribu-tion fee from sites that request KERMIT directly from Columbia?}. The scheduleis as follows: Complete KERMIT Distribution $100.00 (Tape, Users Guide, and Protocol@} Manual) Printed Documents $5.00 each (Users Guide, Protocol Manual, or Any Source Listing)A}Other sites are free to redistribute KERMIT on their own terms, and are en-couraged to do so, with the following stipuB}lations: KERMIT should not be soldfor profit; credit should be given where it is due; and new material should besent bacC}k to Columbia University at the address below so that we can maintain adefinitive and comprehensive set of KERMIT implementD}ations for further dis-tribution.To order KERMIT from Columbia University, send a letter requesting either: (a) The E}manuals or source listings you desire (specify each one), or (b) A 9-track magnetic tape in one of the following formats:F} System Tape Format Densities TOPS-10 BACKUP/Interchange, Unlabeled 8G}00, 1600 TOPS-20 DUMPER, Unlabeled 800, 1600 IBM VM/CMS EBCDIC, CMS Format H} 1600, 6250 or EBCDIC, OS Standard Label 1600, 6250 Other ASCII, ANSI LabeI}l, Format ``D'' 800, 1600 (Specify system, format, and density.) One copy of each manual will be included wiJ}th the tape. We will supply the tape, packaging, and postage.We can only make tapes in the formats listed above. We cannoK}t produce floppydisks; bootstrapping procedures are provided to allow the microcomputer ver-sions to be downloaded froL}m the mainframe for which the tape is produced. Thetape includes all source programs, documentation, and, when practical, M}binariesor hex. Unfortunately, our limited resources to not allow us to provideautomatic updates to KERMIT recipienN}ts when new implementations, documentation,or bug fixes appear.Send your letter to: KERMIT Distribution Columbia O}University Center for Computing Activities 7th Floor, Watson Laboratory 612 West 115th Street New York, N.Y. 100P}25Please list the machines and operating systems you expect to run KERMIT on,specify the tape format or the listings Q}desired, and mention whether there areOrdering Information Page 4addiR}tional systems for which you require KERMIT or if you might be interestedin attempting your own implementation for a new sS}ystem. Make checks payable toColumbia University Center for Computing Activities.KERMIT is available to users of the BITNT}ET network via a server at host CUVMA.BITNET users may type ``SMSG RSCS MSG CUVMA KERMSRV HELP'' for further infor-matioU}n. KERMIT is also available to users of ARPANET, via anonymous FTP fromhost COLUMBIA-20, in the area PS:. And KEV}RMIT is distributed regularlyby various computer user groups such as DECUS and SHARE.Since new KERMIT programs are added W}-- and old ones improved -- so frequently,sites that use KERMIT heavily are encouraged to contact Columbia two or threetiX}mes a year for news.No warranty of the software nor of the accuracy of the documentation surround-ing it is expressed or Y}implied, and neither the authors nor Columbia Universityacknowledge any liability resulting from program or documentation erZ}rors.Introduction Page 51. IntroductionEveryone wants to ge[}t computers talking to one another. There are many ways todo this, and most of them are very expensive. But there is o\}ne way that ischeap and relatively easy: connect the two computers through their terminal(TTY) ports, tricking one comp]}uter (or both) into believing that the other is aterminal. This can be expected to work because the standard for connec^}tingcomputers to terminals is almost universally followed, in both hardware (plugand signal: EIA RS-232) and software _}(character code: ASCII). Once two com-puters are connected in this way, cooperating programs can be run on each toachie`}ve the desired communication by means of a communication protocol.Why is a protocol necessary at all? Three major problemsa} occur when you try toconnect two computers via TTY line: 1. Noise -- It is rarely safe to assume that there will be nob} electri- cal interference on a line; any long or switched data communication line will have occasional interc}ference, or noise, which typically results in garbled or extra characters. Noise corrupts data, per- haps in sd}ubtle ways that might not be noticed until it's too late. 2. Synchronization -- Data must not come in faster than the re}eceiving machine can handle it. Although line speeds at the two ends of the connection may match, the receif}ving machine might not be able to process a steady stream of input at that speed. Its central proces- sor may beg} too slow or too heavily loaded, or its buffers too full or too small. The typical symptom of a synchronization prh}oblem is lost data; most operating systems will simply discard incoming data they are not prepared to receive.i} 3. Line Outages -- A line may stop working for short periods because of a faulty connector, loss of power, or similj}ar reason. On dialup or switched connections, such intermittent failures will cause carrier to drop and the ck}onnection to be closed, but for any connection in which the carrier signal is not used, the symptom will be lost data.l}To prevent corruption of data and to synchronize communication, cooperatingcomputers can send control information tm}o one another at the same time thatthey are transferring data. This intermingling of control information withdata, andn} the resulting actions, constitute a "protocol".KERMIT is such a protocol. It is specifically designed for transfer of seqo}uen-tial files over ordinary serial telecommunication lines. KERMIT is not neces-sarily better than many other terminal-op}riented file transfer protocols but itis free, it is well documented, and it has been implemented compatibly on avarieq}ty of microcomputers and mainframes.KERMIT transfers data by encapsulating it in "packets" of control information.This ir}nformation includes a synchronization marker, a packet number to allowdetection of lost packets, a length indicator, ans}d a "checksum" to allowverification of the data. Lost or corrupt packets are detected, andretransmission ist} requested. Duplicated packets are discarded. In addition,various special control packets allow cooperating KERMITs tou} connect and dis-connect from each other and to exchange various kinds of information. Very fewassumptions are made about v}the capabilities of either computer, so the KERMITprotocol can work between many different kinds of systems.Introduction w} Page 6 ORGANIZATION OF THIS MANUALSx}ection 2, How to Use KERMIT, tells all you need to know to transfer text filesin most cases, and shows some specific exampley}s.If you follow the examples in Section 2 but you can't make a terminal connec-tion or you can't transfer files successfz}ully, consult Section 3, When ThingsGo Wrong.If you expect to be a heavy user of KERMIT, you should read Section 4, KE{}RMITCommands, which describes all the features of KERMIT in detail. You may findthat familiarity with the material in t|}his section will help you get past dif-ficulties that can crop up when you are making new kinds of connections ortrans}}ferring unusual kinds of files. You will also find descriptions of someadvanced file management features that have been o~}mitted from the earlier sec-tions.Section 5, KERMIT Implementations, briefly lists the systems for which KERMITis avai}lable as of this writing. The subsequent chapters describe selectedparticular implementations. You should read the a}ppropriate section for eachsystem with which you are using KERMIT; each section describes the file namingconventions and } other system features that are important to KERMIT users, andlists the KERMIT commands for that system mainly in terms of t}heir differencesfrom the "ideal" KERMIT described in section 4.How to Use KERMIT } Page 72. How to Use KERMITKERMIT is a protocol for reliable file transfer between computers over uthe or-dinary serial telecommunication lines that are used to connect terminals tocomputers. The mechanics of using KE}RMIT to get a file transferred can be con-fusing until you get the hang of it. A little background material might maketh}e process a bit easier to understand.KERMIT is probably the cheapest way to put two computers into communication.The r}equired hardware is usually already available, the software is free, andall components run as ordinary user programs, with} no system modifications.This is in sharp contrast to a communication network, where there are dedicatedhigh-speed comm}unications channels and drivers, expensive software, and soforth. The network provides more services than KERMIT, u}sually at higherspeed, and with greater convenience, because the network is usually part of thesystem. When a network is} not available, KERMIT can fill in. But since KERMITis not integrated with any particular system, but rather grafted on top} of manydifferent systems, it requires some extra work from those who use it.2.1. The KERMIT ProgramKERMIT embodies a} set of rules for transferring files reliably between com-puters. In general, one computer is a large system (a host, f}or instance atimesharing system with many terminals), and the other is a personal computer1(PC) } . The host believes that the PC is an ordinary terminal.Inorderforthe } KERMIT protocol to occur, a KERMIT program must be running on each end ofthe communication line -- one on the host, one on} the PC.The two Kermit programs exchange messages in a special language all their own,the Kermit protocol. The dialo}g runs something like, "Hi! I'm going to besending files to you. When you send messages to me, please don't make them}more than 80 characters long, and if you don't hear anything from me for 15seconds, wake me up, OK?" "OK." "Now, here c}omes a file called FOO.TXT, OK?""OK." "Here's the first piece..." "Got it." "Good, here's the second piece...""That seco}nd piece was junk." "Well, then here it is again..." Et cetera. Youdon't see any of this. It's all packed into a concise} code which the two Ker-mits can understand; they do all the worrying about transmission, error check-ing, character set t}ranslation, and so forth. Each message is called a packet,and each packet is in a special format that all Kermits can under}stand.2.2. Talking to Two Computers at OnceYour task is just to get the two Kermits started. The confusion arises becau}seyou have to use a single keyboard and screen to talk to two different com-puters, two different programs. Let's tal}k about a common case: you are sit-_______________ 1 Host-to-host and PC-to-PC connections are also possible.Ho}w to Use KERMIT Page 8 2ting at a }personal computer (PC ), which has a serial communication port. The } 3serial port is connected to a host computer using, say, a dialup modem .Normally, when you use your PC, you} are "talking" directly to it; your commandsare interpreted directly by the PC's operating system (CP/M, MS-DOS, UNIX,}whatever), or by some program that runs on the PC (an editor, a text formatter,space invaders...). The version of Kermi}t on your PC is a program like anyother, but it has a special ability to either interpret your commands directly,like other} programs, or to pass everything you type through to the host. Whenyou tell Kermit to CONNECT, it sends every character} you type out the serialport, and it will put every character that comes in the serial port onto thescreen. This is } called virtual terminal service -- one computer acts"virtually" as though it were a terminal on another. You are now} "talking" tothe host, and the PC is ignoring you.Kermit, like most programs, has a prompt. The prompt is a symbol it }types onthe left margin to indicate that it is ready for you to type a command.Kermit's prompt is normally "Kermit-}xx>". The xx identifies the implementationof Kermit; the Kermit that runs on the DEC-20 is called "Kermit-20" and itsp}rompt is "Kermit-20>"; the Kermit that runs on Z80 and 8080-based microcom-puters is called "Kermit-80" and its prompt i}s "Kermit-80>"; the Kermit on the 4IBM PC is "Kermit-86" , and so forth. If you become confused about }who you aretalking to, the prompt should provide a clue. In addition, most Kermits printan informative message like [C}onnecting to remote host, type CTRL-]C to return]when you CONNECT, and type another message like [Connection closed, bac}k at PC]when you return.Having "connected" to the host, there must be a way for you to get back to thePC. This is acco}mplished by an escape sequence. As Kermit passes your charac-ters through to the host, it checks each one to see if } it's a specialpredefined escape character. When the PC sees this character, it stops ignor-ing you -- you are once aga}in "talking" to the PC, not the host. The escapecharacter is normally chosen to be one that you will not need to typ}e while_______________ 2 The terms PC, micro, microcomputer, and workstation will all be used looselyin this documen}t to denote a single-user system. 3 The actual means of connection isn't important in this case -- it also couldbe a d}irect line to the host, some kind of switched line, etc. 4 Although the processor in the IBM PC is an 8088, it is progr}ammed as thoughit were an 8086.How to Use KERMIT Page 9talking t}o the host, and one that is hard to type by accident -- it's usually acontrol character, such as Control-], which is accompl}ished by holding down thekey marked CTRL or CONTROL and typing the indicated character (in this case, aright bracket "]").} The CTRL key works just like a SHIFT key. Control charac-ters are written either as CTRL-A or ^A, where A is the characte}r to be typedwhile holding down CTRL.2.3. Transferring a FileTo transfer a file, you must first get the attention of }the PC's operating sys-tem. This is normally done by starting the PC, possibly inserting your systemfloppy disk first. O}nce you're at command level on your PC, you run Kermit.Then you tell Kermit to CONNECT you to the host. Now you're t}alking to thehost -- at this point you must log in, and then run Kermit on the host.Now you have a Kermit on each end of t}he wire. The next step is to tell eachKermit what to do. Suppose you want to transfer a file from the host to thePC;} you would first tell the host Kermit to SEND the file, then "escape" backto the PC Kermit and tell it to receive the fi}le. The transfer begins -- youcan sit back and watch, or go make yourself a sandwich. The PC Kermit willcontinuously } show packet and retry counts on your screen, and will notify youwhen the transfer is complete.The desired file is now on} your PC's disk. The Kermit protocol has ensuredthat the file arrived correctly and completely. Now you must clean }up afteryourself: CONNECT back to the host, exit from Kermit on the host, log out fromthe host, "escape" back to PC Kermit} and exit from it. Now you can do whateveryou had planned for your file -- edit it, print it on your PC printer, etc.The } KERMIT protocol, and most Kermit programs, allow you to send a file reli-ably from the host to the PC, from the PC to the }host, from host to host, or PCto PC, usually without any special regard for the nature of the particularmachines invol}ved. Most implementations also allow files to be sent in groups,with a single command, such as "Send all my Fortran files}!" The scenario foreach of these is always the same as above -- only the details of how to estab-lish the actual connecti}on differ.KERMIT works best with "printable" files -- files composed only of letters,digits, punctuation marks, carria}ge returns, tabs, and so forth -- since thesecan be represented on almost any kind of computer. KERMIT is also able t}otransfer "binary" files -- files such as executable programs -- composed of ar-bitrary bit patterns, but binary files norm}ally are meaningful only to the kindof computer on which they are generated. Nevertheless, KERMIT can usually movesuch fil}es from system A to system B (where they are not much use) and back tosystem A in their original condition, although in so}me cases some special caremust be taken to accomplish this.Now that we have a basic understanding of what KERMIT does and } how it works,let's look at some more concrete examples. First you need to know what thebasic Kermit commands are.H}ow to Use KERMIT Page 102.4. Basic KERMIT CommandsThese are gene}ric descriptions of the most basic Kermit commands. Detaileddescriptions will come later. In these descriptions, local r}efers to the sys-tem that you are using directly, remote refers to the system to which you areCONNECTed via Kermit. Com}mands may take one or more operands on the same line,and are terminated by a carriage return.SEND filespec Send the file} or file group specified by filespec from this Kermit to the other. The name of each file is passed t}o the other Kermit in a special control packet, so it can be stored there with the same nam}e. A file group is usually specified by including "wildcard" characters like "*" in the file specifica- } tion. Examples: send foo.txt send *.for Some implementatio}ns of Kermit may not support transfer of file groups; these versions would require a separate SEND command} for each file to be transferred.RECEIVE Receive a file or file group from the other Kermit. If an} in- coming file name is not legal, then attempt to transform it to a similar legal name, e}.g. by deleting illegal or excessive characters. The name thus formed cannot be guaranteed to be } unique, in which case previously existing files could be over- written. Some versions of Ker}mit attempt to prevent this by warning you of filename collisions and taking, or allowing for, } evasive action.CONNECT Make a "virtual terminal" connection to the remote system. On a PC or } micro, this usually means to send all keyboard input out the serial port, and display all input from the ser}ial port on the screen. To "escape" from a virtual terminal connection, type Kermit's es}cape character (e.g. CTRL-], control- rightbracket), followed by the letter "C" for "Close } Connection".SET Establish various nonstandard settings, such as CONNECT escape }character, file characteristics, communication line number, parity, or flow control.SHOW Dis}play the values of SET options.HELP Type a summary of KERMIT commands and what they do.EXIT Exit fr}om KERMIT back to the host operating system.? Typed anywhere within a KERMIT command: List the commands, op-} tions, or operands that are possible at this point. This com- mand may or may not require }a carriage return, depending on the host operating system.How to Use KERMIT } Page 112.5. Real ExamplesKermit can be used in several ways: from a PC that is connected to a }largerhost computer; from a host computer which is connected to another host; fromone PC to another.2.5.1. PC to Host}In this example, the user is sitting at an IBM Personal Computer (PC), which isconnected through its serial port to a DEC}SYSTEM-20 host computer. The IBM PCis local, the DEC-20 is remote. This example will also apply almost literallyto any o}ther microcomputer implementation of Kermit.You have started up your PC and have the Kermit program on your disk. Begin by}running Kermit on the PC. Use Kermit's CONNECT command to become a terminal tothe DEC-20. In fact, the PC emulates the p}opular Heath-19 (or VT52) terminal,so it is desirable to tell the DEC-20 that your terminal is one of these.Login on }the DEC-20 and run Kermit there. Here is an example of this procedurewith commands you type underlined: } 5 A>kermit ! Run Kermit on the PC. Kermit V1.20 Kermit-86> } ! This is the Kermit prompt for the PC. Kermit-86>connect ! Connect to the DEC-20. [Connecting to host, type co}ntrol-] to return to PC. Baud rate is 9600, connecting over COM1.] ! You are now connected to t}he DEC-20. CU20B ! The system prints its herald. @terminal heath-19 ! Set your terminal type (op}tional). @login my-id password ! Login using normal login method. (At this point, the DEC-20 prints various messages.}) @kermit ! Run Kermit on the DEC-20. Kermit-20> ! This is Kermit-20's prompt.You are n}ow ready to transfer files between the two machines.The following example illustrates how to send files from the DEC-20 to} the PC.Note the use of the "*" wildcard character to denote a file group._______________ 5 Everthing from a "}!" mark to the end of line is commentary, not systemtypeout or part of a command.How to Use KERMIT } Page 12 Kermit-20>send *.for ! Send all my FORTRAN files. ^]c } ! Now return back to the PC by ! typing the escape sequence, in this case } ! ^]C (Control-] followed by "C") [Back at PC.] Kermit-86>receive ! Tell the PC files are coming.If you } take more than about 5 seconds to get back to Kermit-86 and issue the RECEIVE command, the first packets from Kermit-20 ma}y arrive prematurely andappear on your screen, but no harm will be done because the packet will beretransmitted by t}he DEC-20 until the PC acknowledges it.Once the connection is established, the PC will show you what is happening-- }it first clears the screen and waits for incoming packets; as packets ar-rive, the current file name and packet number wil}l be continuously displayed onthe screen. When the PC's "Kermit-86>" prompt returns to your screen, thetransfer is }done. During file transfer, the microcomputer screen looks some-thing like this: IBM PC Kermit-86 V1.2}0 Number of Packets: 294 Receiving... Number of Retries: 2 File Name: FOO.TXTThe packe}t and retry counts are continuously updated, and the word in the upperright tells the status of the transfer -- receiving, s}ending, complete, inter-rupted, or failed.When the transfer is complete (most versions of KERMIT sound a beep to wake you}up), you must CONNECT back to the DEC-20 host, EXIT from Kermit there, logout,and "escape back" to the PC as you did previ}ously. Kermit-86>connect ! Get back to the DEC-20. [Connecting to host. Type CTRL-]C to return to PC.] Kermit-2}0> ! Here we are. Kermit-20>exit ! Get out of Kermit-20. @logout ! Logout from t}he DEC-20. Logged out Job 55, User MY-ID, Account MY-ACCOUNT, TTY 146, at 24-Jan-84 15:18:56, Used 0:00:17 in 0:21:55} ^]c ! Now "escape" back to the PC, [Back at PC.] Kermit-86>exit ! and exit from the PC}'s Kermit.The files you transferred should now be on your PC disk.To send files from the PC to the DEC-20, follow a simi}lar procedure. Firstfollow the instructions in the previous section to log in to the DEC-20 throughthe PC. Then in} response to the host Kermit's "Kermit-20>" prompt you type RECEIVE rather than SEND. Now escape back to the PC and use the } SEND commandHow to Use KERMIT Page 13to send the local PC files } to DEC-20 host. The PC will show you the progressof the transmissio Page 13to send the local PC filesFn on its screen.When the "Kermit-86>" prompt indicates that the transmission is complete youshould follow the procedur }e shown above to logout from the DEC-20 host, exceptthat you may first wish to confirm that the files have been stored corre }ctly inyour directory on the DEC-20.2.5.2. Host to HostThis section describes use of Kermit between two hosts. A "host }" is consideredto be a large or multi-user system, whose distinguishing characteristic is thatit has multiple terminals. U }se of Kermit for host-to-host file transfers dif-fers from the PC-to-host case in that the line your terminal is connected }to isnot the same as the line over which the data is being transferred, and thatsome special commands may have to be is }sued to allow one Kermit to conform tounusual requirements of the other host.In this example, you are already logg }ed in to a DEC-20, and you use an autodialer to connect to an IBM 370-series system running VM/CMS throughDEC-20 }TTY port 12. The autodialer, in this example, is invoked from programcalled DIAL (idealized here, for simplicity), to whic }h you merely supply thephone number. @dial 765-4321/baud:1200 765-4321, baud 1200 [confirm] Dialing your number, } please hold... Your party waiting is on TTY12: @Other methods exist for connecting two hosts with a serial line. }Dedicatedhookups can be made simply by running an EIA cable between TTY ports on the two6systems. } For connecting to remote systems when no autodialerisavailable,a } 7manual dialup connection is also possible, but tricky. If you have a microcom-p }uter that supports KERMIT, you may find it easier to first transfer from hostA to the micro, then from the micro to host B. }The following procedure would be the same in any case, once a connection is_______________ 6 Such a connectio }n, by the way, usually requires the receive and transmitleads (pins 2 and 3) be swapped in one of the RS-232 connectors; t }his is calleda "null modem" cable. 7 Here's one way: log in on port x on your system, and assign another port, y,to w }hich you have physical access. Unplug the terminal from port y, and con-nect the terminal to a dialup modem. Dial up the } remote computer and log in onit. Now, using a null modem cable, connect the modem directly to port y. Goback to your t }erminal on port x, run Kermit from it, and CONNECT to port y.How to Use KERMIT } Page 14made. Note that Kermit-20 accomplishes remote terminal connection by running aprogram called TTLINK in a !}n inferior "fork". @ @kermit ! Run Kermit on the DEC-20. Kermit-20>set ibm ! Turn on special h "}andshaking, parity, local ech Kermit-20>set line (to tty) 12 ! Indicate the line we'll use. Kermit-20>connect ! An #}d connect to it. [TTLINK: Connecting to remote host over TTY12:, type C to return. VM/370 ONLINE ! Th $}e IBM system prints its herald. .login myuserid mypassword ! Login to the IBM syst LOGON AT 20:4 %}9:21 EST THURSDAY 01/20/84 CUVMB SP/CMS PUT 8210 01/19/84 . .kermit KERMIT-CMS>.send profile exec ! Send a file. ^Y &}c ! TTLINK's escape sequence typed here. [TTLINK: Connection Closed. Back at DEC-20.] Kermit-20>rece '}ive ! Tell Kermit-20 to RECEIVE.The transfer takes place now; Kermit-20 will print the names of incoming files,foll (}owed by dots or percents to indicate the packet traffic (a dot for every 5packets successfully transferred, a percen )}t for every timeout orretransmission). It is complete when when you see "[OK]", a beep is sounded,and the Kermit *}-20 prompt next appears. At that point we connect back to theremote IBM system, exit from the remote Kermit and log out. +} . PROFILE.EXEC.1 ..%%.[OK] Kermit-20>connect ! Get back to IBM and clean up. [TTLINK: Connecting to remote h ,}ost over TTY12:, type C to return. KERMIT-CMS>. KERMIT-CMS>.exit R; . SP/CMS .logout CONNECT= 00:03:0 -}1 VIRTCPU= 000:00.12 TOTCPU= 000:00.60 LOGOFF AT 20:52:24 EST THURSDAY 01/20/84 ^Yc ! Type Kermit-2 .}0's escape sequence [TTLINK: Connection Closed. Back at DEC-20.] Kermit-20>exit ! All done with Kermit.That's /} the whole procedure. The file is in your DEC-20 directory, completelyreadable, as PROFILE.EXEC -- note that KERMIT-CMS 0} translated from the IBMEBCDIC character encoding into standard ASCII, and converted the space betweenthe file name an 1}d file type to a dot.To send a file from the local host to the remote host, we would merely havereversed the SEND and 2}RECEIVE commands in the example above.How to Use KERMIT Page 152.5. 3}3. Micro to MicroKermit also works between personal computers (microcomputers, workstations).The difference here is tha 4}t commands are typed on two keyboards, rather than asingle one. This is because a personal computer normally only accepts 5}commandsfrom its own keyboard. If one PC Kermit CONNECTs to another, there will nor-mally be no program on the other sid 6}e to listen.Making the physical connection between two micros is tricky. If the two units 8are 7} in close proximity , you can connect their serial ports with a nullmodem cable. However, different micros have diff 8}erent requirements -- some maywant a male connector on their serial port, others a female; many require that 9} 9certain of the RS-232 signals be held high or low . In any case, you must alsomake sur :}e the port speeds are the same at both ends.Connections at longer distances can be made via dialup, providing the required ;}modems are available (one side needs autoanswer capability), or using any kindof dedicated or switched circuit that may b <}e available -- PBX, port contentionunit, almost anything you can plug an EIA connector into.In this example, a DEC VT180 " =}Robin" CP/M microcomputer is connected to a In-tertec "SuperBrain" CP/M micro, using a female-to-male null modem cable. >}Get-ting the cable right is the hard part. The connection can be tested by runningKermit and issuing the CONNECT command o ?}n both ends: typein from each microshould appear on the screen of the other.Suppose you want to send a file FOO. @}HEX from the Robin to the SuperBrain.Proceed as follows: 1. Run Kermit on the SuperBrain, and give the RECEIVE command: A} A>kermit Intertec SuperBrain Kermit-80 - V3.7 Kermit-80>receive 2. Run Kermit on the Robin, and B}give the SEND command for FOO.HEX. A>kermit DEC VT18X Kermit-80 - V3.7 Kermit-80>send foo.hex____ C}___________ 8 Why would you want to run Kermit between two PCs that are next to eachother? One good reason D} is that if they are different models, their floppydisks are probably incompatible. 9 By wiring certain of the pins in E} the connector together; for instance, somemicros want DTR (Data Terminal Ready, pin 20) to be held high, and this might F}be accomplished by connecting it to CTS (Clear To Send, pin 5). See EIA Stan-dard RS-232-C, and the appropriate manuals fo G}r your micro.How to Use KERMIT Page 16 Watch the packets fly. H} When you get the next Kermit-80> prompt, the transfer is done, and you can EXIT from both Kermits.The key point is t I}o start the receiving end first -- most microcomputer Kermitsdo not include a timeout facility, and if the receiver is not J}ready to receivewhen the sender first sends, there will be a protocol deadlock.2.6. Another Way -- The KERMIT ServerSo K}far, we have been describing the bare-bones version of the KERMIT protocol.An optional extension to the protocol includes L}the concept of a Kermit server.A KERMIT server is a Kermit program that does not interact directly with theuser, but onl M}y with another Kermit program. You do not type commands to a Ker-mit server, you merely start it at one end of the connecti N}on, and then type allfurther commands at the other end.Not all implementations of Kermit can be servers, and not all know O} how to talkto servers -- yet. The server is run on the remote computer, which would nor-mally be a large host, such P} as the DEC-20. You must still connect to theremote host to log in and start the server, but you no longer have to tell o Q}neside to SEND and the other to RECEIVE, nor must you connect back to the remoteside to clean up and log out when you're d R}one. Using the server, you can do asmany send and receive operations as you like without ever having to connectback t S}o the remote host. Some servers also provide additional services, suchas directory listings, file deletion, or disk usage T}inquiries.A Kermit server is just a Kermit program running in a special mode. It actsmuch like ordinary Kermit does a U}fter you give it a RECEIVE command -- it waitsfor a message from the other Kermit, but in this case the message is a comman V}dtelling what to do, normally to send or to receive a file or group of files.After escaping back to the local system, yo W}u can give as many SEND and GET com-mands as you like, and when you're finished transferring files, you can givethe BYE X} command, which sends a message to the remote Kermit server to log it-self out. You don't have to connect back to the rem Y}ote host and clean up.However, if you want to connect back to the host, you can use theFINISH command ins Z}tead of BYE, to shut down the Kermit server on the remotehost without logging it off, allowing you to CONNECT back to yo [}ur job there.Here's an example of the use of a Kermit server. The user is sitting at aCP/M-80 microcomputer and a DE \}C-20 is the remote host. A>kermit ! Run Kermit on the micro. Kermit V3.7 Kermit-80> ! T ]}his is the micro Kermit's prompt. Kermit-80>connect ! Connect to the DEC-20. [Connecting to remote host. Type CTR ^}L-]C to return to micro.] CU20E ! The DEC-20 prints its herald. @login my-id password ! Log in nor _}mally.(The DEC-20 prints various login messages here.)How to Use KERMIT `} Page 17 @kermit ! Run Kermit-20 normally Kermit-20>server ! Tell it to be a server. Kerm a}it Server running on DEC-20 host. Please type your escape sequence t return to your local machine. Shut down the server b b}y typing the Kermit command on your local machine. ^]c ! Now escape back to the micro. [Connectio c}n closed, back at micro.] Kermit-80>get *.pas ! Get all my DEC-20 Pascal programs. Kermit-80>send foo.* ! Send a d}ll the "foo" files from my micro. Kermit-80>exit ! Exit from Kermit back to CP/M. A>(Here you can do some wor e}k on the micro, edit files, whatever you like.) A>kermit ! Run Kermit-80 some more. Kermit-80>send file. f}pas ! Send another file. Kermit-80>bye ! That's all. Shut down the Kermit server. A> ! g} Back at CP/M automatically.This is much simpler. Note that once you've started the Kermit Server on theremote end, you q}1bUSMANUAL1 bUSMANUAL2 b USMANUAL3 bUSMANUAL4 bUSMANUAL5 can run Kermit as often as you like on the micro without havingto go back and forth any more; just make sure to shut the r} server down whenyou're done by typing the BYE command.Here are basic the commands available for talking to servers.SE s}ND filespec Sends a file or file group from the local host to the remote host in the normal way.GET fi t}lespec Ask the remote host to send a file or file group. Example: get *.c This comman u}d is exactly equivalent to typing "send *.c" at the remote host followed by "receive" on the local host. No v}te that the local Kermit does not attempt to validate the filespec. If the server cannot w}parse it, or cannot access the specified file(s), it will send back an appropriate error message.BYE x} Shut down the remote server and exit from Kermit. This will cause the job at the remote end to y} log itself out. You need not connect back and clean up unless you get an error message in z} response to this command (for instance, if your logged-out disk quota is exceeded on the remote host).FI {}NISH Shut down the server without having it log itself out, and don't exit from Kermit. A sub |}sequent CONNECT command will put you back at your job on the remote host, at system command }} level.When Things Go Wrong Page 183. When Things Go WrongConnect ~}ing two computers can be a tricky business, and many things can gowrong. Before you can transfer files at all, you mu }st first establish terminalcommunication. But successful terminal connection does not necessarily meanthat file trans }fer will also work. And even when file transfer seems to beworking, things can happen to ruin it.3.1. Communication Li }ne ProblemsIf you have a version of KERMIT on your microcomputer, but the CONNECT commanddoesn't seem to work at all, ple }ase: - Make sure all the required physical connections have been made and have not wiggled loose. If you are usi }ng a modem, make sure the car- rier light is on. - If you have more than one connector on your micro, make sure you } are using the right one. - Make sure that the port is set to the right communication speed, or baud rate. S }ome versions of KERMIT have a built- SET BAUD command, others require that you set the baud rate using a system comm }and or setup mode before you start the KERMIT program. Use the SHOW command to find out what the current baud rate } is. - Make sure that the other communication line parameters, like parity, bits per character, handshake, and flow } control are set correctly.You must consult the appropriate manuals for the systems and equipment in ques-tion.If all }settings and connections appear to be correct, and communication stilldoes not take place, the fault may be in your modem. } Internal modems (i.e.those that plug in to a slot inside the microcomputer chassis) are not recom-mended for use with } KERMIT. Many microcomputer KERMIT programs are written tocontrol the communication hardware explicitly; internal modem }s can interferewith that control.KERMIT normally expects to have full control of the communication port.However, } it is sometimes the case that some communications equipment controlsthe line between the two computers on either end. }Examples include modems(particularly "smart" modems), port contention or selection units, mul-tiplexers, local ne }tworks, and wide-area networks. Such equipment can inter-fere with the KERMIT file transfer protocol in various ways: } - It can impose parity upon the communication line. This means that the 8th bit of each character is used by the eq }uipment to check for correct transmission. Use of parity will: * Cause packet checksums to appear incorrec }t to the receiver and foil any attempt at file transfer. In most cases, not even the first packet will }get through. * Prevent the use of the 8th bit for binary file data.When Things Go Wrong } Page 19 If terminal connection works but file transfer does not, parity is the most li }ke Page 19 If terminal connection works but file transfer does not, parity is the most lily culprit. To overcome this impediment, you should find out what parity is being used, and inform the KERMITs o }n each side (using the SET PARITY command) so that they can: * Compose and interpret the checksums correctly. } * Employ a special encoding to allow 8-bit data to pass through the 7-bit communication channel. M }any packet-switched networks, such as GTE TELENET, require parity to 10 be set. - Communications equipme }nt can also interpret certain characters in the data stream as commands rather than passing them along to the other } side. For instance, you might find your "smart" modem suddenly dis- connecting you and placing a call to Tasmania. } The only way to work around such problems is to put the device into "transparent" or "binary" mode. Mos }t communication devices have a way to do this; consult the appropriate manual. In some cases, transparent mode will } also cancel the parity processing and allow the use of the 8th bit for data.3.2. The Transfer is StuckThere }are various ways in which Kermit file transfers can become stuck, butsince many hosts are capable of generating timeo }ut interrupts when inputdoesn't appear quickly enough, they can usually resend or "NAK" (negativelyacknowledge) lost } packets. Nevertheless, if a transfer seems to be stuck, youcan type RETURN on the keyboard of most micros to simulate a t }imeout.An interesting exception is the IBM mainframe (VM/CMS) Kermit -- it cannot timeout its "virtual console" (i.e. the }user's terminal), so when using Kermit froma micro to an IBM host, occasional manual wakeups may be necessary.The followin }g sections discuss various reasons why a transfer in progress couldbecome stuck. Before examining these, first make sure }that you really have aKermit on the other end of the line, and you have issued the appropriate com-mand: SEND, RECEIVE, } or SERVER. If the remote side is not a server, rememberthat you must connect back between each transfer and issue a n }ew SEND orRECEIVE command._______________ 10 TELENET uses MARK parity.When Things Go Wrong } Page 203.3. The Micro is HungThe micro itself sometimes becomes hung for reason }s beyond Kermit's control,such as power fluctuations. If the micro's screen has not been updated for along time, then } the micro may be hung. Try these steps (in the followingorder): - Check the connection. Make sure no connectors }have wiggled loose from their sockets. If you're using a modem, make sure you still have a carrier signal. }Reestablish your connection if you have to. - Press RETURN to wake the micro up. This should clear up any protocol } deadlock. Several RETURNs might be necessary. - If the problem was not a deadlock, restart the micro and then restart } Kermit, CONNECT back to the host, get back to your job or login again, and restart the transfer. You may h }ave to stop and restart Kermit on the remote host.3.4. The Remote Host Went AwayIf your local system is working but } the transfer is hung, maybe the remote hostor the remote KERMIT program crashed. Get back to command level on the local }KERMIT (on microcomputer implementations, you may be able to do this by typingabout five RETURNs, or one or more Control-C' }s). Issue the CONNECT command sothat you can see what happened. If the remote system has crashed then you willhave to }wait for it to come back, and restart whatever file that was beingtransferred at the time.3.5. The Disk is FullIf yo }ur local floppy disk or remote directory fills up, the Kermit on themachine where this occurs will inform you and then } terminate the transfer. Youcan continue the transfer by repeating the whole procedure either with a freshfloppy or after } cleaning up your directory. Some KERMIT programs allow you tocontinue the sequence where it left off, for instance on }the DEC-20 by usingthe SEND command and including the name of the file that failed in the"(INITIAL)" field: Ker }mit-20>send *.for (initial) foo.forSee the Kermit-20 command summary for further information about the initialfilespec }.3.6. Message InterferenceYou may find that file transfers fail occasionally and upredictably. One ex-planation coul }d be that terminal messages are being mixed with your file packetdata. These could include system broadcast messages (l }ike "System is goingdown in 30 minutes"), messages from other users ("Hi Fred, what's that KERMITprogram you're always r }unning?"), notifications that you have requested ("It's7:30, go home!" or "You have mail from..."). Most KERMIT programs a }ttempt todisable intrusive messages automatically, but not all can be guaranteed to doWhen Things Go Wrong } Page 21so. It may be necessary for you to "turn off" such messages before starti }ngKERMIT.3.7. Host ErrorsVarious error conditions can occur on the remote host that could effect filetransmission. } Whenever any such error occurs, the remote Kermit normally at-tempts to send an informative error message to the local on }e, and then breakstransmission, putting you back at Kermit command level on the local system.3.8. File is GarbageTher }e are certain conditions under which Kermit can believe it transferred afile correctly when in fact, it did not. The mos }t likely cause has to do withthe tricky business of file attributes, such as text vs binary, 7-bit vs 8-bit,blocked vs s }tream, and so forth. Each system has its own peculiarities, andeach KERMIT has special commands to allow you to specify ho }w a file should besent or stored. However, these difficulties usually crop up only when sendingbinary files. Textual f }iles should normally present no problem between any twoKERMIT programs.3.9. Junk after End of FileWhen transferring a t }ext file from a microcomputer to a mainframe, sometimesyou will find extraneous characters at the end of the file after }it arrives onthe target system. This is because many microcomputers don't have a consistentway of indicating the end of a }file. CP/M is a good example. The minimum unitof storage on a CP/M floppy is a "block" of 128 bytes. Binary files alw }aysconsist of a whole number of blocks, but a text file can end anywhere within ablock. Since CP/M does not record a file }'s byte count, it uses the conventionof marking the end with an imbedded Control-Z character. If your microcomputerversio }n of KERMIT is not looking for this character, it will send the entirelast block, which may contain arbitrary junk after }the "real" end of the file.To circumvent this problem, most microcomputer KERMITs have commands like SETFILE ASCII or SE }T FILE TEXT to instruct KERMIT to obey the CTRL-Z convention.Some microcomputer KERMITs operate in "text" mode by }default, others in"binary" or "block" mode.KERMIT Commands Page 22 }4. KERMIT CommandsAn "ideal" KERMIT program will be described here, which has most of the fea-tures specified in the }KERMIT Protocol Manual. No KERMIT program will have allthese commands or support all these options. The exact form of so }me of thecommands may differ from version to version. Some KERMIT programs may supportsystem-dependent options not desc }ribed here. The intention of this descriptionis to provide a base from which specific KERMIT programs can be described i }nterms of their differences from the "ideal."4.1. Remote and Local OperationSome KERMIT programs can be run in two ways }, remote and local. A remote Kermitis usually running on a mainframe, which you have CONNECTed to through a PC orother co }mputer. When KERMIT runs remotely, all file transfer is done over thejob's controlling terminal line -- the same line ove }r which you logged in, andto which you would type interactive commands. What the system thinks is yourterminal is real }ly another computer, usually a microcomputer, running its owncopy of Kermit.When KERMIT is in "local mode", file transfer }is done over an external device,such as a microcomputer's serial communication port, or an assigned terminalline on a m }ainframe. The local Kermit is connected in some way (like a dialoutmechanism) to another computer, again running its own co }py of Kermit. A localKermit is in control of the screen, a remote Kermit has no direct access to it.Microcomputer KERMIT }s usually run in local "mode", whereas mainframe Kermitsusually need to be given some special command to run in local mode }. Some com-mands make sense only for remote Kermits, others only for local, still otherscan be used with either. Loca }l and remote operation of KERMIT is shownschematically here: PC is Local, Mainframe is Remote:KERMIT Commands } Page 23 Communication Line (Packets) } +-------------------/ /-----------------+ Other terminals | | | | | } | | | | | PC | LOCAL Mainframe | | | } | REMOTE +----------+----------+ +------------+--+--+--+--------+ | Serial Port | }| | | | | | | | | } | | | | | +---------------+ | | Your job's }| | | Packets: 724 | | | terminal line | | | Retries: 7 | | | } | | | File: FOO.BAR | | | | | +---------------+ | } | | | Screen | | | | } | | | +---------------+-----+ +------------------- }-----------+ | | (Commands) | +------------+---------+ \ Ke }yboard \ +----------------------+ YouThe KERMIT program on the PC is a local Kermit. It can } control the screen, thekeyboard, and the port separately, thus it can update the screen with statusinformation, watch f }or interrupt signals from the keyboard, and transfer pack-ets on the communications port, all at the same time.The KERMI }T program running on the mainframe is a remote Kermit. The user logsin to the mainframe through a terminal port. The host } computer cannot tellthat the user is really coming in through a microcomputer. The keyboard,screen, and port fun }ctions are all combined in user's mainframe terminal line.Therefore a remote Kermit is cut off from your screen and keyboa }rd during filetransfer.A KERMIT server is always remote, and must get its commands from a local KER-MIT. The following } descriptions will indicate when a command must be remote orlocal.4.2. Command InterfaceMost implementations (the UNI }X version is the major exception) have an inter-active keyword-style command interface, modeled after that of the DECSYSTEM- }20,which is roughly as follows: In response to the "Kermit-xx>" prompt you maytype a keyword, such as SEND, RECEIVE, or } EXIT, possibly followed by additionalkeywords or operands, each of which is called a field. You can abbreviatekeywor }ds (but not file names) to any length that makes them distinguishablefrom any other keyword valid for that field. You } can type a question mark atany time to get information about what's expected or valid at that point. TheESC and "?" } features work best on full duplex systems (all but the IBMKERMIT Commands } Page 24mainframe, so far), where the program can "wake up" immediately and perform therequired function. On }half duplex or record-oriented systems, the ESC featureis not available, and the "?" requires a carriage return to follow. }In this example, the user types "set" and then a question mark to find out whatthe SET options are. The user then continue }s the command at the point wherethe question mark was typed, adding a "d" and another question mark to see whatset opti }ons start with "d". The user then adds a "u" to select "duplex" (theonly SET option that starts with "du") followed by an }ESC (shown here by a dol-lar sign) to complete the current field and issue the guide word "(to)" for thenext one, then anot }her question mark to see what the possibilities are, and soforth. The command is finally terminated by a carriage retur }n. Before car-riage return is typed, however, the command can be edited using RUBOUT or othercommand editing keys. Finall}y, the same command is entered again with a min-imum of keystrokes, with each field abbreviated to its shortest unique le}ngth.In the example, the parts the user types are underlined; all the rest is systemtypeout: Kermit-20>set ? one of the} following: debugging delay duplex escape file handshake IBM } line parity receive send Kermit-20>set d? one of the following: debugging delay du}plex Kermit-20>set du$plex (to) ? one of the following: full half Kermit-20>set duplex (to) h$alf Kermit-20>set du} h4.3. NotationIn the command descriptions, the following notation is used:anything A parameter - the symbol in ita}lics is replaced by an argument of the specified type (number, filename, etc).[anything] An optional field}. If omitted, it defaults to an appropriate value.number A whole number, entered in prevailing notati}on of the system.character A single character, entered literally, or as a number (perhaps oc- tal or hexadec }imal) representing the ASCII value of the character.floating-point-number A "real" number, possibly containi }ng a decimal point and a frac- tional part.filespec A file specification, i.e. the name of a file, possibly  }including a search path, device or directory name, or other qualifying infor- mation, and possibl }y containing "wildcard" or pattern-matching characters to denote a group of files.^X A control char }acter may be written using "uparrow" or "caret" nota-KERMIT Commands } Page 25 tion, since many systems display control characters this way. Con- trol characters are pr}oduced by holding down the key marked CTRL or Control and typing the appropriate character, e.g. X.Commands ar}e shown in upper case, but can be entered in any combination of up-per and lower case.KERMIT Commands } Page 264.4. Summary of KERMIT CommandsHere is a brief list of KERMIT commands as the}y are to be found in most KERMITprograms. The following sections will describe these commands in detail.For exchanging fi}les: SEND, RECEIVE, GETFor connecting to a remote host: CONNECT, SET LINE, SET PARITY, SET DUPLEX, SET HANDSHAK}E, SET ESCAPE, SET FLOW-CONTROLFor acting as a server: SERVERFor talking to a server: BYE, FINISH, GET, SEN}D, REMOTESetting nonstandard transmission and file parameters: SET BLOCK-CHECK, SET DEBUG, SET DELAY, SET FILE, }SET INCOMPLETE, Sg nonstandard transmission and file parameters: SET BLOCK-CHECK, SET DEBUG, SET DELAY, SET FILE, ET PARITY, SET RETRY; SET SEND (or RECEIVE) END-OF-LINE, START-OF-PACKET, PACKET-LENGTH, PAUSE, TIMEOUT, PADDIN}GFor defining "macros" of SET commands: DEFINEFor interrupting transmission: Control-X, Control-Z, Control-CGet}ting information: HELP, STATISTICS, SHOWExecuting command files: TAKEFor recording the history of a file transfer} operation: LOG TRANSACTIONSFor non-protocol file capture or transmission: LOG SESSION, TRANSMITLeaving the progr}am: EXIT, QUITIf you have a file called KERMIT.INI in your default or home disk, KERMIT willexecute an automatic TAKE} command on it upon initial startup. KERMIT.INI maycontain any KERMIT commands, for instance SET commands, or DEFINEs for} SET mac-ros to configure KERMIT to various systems or communications media.KERMIT Commands } Page 274.5. The SEND CommandSyntax:Sending a single file: SEND nonwild-filespec1 [filesp}ec2]Sending multiple files: SEND wild-filespec1 [filespec2]The SEND command causes a file or file group to be sen }t to the other system.There are two forms of the command, depending on whether filespec1 contains"wildcard" characters.!} Use of wildcard characters is the most common method ofindicating a group of files in a single file specification. For"} instance ifFOO.FOR is a single file, a FORTRAN program named FOO, then *.FOR might be agroup of FORTRAN programs. S#}ending a File GroupIf filespec1 contains wildcard characters then all matching files will be sent,in directory-listing ord$}er (according to the ASCII collating sequence) by name.If a file can't be opened for read access, it will be skipped. T%}he initialfile in a wildcard group can be specified with the optional filespec2. Thisallows a previously interrupted&} wildcard transfer to continue from where itleft off, or it can be used to skip some files that would be transmitted first.'} Sending a Single FileIf filespec1 does not contain any wildcard characters, then the single filespecified by fi(}lespec1 will be sent. Optionally, filespec2 may be used tospecify the name under which the file will arrive at the)} target system;filespec2 is not parsed or validated locally in any way. If filespec2 is notspecified, the file will be*} sent with its own name. SEND Command General OperationFiles will be sent with their filename and filetype (for instanc+}e FOO.BAR, nodevice or directory field, no generation number or attributes). If communica-tion line parity is being use,}d (see SET PARITY), the sending KERMIT will re-quest that the other KERMIT accept a special kind of prefix notation for b-}inaryfiles. This is an advanced feature, and not all KERMITs have it; if the otherKERMIT does not agree to use this featu.}re, binary files cannot be sent cor-rectly.The sending KERMIT will also ask the other KERMIT whether it can handle a /}spe-cial prefix encoding for repeated characters. If it can, then files with longstrings of repeated characters will be 0}transmitted very efficiently. Columnardata, highly indented text, and binary files are the major beneficiaries ofthis 1}technique.KERMIT Commands Page 28 SEND Remote OperationIf you2} are running KERMIT remotely (for instance, from a microcomputer), youshould "escape back" to your local Kermit within a r3}easonable amount of timeand give the RECEIVE command. Don't take more than a minute or two to completethe switch, or K4}ERMIT may "time out" and give up (in that case, you'll have toCONNECT back to the remote system and reissue the SEND command5}). SEND Local OperationIf you're running KERMIT locally, for instance on a microcomputer, you shouldhave already r6}un KERMIT on the remote system and issued either a RECEIVE or aSERVER command.Once you give KERMIT the SEND command, the n7}ame of each file will be printed onyour screen as the transfer begins, and information will be displayed to in-dicate t8}he packet traffic. When the specified operation is complete, theprogram will sound a beep, and the status of the opera9}tion will be indicated bya message like OK, Complete, Interrupted, or Failed.If you see many packet retry indications, you:} are probably suffering from anoisy connection. You may be able to cut down on the retransmissions by usingSET SEND P;}ACKET-LENGTH to decrease the packet length; this will reduce theprobability that a given packet will be corrupted by no<}ise, and reduce the timerequired to retransmit a corrupted packet.If you notice a file being sent which you do not reall=}y want to send, you maycancel the operation immediately by typing either Control-X or Control-Z. Ifyour are sending a>} file group, Control-X will cause the current file to beskipped, and KERMIT will go on to the next file, whereas Control-Z?} will cancelsending the entire group and return you to KERMIT-20 command level.4.6. The RECEIVE CommandSyntax: RECEIV@}E [filespec]The RECEIVE command tells KERMIT to wait for the arrival a file or file groupsent by a SEND command from theA} other system. If only one file is beingreceived, you may include the optional filespec as the name to store the incB}om-ing file under; otherwise, the name is taken from the incoming file header. Ifthe name in the header is not a legalC} file name on the local system, KERMITwill attempt to transform it to a legal name.If an incoming file has the same name aD}s an existing file, KERMIT will eitheroverwrite the old file or else try to create a new unique name, depending onthe E}setting of FILE WARNING.If you have SET PARITY, then 8th-bit prefixing will be requested. If the otherside cannot do thisF}, binary files cannot be transferred correctly. The sendingKERMIT may also request that repeated characters be compressed.G}If an incoming file does not arrive in its entirety, KERMIT will normally dis-card it; it will not appear in your directorH}y. You may change this behavior byusing the command SET INCOMPLETE KEEP, which will cause as much of the file asKERMIT CoI}mmands Page 29arrived to be saved in your directory. RECEIVE RJ}emote OperationIf your are running KERMIT remotely, you should escape back to your local Ker-mit and give the SEND commanK}d. You should do this within about two minutes, orKERMIT may time out and give up; if this happens, you can CONNECT back tL}o theremote system and reissue the RECEIVE command. RECEIVE Local OperationIf you are running KERMIT locally, you sM}hould already have issued a SEND com- 11mand to the remote KERMIT, and then escaped back to DEC-20 Kermit.As files aN}rrive, their names will be shown on your screen, along with a con-tinuous display the packet traffic.If a file begins tO}o arrives that you don't really want, you can attempt to can-cel it by typing Control-X; this sends a cancellation requeP}st to the remoteKermit. If the remote Kermit understands this request (not all implementationsof Kermit support this featuQ}re), it will comply; otherwise it will continue tosend. If a file group is being sent, you can request the entire group bR}e can-celled by typing Control-Z.4.7. GETLOCAL ONLY -- Syntax: GET remote-filespecThe GET command requests a remote KS}ERMIT server to send the file or file groupspecified by remote-filespec. Note the distinction between the RECEIVE and GETT}commands: RECEIVE puts KERMIT into a passive wait state, whereas GET activelysends a command to a server.The GET commandU} can be used only when KERMIT is local, with a KERMIT server onthe other end of the line. This means that you must haV}ve CONNECTed to theother system, logged in, run KERMIT there, issued the SERVER command, and es-caped back to the local KW}ERMIT.The remote filespec is any string that can be a legal file specification forthe remote system; it is not parsed oX}r validated locally. As files arrive,their names will be displayed on your screen, along with a continuous indica-tiY}on of the packet traffic. As in the RECEIVE command, you may type Control-Xto request that the current incoming file beZ} cancelled, Control-Z to requestthat the entire incoming batch be cancelled.If the remote KERMIT is not capable of server [}functions, then you will probablyget an error message back from it like "Illegal packet type". In this case,__________\}_____ 11 not SERVER -- use the GET command to receive files from a KERMIT server.KERMIT Commands ]} Page 30you must connect to the other Kermit, give a SEND command, escape back, and^}give a RECEIVE command.4.8. SERVERREMOTE ONLY -- Syntax: SERVERThe SERVER command instructs KERMIT to cease taking co_}mmands from the keyboardand to receive all further instructions in the form of KERMIT packets fromanother system. A `}KERMIT server must be remote; that is, you must be logged into the system through another computer, such as a microcomputer.a} In addition,your local KERMIT should have commands for communicating with remote servers;these include GET, FINISH, anb}d BYE.After issuing this command, escape back to your local system and issue SEND,GET, BYE, FINISH, or other server-orc}iented commands from there. If your localKERMIT does not have a BYE command, then it does not have the full ability tocod}mmunicate with a KERMIT server and you should not put the remote KERMIT intoSERVER mode. If your local KERMIT does have a e}BYE command, use it to shut downand log out the KERMIT server when you are done with it.Any nonstandard parameters should f}be selected with SET commands before puttingKERMIT in server mode, in particular the block check type and special fileg}modes.4.9. BYELOCAL ONLY -- Syntax: BYEWhen running as a local Kermit talking to a KERMIT server, use the BYE commanh}dto shut down and log out the server. This will also close any debugging logfiles and exit from the local KERMIT.4.1i}0. FINISHLOCAL ONLY -- Syntax: FINISHWhen running as a local Kermit talking to a remote KERMIT server use the FINISHcommj}and to shut down the server without logging out the remote job, so that youcan CONNECT back to it. Also, close any local dek}bugging log file.4.11. REMOTELOCAL ONLY -- Syntax: REMOTE commandWhen running in local mode, talking to a remote l} KERMIT server send thespecified command to the remote server. If the server does not understand thecommand (all of thm}ese commands are optional features of the KERMIT protocol),it will reply with a message like "Unknown KERMIT server commann}d". If does un-derstand, it will send the results back, and they will be displayed on thescreen. The REMOTE commandso} are:KERMIT Commands Page 31CWD [directory] Change Working Direp}ctory. If no directory name is provided, the server will change to the default directory. Otherwise, q} you will be prompted for a password, and the server will at- tempt to change to the specifier}d directory. If access is not granted, the server will provide a message to that effect.DELETE filespec s}Delete the specified file or files. The names of the files that are deleted will appear on your screen.t}DIRECTORY [filespec] The names of the files that match the given file specification will bu}e displayed on your screen. If no file specification is given, all files from the current directory will be v}listed.DISK [directory] Provide information about disk usage in the current directory, sucw}h as the quota, the current storage, the amount of remaining free space.HELP Provide a list of tx}he functions that are available.HOST [command] Pass the given command to the server's host command processor, y} and display the resulting output on your screen.KERMIT [command] Pass the given command, which is z}expressed in the server KERMIT's own interactive-mode command syntax, to the server for ex{}ecution. This is useful for changing settings, logging, and other functions.RUN program-name [command-lin|}e-argument] Have the remote KERMIT run the indicated program with the in- dicated command l}}ine; send the results back to your screen.PROGRAM [command] Send the command to the program started by mo~}st recent REMOTE RUN program, and display the results on the screen. If no com- mand is give}n, send newline character.TYPE filespec Display the contents of the specified file on your screen.4.12. LOCALSyntax:} LOCAL commandExecute the specified command on the local system -- on the system where KERMITto which your are typing this} command is running. These commands provide somelocal file management capability without having to leave the KERMIT pro}gram,which is particularly useful on microcomputers.CWD [directory] "Change Working Directory" to the specified directory.}DELETE filespec Delete the specified file or files.DIRECTORY [filespec] Provide a directory listing of the specified file}s.KERMIT Commands Page 32Some KERMIT programs may provide comma}nds for these or other functions in thesyntax of their own system, when this would cause no confusion. For instance,CP/M }KERMIT may use ERA in place of LOCAL DELETE.4.13. CONNECTLOCAL ONLY -- Syntax: CONNECT [terminal-designator]Establish } a terminal connection to the system at the other end of the com-munication line. On a microcomputer, this is normally }the serial port. On amainframe, you will have to specify a terminal line number or other identifier,either in the CON}NECT command itself, or in a SET LINE command. Get back tothe local KERMIT by typing the escape character followed by a sin}gle character"command". Several single-character commands are possible: C Close the connection and return to the loca}l KERMIT. S Show status of the connection. B Send a BREAK signal. 0 (zero) Send a NUL (0) character. P Push }to the local system command processor without breaking the connec- tion. Q Quit logging session transcript. R }Resume logging session transcript. ? List all the possible single-character arguments. ^] (or whatever you have set the} escape character to be) Typing the escape character twice sends one copy of it to the connected host.You ca}n use the SET ESCAPE command to define a different escape character, andSET PARITY, SET DUPLEX, SET HANDSHAKE to establish o}r change those parameters.4.14. HELPSyntax: HELPTyping HELP alone prints a brief summary of KERMIT and its commands, }and pos-sibly instructions for obtaining more detailed help on particular topics. MostKERMIT implementations also allow }the use of "?" within a command to produce ashort help message.4.15. TAKETAKE filespecExecute KERMIT commands from th}e specified file. The file may contain containany valid KERMIT commands, including other TAKE commands.KERMIT Commands } Page 334.16. EXIT, QUITEXITExit from KERMIT.QUIT is a synonym }for EXIT.4.17. The SET CommandSyntax: SET parameter [option] [value]Establish or modify various parameters for file} transfer or terminal connec-tion.When a file transfer operation begins, the two KERMITs automatically exchangespecial } initialization messages, in which each program provides the other withcertain information about itself. This information i}ncludes the maximum packetsize it wants to receive, the timeout interval it wants the other KERMIT touse, the number } and type of padding characters it needs, the end-of-linecharacter it needs to terminate each packet (if any), the block} check type, thedesired prefixes for control characters, characters with the "high bit" set,and repeated characters. } Each KERMIT program has its own preset "default"values for these parameters, and you normally need not concern yourself} withthem. You can examine their values with the SHOW command; the SET command isprovided to allow you to change them i}n order to adapt to unusual conditions.The following parameters may be SET:BAUD-RATE Set the speed of the current c}ommunications portBLOCK-CHECK Packet transmissing parameters may be SET:BAUD-RATE Set the speed of the current c3