Q
1
S
Kermit
This
document
Abstract
describes the
Kermit
file
transfer
protocol as implemented at ICCC. Frank da Cruz and
Bill
Catchings wrote in Byte in June 1984: `A
communication
protocol
is
a
set
of
rules for handling
packets of
information; Kermit is not written
in
any
particular
language as it is not a portable program but a
portable
protocol.'
Bulletin: NOS Kermit
Authors: Allison Ballard
Paul Jarvis
October 1986
Q
1
LIST OF CONTENTS
Section
Page
1.
Introduction
1
1.1
Notation used
1
2.
Quick guide to using Kermit
3.
File types on the Cyber mainframe
2
3
3.1
Structured files
3.2
File formats supported by Kermit
4
4
4.
Understanding Kermit
5
4.1
Server mode
4.2
Local and remote
4.3
Error handling
6
6
6
5.
Running Kermit on the Cyber mainframes
6
5.1
Explanation of Set command parameters
7
6.
Extensions to the Kermit command
7.
Glossary
8
8
Appendix 1 - Running Kermit on an IBM PC/AT
9
Appendix 2 - Running Kermit on Zenith Z148s
10
Appendix 3 - Running Kermit on a BBC micro
11
Q
1
1
NOS Kermit
1. Introduction
Imperial College is typical of many institutions which
have a large
time-sharing computer and a number of smaller systems
within departments.
Thus, the need arises to transfer files between the central
computer and
the departmental systems. There is also a requirement to
transfer files
between different microcomputers that are available
throughout the college.
Kermit was developed at the Columbia University Centre
Computing
Activities (CUCCA) in 1981-82, largely by Bill Catchings and
Frank da Cruz.
It now runs on almost all the popular personal computers
and a wide range
of mainframe computers.
of
This document assumes that you are familiar with the Cyber
If
not you should refer to EXPLAIN, the on-line help facility,
to find out how
to manipulate files on the Cybers and how to ensure that
files are saved.
(See ICCC Bulletin number 2.4/6, available from the
Documentation Office.)
You will find information on how to run Kermit on
different micros in the
appendices at the end of this document.
mainframes.
1.1 Notation used
Any character or sequence of characters enclosed in angle
brackets, < > ,
means press the key so marked. E.g. < return >
means press the key
labelled return.
following
To indicate when you press two keys
notation is
used:
together
the
< ctrl + Y >
This means press the 'control' key and while you hold the
key down type the
Y key. Then release the control key. Do not type the angle
bracket keys on
the keyboard.
by
itself,
If you need to press two keys together followed by a third
the
following notation is used:
< ctrl + P > A
This means press the key labelled control and while you hold
this down type
the P key. Release both keys and then type the A key. Do not
type the angle
brackets on the keyboard.
Items enclosed
punctuation, are
optional.
in
square
brackets,
[]
including
any
2. Quick guide to using Kermit to transfer files
For a successful Kermit transfer two copies of Kermit are
required, one on
the local system and one on the remote system with
which you wish to
transfer files.
The following shows you how to transfer files between a
Cyber mainframe and
a BBC micro.
a.
Start Kermit on the BBC by typing:
*KERMIT
b.
In response to the Kermit prompt type:
Q
1
2
NOS Kermit
CONNECT
c.
Run Kermit on the Cyber by typing:
KERMIT
d.
Type in the micro Kermit's escape sequence
< ctrl + f0 >
to return to the micro.
e.
Type in required Kermit commands, for example:
SEND filename
to send a file to the mainframe
GET filename
to retrieve a file from the mainframe.
When you transfer a file, in either direction, you
must
ensure
that
the
correct
file
format is used. Failure to observe
this rule will
result
For
in
the
transferred
further
information see section 3.
file
being
unusable.
f.
Kermit when you
There
are
three
commands
you can use to exit from
have finished transferring files.
If you enter:
BYE
the Cyber Kermit finishes and you log
the
micro
off.
However,
is
still running Kermit.
If you enter
The
FINISH
Cyber Kermit terminates; however, you are still
logged in to the
mainframe and can now enter NOS commands. The micro is
still
running
Kermit.
If you enter
EXIT
The micro version of Kermit is terminated,
however, the mainframe
state is left unchanged. I.e. If you enter
'finish' followed by
'exit' then the mainframe will be waiting for a NOS
command and the
micro will also be waiting for a command.
3. File types on the Cyber mainframe
For those who are not used to the Cyber mainframe the
following section
describes some of the file types that are available. A
description of
Indirect access and Direct access files is given since some
large files may
need to be stored as Direct access files.
a)
Indirect access files ( IAF )
Q
1
3
NOS Kermit
These
are
by
far the most common type of file on
the system, about
99% of files are IAFs.
few
sectors
They are typically only a
long
and can contain all types of information, e.g. source
programs, data,
text.
a local copy of
When
you work on an IAF you are in fact using
the permanent file. If you change or create the local
version
of
a
file
you
have
to make it permanent if you want to
keep it. You can
have a number of versions of the same file, providing
you
give
each
version a different name and you have enough disk
space allocation.
IAFs
are created by SAVE and
REPLACE
commands and
retrieved by GET
and OLD commands. Because the local copy of the file
is temporary
in
nature, if you log off or your batch job
finishes the file is
destroyed. If you want to keep the local copy you can
either use the
REPLACE command, in which case the old permanent file
is overwritten,
or you can use the SAVE command and make a copy of
the file into a
new IAF with a new name.
Obviously, as a copy is involved each time the file is
accessed
the
system can take a long time retrieving large files.
For this reason a
limit of 256 sectors is placed on IAFs.
Above this
size you must use
a Direct access file.
b)
Direct access files ( DAF )
These are mainly used for files greater than 256
sectors in length
and for files transferred between computers with
File
the
Transfer
Protocol (FTP).
DAFs
ATTACH
are created and accessed with the DEFINE and
commands.
You act directly on a DAF, thus, if
contents
you
modify
the
your
changes take place immediately.
Because
DAFs
are not
accessed
via a local copy
they do have speed
advantages, but they cost more. This is a consequence
of the way they
are stored on disk. On our present hardware
disk
space
system,
is
assigned
to
DAFs in complete tracks,
each of 640
sectors. If a DAF
fills one track, another is assigned, so space is lost
to the
system
in
multiples
of
tracks
regardless of the actual
size of your DAF.
Hence, a DAF which is not a multiple of 640
in
length
sectors
has
some wasted space associated with it. In
contrast, an IAF only
occupies the space it needs. Therefore, DAFs are not
an efficient or
cost effective way of storing small files, since they
are charged to
your allocation according to the number of tracks
you use (i.e. in
multiples of 640 sectors). Obviously, to keep a DAF
you need an
allocation in excess of 512 sectors.
3.1 Structured files
Certain files on the Cybers are structured that is,
they may contain
pointers, within the file in order to ascertain where data
is located, or
they may contain delimiters which are not recognised by
Kermit. These files
cannot be transferred using Kermit.
N.B. most text files are not structured.
3.2 File formats supported by Kermit
Kermit only supports some of the many file formats that
are available on
the Cyber mainframes. Even with the reduced set available,
there are still
a number of pitfalls to avoid. A summary of the
supported file formats
follows. Further information can be found in the CDC
manuals, available for
short term loan or reference from the Documentation Office.
Q
1
4
NOS Kermit
DIS64.
This file format stores each received character as a sixbit quantity and,
hence, there are only 64 allowed characters. This is the
default file
format on the Cyber machines although Kermit defaults to
ASCII. DIS64 is
used by the FORTRAN compilers and so you should transfer
any such source
files using this file format.
There is one major flaw with this format and that is the
representation of
the 'end of line', which is '0000'. As a colon (':') is
stored as '00' two
or more consecutive colons could produce an 'end of
line'. Although this
may seem an unlikely occurrence, it can still cause obscure
errors.
ASCII
Kermit uses this file format by default. The full 128
character ASCII
standard is supported so that any text file from a micro can
be stored with
all characters remaining intact. Note that the Cyber
character size is six
bits so, in order to obtain the full 128 ASCII character
set, a convention
is used where by some ASCII characters are saved as two
Cyber mainframe
characters. For example, the character 'A' is stored as
'01' and the
character 'a' is stored as '7601'. The Cyber mainframe
file therefore
contains either six or twelve bits per ASCII character
and, hence, this
file format is often referred to as '6/12' format. When an
ASCII character
is stored as a twelve bit value, the first six bits are
either '74' or '76'
which correspond to the Cyber mainframe characters '@' and ^
(which have an
alternative twelve-bit representation). If an operation is
done on a file
and any resulting output has a liberal quantity of '@' or ^
characters then
it is reasonable to assume that the file is in ASCII
format. However there
is no absolute method of determining the file format.
ASCII8
This file format supports the full ASCII character set and
each character
is saved as its eight bit value. As the Cyber machines
use a 60 bit word
length, where eight bit values cannot be packed exactly,
each eight bit
ASCII character is saved within twelve bits. This means
that five ASCII
characters can be stored per machine word. This file
format is often
referred to as '8 in 12': eight data bits are saved in each
12 bits of the
popular
of
computer word. This file format is probably
those
supported by Kermit.
the
least
HEX
This is not a Cyber mainframe file format but one invented
specifically for
Kermit. If a file is transferred into a Cyber mainframe,
using one of the
above file formats, one or more blanks may be added at the
end of the file
to ensure that the file contains a complete number of
computer (60 bit)
words. If this file is subsequently transmitted back to the
source micro
these blanks will be sent so that the received file is not
identical to the
one sent. To overcome this problem you can use HEX mode.
This stores each
received ASCII character as two hexadecimal digits and will
only transmit
similarly coded files. Thus, the file returning to the
original micro will
be identical, although not particularly useful on the Cyber.
4. Understanding Kermit
The previous sections describe how to use Kermit for
transferring files
between a micro and the Cyber mainframes and file types
available. This
section introduces you to some of the concepts and tools
that Kermit uses
in order to achieve a successful transfer between a
number of different
types of micro and the Cyber mainframes.
packet
Kermit
contains
transfers
data
in
the
form
of
packets.
A
Q
1
5
NOS Kermit
information, in the form of characters, to enable Kermit to
both
commands and data. Generally, when one packet is
transmitted no further
transmission occurs until the receiving Kermit has
acknowledged that the
packet has been successfully transferred. Each packet
contains a sequence
exchange
number and length. The sequence number ensures that no
lost and
the packet length enables the end of the packet to be
located. The end of
the packet contains a check character, as defined by the
contents of the
packet, to enable error checking.
packet is
Kermit is very easy to use, but some people may find
it difficult to
understand that Kermit involves running two programs at the
same time on
two computers from the same terminal, and that one computer
will sometimes
pass on your commands to the other. To clarify this, let us
first describe
the different states or conditions each computer can enter.
Your micro can be in one of four states or conditions:
1
Not running Kermit
2
Running Kermit and expecting a command from you.
This is called Kermit command mode.
3
Running Kermit and pretending to be a normal terminal.
In this state it passes almost everything typed to
the Cyber. There
is a special 'escape character(s)' which restores the
micro back to
Kermit command mode.
4
Running Kermit, but not acting as a terminal nor
expecting a command.
In this state Kermit is exchanging information with
the Cyber in the
form of specially encoded packets.
At the same time the Cyber may also be in one of four
states:
1
2
3
4
Not connected to your micro, i.e. not logged in.
Connected to the micro but not running Kermit.
In this state the Cyber expects a normal NOS command.
Running Kermit and waiting for a Cyber Kermit command.
The Cyber is in Kermit command mode.
Running Kermit but not expecting a Cyber Kermit
command.
In this state the Cyber is expecting
code
to
exchange
information
with the micro.
4.1 Server mode
When using Kermit on the Cybers the default is to put
Kermit in server
mode. Server mode enables you to enter commands to the
Kermit running on
the micro which will then instruct the Cyber mainframe
accordingly.
If you do not use Server mode you must enter commands to
both the Kermit on
the micro and the Cybers.
You can, if you wish, use the Cyber mainframe in nonServer mode. This is
used if your micro has an implementation of Kermit that
cannot talk to
Servers. If you find that you cannot use the GET
command on your micro
Kermit, you will not be able to use Server mode to transfer
files.
4.2 Local and remote
In a lot of Kermit documentation, you will see references to
a local Kermit
and a remote Kermit. The local Kermit is the version of
Kermit available on
the machine that you are using to input commands, i.e. if
you are using a
micro in the Microlab, the local Kermit is the version
available on that
micro. The remote Kermit is the version of Kermit on the
machine that does
not receive direct input from you, i.e. if you are using
a micro in the
Microlab to transfer files to and from the Cyber
mainframes, the remote
Kermit is the Kermit on the Cyber. You have to go through
the local Kermit
Q
1
6
NOS Kermit
in order to issue commands to the remote Kermit.
4.3 Error handling
If an error occurs during transfer then Kermit
attempts to recover by
resending the corrupt or missing data. Many implementations
of Kermit will
display a re-try count which indicates the number of
recovery attempts.
Similarly, if transfer appears to stop then the sending
Kermit will be
asked to re-transmit its last packet. This will also
be counted as a
re-try. If this re-try count exceeds its limit then the
transfer will be
aborted. This limit may be 'set'
Kermit, see relevant
documentation for the Set command.
entering
for
the
5. Running Kermit on the Cyber mainframes
You start the Kermit program that resides on the
the
command:
micro
system
by
KERMIT.
This command will start Kermit running in Server mode,
using the default
parameters, as indicated below. Should you need to
change any of the
parameters from their default values then use the
alternative form:
KERMIT,I.
This will initialize an interactive dialogue.
After the prompt:
NOS KERMIT >
you can specify any of the following:
Command
Parameters
-------
----------------------------------------------
Default
------SET
CODE
DIS64
ASCII
(set 6 bit display code)
(set 6/12 display code)
ASCII8
HEX
(set 8 in 12 ascii)
(set hex pair code)
OFF
(deselect debug logging)
ON
(select debug logging)
n
(set delay time to n seconds)
LOCAL
SAVE
(leave files local)
(save files, do not replace)
REPLACE
(replace files)
OFF
(deselect windowing option)
*
DEBUG
*
DELAY
0
MODE
*
WINDOW
8)
ON
(select default window size of
SIZE m
(set window size to m where
*
0<m<32)
SEND
filename
(transmit file to remote micro)
RECEIVE
(wait for incoming file)
SERVER
(enter server mode)
*
Q
1
7
NOS Kermit
QUIT
(terminate interactive dialogue
and Kermit)
VERSION
(print out the Kermit version
number)
at the
end
You should only enter the commands send, receive and server
of
your input as they terminate the interactive dialogue.
5.1 Explanation of Set command parameters
SET CODE
This selects the Cyber file format to be used for all
subsequent transfers.
SET DEBUG
Used mainly for developing the Kermit program itself;
however, may prove
useful for diagnostic purposes. When Debug is selected,
all input and
output to the Cyber is also written to a local file;
by default the
filename is zzzzdbg.
SET DELAY
This parameter is only used in conjunction with the
send command. It
specifies the time to wait after the send command has been
entered before
the transfer starts. This will allow you enough time to
prepare the local
micro for receiving a file.
SET MODE
This allows you to specify whether an incoming file is
to be kept as a
local file on the Cyber, or saved or replaced. If you save a
file and one
of the same name already exists, the name of the incoming
file is altered
by the addition of a decimal number. If you specify
replace then any
existing file of the same name is overwritten.
SET WINDOW
Windowing is an extension to the basic Kermit protocol
and is currently
supported on few micros. It enables more than one packet
acknowledgement to
be outstanding and results in a faster data transfer.
Generally, the larger
the window size, the faster the transfer.
If windowing is requested but the micro cannot support it,
this is resolved
at the start of the transfer and windowing is not used.
6. Extensions to the Kermit command
The full Kermit command is of the form:
KERMIT[,I=lfn1][,D=lfn2][,L=lfn3].[cmd1][/cmd2][...
where:
lfn1 is the name of a local file which contains Kermit
of the
form given in section 5.1. If omitted, the file
zzzzcmd is used, if
it is local. An I on its own defaults to the
interactive dialogue
described in section 5.1 and is equivalent to I=input.
directives
lfn2 is the name of the local file which is
produced when debug is
selected. This file contains a copy of all packets
received and
transmitted by the Cyber; by default the filename is
zzzzdbg.
lfn3
equivalent of a
is
the
name
of
the
local file which contains the
Q
1
8
NOS Kermit
dayfile
of
the
Kermit session. It lists all the
directives entered
and all files transferred. This is particularly useful
if you try and
save a file with the same name as an existing
these
circumstances the Cyber will invent a new name for
the file and this
will be written into the log file; by default
this filename is
zzzzlog.
file.
Under
cmd1 is a Kermit directive of the form given in
section 5.1. Note,
however, if input directives are also to be read from
an input file
then those in the input file will be processed first.
The opposite is
true if you are in interactive mode, that is,
those on the Kermit
command will be executed first.
cmd2
machine
is
as above.
7. Glossary
LOCAL:
When two machines are connected the local
the one
which you interact with directly.
PACKET:
characters,
of
A
Packet
is
a
clearly
delimited
string
consisting of a control field nested around
data.
The
control
fields allow a KERMIT program to determine
whether the data has
been transmitted correctly and completely. A
Packet is the unit
of transmission in the KERMIT protocol.
side
of
REMOTE:
the
The
remote
machine
is
connection; you interact
machine
by
the
with
one
the
on
the
far
remote
going
through the local device.
SERVER:
accept commands in
An
implementation of remote Kermit that can
packet form from a local Kermit program,
instead
of
directly
from the user.
TIMEOUT:
does not arrive
A
timeout
event
can
occur
if expected data
within a specified periond of time. The program
generating
the
input
request
can
set a 'timer interrupt' to
break it out of
non-responsive
procedures
can
read,
so
that
recovery
be
activated.
Q
1
9
NOS Kermit
Appendix 1 - Running Kermit on an IBM PC/AT
1. Using Kermit when running Procomm
If you are running Procomm on an IBM PC/AT and wish to
use Kermit you
cannot use Kermit on the Cyber in Server mode. You must,
therefore, issue
commands to both Kermits. Procomm at level 2.2 and
higher contains a
version of Kermit that permits windowing. This
increases throughput
providing the other Kermit can also support windows. The
Cyber Kermit will
support windowing.
Sending a file to the Cyber
1.
Log in to the Cyber in the normal way; when the
Cyber asks you for
your terminal type you should enter VDU. Once you
have logged into
the Cyber start Kermit by typing:
KERMIT.RECEIVE
If
you
want
to
enter any other optional commands
you should enter
these interactively or as follows:
KERMIT.COMMAND/COMMAND1/COMMAND2/RECEIVE
This starts the Cyber Kermit and places it in receive
mode, expecting
a file from a micro.
2.
display a menu
which
Press the PgUp key on the right-hand keypad. This will
of possible transfer protocols. Type the number 2
select
Kermit.
will
After
selecting
Kermit,
you
must enter the name of
the file to be
transferred. The screen display will then show the
progress
of
the
transfer.
3
On completetion of transfer Procomm will revert to
terminal emulation
mode.
Sending a file from the Cyber
1.
Log in to the Cyber and start Kermit, using
interactive mode, or an
input file containing Kermit directives, see section
6. Since Procomm
cannot converse with a Server the following commands
must be issued:
SET DELAY 2
SEND filename
press
the
2.
PgDn
After issuing a Send command you must, immediately,
key
on
the
right-hand keypad and the number 2 to
select the Kermit
protocol. The screen will then show the progress of
the transfer and,
on completion, Procomm will revert to terminal
emulation mode.
in
the
Warning:
When using Procomm version 2.2 or earlier there is an
flow
error
control which can result in packets being corrupted if
you are network
connected. To reduce this problem you are advised to use
the command SET
WINDOW SIZE 2.
Q
1
10
NOS Kermit
Appendix 2 - Using Kermit on the Zenith Z148s
Transferring a file from the Cyber to the Zenith
1.
First start Kermit on the Zenith by typing:
KERMIT
your
2.
default
After the Kermit Prompt, KERMIT-MS >
disk
drive
you
should
set
to drive B, the drive containing your
data disk, not the
system disk. To do this enter:
SET DEFA B:
3.
Now connect to the Cyber by typing:
C < return >
your
4.
terminal
Log in to the Cyber as usual; when the Cyber asks for
type
you
should enter VDU. The system prompt, /,
will now appear on
your screen.
5.
To run Kermit on the Cyber you enter:
KERMIT.
6.
Now escape back to the Zenith by typing:
< ctrl + ] > C
This will return you to the Micro Kermit prompt.
7.
To transfer a file from the Cyber to the Zenith enter:
GET filename
the session
8.
as
When you have finished using Kermit you should finish
described in section 2.
Transferring a file to the Cybers
1.
Follow steps 1-6 above.
2.
To send a file to the Cyber enter:
SEND filename
3.
Finish the session as described in section 2.
Q
1
11
NOS Kermit
Appendix 3 - Using Kermit on a BBC Micro
Transferring a file from the BBC to the Cyber
1.
Start running Kermit on your micro by typing:
*KERMIT
2.
In response to the Kermit prompt type:
CONNECT
3.
Run Kermit on the Cyber by typing:
4.
KERMIT.
Type in the micro Kermit's escape sequence
< ctrl + f0 >
to return to the micro.
5.
To send a file to the Cyber enter:
SEND filename
6.
Finish the Kermit session as described in section 2.
Transfering a file from the Cyber to the micro
1.
Follow steps 1-4 above.
2.
should now enter:
To transfer a file from the Cyber to the micro you
GET filename
3.
2.
Terminate the Kermit session as described in section