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.

