Kermit transfers files over a serial line; it is sort of a poor man's FTP
or Archive.Copy.  Although it lacks many features and is clumsy to use,
it does have the virtues that

  - there are COMPATIBLE implementations for a wide variety of machines, 
    including most mainframes and almost all PCs,
    
  - the required hardware (RS-232) is cheap, and
  
  - it works over dialup modems.
    
I have implemented Kermit in Ada, targeted for the Rational R1000.  It is
in the subsystem !Tools.Kermit.  I made some effort to write portable
code, but I have not actually tried to port it anywhere.

I know of no bugs in this code, although previous versions have had some,
and there are several features that are not implemented at all.  It has
been used for 'real work' with some success by various people.  I do
maintain it, but in my spare time, and sometimes slowly.  I get more
enthusiastic about working on it if you tell me about the neat things 
you want to do with it.

To install the Rational Kermit software, copy the spec view and at least
one compatible load view onto your machine (as !Tools.Kermit.@), get all
the Ada units coded, and execute the procedure Install immediately within
the load view (like Rev2_2_4.Install).  By default, Install puts command 
links into !machine.release.current.commands; if this is not in your search 
list you'll need to run Install with a different parameter value. 

To use Kermit, you must first set up a communication path between the two 
machines that are going to exchange files.  You'll need

  - an asynchronous RS-232 wire, or
  
  - an asynchronous RS-232 switching system, or
    
  - dialup modems, or
  
  - a Telnet/TCP/IP/Ethernet network, or
  
  - any combination of the above
  
that can connect the two machines.  There are lots of other esoteric 
possibilities, but you get the idea.

You run Kermit commands from a command window.  The two most useful are
Kermit.Send, which sends a file from your Rational machine to somewhere
else; and Kermit.Receive, which receives a file from somewhere else and
stores it on your Rational machine.  There is also Kermit.Connect, which
connects your terminal to some other machine (so you can run Kermit
there); this is a bit like Telnet.Connect, except with RS-232 lines
instead of network connections.  You can run Kermit on top of a Telnet
connection; this happens naturally when you login to the Rational
Environment via Telnet, and you can also connect to other machines over
the network, using Kermit.Call and Kermit.Clear.

All the Kermit commands take a Port parameter, which is the port number
of either an RS-232 port or a Telnet port.  The default value is your own
port, that is, the port to which your terminal is connected.  This
default is appropriate for Send or Receive when you have logged in from
some other machine using its Kermit.  For other commands, you must
specify the port on your machine that is connected to the remote machine
with which you want to communicate.  You can pass the port number to each
command, or assign it to Kermit.Port to make it the new default;
Kermit.Call does the latter automatically.

The most convenient way to use Kermit it is to run it on non-Rational
machine (like a personal computer), using the Connect command to login to
a Rational machine.  Once you've done this, you can Kermit.Send or
Receive over the same port you're logged in on, and then quickly escape
back to your non-Rational machine to run the other half of the Kermit
protocol.  It is also possible to use the Rational Kermit.Connect command
to login to another machine, run Kermit, and then quickly escape back to
the Rational machine to run the other half of the Kermit protocol.  From
the Rational machine, you can Kermit.Connect to an RS-232 port.

Rational Kermit is a little unusual in that its 'commands' are callable
Ada procedures (you run them from a command window); whereas most Kermits
have a little command line interpreter with which you interact.  This has
advantages; for example you can write a little program that performs a
sequence of Kermit commands automatically.  However, if you prefer an
interpreter, Dave Kaelbling (DRK@Rational) has written one; see him for
details.

Instead of an RS-232 port, you can use Kermit.Call to connect a Telnet
port to another computer's Telnet server, and then Kermit.Connect to the
same port to interact with it (Kermit.Call changes the value of
Kermit.Port, so that Kermit.Connect will do the right thing by default).
There is a restriction with Kermit.Call, however: you must perform all
Kermit commands on a Telnet connection in the same job (command window)
as the Kermit.Call that created it.  When the job that executed
Kermit.Call terminates, the Telnet connection will be automatically
Cleared.

There are lots of Kermit protocol options, which you can usually ignore 
(the defaults are OK).  If you need a non-default value, you can write 
something like this in your command window:

    Kermit.Options.Physical.Bits := 7;
    Kermit.Send (...
    Kermit.Receive (...
    
Kermit.Options is a big record with a field for each option.  Every time
you run a command (elaborate Kermit) it gets initialized to the default
values, but you can change them as above.  With other Kermits, you would
run a Kermit command like 'set bits 7'.

I regret that I have not written a users' manual, however, there are good
general users' guides to Kermit available that should help a novice user
to get started.  I have a photocopy of one such manual, edited by Frank
da Cruz at Columbia.  A later edition has been published as a large
format paperback.  Perhaps if there is a need I could write a little
manual.

   -- John Kristian
      Rational
      4 May 1988