5.6 USING BBC KERMIT WITH A REMOTE NON-SERVER Transferring data to and from a non-server is a little more complicated, since you will need to continually change from BBC KERMIT command mode to terminal mode and back again. With a little practice, though, the technique becomes natural. 5.6.1. Sending files to a non-server To send a file to a non-server you use the command SEND. However, unlike sending files to a server, you must also tell the remote KERMIT that a file is on its way. One means of doing this is as follows: 1. In terminal mode, start the remote KERMIT program, and issue its RECEIVE command. This tells it to expect a file from BBC KERMIT. The remote system may output a message when you do this, but more probably it will do nothing but wait for you do something. 2. Press CONTROL and F0 to return BBC KERMIT to KERMIT command mode. 3. Issue the BBC KERMIT SEND command. What happens now is identical to the actions described above for sending files to a server: you can use the same wildcard facilities to select files, etc., as described in section 5.5.1. If you are transferring to another micro KERMIT, you would need to do this: 1. From BBC KERMIT command mode, issue the SEND command as above. 2. From the other micro's command mode, issue its RECEIVE command. BBC KERMIT by default allows you 30 seconds to do this: you can change this interval if you wish. The command SET DELAY 10 for example, changes the delay to 10 seconds. 5.6.2. Receiving files from a non-server If the remote KERMIT system is not a server, you will need to transfer files from it by the exact reverse of the above SEND procedure: all you need to do is reverse the roles of the two machines. Thus, you could take the following steps: 1. In terminal mode, start the remote KERMIT program, and issue its SEND command. This tells it to transfer a file to the BBC system. There will normally be a delay before anything happens - the interval may be anything from a few seconds upwards, and is intended to let you do the next step before the transfer starts. On many KERMITs there will be a command to let you change the interval if you find it too short. 2. Press CONTROL and F0 to return to BBC KERMIT command mode. 3. Issue the RECEIVE command to BBC KERMIT. When the remote system's delay time expires, it will start to send the file. The RECEIVE command tells BBC KERMIT to sit and wait until this happens. If you are transferring files between micro systems, you could do 1. From BBC KERMIT command mode, issue the RECEIVE command. 2. On the remote system, issue the SEND command. The transfer will start once the remote system's delay period has expired. The advantage of the above approach is that you have no need to hurry to prepare the BBC system, since the RECEIVE command will leave it waiting indefinitely for you to get the other side going. You can't, though, use this method when you are talking to a mainframe KERMIT, since once you issue the RECEIVE command you cannot enter terminal mode to issue the corresponding SEND command to the remote system. 5.7 TRANSFERRING DATA TO AND FROM MEMORY BBC KERMIT will transfer data not only to and from files on disc, but also to and from the BBC's random-access memory. BBC KERMIT knows at all times the currently-defined "source" and "destination" of data, which tell it what to do when sending and receiving respectively. Source and destination can be set to either "file" (the default) or "memory". For example, suppose you wished to send the contents of memory from address &1900 to &357C inclusive to the remote system. You would issue the command SET SOURCE MEMORY 1900 357D to tell BBC KERMIT that data it sends now comes from meory instead of file, and also tells it where in memory. Note that the second address given is "357D": this value is the last address to be transferred, plus one. When you now issue the SEND command, the contents of this area of memory will be transferred. Since there is no BBC file involved, the form of the SEND command changes slightly. There is now only one parameter, which you must supply: this is the name of the file that you wish to be used on the remote system. Thus you might type SEND /mem/contents to send the memory contents to a file "/mem/contents" on the remote system. Bringing data from the remote KERMIT into the BBC memory is also simple. You might, for example, issue the command SET DESTINATION MEMORY 1B00 to tell BBC KERMIT that data now goes into memory, starting at address &1B00. Here also there is no BBC file involved, so the forms of the GET and RECEIVE commands change slightly. RECEIVE now has no parameters: all you are allowed to type is RECEIVE The GET command now has only one parameter, which is the name of the file you wish the remote server to send you. Thus, you would type GET /mem/dump to bring the contents of file "/mem/dump" into the BBC's memory. There are some points that you should bear in mind when doing transfers to and from memory: 1. The effect of the SET SOURCE and SET DESTINATION commands persist until you specify otherwise. Thus, if you transfer a group of files from the remote system to BBC KERMIT, all will end up in the same memory area. 2. BBC KERMIT has no way of knowing whether the addresses you specify are sensible: it is up to you to get them right. 3. Although no files are involved, the transfer of data to and from memory still obeys the settings defined by the SET FILE TYPE command. Thus if you wish to transfer the memory contents as unchanged binary data, you must type SET FILE TYPE BINARY to tell BBC KERMIT this. 5.8 TRANSFERRING DATA TO A PRINTER When you transfer a file from another system to your BBC Computer, BBC KERMIT will allow you to send it directly to a printer rather than to disc or memory. The command SET DESTINATION PRINTER will select this option: after you have issued it, all files that you transfer with RECEIVE or GET will go directly to the printer. Routing to the printer will persist until you specify another destination. This technique is very similar in result to using the terminal mode "log to printer" facility described in chapter 4. However, terminal logging, since it does not use the KERMIT transfer protocols, suffers from all the restrictions described in the introductory chapters. It is prone to error if you are using a noisy communications line, and also, of course, you may not be able to transfer all the characters of a particular file. Using the "transfer to printer" option will let you accomplish the result using all of KERMIT's error detection and transfer facilities. A little care may be needed when using this facility, especially if the KERMIT on the other machine is able to time out. Printers are far slower than discs, of course, so it will take BBC KERMIT very much longer to deal with output from the other system and acknowledge it. The other system may expect a rapid response, and so may assume that the data did not arrive and start to take recovery action. You can get round this potential problem by either setting a very long timeout on the remote system, or by disabling its time-out facility altogether. In this mode BBC KERMIT will treat incoming data according to the file type you have specified with the SET FILE TYPE command, even though no file is involved. Thus, for instance, you might need to specify SET FILE TYPE BINARY if you are transferring a graphics dump to a printer. You can also use the file type to control whether lines of a text file are terminated with a Carriage-Return and a Line-Feed, or simply by a Carriage-Return. If you have your printer set to perform an automatic line feed when a Carriage-Return byte is printed, you should use SET FILE TYPE ASCII CR otherwise, you should use SET FILE TYPE ASCII CRLF You should note here that the "printer ignore" byte set by *FX 6 is not used by BBC KERMIT. 5.9 HANDLING PROBLEMS By design, KERMIT is a highly reliable file transfer system, and performs considerably better than any "dumb capture" facility within a terminal emulator. The error-detection capabilities of KERMIT ensure that data is transmitted correctly: in the rare cases where the communications system you are using is unreliable, KERMIT systems will abort a file transfer rather than transfer garbage. That said, there are some cases where you may need to give BBC KERMIT some assistance. The most common case will arise when one byte is transmitted by one system but does not arrive at the other. KERMIT breaks data up into small chunks called "packets", and if the missing byte is one of the ones that the KERMIT systems use to control these packets, you may end up with a machine that is waiting forever for something that will never arrive. The simplest way out of this possible problem is for you to keep an eye on the progress of the transfer and see when it appears to grind to a halt. The file transfer status display shows you a continuous count of the packets as they are transmitted and received: normally the number will increment steadily. If the number does not change for a significant time (and here you must bear in mind that the mainframe you are talking to may be running very slowly, so allow a good interval to pass), you can press the RETURN key once. This tells BBC KERMIT to drop whatever it was doing, and retransmit its last packet of data to the other end. If the other system was stuck waiting for data that had been lost, the retransmission will prod it into life, and the automatic recovery mechanisms of KERMIT should allow the two ends to pick up the transfer from where it stopped. If you wish, you can automate this recovery by using the "timeout" facility of BBC KERMIT. This is described below in the section on "Advanced facilities" 5.10 ADVANCED FACILITIES BBC KERMIT permits you to use some more advanced techniques to control file transfers. Some of these facilities involve the remote KERMIT system, and it is possible that you will find a system that does not implement them, since they are fairly recent additions to the KERMIT specification. However, BBC KERMIT will be able to detect this, and will act accordingly. 5.10.1. Interrupting transfers If you discover that you don't want a transfer to continue for some reason, you may interrupt it at any point by pressing a control key. There are two possibilities here: 1. To interrupt one file Pressing CONTROL and X together will interrupt the sending or receiving of a file. If the file was one of a group (i.e. you have specified a wildcard character to one of the systems), BBC KERMIT and the remote system will carry on with the next file in the group. 2. To interrupt a group Pressing CONTROL and Z together will interrupt the sending and receiving of one file, as in (1) above. However, if the file was part of a group, the whole group is abandoned. As we saw earlier, transfer interruption uses some fairly recently devised KERMIT facilities. BBC KERMIT will notify the remote system that you wish to interrupt the transfer, and the remote system will acknowledge this if it supports the facility. However, if it does not support the interrupt facility, it will not respond correctly. When BBC KERMIT detects this situation, it will use a different method to abort the transfer, by simulating an irrecoverable error. The transfer will be terminated as before, but here the systems will not be able to carry on to the next file of a group, so that CONTROL-X and CONTROL-Z will both have the same effect. A more drastic way of interrupting a transfer is to press the CONTROL and E keys together. This causes BBC KERMIT to notify the remote system of an irrecoverable error, which will cause a transfer to be abandoned. This technique, though, should really only be used if the transfer is going wrong in some way. If you interrupt the reception of a file into BBC KERMIT (or, indeed if an error such as "Disc full" or "Can't extend" occurs), you will be left with a file on disc that contains only part of the data that should have been sent. By default, BBC KERMIT will delete this partial file for you. If, though, you want to preserve whatever data has been transferred, you can issue the command SET INCOMPLETE KEEP after which BBC KERMIT will close the file normally and preserve it. You can re-instate the normal situation at any time with the command SET INCOMPLETE DELETE 5.10.2. Using timeouts As we saw above, it is possible to automate the detection that the transfer has stopped. This is done by defining "timeout periods": if one or other system has not received any data when its timeout expires, it will try to re-establish contact with the other. You control the use of timeouts in two ways. The first way enables you to tell the remote system what timeout interval it should use when receiving data from BBC KERMIT. This information is transmitted to the remote system when a transfer starts. By default, BBC KERMIT asks the remote system to use a timeout of 30 seconds, but you can change this with the SET SEND TIMEOUT command. Note, though, that the remote system may or may not do as it is asked: it may not support the timeout facility; it may ignore the value sent and use its own interval; or the timeout facility may need to be switched on by your giving it a command. BBC KERMIT can also timeout if data does not arrive from the remote system within a given interval. By default, the timeout facility is turned off, so BBC KERMIT will never time out. Issuing the command SET TIMER ON will switch the timeout facility on, and by default BBC KERMIT will time out if it has not received any data in 15 seconds. The SET RECEIVE TIMEOUT command lets you change this interval as required. You can turn the timeout facility off a any time with SET TIMER OFF Note that here the remote system may ask BBC KERMIT to use a specified timeout period when a transfer starts. BBC KERMIT, though, always ignores this request, and decides what to do on the basis of the SET commands you have issued. 5.10.3. File name translation As the preceding sections explained, a KERMIT program that sends a file will pass the receiving KERMIT a standard-form filename derived from the real name. Thus, a remote system may tell BBC KERMIT to receive a file called DATA.DAT which has the "normal" format "name.type". By default, BBC KERMIT will translate the filenames the other system sends it, in an attempt to form a name that is legal for the filing system in use. It will discard the dot and what follows it, and use the rest of the name as its basis. This approach is normally exactly what you require, especially for mainframe-to-micro transfers. However, sometimes you may be able to control the name the remote system sends, and may be able to ensure that it is a legal BBC filename without translation. For example, if you are sending a file from one BBC KERMIT to another, the sending command SEND MYFILE $.PROGRAM.LIST3 would pass the name "$.PROGRAM.LIST3" to the other machine - here you have told the sender the name to use rather than letting it generate a "name.type" form. In this case, you would tell the receiving system to use the name exactly as it is with the command SET FILE NAME UNTRANSLATED command. It will store the incoming data in a file called $.PROGRAM.LIST3 - it's up to you to make sure this really is a legal filename. You can restore the normal translation action at any time with the command SET FILE NAME NORMAL 5.10.4. Detailed protocol control The rules by which files are transferred between KERMIT systems are termed the "KERMIT protocol". These rules define in detail how data should be transferred: they specify how much can be sent in one chunk or packet; what control sequences indicate the start and end of a packet; what character encoding is to be used, and so on. In almost every case you will have no need to change any of these settings, since they are carefully chosen so that any KERMIT can communicate to any other KERMIT in just about every circumstance. However, it is possible that you may come across cases where you need to change some of the protocol values, either to improve the performance of the file transfer mechanism, or because the standard settings are inappropriate and do not work. The protocol values are changed by the SET command, and BBC KERMIT allows you to change all the possible values. The reference section details all the SET commands concerned and their effects. A detailed discussion of the various possibilities is beyond the scope of this user guide, though, since some understanding of the KERMIT protocol is needed. You will find this explained in the "KERMIT Protocol Manual" (Edition 5 or later); or you might contact the systems support personnel at your computer centre.