⟦2ff0df046⟧

TextFile

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.@), and 
execute the procedure Install immediately within the load view (like 
Rev2_4_1.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 command window (job)
as the Kermit.Call that created it, or at least while that job is running.
When the job that executed Kermit.Call terminates, the Telnet connection 
will be automatically Cleared (like Kermit.Clear).

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

TROUBLESHOOTING
---------------
If Kermit.Send produces a log file like this:

88/08/02 16:41:46 --- Kermit.Send (Port 234).
88/08/02 16:41:49 --- Options => (...
88/08/02 16:41:49 ... 
88/08/02 16:41:50 --- Kermit.Send MY_SOURCE_FILE => ...
88/08/02 16:47:06 ++* Kermit.Send failed (TIMED_OUT).
                                                     
it means that the sending Kermit transmitted a data packet repeatedly but
didn't receive an acknowledging packet from the receiving Kermit.  This is
usually caused by a transmission path that damages packets in transit,
either with noise (common with modems), or by systematically modifying the
8th bit of every byte. 

You can often overcome these problems by changing Kermit options.  A
convenient way to change the options is to assign values to the fields of
the Kermit.Options record; be sure to make the assignment in the same
command window (job) as the Kermit.Send or Receive, as all options revert
to their default values at the beginning of a job.  If noise is the
problem, set

    Kermit.Options.Receive.Packet_Length := 50; -- or less
    
in the receiver machine before running Kermit.Receive in the same command. 
Smaller packet_lengths are more likely to work, but degrade performance. 
If the transmission path echoes, set

    Kermit.Options.Pause := 0.5; -- or more

in BOTH the sender and receiver machines before transferring.  A larger 
Pause is more likely it to work, but degrades performance.  Finally, if 
the transmission path passes only 7 data bits (modifying the 8th), set

    Kermit.Options.Physical.Bits := 7;
    
in BOTH the sender and receiver machines before transferring.  You can
combine all three settings for maximum robustness, but the resulting
performance will be poor.
DataMuseum.dk

Rational R1000/400 Tapes

⟦2ff0df046⟧ TextFile

Derivation

TextFile
