File RMKNODDY.DOC ----------------- Chris Kennington 9th July 1985. Noddy Guide to the Use of KERMIT on ----------------------------------- RML 480Z and Nimbus Computers ------------------------------ 0. Summary. -------- This guide tries to set out simply the steps needed to use a 480Z or Nimbus micro as a terminal to a mainframe computer or to transfer files between two micros or a micro and a mainframe. The Kermit system used is copyrighted by the University of Columbia, New York. They have produced a very full User Manual, a shortened version of which is in the file KUSER.DOC. This gives a lot more explanation on some of the points covered below. The RM Kermit program is described fully in the file RMKINFO.DOC. 1. Kermit - What It Does. ---------------------- The Kermit program lets you use a micro as a fairly standard terminal to (almost) any mainframe computer which runs a terminal system. "Mainframe" here means anything from a Cray II down to a 68000 running Unix(TM). To use Kermit in this way no special facilities at all are needed on the mainframe. The more important part of Kermit is that it also lets you transfer files between a micro and a mainframe, or between two micros. To do this requires a version of the Kermit program running at both ends of the connection. RML supplies Kermits for both 480Z and Nimbus; a version for later-model 380Zs is available from the University of Oxford. Kermits have been written by various people for almost every micro and mainframe under the sun (except ICL equipment). U. of Columbia maintain a distribution service at nominal cost. In the U.K. educational users can get versions from the University of Lancaster. Other groups which can help include DECUS (the DEC user organization) and the IBM-PC User Group. When sending files from one computer to another, Kermit makes sure that if the file is received at all it is received correctly. The files can be either printable (text) files, which consist of normal printing characters and a few control-characters such as RETURN; or they can be binary files of any sort. They must however be "sequential" files; "direct-access" files as used by some special programs cannot be moved between computers by Kermit. 2. Using the Menus. ---------------- When Kermit starts up, it displays a menu called "KERMIT MAIN MENU". This show you the different sorts of things it can do. There are two other menus, "COMMANDS to SERVER" and the parameter-menu. All work in much the same way. An arrow on the right shows which item is currently selected; you can move this arow up and down by the up- and down-arrow keys, or by F1 and F3, or by PG UP and PG DOWN. The main and server menus get all their options on one screen. All you do is move the arrow and when it is on the correct line hit RETURN (480Z) or ENTER (Nimbus) to do what you want. The parameter menu is more complicated; not only does it have many more parameters than can fit on the screen, but each parameter has values you can change. Using the arrow and F keys moves both the indicating arrow and the selection of parameters on display so that you can get at all of them. The current value of each parameter is displayed on the right of its name. These values are changed by using the right- and left-arrow keys. You should change any and all the parameters which you wish to, then hit RETURN or ENTER to get back to the main menu and do something useful. When you are viewing any menu, the bottom 5 lines are reserved for some helpful comments. With the main and server menus these change as you go up and down the menu. With the parameter menu you must enter "?" to get up the appropriate help-text. In either case entering "H" will get you some general help on how to use the system. 3. Getting Started. ---------------- Make sure that you have got the correct version of RM Kermit for the 480Z or Nimbus that you are using. There are different versions according to the way the communications-line is plugged in; this is described in the main documentation-file RMKINFO.DOC. Run Kermit just as you would any other program, by typing its name (which may be KERMIT or else some recognizable derivative such as AKMIT21). If you are using a Nimbus with Piconet you will fiorst have to tell Kermit the address of the Piconet module which is connecting you to the other computer. Kermit will then come up with its main menu and some header information; check the item in the lower right corner "Communications:" to make sure that it corresponds with where your communications-cable is plugged in. If it doesn't, get a new Kermit or a new communications-cable. The first thing that you need to do is make sure that you can actually send and receive characters to/from the other computer. All Kermit transfers require that you can both send and receive, so you will have to have a "full-duplex" cable connecting your micro to the other computer. (This means that a "half-duplex" cable as used to connect some printers to micros is not suitable.) Anyway, make sure that the cable used to connect the two computers is plugged into the right ports at both ends. There are two other fundamentals on which the computers must agree - line-speed and parity. (Speed, measured in "baud", is the effective electronic frequency used on the connecting cable; parity describes the way that the 7-bit characters usually used for text are converted to and from the 8-bit characters sent on the communications line.) If the other computer is a mainframe, it will have firm ideas about these things and you can only set your micro-Kermit to agree. If you are running between two micros, then both must be set to the same values; if you have control in this way, use parity OFF and the fastest line-speed supplied. (If you are connecting to the other computer through a network or switching system, this may alter the speed and parity setting you have to use; ask the people who run it.) When you think that everything is correctly set, select "Connect to Mainframe" on the main menu and hit RETURN/ENTER. Kermit will tell you that it is connecting you, and from then on everything you type will be sent and anything received will be shown on the screen. Your own type-in will not be shown on the screen unless you have set the parameter "Local Echo" to ON. If you are connected to a mainframe, type RETURN/ENTER (several times) and you should get whatever message it habitually displays to a newly-connected terminal. If you are connected to another micro, type some text and see whether it is displayed on the other screen; do this in both directions. If these activities produce no result whatsoever, then you do not have contact. Check that all the parameters are correctly set and the bits-and-pieces of equipment firmly plugged together and all computers alive. If everything checks out, but you still don't get any response, you need help from your communications people. Carry on with this document after they have sorted you out. If you are working to a mainframe and it gives ridiculous messages, try other settings of parity. When you are connected, all normal keys work like they would on a real terminal. The Kermit program will only pay attention if you hit the F4 key (or on Nimbus also F6 to F10). Hitting this causes Kermit to wake up and show a prompt "KmESC>" or "KmF4>". It then expects you to give it either 1 or 2 more charcters to tell it what to do. The full possibilities are described in RMKINFO.DOC, but a summary can be obtained by hitting ? after the prompt. (This procedure is called "breaking in".) The two most important possibilites at this point are to hit K after the prompt, which will get you back to the main menu, or Q which will let you cancel Kermit and run another program. If you didn't mean to break in, hit RETURN/ENTER. 4. Transferring Files. ------------------- To transfer files you need to have a Kermit running at each end of the connection. With two micros this just means loading Kermit into each separately, from its own keyboard. With a mainframe it means connecting (as described above) and then working as a terminal until you have logged in and gone through any other work needed before you can start Kermit on the mainframe (or link to it if it is a permanently-running type). You will also need to know something about how to run the mainframe Kermit - consult its helptexts or the mainframe user documentation. In particular, find out whether it is a "server" or not. Mainframe Kermits which are servers need only to be set going and then will take all their instructions from the Kermit running in the micro. Other mainframe Kermits ( "simple" ones) need to be told what to do while you are still connected as a terminal, before you tell your micro Kermit what to do. Many mainframe Kermits work in an interactive manner. This means that, while you are connected, they accept commands one at a time and send you back a response for each. Others expect all their command information to be entered on the "command-line" which you type in to start them going. In this case you have to go out of "connect" as soon as the mainframe Kermit starts to run. (The official Kermit jargon for the two ends of the Kermit-Kermit link-up is that the one running in the micro, to which you talk directly, is the "local" Kermit; the one on the mainframe is a "remote" Kermit. This is fine until you connect two micro-Kermits, at which point you really have two locals. However, everything still works O.K.) 5. Micro-Micro Transfers. ---------------------- Unless you are using two RML micros, you will need to get the instructions for the other micro's Kermit and talk to it in the way it understands. The details of the instructions below apply only to RM (480Z and Nimbus) Kermits. Once you have tested out the micro-micro link in connect-mode, you can arrange for files to be transferred. Obviously, one Kermit has to send and the other to receive. In general you have to tell each micro what to do from its own keyboard; things tend to work better if you set the receiving end going first. To prepare RM Kermit to receive files, use "F4 k" to get back to the main menu and select the option "Receiving Files". Hit RETURN/ENTER, and you will be asked whether you wish to have them stored under their own names. Usually this is so, and all you need do is hit RETURN/ENTER again. If however you know that the names which the other Kermit will send are for some reason unsuitable, you can enter one or more replacement names (separated by spaces). End the list with RETURN/ENTER and Kermit will start listening for the other end to get going. It will receive as many files in one go as the other Kermit cares to send. To prepare RM Kermit to send files, select the main-menu item "Sending Files". You will be asked to enter a list of filenames. Type these in (in either capitals or lower-case), separating the names by spaces and ending with RETURN/ENTER. You can use the "wildcard" characters "?" and "*" to get Kermit to look on the disk and see what files there are to send (in which case it will tell you what it found). Up to 8 files can be sent in one go (but not more than one lot of wildcards or 80 characters on the whole line). The files are kept separate, and will end up at the receiving end as separate files under their own names (or reasonable derivatives thereof). Once both ends are going, they will get in touch with each other, exchange some housekeeping information and the filenames, and then transfer the file(s). RM Kermit will show a dot on the screen for each good block of data transferred (about 90 characters), and will also display the letters D, T, C and N to indicate various sorts of trouble. Kermit knows how to recover from problems in the communications, so provided there are only a small scattering of alphabetics mixed with the dots, you have nothing to worry about. If there are a very large proportion of error-letters, the connection must be very bad and it is probably wise to kill the transfer, disconnect, and start again from the beginning. When a transfer is in progress, the name of the file being transferred is shown on line 3 of the screen, and some counts of activity so far on lines 3 & 4. Messages are also displayed on the lower part of the screen as each significant event takes place. If the message "trying..." is repeated again and again, or if instead of dots only T's are displayed, it means that your local Kermit cannot get in touch with the other one. Go back to connect-mode, make sure the other Kermit has not collapsed and start again. 6. Transfers with a Mainframe Server. ---------------------------------- If the remote mainframe Kermit has a server-mode (sometimes called automatic), then there is no need to talk to it in connect-mode once you have got it started. Get out of connect-mode on your local RM Kermit by "F4 K" and select "Commands to Server" from the main menu. As soon as you enter this mode, you will have the command menu displayed. The important items here are "Get Files" and "Sending Files". Select whichever of these is appropriate. "Get Files" requests you to type in a list of filenames which you want the mainframe to send you. This has to be typed in exactly as you would have done to any other program RUNNING ON THE MAINFRAME. The list will be sent to the other end exactly as you type it. Whether you can use wildcards, whether you should use upper or lower case etc. depends entirely on the mainframe's habits. End the list wih RETURN/ENTER and the two Kermits will sort matters out between them. Before the files are actually received you will have the same query "Store under own names - Yes?" which was noted above, and it must be answered in the same way. "Sending Files" works in apparently the same way as the sending process described between two micros. The actual transfer proceeds just as it did between two micros. At the end of a transfer, you will be asked to enter any character before Kermit returns you to the command menu. The pause is to allow you to read the various messages before the menu wipes them out. 7. Transfers with a Simple Mainframe Kermit. ----------------------------------------- If the mainframe Kermit does not have server abilities, you must use it in simple mode. This is just like the micro-micro transfer except that you work with RM Kermit in connect-mode as a terminal of the mainframe until you have finished telling the mainframe Kermit what you want it to do (i.e. send files or receive files). When you have achieved this, the mainframe Kermit will switch into "send" or "receive" mode and probably put some strange characters on your screen; this is it prodding your local Kermit to see if it is yet ready. You should enter "F4 K" to get back to the main menu, then select "Sending Files" or "Receiving Files" as appropriate, then carry on as between micros. (It goes without saying that if the mainframe is set to receive, the micro must send, and vice versa. Both sending or both receiving may lead to an error or just to an unlimited sequence of "trying..." messages ot T's, or to nothing.) At the end of a transfer with a simple mainframe Kermit, you are again given a chance to read the completion messages before being returned to the main menu. 8. Errors and General Snafus. -------------------------- Provided that the two Kermits can talk to each other, they will start to transfer the file. However, things can go wrong. The sender will have made sure the first file exists before starting, but one of the others in its list could be missing; or the receiver may be unable to store the file; or there may be disk errors. In any of these cases, one end or the other may decide that it can no longer carry on. It will then try to send an error-message to the other end before collapsing gracefully. RM Kermit will display any such error-message that it either sends or receives before going back to one of the menus. If the transfer which collapsed was a file-receive, RM Kermit will close the file normally and leave it on the disk in its incomplete state. Not all Kermits behave this way; some will remove the partial file, and others have parameter-settings which allow the user to decide in advance what should be done. You can force a transfer to be aborted by hitting F4 or ESC and then A. Kermit will query you to make sure that you really wish to abort the transfer; if you answer Y or just hit RETURN/ENTER, it will be aborted; hitting anything else will allow it to carry on. Similarly hitting CTRL-C at any time will give you a chance to cancel either the transfer or the whole Kermit program (after giving confirmation). It is always possible for a communications-line to collapse, particularly across a network. If this happens, Kermit will try 10 times to send or acknowledge the last block of data, at intervals of about 10 seconds, displaying a "T" on the screen each time. Eventually it will abort (as explained above). To cut this process short you can enter "ESC A", just as though you were killing a transfer which was proceeding normally. 9. Disks and Names. ---------------- Filesystems on different micros and mainframes have very different ideas about what files should be called and where to put or look for them. Kermit in general ignores all parts of a filename except its principal name, which is usually the last part of the complete name; and converts this to upper-case letters. (E.g. a file in unix might have a full name "/44d/staff/cjk/documents/blurb", Kermit would send this under the name "BLURB"; an MSDOS file might be "B:DEMO\DUCKS.BAS", which Kermit would send as "DUCKS.BAS".) This means that the CP/M disk-letter and user-number and the MSDOS disk-letter and path do not get included in the names of files received. You have to set these up before starting the transfer. They can be set before loading Kermit in the micro, or in the Kermit disk-maintenance mode (described in RMKINFO.DOC). A special case is that, when receiving, you can enter a disk-letter (complete with its trailing semicolon) in reply to the query "Store under own names - Yes?". If you do this, all files in the current batch will be stored on that disk but with the names which were sent with them. Names can come in from mainframe Kermits which have odd characters in them. To prevent trouble on the disks, RM Kermit checks all incoming names to make sure that they are in CP/M or MSDOS format and consist only of alphanumerics, "$" and the single dot which separates the two parts of the name. Filenames which break these rules are altered so that they conform. When a file starts to come in, Kermit tells you both the name sent with it and the name under which it is being stored. It is a nuisance if an incoming file overwrites one on the disk with the same name but different contents. RM Kermit therefore checks to see if the name duplicates one already on disk. If it does, then Kermit changes the name of the new file before storing it. The details of this are reported to you as they happen. (You can change the way this works by altering the parameter "File Collision".) 10. Binary Files. ------------- The majority of files transferred by Kermit are of text, so it is set up by default to handle such files. This is controlled by the parameter "8th-bit mode", where the setting "7-bit stripped" is right for text files. If you want to transfer binary files (ones in which the bytes may have any value from 0 to 255), this can be done in two ways. The better way is to use setting "8-bit prefixed"; this is certain to result in a good transfer if the other Kermit agrees to do it. Unfortunately not all Kermits can handle this part of the protocol; if the mainframe Kermit does not agree to use prefixed mode, you will get a warning message and should assume that the transfer will probably produce garbage. An alternative is to use "8-bit image". This assumes that 8-bit characters (values 128-255) will be received correctly as sent, a reasonable assumption over a piece of wire between two micros but very uncertain over complicated connections. The drawback is that if the 8-bit characters are received wrong, this may not be detected. Some experimentation is called for. In any case, it is likely that both Kermits will have to be informed separately that image-mode is to be used; prefixed-mode is sorted out automatically between the Kermits. 11. Other Facilities. ----------------- There are a number of other parameters on the parameter menu, modes on the main menu and possible server commands in the command menu. Some of these are fairly obvious. All are described, at least briefly, in RMKINFO.DOC. *********************************************************