INDRA Note No.1792                                UCL  INDRA
                                                   INTERNAL
27th Aug 1985                                    Working Paper











                      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.                 10



            APPENDIX II - Kermit Availability.    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]                - 1 -           [IN1792, Aug 1985]


0.  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:                 No
    Remote operation:                Yes
    User Interface:                  Command-line
    Transfers text files:            Yes (CR/LF checks)
    Transfers binary files:          Yes (image/prefixed)
    Wildcard send:                   Yes (on command-line)
    ESC interruption:                Yes
    Filename collision avoidance:    No
    Can time out:                    Yes
    8th-bit prefixing:               Yes
    Repeat count prefixing:          Yes
    Alternate block checks:          No
    Terminal emulation:              No
    Communication settings:          Depends on system
    Transmit BREAK:                  No
    IBM communication:               No
    Diagnostic logging:              Yes
    Session logging:                 No
    Raw upload/download:             No
    Act as server:                   Yes
    Talk to server:                  No
    Advanced commands for servers:   No
    Local file management:           No
    Handle file attributes:          No
    Command/init files:              No
    Printer control:                 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 -           [IN1792, Aug 1985]


3.  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  -  send-flag
              r  -  receive-flag
              a  -  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  -  7-bit flag
              8  -  8-bit-prefixing flag
              i  -  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 I-
  packet 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 -           [IN1792, Aug 1985]


5.  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]                - 6 -           [IN1792, Aug 1985]


7.  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 compiler-
  dependent.  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 -           [IN1792, Aug 1985]


              APPENDIX I  -  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 end-
          of-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-of-
  distribution.  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 system-
  specific (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 command-
  line, 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 terminal-
  line 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 text-
  files 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 cpu-
  power of the system on which it is running.

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
















































[UCL Kermit]                - 12 -          [IN1792, Aug 1985]


            APPENDIX II  -  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]                - 13 -          [IN1792, Aug 1985]


2.  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 IBM-
  PC 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]                - 14 -          [IN1792, Aug 1985]


4.  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]                - 15 -          [IN1792, Aug 1985]


         APPENDIX III  -  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.

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