INDRA Note No.1792
UCL INDRA
INTERNAL
Working Paper
27th Aug 1985
U C L
K E R M I T
C. J. Kennington
ABSTRACT:
A description of UCL's portable
implementation of a mainframe Kermit
file-transfer system, with notes on how
to obtain and use copies of Kermit.
Department of Computer Science
University College London
[UCL Kermit]
- 1 -
[IN1792, Aug 1985]
CONTENTS
page
0.
Introduction.
1
1.
UCL Kermit.
1
2.
Invoking UCL Kermit.
2
3.
Command-Line Flags.
3
4.
Debug-File Handling
4
5.
CR/LF Expansion.
5
6.
Automatic (Server) Mode.
5
7.
Cancelling Kermit.
6
8.
Source Text and Dependent Routines.
6
9.
Operating System Assumptions.
7
APPENDIX I - The Kermit System.
8
1.
Kermit.
8
2.
UCL Kermit.
9
3.
Kermit Performance.
APPENDIX II - Kermit Availability.
10
12
1.
University of Columbia.
12
2.
UK Distribution.
12
3.
Other Sources.
13
4.
Information Distribution.
13
APPENDIX III - A Kermit Session.
15
[UCL Kermit]
0.
- 1 -
[IN1792, Aug 1985]
Introduction.
This document describes the version of Kermit
produced at University College London during the first half
of 1985. To avoid duplication, it is intended to serve
both as a chapter of the U. of Columbia Kermit Manual and
as a UCL internal document. General information about
Kermit is given in Appendix I, which should be read before
the rest of the document by those not familiar with Kermit
file-transfer and the Kermit world. Information about
obtaining and running Kermit programs on various micros
etc. is given in Appendix II. A simple guide to running a
Kermit session comprises Appendix III.
1.
UCL Kermit.
UCL Kermit is a fairly simple mainframe-only Kermit,
written at UCL at about the same time that 1985 C-Kermit
was being written at Columbia. It contains a certain
amount of the code from 1983 Unix-Kermit (as printed in the
1984 Kermit Protocol Manual), and its user-interface
derives also from that Kermit. It is being made available
generally because it is believed to have something to offer
in the fields of portability, diagnostic capacity, and
possibly efficiency. These matters are discussed further
in later parts of this document.
UCL Kermit Capabilities At A Glance:
Local operation:
Remote operation:
User Interface:
Transfers text files:
Transfers binary files:
Wildcard send:
ESC interruption:
Filename collision avoidance:
Can time out:
8th-bit prefixing:
Repeat count prefixing:
Alternate block checks:
Terminal emulation:
Communication settings:
Transmit BREAK:
IBM communication:
Diagnostic logging:
Session logging:
Raw upload/download:
Act as server:
Talk to server:
No
Yes
Command-line
Yes (CR/LF checks)
Yes (image/prefixed)
Yes (on command-line)
Yes
No
Yes
Yes
Yes
No
No
Depends on system
No
No
Yes
No
No
Yes
No
Advanced commands for servers:
Local file management:
Handle file attributes:
Command/init files:
Printer control:
No
No
No
No
No
[UCL Kermit]
- 2 -
[IN1792, Aug 1985]
UCL Kermit handles only the file-transfer aspects of
Kermit (including a modest Server capability). It has no
facilities for routing through the mainframe to work with
another (remote) Kermit, nor does it support the Kermit
"remote session" facilities. It is designed for an
environment in which effective terminal access to
mainframes is already available over general-purpose
networks.
Further development of UCL Kermit is unlikely. The
status of the code is "Copyright UCL and U. of Columbia",
but free permission is given to copy and use it for all
non-commercial purposes. Commercial use is governed by the
U. of Columbia regulations on the subject.
UCL Kermit has been developed on PDP 11/44s running
Unix(tm) (Berkeley 2.8), but has been ported to a number of
other systems. When discussing mainframe-system-oriented
matters, this document uses unix terminology, but the
principles remain valid even if the program has been ported
to a system with different characteristics
2.
Invoking UCL Kermit.
UCL Kermit runs as a normal unix program. It is
started by the user issuing a normal command-line to the
unix shell, and terminates when its work is finished,
leaving the user again in communication with the shell.
All its command-information comes from either the
parameters on the command-line invoking it, or by way of
commands from the local Kermit. It has no interactive
command mode, neither does it make use of any init-file to
alter its various defaults. It is fairly verbose, both
when starting up and when logging in its debug file. Where
appropriate, it identifies its output with the prefix
"KmUCL".
Kermit is invoked with a command-line of the following
format:kermit
[-flags] [-Ddebugfile] [filename(s)]
where the flags and debugfile are as described in the next
sections and the filenames are normal references to unix
files. Since the command-line is processed by the unix
shell, wildcards may be used in filenames as in any other
unix command. The filenames are included only in the case
where a "s" parameter (send files) is included in the
flags. The "-" preceding the flags is optional, but that
before the "D" is mandatory.
[UCL Kermit]
3.
- 3 -
[IN1792, Aug 1985]
Command-Line Flags.
The following flags are valid. Each consists of a
single lower-case character only. Where they define
mutually-exclusive actions, to include more than one from
the mutually-exclusive group constitutes an error, which is
detected. Invalid characters in the flags also consititues
an error. On detecting any such error, UCL Kermit displays
a short summary of the valid flag-codes and terminates.
s
r
a
-
send-flag
receive-flag
automatic-flag
These form a mutually exclusive group. UCL Kermit, after
outputting banners etc, switches to send, receive or
automatic (server) mode according to which one is entered.
If none is included in the flags, automatic is assumed.
Iff a "s"-flag has been included, then one of more
filenames must be appended. These specify the files to be
sent. Wildcards (as accepted by unix) may be included.
h
-
help-flag
(alternative: ?)
This flag overrides all others and causes 2 screensfull
(about 45 lines) of help-information to be displayed.
f
-
filename-conversion flag
If this flag is present, then the filenames sent will be
allowed to remain in upper or lower (or mixed) case, as
found on the disks. By default, UCL Kermit converts all
unix filenames (typically lower-case) to upper-case before
sending them as the name of the file to be transferred.
7
8
i
-
7-bit flag
8-bit-prefixing flag
binary-image flag
These form a mutually exclusive group. "7" specifies that
the files are to be treated as files of ASCII character
data; characters received are masked to 7 bits (discarding
any parity-bits) before storing, and characters sent have
the top bit zero; CR/LF expansion is activated (see section
5). "8" specifies that UCL Kermit should attempt to
negotiate 8th-bit prefixing with the local (micro) Kermit;
this is the default if no such flag is included. If the
local Kermit refuses to use 8th-bit prefixing, then the
transfer reverts to 7-bit mode as described above.
"i" (image-mode) specifies that the file is to be
sent/received as 8-bit characters. CR/LF expansion is
inhibited in 8th-bit prefixing and image-modes.
[UCL Kermit]
- 4 -
[IN1792, Aug 1985]
Repeat-count-prefixing (data-compression) is always
"on". It will be used if the local Kermit agrees. Use of
this facility makes no difference to the accuracy of the
transfer, but can materially affect the time needed.
4.
Debug-File Handling and Information Recorded.
The second (optional) parameter of the command-line
consists of a minus sign, one or more capital D's and the
name of a file into which debugging information is to be
written. If no debug is required, then the whole parameter
should be omitted. There may be up to three capital D's,
controlling the debugging level to be used; they are
followed without a space by the name of the file into which
debug is to be written. (This precludes the use of a file
whose name starts with a capital D.) A null filename is an
error and results in debug being switched off.
UCL Kermit always checks rigorously that incoming
packets conform to the Kermit protocol as laid down.
Protocol errors are always reported (in ERROR-packets) to
the local Kermit; if debug is switched on details will also
be logged in the debug file.
The debug file is opened in "append" mode, so that one
file may hold the debug output from several runs. At the
beginning and end of each run a banner is put into the file
so that the start of each run may be easily located. No
check is performed to prevent the debug-file from also
being specified as a file to be sent.
Level-1 debug (a single D) consists of a record of the
way in which the program is used, plus a note of the files
sent or received, packet by packet. The details of the Ipacket negotiation are logged; error-packets sent by or to
the local Kermit are also logged, as are the details of any
transmission errors which may be detected. Level 1 debug
is intended to serve as a record of activity and to
identify errors at the protocol level, especially when a
revised or new local Kermit is in use.
Level-2 debug (2 D's) prints in addition the details
of each packet as it is sent or received. It is intended
for use where there is some problem to do with the
formatting of the packets exchanged or the data in them.
Level-3 debug (3 D's) adds a subroutine-trace through
the program, plus a record of each character sent or
received on the communications line (in hex). The main use
of this is where there is a communications problem such
that no packets are ever received successfully, or some
packets are entirely lost.
[UCL Kermit]
5.
- 5 -
[IN1792, Aug 1985]
CR/LF Expansion.
In the case of 7-bit file transfers only, care is
taken to ensure that each line of text in the file is sent
terminated by a single CR/LF pair, and each line of text
received is terminated by a single LF before being stored.
If a file is found to contain strings of repeated or
intermixed CRs, LFs and CR/LF pairs, these are processed so
that each CR/LF or LF/CR, and each CR or LF which does not
pair with a LF or CR respectively, converts to a CR/LF pair
for transmission or a single LF for storage. This is
believed to be what is needed for all unix-based systems.
The routine which carries out this transformation is
included in the "machine-dependent" section (see below) so
that it may be easily modified if necessary when porting
the program to a new mainframe.
CR/LF expansion is essential if files are to be
transferred correctly between unix (which uses LF as a
line-terminator) and systems such as CP/M which use CR
instead. For this reason care should be taken that, if a
text-file is being transferred, 8th-bit-prefixing is not
accidentally switched on. See Appendix III.
6.
Automatic (Server) Mode.
When in automatic mode, UCL Kermit behaves as a rather
simple Kermit server. It is not really a server, since it
is running as the creature of the user-shell which invoked
it. It will accept the following commands from the local
Kermit:SEND - allow local Kermit to send files (as many as
the local Kermit may wish);
GET - send one or more files to the local Kermit; the
names should be entered into the get-request assuming the
path which was in existence when UCL Kermit was invoked; no
wildcards are allowed.
BYE and LOGOUT - both cause UCL Kermit to terminate
gracefully and leave the remote Kermit (if still online)
connected to the unix shell.
An ERROR packet
-
this has the same effect as BYE.
After automatic mode, as after send or receive modes,
UCL Kermit terminates like any other unix program, leaving
the shell in control.
[UCL Kermit]
7.
- 6 -
[IN1792, Aug 1985]
Cancelling Kermit.
Any error packet received at any time, or any
substantial protocol error, will cause UCL Kermit to
terminate (fairly) gracefully. Situations can, however,
arise where UCL Kermit has not received an error but the
local Kermit has failed or been inadvertently cancelled.
In these cases UCL Kermit will repeatedly time out, sending
a NAK (and a message in clear as well) each time it does
so. In all cases except automatic-mode, the timeouts will
eventually reach a limit and UCL Kermit will quit, but it
is not convenient to have to wait this long.
If the local Kermit has a "send-error-packet"
facility, this may be used to cancel UCL Kermit.
Alternatively, using the local Kermit in connect-mode, the
sequence "ESC-C" will be recognized and cause UCL Kermit to
abort gracefully, restoring the communications line to
"cooked" before it does so. The only time when this is not
effective is if UCL Kermit times out between the ESC and
the C.
8.
Source Text and Machine Dependent Routines.
The source of UCL Kermit consists of a single large
file of code which it is believed will run unchanged under
any operating system (subject to the provisos below) plus a
short file containing about 10 procedures which are thought
to be potentially machine- or system- or compilerdependent. These are fairly heavily commented, but the
following notes may be useful.
CR/LF processing is controlled by routines ascedit()
and ascout(). These are called whenever a CR or LF is
encountered in text-data to be sent or received
respectively. (See above, section 5.)
Errors when reading/writing data from/to disk are
controlled by routine filerr(), whose function is to return
a sensible error-code (for logging in the debug file and
reporting to the local Kermit), and to distinguish errors
from normal end-of-file conditions.
Routine flushinput() is called whenever there is a
need to discard characters already received.
Functions rawtty() and cooktty() are called when it is
necessary to convert the mode of the terminal connection
from that normally used by the system to one in which all
characters are passed to/from the program without editing.
Function unbuffer() is called during initiation to ensure
that input/output on the communications line is not delayed
e.g. by waiting for end-of-line characters.
[UCL Kermit]
- 7 -
[IN1792, Aug 1985]
The whole of the main character-input routine,
nextin(), is included in the machine-dependent section,
together with the the timeout-setting routine, timoset().
These interact because there is a fundamental difference
between systems in which a timeout expiring will cause an
unsatisfied character-read to abort and one in which it
will not. The "#ifdef" parameter "BSD42" controls which of
these situations is expected; but systems other than unix
may require yet other types of logic. The timeout handling
is intentionally kept very simple so that there is no
reliance on unix-oriented features of C such as "longjump".
9.
Operating System Assumptions.
In considering the portability of UCL Kermit, certain
assumptions were made about the environment in which it
would be running. These certainly include:-- that the system stores its files (or at least
retreives them from storage) in ASCII with line-terminators
rather than record-delimiters or carriage-control
characters;
-- that the system supports users on teletype-like
terminals, and that these terminal-users can invoke
programs and access files without unreasonable restraint;
-- that the terminal-line can be set into such a mode
that it will pass a character-set comprising all printable
characters plus SOH (01) transparently to and from the
user's program.
It is believed that UCL Kermit can be ported to any
system which meets these (and possibly a few other
unrecognized) criteria, with only a small amount of
attention to the routines discussed in section 8. The
author would be interested to receive reports from anyone
who carries out such porting.
********************************************
[UCL Kermit]
- 8 APPENDIX I
-
[IN1792, Aug 1985]
The Kermit System.
[This Appendix provides a general
description of Kermit file-transfer and the
way in which UCL Kermit fits into the
general picture.]
1.
Kermit.
Kermit is a system designed at the University of
Columbia, New York to permit file transfer between
computers, both micro and mainframe, and access to a
substantial proportion of a mainframe's file-handling and
general organizing ability. It requires no special
communications facilities beyone those normally provided
for direct "time-sharing" terminal access to a mainframe.
The U. of Columbia Kermit User Manual and Kermit Protocol
Manual provide the basic documentation of Kermit and
describe its facilities and a selection of its
implementations. A more general discussion of the reasons
which led to the production of Kermit is contained in an
edited version of an article from Byte magazine. All these
documents may be obtained from Columbia, but are also held
online at various centres (including, at the time of
writing, UCL). See Appendix II.
Kermit does not make use of the sort of reliable
connections over computer communications which are provided
by the various ISO and other protocols. It must be
considered to belong to an earlier generation of
communications activities. Its great advantage is that
there are now in existence implementations for almost the
whole range of general-purpose computers, micro mini and
mainframe, all of which can be expected to interwork
without difficulty. It therefore provides a practical
state-of-the-art solution to the problems of transferring
files between micro computers and mainframes, or between
micros of differing natures. The files transferred may be
either text or binary, but must be of a sequential nature.
Kermit protocol includes packet-numbering and
checksums with error-recovery to ensure that any file
transfer which completes normally will actually have
transferred a correct copy of the file. The only
exceptions to this general rule are:--
where 8-bit-image transfers are used, the 8th bit
may not be checked effectively.
--
where systems use different conventions for endof-line, CR/LF expansion must be activated (see
above section 5).
[UCL Kermit]
--
- 9 -
[IN1792, Aug 1985]
where a binary file (8-bit data) is to be
transferred, but one end or other has not
implemented the neccessary option.
Kermit also provides a mainframe-to-mainframe
capability, enabling a terminal user on one mainframe to
acquire a link to another and conduct a substantial remote
session on it, including file-transfer between the two. In
the U.S.A. this is apparently much used. The U.K. Academic
Community has a well-developed system of access to remote
mainframes, using X25 protocols. In this environment,
Kermit-based inter-mainframe working seems superfluous (and
likely to consume excessive resources). It is for this
reason, among others, that UCL Kermit has been designed to
a specification which is restricted compared with that used
for some of the American implementations.
Kermit is, of course, only one of a family of
protocols designed to transfer files between micros and
mainframes, mostly using rather similar techniques. Its
main advantages are widespread availability and the fact
that it is free. Kermit is not "public domain" but
"copyright, freely available"; as such all Kermits must be
made available either without charge or at cost-ofdistribution. This policy of Columbia's has resulted in
widespread distribution of Kermits as they have come into
existence. See also Appendix II.
2.
UCL Kermit.
UCL Kermit was produced at the Department of Computer
Science to provide at UCL a simple reliable Kermit to run
on all the Department's unix systems. The immediate
objective was the transfer of text files to and from
various micros (BBCs, Sirius etc.), but the opportunity was
taken to write a version which would move easily to almost
any environment in which asynchronous ASCII terminals were
supported for command-input. See sections 8 & 9 above.
Since there is in fact no real problem in letting
terminals at one UK academic site access the computers at
another (using JANET and X29), no facilities were provided
for routing through the mainframe to the outside world. In
Kermit terminology, this is a "remote-only" Kermit. This
policy also had the advantage of avoiding the areas in
which many facilities are provided in highly systemspecific (and hence non-portable) ways.
UCL Kermit used as a starting-point the C-coded
example version included in the Protocol Manual. This was
designed to run under unix, and does not provide a
conversational interface to the user. UCL Kermit therefore
also expects to get its full commands from an OS commandline, entering either file-transfer or automatic mode as
soon as it has output its informative banners.
[UCL Kermit]
- 10 -
[IN1792, Aug 1985]
While UCL Kermit was in gestation, Columbia released
their completely new C-Kermit, which provides almost all
possible Kermit facilities on a wide range of unix-like and
other systems. C-Kermit is a much fuller implementation
than UCL Kermit, and could be preferred in many
circumstances. The principal areas in which it is believed
that UCL Kermit scores are in ease of porting to new
systems and in its very full diagnostic tools (see above).
There may also be installations in which the system
managers would prefer not to provide the full Kermit
facilities to route through from one mainframe to another
over lines intended for terminal access.
3.
Kermit Performance.
Few systematic measurements of Kermit performance have
been published. The implementations for various computers
differ widely in techniques, languages and in the operating
systems for which they are designed. It is known that some
of the implementations for "generic" micros, e.g. those
running under CP/M, are cpu-intensive and cannot drive fast
communications lines. However, many of the more specific
Kermits are very efficient.
Since the data is transferred over a normal terminalline in asynchronous mode, the actual line speed (e.g. 960
char/sec for a 9600baud line) is an upper limit to the
possible character rate. This has to be reduced for the
overhead of the envelope of each packet and for the
acknowledgments, but these are arranged to be quite small.
Kermit data (except in image-mode) is encoded by a
prefixing system to allow control-characters and 8-bit
characters to be passed over a medium with a restricted
character-set. The degradation caused by this is
potentially large; but in practice the majority of textfiles incur quite low overheads (less than 10%) from this
encoding. Against this can be set the compression effected
by using repeat-counts, which can often be greater than 20%
in files such as formatted program source. The largest
delays are usually the inter-block times caused by
scheduling in the mainframe and by cross-network time on
long connections. Disk operations can also cause
substantial delays on some micro operating systems.
In good conditions, e.g. with back-to-back micros,
Kermit will often achieve net transfer rates greater than
60% of the limit imposed by the line-speed (i.e. more than
600 char/sec at 9600baud). Working between a micro and a
mainframe, provided that the latter is not so heavily
loaded as to show a degraded response time, rates greater
than 40% of line-speed have been observed. These speeds
cannot be expected to compare with those achieved by
protocols such as NIFTP over X25 using fast (48Kbaud)
lines, but are adequate for the majority of micro-mainframe
and micro-micro transfers.
[UCL Kermit]
- 11 -
[IN1792, Aug 1985]
It is perhaps more relevant to compare the transfer
speeds achieved by Kermit with those of other similar
micro-file-transfer systems. Kermit is believed to achieve
higher net transfer rates than most of its competitors.
UCL Kermit has been designed so that it will give high
performance while making only modest demands on the cpupower of the system on which it is running.
********************************************
[UCL Kermit]
- 12 APPENDIX II
-
[IN1792, Aug 1985]
Kermit Availability.
[This Appendix provides information on
the sources from which copies of Kermit
programs and further information about
Kermit may be obtained by users in the UK.]
1.
University of Columbia Distribution.
The Center for Computing Activities at the University
Of Columbia maintain a database containing copies of all
known Kermit implementations and documentation. This is
held online (on a TOPS-20 machine), accessible over ARPANET
as CU20B, using "anonymous ftp" and arpaftp protocol (log
in as "anonymous"). UK users can obtain further
information about use of Arpanet from the Liason section at
UCL Dept. of Computer Science. Columbia will also supply
copies of the bulk of this database on magnetic tape in
various formats at a distribution cost of (currently) 100
dollars. Printed copies of the User and Protocol Manuals
are available at (currently) 10 dollars each. Application
should be made to:Kermit Distribution
Center for Computing Activities
Columbia University
New York,
N.Y.
USA
10027
There are a number of other copies of this database
accessible in the USA, notably one held on a unix system
which can be reached via UUCP. Details are given
intermittently in the Columbia Kermit Information-Digests.
These are edited versions of electronic mail exchanged
between Columbia and Kermit users, plus announcements of
general interest etc. They are issued approximately weekly
by electronic mail to a mailing-list held at Columbia.
Various UK sites receive copies, including UCL and
Lancaster. Copies of all back issues are held in the
Columbia database.
[UCL Kermit]
2.
- 13 -
[IN1792, Aug 1985]
UK Distribution.
[This information is correct at time of writing but
obviously may change with time.]
The University of Lancaster obtain copies of the
Columbia distribution tapes several times a year and keep
the majority of the information available in a database on
their VAX computer. They also update this from time to
time by direct arpaftp transfers from Columbia. This
database is available to UK Academic Community over JANET
by NIFTP or Kermit. Further information may be obtained
from:Alan Phillips
The Computer Centre
University of Lancaster
LANCASTER
or by sending JANET mail to "syskermit@lancs.vax1", or by
telephoning 0524-65201 Xtn 4881.
Lancaster are themselves the authors of the
implementaion of Kermit for the BBC micro. They will
supply this on request either in a PROM or on floppy. They
are also able to supply on floppy the version for the IBMPC family (and clones). Kermit for Research Machines
micros (480Z and Nimbus) is obtainable from Tech. Support
at RML, Oxford. Kermit for Apricots is available form
Ralph Mitchell at Brunel University.
Versions of Kermit for PRIME computers are available
from Teesside Polytechnic; and for GEC 4000-series from
Paul Bryant at the Rutherford-Appleton Laboratory.
3.
Other Sources.
The Kermit fraternity is not highly organized; in
particular there is little contact in the UK between the
Academic and Commercial users. It is known however that
both DECUS and the IBM-PC User Group hold and distribute
copies of Kermit for the machines in which they are
interested.
Kermit is widely in use in the UK Academic community.
There are obvious bootstrapping problems in transferring a
Kermit from the disks at Lancaster to a micro, but most of
the micro-Kermits are probably now in use somewhere in the
UK. Any user wanting to obtain a copy on floopy of some
particular Kermit (not mentioned above) is advised to send
an appeal out to "info-kermit@ucl.cs". The Kermit
fraternity is supposed to practice self- and mutual-help.
[UCL Kermit]
4.
- 14 -
[IN1792, Aug 1985]
Information Distribution.
At the time of writing, UCL are maintaining a mail
distribution list "info-kermit@ucl.cs". Anyone who wishes
may send mail to this list, which contains names of some 50
UK Kermiteers. Requests for inclusion on the list should
be addressed to "cjk@ucl.cs". [This situation is likely to
change radically by early 1986.]
Both Lancaster and UCL hold copies of the Columbia
Information-Digests, which are accessible by NIFTP, Kermit
or normal login. For information on accessing the UCL
copies, contact Liason at UCL Dept. Computer Science. UCL
notify the info-kermit list as new issues are placed
online.
Lancaster issue "Mailshots" a few times a month to the
info-kermit distribution list giving information on current
activities.
********************************************
[UCL Kermit]
APPENDIX III
- 15 -
[IN1792, Aug 1985]
Running a Kermit Session.
[This Appendix assumes that Kermit is
being used between a micro and the UCL
systems. Much of it is obviously
applicable to other Kermit connections.]
Running a Kermit session is complicated by the fact
that the user, sitting at the keyboard of a micro, is in
contact both with the micro-OS (e.g. CP/M) plus the Kermit
running on it (called the "local Kermit"), and also with
the mainframe-OS (unix) plus the mainframe Kermit (UCL
Kermit). At any one time keyboard input will be going
either to the local system or to unix; screen output may
however contain information originating from both. The
behaviour of UCL Kermit is discussed above, and it is
assumed that the user has some familiarity with unix. The
behaviour of the local setup depends however on the actual
micro being used.
When obtaining the Kermit for the micro, you will have
acquired at least some instructions for running it.
Instructions for the most common micro-Kermits are also
included in the Columbia Kermit User Manual, a copy of
which is invaluable. Most micro-Kermits, however, work in
much the same way.
At the risk of stating the obvious, Kermit will not
run between micro and mainframe until the hardware
communications link has been established. If no other
software tools are available, put the micro-Kermit into
"connect" mode while doing this. When you have managed to
log on to the mainframe and list a file by "type", "cat" or
etc., then you are ready to proceed with file-transfers.
The micro-Kermit will probably supply four modes of
working:
-----
CONNECT, in which it behaves as a normal terminal;
SEND, in which it will transfer files to the
mainframe;
RECEIVE, in which it will accept incoming files
from the mainframe;
COMMAND, in which it will send commands to the
mainframe to send or get (receive) files
or do a number of other things.
It may be that COMMAND mode is in fact represented by a
number of commands such as GET etc.
[UCL Kermit]
- 16 -
[IN1792, Aug 1985]
CONNECT is used, working as a terminal, to log on to
the mainframe, do any necessary housekeeping and then start
the mainframe Kermit. It is probably also needed at the
end of the session for logging out etc. What sort of a
terminal the micro is emulating depends on the details of
the local Kermit.
SEND / RECEIVE and COMMAND represent two different
ways of using Kermit, which will be described separately.
UCL Kermit supports both; not all Kermits support COMMAND.
(COMMAND is often referred to as "Send Server Command"
mode, because the local Kermit is in fact sending
specially-formatted commands to the mainframe Kermit,
expecting it to be in "Server" mode. UCL Kermit's
"automatic" mode corresponds to this.)
To use SEND, you must first (while in CONNECT) start
UCL Kermit to receive files by a command-line such as:kermit
r7
After UCL Kermit's initial banners have been received, you
must escape out of CONNECT (see local Kermit instructions)
and issue a SEND command to the local Kermit. This will
probably prompt you for a list of files to be sent. When
this has been entered, the two Kermits should transfer the
files without more ado. Your micro-Kermit will give you
some information as to how the transfer is progressing; the
amount depends very much on which particular micro-Kermit
you are running. At the end of the transfer, UCL Kermit
will terminate and leave the unix shell in control. The
micro-Kermit will tell you that this has happenned. You
should put it back into CONNECT and carry on working unix.
To use RECEIVE, you must first (while in CONNECT)
start UCL Kermit to send files by a command-line such as:kermit
s7
foo data1 fudge*
After UCL Kermit's initial banners have been received, you
must escape out of CONNECT (see local Kermit instructions)
and issue a RECEIVE command to the local Kermit. The two
Kermits should then proceed much as they did for SEND, but
with the file going in the opposite direction. You end up
back with unix.
To use COMMAND (in whatever way the local Kermit
implements it), you must first (while in CONNECT) start up
UCL Kermit in automatic mode by a command-line such as:kermit
a7
The initial banners will tell you to send commands. Escape
back to your local Kermit and follow its instructions for
working with server Kermits. In this mode you can do a
succession of SENDs or GETs; UCL Kermit simply waits for
the next command. To get back to unix you have to use the
[UCL Kermit]
- 17 -
[IN1792, Aug 1985]
BYE or LOGOUT or FINISH command of the local Kermit (or go
into CONNECT and send ESC-C). Note that UCL Kermit does
not implement the esoteric commands such as DIR and FINGER;
to list directories or see who's online you must get back
to unix.
You are most likely to be transferring a text-file.
if this is the case, it is often essential that CR/LF
expansion is active (see above section 5). Therefore make
sure that one or other of the two Kermits is firmly set to
transfer 7-bit data. If both ends are set to deal with
8th-bit-prefixed (binary) data, then CR/LF expansion will
get switched off. UCL Kermit's default is 8th-bit-prefixed
(see section 2 above). See the instructions of the local
Kermit for its default and settings.
Unfortunately, as with all communications, lots can go
wrong. Discussing this is beyond the scope of this Note.
However, a sensible connection to unix (to let you start
again) should always be possible by escaping back into
CONNECT on the micro and sending ESC-C to UCL Kermit.
********************************************