kermit.columbia.edu/kermit.columbia.edu.tar/kermit.columbia.edu/researchmachines/rmlnoddoc.txt

Text File | 1985-07-10 | 21KB | 423 lines

File RMKNODDY.DOC
-----------------        Chris Kennington    9th July 1985.



        Noddy Guide to the Use of KERMIT on
        -----------------------------------

           RML 480Z and Nimbus Computers
          ------------------------------


0.  Summary.
    --------

     This guide tries to set out simply the steps needed to use a 480Z
or Nimbus micro as a terminal to a mainframe computer or to transfer
files between two micros or a micro and a mainframe.  The Kermit system
used is copyrighted by the University of Columbia, New York.  They
have produced a very full User Manual, a shortened version of which
is in the file KUSER.DOC.  This gives a lot more explanation on some of
the points covered below.  The RM Kermit program is described fully in
the file RMKINFO.DOC.



1.  Kermit - What It Does.
    ----------------------

     The Kermit program lets you use a micro as a fairly standard terminal
to (almost) any mainframe computer which runs a terminal system.  "Mainframe"
here means anything from a Cray II down to a 68000 running Unix(TM).  To
use Kermit in this way no special facilities at all are needed on the
mainframe.

     The more important part of Kermit is that it also lets you transfer
files between a micro and a mainframe, or between two micros.  To do this
requires a version of the Kermit program running at both ends of the
connection.  RML supplies Kermits for both 480Z and Nimbus; a version for
later-model 380Zs is available from the University of Oxford.  Kermits
have been written by various people for almost every micro and mainframe
under the sun (except ICL equipment).  U. of Columbia maintain a distribution
service at nominal cost.  In the U.K. educational users can get versions
from the University of Lancaster.  Other groups which can help include
DECUS (the DEC user organization) and the IBM-PC User Group.

     When sending files from one computer to another, Kermit makes sure that
if the file is received at all it is received correctly.  The files can
be either printable (text) files, which consist of normal printing
characters and a few control-characters such as RETURN; or they can be
binary files of any sort.  They must however be "sequential" files;
"direct-access" files as used by some special programs cannot be moved
between computers by Kermit.



2.  Using the Menus.
    ----------------

     When Kermit starts up, it displays a menu called "KERMIT MAIN MENU".
This show you the different sorts of things it can do.  There are two
other menus, "COMMANDS to SERVER" and the parameter-menu.  All work in
much the same way.  An arrow on the right shows which item is currently
selected; you can move this arow up and down by the up- and down-arrow
keys, or by F1 and F3, or by PG UP and PG DOWN.

     The main and server menus get all their options on one screen.
All you do is move the arrow and when it is on the correct line hit
RETURN (480Z) or ENTER (Nimbus) to do what you want.  The parameter menu
is more complicated; not only does it have many more parameters than
can fit on the screen, but each parameter has values you can change.
Using the arrow and F keys moves both the indicating arrow and the
selection of parameters on display so that you can get at all of them.
The current value of each parameter is displayed on the right of its
name.  These values are changed by using the right- and left-arrow
keys.  You should change any and all the parameters which you wish
to, then hit RETURN or ENTER to get back to the main menu and do something
useful.

     When you are viewing any menu, the bottom 5 lines are reserved for
some helpful comments.  With the main and server menus these change as
you go up and down the menu.  With the parameter menu you must enter
"?" to get up the appropriate help-text.  In either case entering "H"
will get you some general help on how to use the system.



3.  Getting Started.
    ----------------

     Make sure that you have got the correct version of RM Kermit for
the 480Z or Nimbus that you are using.  There are different versions
according to the way the communications-line is plugged in; this is
described in the main documentation-file RMKINFO.DOC.  Run Kermit
just as you would any other program, by typing its name (which may
be KERMIT or else some recognizable derivative such as AKMIT21).
If you are using a Nimbus with Piconet you will fiorst have to tell
Kermit the address of the Piconet module which is connecting you to the
other computer.  Kermit will then come up with its main menu and some
header information; check the item in the lower right corner
"Communications:" to make sure that it corresponds with where your
communications-cable is plugged in.  If it doesn't, get a new Kermit
or a new communications-cable.

     The first thing that you need to do is make sure that you can
actually send and receive characters to/from the other computer.
All Kermit transfers require that you can both send and receive, so
you will have to have a "full-duplex" cable connecting your micro to
the other computer.  (This means that a "half-duplex" cable as used
to connect some printers to micros is not suitable.)    Anyway, make
sure that the cable used to connect the two computers is plugged into
the right ports at both ends.

     There are two other fundamentals on which the computers must
agree - line-speed and parity.  (Speed, measured in "baud", is the effective
electronic frequency used on the connecting cable; parity describes the way
that the 7-bit characters usually used for text are converted to and from
the 8-bit characters sent on the communications line.)
If the other computer is a mainframe, it will have firm
ideas about these things and you can only set your micro-Kermit to agree.
If you are running between two micros, then both must be set to the
same values; if you have control in this way, use parity OFF and the
fastest line-speed supplied.  (If you are connecting to the other computer
through a network or switching system, this may alter the speed and
parity setting you have to use; ask the people who run it.)

     When you think that everything is correctly set, select "Connect
to Mainframe" on the main menu and hit RETURN/ENTER.  Kermit will
tell you that it is connecting you, and from then on everything you
type will be sent and anything received will be shown on the screen.
Your own type-in will not be shown on the screen unless you have
set the parameter "Local Echo" to ON.  If you are connected to a mainframe,
type RETURN/ENTER (several times) and you should get whatever message
it habitually displays to a newly-connected terminal.  If you are
connected to another micro, type some text and see whether it is
displayed on the other screen; do this in both directions.  If
these activities produce no result whatsoever, then you
do not have contact.  Check that all the parameters are correctly
set and the bits-and-pieces of equipment firmly plugged together
and all computers alive.  If everything checks out, but you still
don't get any response, you need help from your communications
people.  Carry on with this document after they have sorted you out.
If you are working to a mainframe and it gives ridiculous messages,
try other settings of parity.

     When you are connected, all normal keys work like they would on
a real terminal.  The Kermit program will only pay attention if you
hit the F4 key (or on Nimbus also F6 to F10).  Hitting this causes
Kermit to wake up and show a prompt "KmESC>" or "KmF4>".  It then
expects you to give it either 1 or 2 more charcters to tell it what to
do.  The full possibilities are described in RMKINFO.DOC, but a
summary can be obtained by hitting ? after the prompt.  (This
procedure is called "breaking in".)  The two most important
possibilites at this point are to hit K after the prompt, which will
get you back to the main menu, or Q which will let you cancel Kermit
and run another program.  If you didn't mean to break in, hit
RETURN/ENTER.



4.  Transferring Files.
    -------------------

     To transfer files you need to have a Kermit running at each end of
the connection.  With two micros this just means loading Kermit into
each separately, from its own keyboard.  With a mainframe it means
connecting (as described above) and then working as a terminal until
you have logged in and gone through any other work needed before
you can start Kermit on the mainframe (or link to it if it is a
permanently-running type).  You will also need to know something about
how to run the mainframe Kermit - consult its helptexts or the
mainframe user documentation.  In particular, find out whether it is
a "server" or not.  Mainframe Kermits which are servers need only to
be set going and then will take all their instructions from the Kermit
running in the micro.  Other mainframe Kermits ( "simple" ones)
need to be told what to do while you are still connected as a terminal,
before you tell your micro Kermit what to do.

     Many mainframe Kermits work in an interactive manner.  This means
that, while you are connected, they accept commands one at a time and
send you back a response for each.  Others expect all their command
information to be entered on the "command-line" which you type in to
start them going.  In this case you have to go out of "connect" as
soon as the mainframe Kermit starts to run.

     (The official Kermit jargon for the two ends of the Kermit-Kermit
link-up is that the one running in the micro, to which you talk
directly, is the "local" Kermit; the one on the mainframe is a
"remote" Kermit.  This is fine until you connect two micro-Kermits,
at which point you really have two locals.  However, everything still
works O.K.)



5.  Micro-Micro Transfers.
    ----------------------

     Unless you are using two RML micros, you will need to get the
instructions for the other micro's Kermit and talk to it in the way
it understands.  The details of the instructions below apply only
to RM (480Z and Nimbus) Kermits.

     Once you have tested out the micro-micro link in connect-mode,
you can arrange for files to be transferred.  Obviously, one Kermit
has to send and the other to receive.  In general you have to tell
each micro what to do from its own keyboard; things tend to work
better if you set the receiving end going first.

     To prepare RM Kermit to receive files, use "F4 k" to get back to the
main menu and select the option "Receiving Files".  Hit RETURN/ENTER, and
you will be asked whether you wish to have them stored under their own names.
Usually this is so, and all you need do is hit RETURN/ENTER again.  If however
you know that the names which the other Kermit will send are for some
reason unsuitable, you can enter one or more replacement names (separated
by spaces).  End the list with RETURN/ENTER and Kermit will start
listening for the other end to get going.  It will receive as many
files in one go as the other Kermit cares to send.

     To prepare RM Kermit to send files, select the main-menu item
"Sending Files".  You will be asked to enter a list of filenames.
Type these in (in either capitals or lower-case), separating the names
by spaces and ending with RETURN/ENTER.  You can use the "wildcard"
characters "?" and "*" to get Kermit to look on the disk and see what
files there are to send (in which case it will tell you what it found).
Up to 8 files can be sent in one go (but not more than one lot of
wildcards or 80 characters on the whole line).  The files are kept
separate, and will end up at the receiving end as separate files
under their own names (or reasonable derivatives thereof).

     Once both ends are going, they will get in touch with each other,
exchange some housekeeping information and the filenames, and then
transfer the file(s).  RM Kermit will show a dot on the screen for each
good block of data transferred (about 90 characters), and will also
display the letters D, T, C and N to indicate various sorts of trouble.
Kermit knows how to recover from problems in the communications, so
provided there are only a small scattering of alphabetics mixed with the
dots, you have nothing to worry about.  If there are a very large
proportion of error-letters, the connection must be very bad and it
is probably wise to kill the transfer, disconnect, and start again
from the beginning.

     When a transfer is in progress, the name of the file being
transferred is shown on line 3 of the screen, and some counts of
activity so far on lines 3 & 4.  Messages are also displayed on the lower
part of the screen as each significant event takes place.

     If the message "trying..." is repeated again and again, or if instead
of dots only T's are displayed, it means that your local
Kermit cannot get in touch with the other one.  Go back to connect-mode,
make sure the other Kermit has not collapsed and start again.



6.  Transfers with a Mainframe Server.
    ----------------------------------

     If the remote mainframe Kermit has a server-mode (sometimes called
automatic), then there is no need to talk to it in connect-mode once
you have got it started.  Get out of connect-mode on your local RM Kermit
by "F4 K" and select "Commands to Server" from the main menu.  As soon
as you enter this mode, you will have the command menu displayed.  The
important items here are "Get Files" and "Sending Files".  Select
whichever of these is appropriate.

     "Get Files" requests you to type in a list of filenames which you
want the mainframe to send you.  This has to be typed in exactly as you
would have done to any other program RUNNING ON THE MAINFRAME.  The list
will be sent to the other end exactly as you type it.  Whether you can
use wildcards, whether you should use upper or lower case etc. depends
entirely on the mainframe's habits.  End the list wih RETURN/ENTER and
the two Kermits will sort matters out between them.  Before the files
are actually received you will have the same query "Store under own
names - Yes?" which was noted above, and it must be answered in the
same way.

     "Sending Files" works in apparently the same way as the sending
process described between two micros.

     The actual transfer proceeds just as it did between two micros.

     At the end of a transfer, you will be asked to enter any character
before Kermit returns you to the command menu.  The pause is to allow
you to read the various messages before the menu wipes them out.



7.  Transfers with a Simple Mainframe Kermit.
    -----------------------------------------

     If the mainframe Kermit does not have server abilities, you must use
it in simple mode.  This is just like the micro-micro transfer except that
you work with RM Kermit in connect-mode as a terminal of the mainframe
until you have finished telling the mainframe Kermit what you want it
to do (i.e. send files or receive files).  When you have achieved this,
the mainframe Kermit will switch into "send" or "receive" mode and probably
put some strange characters on your screen; this is it prodding your local
Kermit to see if it is yet ready.  You should enter "F4 K" to get back to
the main menu, then select "Sending Files" or "Receiving Files" as
appropriate, then carry on as between micros.  (It goes without saying
that if the mainframe is set to receive, the micro must send, and vice versa.
Both sending or both receiving may lead to an error or just to an unlimited
sequence of "trying..." messages ot T's, or to nothing.)

     At the end of a transfer with a simple mainframe Kermit, you are again
given a chance to read the completion messages before being returned to the
main menu.



8.  Errors and General Snafus.
    --------------------------

     Provided that the two Kermits can talk to each other, they will
start to transfer the file.  However, things can go wrong.  The sender
will have made sure the first file exists before starting, but one of
the others in its list could be missing; or the receiver may be unable
to store the file; or there may be disk errors.  In any of these cases,
one end or the other may decide that it can no longer carry on.  It will
then try to send an error-message to the other end before collapsing
gracefully.  RM Kermit will display any such error-message that it
either sends or receives before going back to one of the menus.

     If the transfer which collapsed was a file-receive, RM Kermit will
close the file normally and leave it on the disk in its incomplete state.
Not all Kermits behave this way; some will remove the partial file, and
others have parameter-settings which allow the user to decide in advance
what should be done.

     You can force a transfer to be aborted by hitting F4 or ESC and
then A.  Kermit will query you to make sure that you really wish to abort
the transfer; if you answer Y or just hit RETURN/ENTER, it will be aborted;
hitting anything else will allow it to carry on.  Similarly hitting CTRL-C
at any time will give you a chance to cancel either the transfer or
the whole Kermit program (after giving confirmation).

     It is always possible for a communications-line to collapse,
particularly across a network.  If this happens, Kermit will try 10
times to send or acknowledge the last block of data, at intervals of
about 10 seconds, displaying a "T" on the screen each time.  Eventually
it will abort (as explained above).  To cut this process short you can
enter "ESC A", just as though you were killing a transfer which was
proceeding normally.



9.  Disks and Names.
    ----------------

     Filesystems on different micros and mainframes have very different
ideas about what files should be called and where to put or look for them.
Kermit in general ignores all parts of a filename except its principal
name, which is usually the last part of the complete name; and
converts this to upper-case letters.  (E.g. a file
in unix might have a full name "/44d/staff/cjk/documents/blurb", Kermit
would send this under the name "BLURB"; an MSDOS file might be
"B:DEMO\DUCKS.BAS", which Kermit would send as "DUCKS.BAS".)
This means that the CP/M disk-letter and user-number and the
MSDOS disk-letter and path do not get included in the names of
files received.  You have to set these up before starting the
transfer.   They can be set before loading Kermit in the micro,
or in the Kermit disk-maintenance mode (described in RMKINFO.DOC).
A special case is that, when receiving, you can enter a disk-letter
(complete with its trailing semicolon) in reply to the query
"Store under own names - Yes?".  If you do this, all files in the
current batch will be stored on that disk but with the names which
were sent with them.

     Names can come in from mainframe Kermits which have odd characters
in them.  To prevent trouble on the disks, RM Kermit checks all
incoming names to make sure that they are in CP/M or MSDOS format
and consist only of alphanumerics, "$" and the single dot which separates
the two parts of the name.  Filenames which break these rules are altered
so that they conform.  When a file starts to come in, Kermit tells
you both the name sent with it and the name under which it is
being stored.

     It is a nuisance if an incoming file overwrites one on the disk
with the same name but different contents.  RM Kermit therefore checks to
see if the name duplicates one already on disk.  If it does, then
Kermit changes the name of the new file before storing it.  The details
of this are reported to you as they happen.  (You can change the way
this works by altering the parameter "File Collision".)



10.  Binary Files.
     -------------

     The majority of files transferred by Kermit are of text, so it is
set up by default to handle such files.  This is controlled by the
parameter "8th-bit mode", where the setting "7-bit stripped" is
right for text files.

     If you want to transfer binary files (ones in which the bytes
may have any value from 0 to 255), this can be done in two ways.
The better way is to use setting "8-bit prefixed"; this is certain
to result in a good transfer if the other Kermit agrees to do it.
Unfortunately not all Kermits can handle this part of the protocol;
if the mainframe Kermit does not agree to use prefixed mode, you
will get a warning message and should assume that the transfer
will probably produce garbage.  An alternative is to use "8-bit image".
This assumes that 8-bit characters (values 128-255) will be received
correctly as sent, a reasonable assumption over a piece of wire
between two micros but very uncertain over complicated connections.
The drawback is that if the 8-bit characters are received wrong,
this may not be detected.  Some experimentation is called for.
In any case, it is likely that both Kermits will have to be informed
separately that image-mode is to be used; prefixed-mode is sorted out
automatically between the Kermits.



11.  Other Facilities.
     -----------------

     There are a number of other parameters on the parameter menu,
modes on the main menu and possible server commands in the command menu.
Some of these are fairly obvious.  All are described, at least briefly,
in RMKINFO.DOC.


    *********************************************************