Columbia Kermit/kermit.zip/e/mail.85a

Text File | 2020-01-01 | 478KB | 11,486 lines

 5-Feb-85 16:10:21-EST,5392;000000000001
Mail-From: SY.FDC created at  5-Feb-85 16:09:41
Date: Tue 5 Feb 85 16:09:41-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #1 -- New Unix Kermit
To: [e-mail]
cc: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Tue,  5 Feb 1985       Volume 2 : Number  1

  ANNOUNCEMENTS -
      New Unix Kermit Available for Testing

----------------------------------------------------------------------

My apologies for the long delay since the last issue of the Info-Kermit
Digest, which was Vol.1, No.46, dated 31 December 1984.  This first issue
of Volume 2 is to announce a test release of the new Unix Kermit.  In
subsequent issues, I'll attempt to catch up on other overdue items.

A new Kermit program has been written in C, initially for 4.2 Berkeley Unix.
The features of this program include:

. Full implementation of the Kermit protocol, except for Attribute packets:
  - Acts as server
  - Talks to server
  - All packet encoding and error checking options are provided
  - File transfer interruption
  - Filename collision avoidance
  - Binary and text file transfer
. Modular construction for easy portability to other systems
. An interactive command parser as well as Unix-style command line arguments
. Command and initialization files
. Piped operation
. Improved terminal connect, with optional logging
. Logs for debugging, packets, and transactions
. Communication with IBM mainframes

Several items on the wish list were not done for lack of time.  They will
probably be added in the future:

. File attributes
. Command macros
. Login scripts
. Raw file transmit

The new program is called "C-Kermit" because it is intended as a basis for
Kermit programs for any systems that have C compilers.  Its version number
is 4.0, to distinguish it from earlier releases of Unix Kermit, the most
recent of which was 3.0.

This prerelease test version of the program runs only under Berkeley Unix 4.2.
We also intend to bring it to the following systems within the coming weeks:

. DEC Pro-350 and Pro-380 with Venix (a Unix v7 derivative)
. Amdahl UTS on IBM 370-series mainframes
. Apple Macintosh (maybe)

Support for other systems will have to be added elsewhere.  The program is
being "pre-released" at this time for two reasons:

1. It seems to be perfectly usable on Berkeley 4.2 systems, and is an
   improvement over the previous version.

2. The modular design may need some adjustment to accommodate certain systems.
   Before a great deal of additional coding is done, it is highly desirable
   to get the design and specification of the system-dependent modules stable.

Therefore, please take the files, read the documentation, try running the
program on your Berkeley Unix system if you have one, and send comments or bug
reports to me as soon as you can.  If you have a Unix system that is not
Berkeley Unix, or a non-Unix system with a C compiler, please take a look at
the system-dependent modules to see how they could be adapted to your system;
again, if you have any suggestions or criticisms of the design, please let me
know.  I'm particularly interested in issues of portability.  After a round or
two of this, perhaps the design can be agreed upon, and then those who would
like to contribute support for Version 6, System III, System V, Xenix, PC/IX,
etc etc, can do so without fear of running into other people's changes for
other systems.  Before attempting to adapt C-Kermit to a new system, please
let me know so I can tell you whether someone else is already at work on the
same thing, and perhaps put you in touch.

The files are on CU20B as KER:CK*.*, available via anonymous FTP.  The file
CKERMI.DOC provides user-level documentation as well as a description of the
program organization and hints for adapting it to new systems.  Within several
days the files should also be available on BITNET via KERMSRV (to get started
with KERMSRV, type SMSG RSCS MSG CUVMA KERMSRV HELP), and to Unix systems via
UUCP from Oklahoma State University, Stillwater, OK.

Here's how to UUCP to OK State:

You need to set up "okstate" as a site in your "L.sys" UUCP dialing file
using the information listed below.  You can then issue the following
command on your system:

    uucp okstate\!/u/kermit/ck\* /usr/spool/uucppublic

   (this example will retrieve the new Unix version of Kermit)

The "/usr/spool/uucppublic" is chosen as the destination on your system since
the destination must be WIDE OPEN (drwxrwxrwx) to everyone.  You should
not remove files from your uucppublic until the entire transfer is complete
including any redials that are necessary.  If you do remove some files
our system may retransmit them, resulting in a higher phone bill for you.

-- UUCP Login information --

Site Name    :  okstate
Phone number :  [phone]  (one line only)
Login name   :  uucpker
Password     :  thefrog
Hours        :  10:00pm - 10:00am central time (7 day per week)
Problem      :  okstate!uucp-support  (UUCP)
  reports    :  uucp-support%okstate@csnet-relay  (ARPA)

The phone number is for 300/1200 baud (bell compatible).

------------------------------

End of Info-Kermit Digest
*************************
-------
 7-Feb-85 17:58:46-EST,4098;000000000001
Mail-From: SY.FDC created at  7-Feb-85 17:58:12
Date: Thu 7 Feb 85 17:58:12-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #2
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Thu,  7 Feb 1985       Volume 2 : Number  2

Topics:
                  Unix Kermit 4.0 for Other Systems
                        New Kermits on the Way

----------------------------------------------------------------------

Date: Thu 7 Feb 85 11:21:54-EST
From: Frank da Cruz <[e-mail]>
Subject: Unix Kermit 4.0 for Other Systems
To: [e-mail]

Responses to the Unix Kermit 4.0 announcement have started to come in.
As many of you pointed out, the makefile (ckermi.mak) did not work
"out of the box", due to some last minute name changes.  The errors were
obvious, and most people got around them.

There have been tentative volunteers to take care of support for various
systems.  Volunteers for systems not listed here should contact me so I
can add you to this list, which will be kept up to date in KER:CKWHO.TXT
on CU20B.  If you're interested in contributing to any of the implementations
listed below, be sure to coordinate with the contact, cc to me.

What                             Who

DEC VAX, 4.2 BSD                 SY.FDC@CU20B (Frank da Cruz)

DEC VAX, Ultrix-32               SY.FDC@CU20B (Frank da Cruz)

DEC Pro-350/380, Venix           SY.FDC@CU20B (Frank da Cruz)

IBM 370-series, Amdahl UTS       SY.FDC@CU20B (Frank da Cruz)

Apple Macintosh                  SY.WBC3@CU20B (Bill Catchings)

Masscomp RTU 2.2                 sob@RICE (Stan Barber)

Coherent                         vortex!lauren@RAND-UNIX (Lauren Weinstein)

Callan UniStar 300 with
 Unisoft 68000 System V Unix     EBM@MIT-XX (Eliot Moss)

ATT 3Bx, System V                Chris@COLUMBIA-20 (Chris Maio)

IBM PC, etc, PC/IX               HFISCHER@USC-ECLB (Herm Fischer)

IBM PC, etc, Xenix               HFISCHER@USC-ECLB (Herm Fischer)

Xenix                            HFISCHER@USC-ECLB (Herm Fischer)

Os9                              BLARSON@USC-ECLD (Bob Larson)

Version 7                        vasoll%okstate.csnet@CSNET-RELAY (Mark Vasoll)

2.9 BSD                          hipl!tony@NYU-CMSL2 (Tony Movshon)

4.2 BSD UUCP Line Locking        hipl!tony@NYU-CMSL2 (Tony Movshon)

By the way, there's some question as to whether UUCP line locking can
actually be included in a program that distributed without any kind of
license.

------------------------------

Date: Thu 7 Feb 85 17:42:42-EST
From: Frank da Cruz <[e-mail]>
Subject: New Kermits on the Way
To: Info-Kermit@CU20B

Quite a number of new Kermits have arrived in recent weeks, but have not
yet been installed for distribution.  They will be installed and announced
over the next week or two.  Here is a list:

. Alpha Microsystems AM-1000, AM-100L and ELS super-micro systems, written
  in Alpha Micro 68000 assembler (which is different from the Motorola
  assembler) by Bob Rubendunst, Soft Machines, Champaign IL.

. A new release of Kermit for the Cray supercomputer from Leah Miller at
  Los Alamos National Laboratory.

. Sanyo MBC-550 support for MS-DOS Kermit, from Joe Smiley, Du Pont Co.,
  Wilmington DE.

. Burroughs 6800 Kermit from Scott Bertilson at Quest Research,
  Burnsville MN.

. The source for the FORTH version of Commodore-64 Kermit, from Bob
  Detenbeck at the University of Vermont.

. A new release of Harris 800 Kermit from Dave Wilson at University of
  Wisconsin.

. Fujitsu Micro-16S support for CP/M-86 Kermit from C. Barker at
  World Institute for Science & Technology, Long Island City NY.

. DG Dasher terminal emulation for MS-DOS Kermit from Duane Galbi,
  Maine-Endwell High School, Endwell NY.

. Kermit in SP/Pascal for DG AOS and AOS/VS systems, also from Duane Galbi.

------------------------------

End of Info-Kermit Digest
*************************
-------
 8-Feb-85 19:07:23-EST,14924;000000000001
Mail-From: SY.FDC created at  8-Feb-85 19:07:03
Date: Fri 8 Feb 85 19:07:03-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #3
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri,  8 Feb 1985       Volume 2 : Number  3

Departments:

  ANNOUNCEMENTS -
        MS-DOS Kermit for Sanyo MBC-550
        New Cray Kermit
        Commodore-64 FORTH Kermit Source Available
        Kermit in Pascal for DG AOS, AOS/VS Systems

  UNIX KERMIT -
        More Unix Kermit Volunteers

  MISCELLANY -
    New MVS/TSO Kermit in PL/I
        Multics Kermit Fix
        Polo Kermit??
    Sacred Characters, a Protocol Issue
    Kermit for PCjr

----------------------------------------------------------------------

Date: Fri 8 Feb 85 11:32:55-EST
From: Frank da Cruz <[e-mail]>
Subject: MS-DOS Kermit for Sanyo MBC-550
To: [e-mail]

This is to announce MS-DOS Kermit for the Sanyo MBC-550 from Joe Smiley,
Du Pont Co, Wilmington DE.  It requires DOS 2.11 or above.

He has supplied the MSXMBC.ASM system-dependent module, plus an executable
program file built from the version 2.26 sources (any volunteers to try
building a 2.27 version?).

He says he's still working on it, and will submit another version with
full VT100 emulation at some future time.  The files are on CU20B in:

    KER:MSXMBC.ASM - System-dependent module source
    KER:MSMBC.HLP  - Help file
    KER:MSMBC.BOO  - "boo" file for downloading
    KB:MSMBC.EXE   - 8-bit binary program image

------------------------------

Date: Wed, 30 Jan 85 16:52:46 mst
From: lfm@LANL (Leah F. Miller)
To: sy.fdc@CU20B
Subject: Cray Kermit

 ... has, to my knowledge, a current grand total of 4 installations: Los
Alamos, Livermore Natl Lab, Sandia in Albuquerque, and Cray Research in
Chippewa Falls, Wisc. So, that makes it rather a curiosity compared to some
others which must have many hundreds of installations.  But user acceptance has
been immediate.  No further updates planned.  It's been a pleasure being
associated with your activities.  Leah Miller

[Ed. - This is by way of announcing a new release of Cray-1 Kermit, which
is now available on CU20B as KER:CRAY.*.]

------------------------------

Date: Fri 8 Feb 85 11:37:24-EST
From: Frank da Cruz <[e-mail]>
Subject: Commodore-64 FORTH Kermit Source Available
To: [e-mail]

Bob Detenbeck of the University of Vermont has sent in the FORTH source
screens for his Commodore-64 Kermit.  They are in KER:C644TH.SCR on CU20B.
There is also a short help file, KER:C644TH.HLP.

------------------------------

Date: Fri 8 Feb 85 16:55:09-EST
From: Frank da Cruz <[e-mail]>
Subject: Kermit in Pascal for DG AOS, AOS/VS Systems
To: [e-mail]

This is to announce a version of Kermit for Data General machines running
AOS and AOS/VS, written in SP/Pascal, contributed by Duane Galbi of
Maine-Endwell High School, Endwell, NY.  The files are in KER:AOSK2.*.

The same person also contributed DG Dasher terminal support for MS-DOS
Kermit, but this cannot be installed for distribution yet because changes
were made to several modules, and these must be reconciled with other
people's changes to the same modules.

------------------------------

Date: Fri 8 Feb 85 16:55:09-EST
From: Frank da Cruz <[e-mail]>
Subject: More Unix Kermit Volunteers
To: [e-mail]

Since yesterday, several more volunteers have come forth, and some errors
in the addresses of previous volunteers have been corrected.  Below is the
list as it stands.  It continues to reside in KER:CKWHO.TXT on CU20B...

Meanwhile, there seems to be agreement that the "UUCP line locking" business
can be included in the Kermit program without legal entanglement if the code
is original, and not lifted from a proprietary program like UUCP itself.
Such code has already been contributed by Tony Movshon (see below), but is
not installed for distribution yet.

Another issue that is reported frequently is the length of the character string
constants, particularly in ckuser.c.  These will need to be shortened.  What is
the minimum longest string constant that the smallest C compiler will allow?
Now I know why so many C programs print long messages using a printf for each
line...

DEC Pro-350/380, Venix           SY.FDC@CU20B (Frank da Cruz)
IBM 370-series, Ahmdah UTS       SY.FDC@CU20B (Frank da Cruz)
Apple Macintosh                  SY.WBC3@CU20B (Bill Catchings)
Masscomp RTU 2.2                 sob@RICE (Stan Barber)
Coherent                         vortex!lauren@RAND-UNIX (Lauren Weinstein)
Callan UniStar 300 with
 Unisoft 68000 System V Unix     EBM@MIT-XX (Eliot Moss)
ATT 3Bx, System V                Chris@COLUMBIA-20 (Chris Maio)
IBM PC, etc, PC/IX               HFISCHER@USC-ECLB (Herm Fischer)
IBM PC, etc, Xenix               HFISCHER@USC-ECLB (Herm Fischer)
Xenix                            HFISCHER@USC-ECLB (Herm Fischer)
Os9                              BLARSON@USC-ECL (Bob Larson),
                                  bdale@cmu-cs-g (Bdale Garbee)
Version 7                        vasoll%okstate.csnet@CSNET-RELAY (Mark Vasoll)
2.9 BSD                          hipl!tony@NYU-CMCL2 (Tony Movshon)
4.2 UUCP Line Locking            hipl!tony@NYU-CMCL2 (Tony Movshon)
Prime                            BLARSON@USC-ECL (Bob Larson)
HP9000 Series 200 (HP9836)
 with HP-UX System III           b-davis@utah-cs (Brad Davis)
CP/M (Small C or BDS C)          bdale@cmu-cs-g (Bdale Garbee)

------------------------------

Date: Wed, 16 Jan 85 15:58:40 CST
From: [e-mail]
To:   [e-mail]
Subject: New MVS/TSO Kermit in PL/I

Rice has now completed implementing KERMIT under IBM MVS/TSO.  This is a new
implementation of KERMIT for the TSO environment rather than a rework of the
VM/CMS code.  It was written in IBM PL/I and a locally developed TSO command
writing package (which is as of yet unreleased).  Rice TSO KERMIT has been
tested in MVS/SP 1.1.1 environment at Rice and the MVS/SP 1.3 environment at
University of Chicago.

This KERMIT is based on the version 5 protocol manual.  It has been tested
with PCKERMIT 1.20, MSKERMIT(IBM) 2.26, Rice MacKermit (in beta test), and
MSKERMIT (IBM) 2.27.  Server mode is also supported.

We are ready to send an MVS load module, the source, and limited
documentation.  Because we have not yet released the command writing package
used in the source, it is not possible for other users to compile the
source.  (We may decide to submit the package to the SHARE Library which
would solve this issue.)  Both Chicago and Notre Dame were able to install
without modifications to the code containing calls to the command writing
package.

Thanks,
Farrell Gerbode
Rice University Computer Center

[Ed. - Note, we've also received other MVS/TSO contributions, but these
are based on the Chicago assembler version.  A recent arrival from the
University of Toronto has Series 1 support.  This one will be announced
when it arrives, and of course any news about the Rice MacKermit will
also be passed along.  Meanwhile, if somebody at the U. of Chicago (which
produced the original MVS/TSO Kermit) could comment on how this version
should be viewed -- a replacement for theirs, an alternate version that's
only useful for PL/I sites, etc...]

------------------------------

Date: Wed 23 Jan 85 09:13:18-EST
From: Paul Amaranth <[e-mail]>
Subject: Multics Kermit Fix
To: [e-mail]

I think I got a fix for that strange problem that was reported in [V1 #44 of
Info-Kermit].  This should work:

The following code should be inserted into the procedure setup_terminal which
is just before the end of the kermit_ module.  My best guess is that an attempt
was being made to change the fnp modes (which included half duplex) before the
current transmission of text was completed.  This code prevents that from
happening.  I talked to the fellow who experienced the problem and he said
that it sometimes happened when receiving, but never sending.  It also depended
on system load.  The only difference in the code is that on SEND, there is a
time delay before the modes are changed, which would let any transmission
complete.

Oh well.  This code has no effect on normal operation.

[Ed. - For now, the patches are in the file KER:MUKMT.BWR.]

------------------------------

Date: Wed, 30 Jan 85 16:23:50 EST
From: Dave Swindell <dswindel@bbn-labs-b>
Subject: Polo Kermit??
To: [e-mail]

Does anyone know if a Kermit version exists for a Polo PC??  The Polo is
supposedly 'IBM compatable' (what isn't), however, V2.26 IBM Kermit doesn't
work on it.  We haven't tried generic MS-DOS Kermit yet.  I wanted to see if
anyone else had any 'Polo' experience before I dive in any deeper!

Dave Swindell
BBN Labs

[Ed. - Bill Catchings had a Polo for a evaluation.  He says it is not in any
way IBM compatible.  They claim to be IBM compatible at the data file level;
in other words they can both use the same 1-2-3 files.  Let us know if generic
MS-DOS Kermit works -- by the way, 2.27 generic Kermit has better support for
fooling around with the port designators and file handles than 2.26 did.]

------------------------------

Date:  Fri, 1 Feb 85 13:23 CST
From:  "David S. Cargo" <[e-mail]>
Subject:  Sacred Characters, a Protocol Issue
To:  [e-mail]

Here at Honeywell we are running into an issue that I'm sure others have
encountered.  I'll explain what we see happening and then ask for some
discussion about what can be done.

We have a number of systems which, for what ever reason, preempt certain
printing characters.  Sometimes these are the computer systems, and
sometimes it is the network control hardware.  Some of the typical
characters that cause problems are the backslash (hex 5C, "\"), the
pound sign (hex 23, "#"), the at sign (hex 40, "@"), and the tilde (hex
7E, "~").  These symbols are either escape characters (in which case
they can make it through the network if they are doubled), hardwired
editing characters, or network hardware command prefix characters.  Some
of the networks over which we want to use Kermit get very convoluted.
There isn't any way we can see that would allow the problem characters
to be doubled, or escaped in an adequate way.  The only way we can see
that avoids collision with "sacred" characters is to avoid using these
characters at all, in much the same way that avoiding use of the control
characters avoids problems.

The questions that I see this presenting are:  how to specify the
characters that must be avoided, how to communicate the set of
characters to be avoided from one Kermit to another, how to agree on the
set, and how to handle the presense of such characters in the file (or
data) being transmitted.

The last question relates to another problem we have encountered, where
the transmitted file contains characters used by the protocol ("#" for
example).  We can't always pick the protocol characters to match
characters which are not used in the source file.  What is a workable
way to avoid that problem?

Ideally, agreeing on the set of characters would be straight forward.
Each side would be told what characters won't make it through if they
are transmitted to the other end, so it won't transmit that set.
Another alternative would be to not transmit any character in either
set.

The problems I see are in specifying the packet length (which is a
number encoded into a character) and the checksum (which is a number of
various size encoded into one or more characters).  If some characters
must be avoided some values become unrepresentable.  That clearly isn't
satisfactory.

One possibility would be to add a character encoding mechanism which
would take a packet, encode any of the forbidden characters before
transmission, and reconstitute them upon receipt.  This has the
disadvantage of adding another layer to the protocol, requiring the
negotiation of another character, and complicating the packet structure
further (since its length on transmission would grow depending on the
number of characters which had to be encoded).

I am not sure that cure isn't worse than the disease.  Still, it would
provide a way for Kermits to communicate through even more hostile
territory than they can now.  We (at Honeywell) have pragmatic reasons
for wanting some way of setting the characters that must be avoided.
Others probably face the same problem.  I want to open the issue up so
it can be discussed, and ideally a solution agreed upon.  It isn't an
easy issue, but it is an important one.

[Ed. - Kermit was designed on the usually correct assumption that any
printable ascii character can make it from one end to the other unscathed.
In the rare cases when a certain printable is sacred, like the '@' that is
normally used as the TAC escape character, one can either change the Kermit
programs involved to double the character (the normal method for passing
escape characters through a device that looks for an escape character), or
change the escape character to a nonprintable character that differs from
Kermit's packet start, packet end, turnaround, and padding characters (if
any), or put the device in "transparent mode".  Beyond that, I'm afraid that
the cure is indeed worse than the disease -- the likelihood that the
required extra layers of protocol could be added to scores of existing
Kermit programs (3 or 4 scores at last count) is pretty small.  What's worse,
the poor user would have to know to tell Kermit to do this!]

------------------------------

Date: Wed 6 Feb 85 18:08:05-EST
From: Bdale Garbee <AG0B%CMCCTE@CMU-CC-TE>
Subject: kermit for pc jr.
To: sy.fdc%CU20B@CMU-CC-TE

Frank -- what is the status of kermit on the PC jr.?  I keep getting
asked about it, and it's getting harder to turn people away.  I haven't
done anything with the MSDOS version before....  reading back issues of
info-kermit pointed me to msibmjr.*, which don't exist.  Does v2.26 work,
and if so, does it work only on the rs232 port?  I think the guy who's
really griping is using some sort of internal modem?

Bdale

[Ed. - The PCjr comes with a built-in modem and an RS232 port.  Kermit 1.20
and later work on the PCjr's RS232 port but not on the modem.  To use the
RS232 port, you have to say 'set port 2', because it's COM2.  We have no
plans to make it work on the modem -- we don't have a PC to play with any
more.  Any volunteers?]

------------------------------

End of Info-Kermit Digest
*************************
-------
11-Feb-85 17:33:39-EST,14560;000000000000
Mail-From: SY.FDC created at 11-Feb-85 17:32:57
Date: Mon 11 Feb 85 17:32:57-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #4
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Mon, 11 Feb 1984       Volume 1 : Number  4

Departments:

  ANNOUNCEMENTS -
    Kermit for Alpha Micro 68000 Systems
    New Release of Harris 800 Kermit

  UNIX KERMIT -
    Data compression for C-Kermit fans
    System III Unix Kermit
    Bugs in C-Kermit 4.0

  MISCELLANY -
    Kermit-MS in Color
    Sacred Characters, Cont'd

----------------------------------------------------------------------

Date: Mon 11 Feb 85 16:43:17-EST
From: Frank da Cruz <[e-mail]>
Subject: Kermit for Alpha Micro 68000 Systems
To: [e-mail]

This is to announce Kermit for Alpha Microsystems AM-1000, AM-100L, and
ELS super-micro computer systems, running AMOSL 1.2 or later, written
in Alpha Micro 68000 assembler, contributed by Bob Rubendunst of Soft
Machines, Champaign IL, and also contributed to the Alpha Micro User's
Society and to the on-line AMUS network in Boulder CO.  The files are in
KER:AM*.* on CU20B, available via anonymous FTP.

------------------------------

Date: Mon 11 Feb 85 17:05:52-EST
From: Frank da Cruz <[e-mail]>
Subject: New Release of Harris 800 Kermit
To: [e-mail]

This is to announce a new release of Harris 800 Kermit from Dave Wilson
at the University of Wisconsin Academic Computing Center.  It's written in
Harris Pascal.  For those Harris sites that do not have Pascal, a ready-
to-execute load module is available from the Harris User Exchange.  Thanks
to Paul Stevens of MACC for sending it in.  No mention was made of what
the differences are between this version and the first one (September 84).
The files are in KER:H800*.* on CU20B.

------------------------------

Date: Fri, 8 Feb 85 16:59:10 pst
From: James Woods <[e-mail]>
To: info-kermit@Berkeley
Subject: Data compression for C-Kermit fans

#  "Shrivel up!" -- DEVO, from their American debut

     Taking advantage of the Lempel-Ziv data compressor now making
the rounds on USENET/ARPANET, C-Kermit users may easily invoke the pair

    compress file | kermit -is -
    kermit -ik | uncompress

for faster file transfer.  How much faster?  Well, the code, which
runs wherever C compilers are sold, typically yields 50-60% reduction
for text, 65-80% for formatted ASCII numerical data, and good rates for
bitmaps.  So, coupled with the fact that compress runs much faster
than typical modem rates (> 60K baud on a VAX 11/750), we have a tidy
savings, even after the 26.6% expansion induced by Kermit's "quoting"
of control characters.  The rates are somewhat less (5-10%) for machines
limited to a 16-bit address space.

     The Kermit designers should be commended for not designing
fancy data compression into the protocol itself.  (This is tough to
do with short packets in any case.)  Of course, the Tinkertoy nature
of UNIX pipelines is also indispensible for this clean separation
of function.  Advise for non-UNIX Kermit users -- weep!

     For a copy of the public domain compress code, contact Joe Orost at
vax135!petsd!joe@berkeley.

     -- James A. Woods    {ihnp4,hplabs}!ames!jaw     (or jaw@amelia)

[Ed. - I agree, pipes are neat.  The 26.6% figure is not a fixed overhead
of Kermit, by the way.  Since 33/128 of the ASCII characters are
non-printable, the 26.6% control-character prefixing overhead will occur
only in files where all ASCII characters occur with equal frequency.  In
fact, most text files have only about 5% control characters.  Kermit's own
dumb data compression also pays off quite well sometimes -- most
dramatically in short binary program files, where lots of contiguous memory
is intialized to 0's.]

------------------------------

Date: Sun 10 Feb 85 23:46:41-PST
From: Herm Fischer <[e-mail]>
Subject: System III Unix Kermit
To: [e-mail]

Frank,

ckmain:  String length problems (134 & 1541).  (512 max on Xenix)

[Ed. - I've received reports of various maximum string constant
or fprint argument sizes; the smallest so far is 128.]

ckwart(178): index used in OR (arithmetic) expression... uncool.
can only compare pointers to "NULL" for equality or lack thereof.

index is called strchr in System III versions.

[Ed. - Index will have to be defined inside wart, perhaps
renamed to avoid lawsuits...]

ckwart/main() lacks exit(0) which prevents System III make from
going onto next make step automatically. Add exit(0) call at end
of main().

[Ed. - Fixed.]

ckuser:  obesely oversized... break apart... many strings too long...

[Ed. - Sigh... Let's only do this once.]

ckxbsd and ckzbsd now outfitted with conditional compilations for: system
III, bsd, Xenix, and PC/IX.  I strongly support having only ONE set of
"unix" modules.  Anyway, that is how I did the System III (and PC/IX and
Xenix 3.0 ) port.  Am in final cleanup stages on it.

re uucp Line Locking, I have already found two different System III
versions which do it two different ways.  Will compare your furnished
example code to mine.

Main problems are with ckuser right now: too large to handle with some
compilers!  several strings too long too!

  Herm

ps - am getting messages from Xenix users with OLD version 7 based
Tandy-distributed versions.  It is highly doubtful that the C-Kermit for
Xenix 3.0/Sys III will be retrofittable to V.7 based Xenixes.  That early
one was highly deficient in "unix-like" features...

------------------------------

Date: 9 February 1985 15:27-EST
From: Ed Schwalenberg <ED @ MIT-MC>
Subject: Bugs in C-Kermit 4.0
To: sy.fdc @ CU20B

I am attempting to bring up C-Kermit 4.0 under 68000 Xenix.  So far, I've
encountered the following bugs:
1. ckxbsd.c function ttxin does a read(foo,bar,&count) instead of
                  read(foo,bar,count).
   I don't see how this could ever have worked.

[Ed. - Me neither...  It's fixed now.]

2. ckxbsd.c functions ttinl and ttinc declare int c; and int ch; respectively,
   then do read(foo,&c,1), followed by c &= 0377.  This doesn't work on
   machines like the 68000 that have bytes in the opposite order from VAXen.
   Declaring c (or ch) unsigned char fixes it, and obviates the need for the
   masking instruction which follows (assuming 8-bit chars).  The function
   coninc does it right, though.

[Ed. - Thanks for pointing this out; it's fixed now.]

3. ckxbsd.c function ttflui has the comment "What's this???" which agrees
   with the code, anyway.  I see that you use one file descriptor for read
   and write; this code seems to think that by specifying FREAD as the
   argument to ioctl(TIOCFLUSH) you'll only flush input.  I think it would
   be lots more clear and portable to have separate read and write channels.
   In any case, the Xenix documentation claims that the arg is ignored for
   TIOCFLUSH.

[Ed. - 4.2BSD allows you to specify which queue's buffer to flush, read or
write.  For now, I just changed to comment.]

4. "C-Kermit> dir /usr/ed" results in ?File not readable, which seems to be
   deliberate.  Is it?  Why?

[Ed. - Not deliberate; cmifi() checks to see if the specified file is
readable, /usr/ed is a directory file, hence not readable.  This will have
to be fixed.  Meanwhile, use "dir /usr/ed/*" or replace cmifi() with cmfld().]

Other than that, it has gone very smoothly and well.  Congratulations on
a fine piece of work, especially the TENEX-style command completion.  (I
don't care for it as a user interface myself, but I'd much rather have ONE
user interface than 2 (or 3, or 4...).

[Ed. - Everybody wanted an interactive command parser, so I put in the one
I liked best.  I tried to make it easy for others to substitute other parsers
to suit their tastes.]

So now it works for 68000 Xenix, though I want to attack it with prof(1) and
see if I can improve the performance (it loses packets over 2400 baud).

[Ed. - C-Kermit works fine on a VAX with 4.2BSD at 9600 baud, using
xon/xoff.  It'll work even better when someone does a DMF32 driver that
will support DMA.  If you don't have xon/xoff, then tweaking performance is
desirable so long as it doesn't interfere with portability.]

------------------------------

Date: Sun 10 Feb 85 00:53:26-PST
From: Jim Celoni S.J. <[e-mail]>
Subject: Kermit-MS in color
To: [e-mail]

Minor glitch in MS-DOS Kermit 2.27:  When on a color display with
foreground/background colors set, Kermit seems to ignore them and
always write to the screen white on black, and the grey + key
replaces the mode line with a black hole instead of writing
background-colored spaces.  +j

[Ed. - Noted.]

------------------------------

Date:  8-Feb-85 20:26:40-PST
From: [e-mail]
Subject: Sacred Characters
To: [e-mail]

The "MMDF Dial-up Link Protocol" had a fairly complete mechanism for
handling sacred characters.  I use past tense because I think that CSNET
is using MMDF II these days, and I have no information about that
protocol.  Anyway, here is a quick description of the MMDF sacred
character (and packet length, and escape character) negotiation.

This description is based on an April 1980 document called "MMDF Dial Up
Link Protocol" by Ed Szurkowski.  It is U. of Delaware report
ud-nsf-csnet-81-002.  Parts of this message are taken almost straight
from that report, particularly the big diagram.  This was the second
version of a carefully designed protocol, and I think that Kermit could
get some goodies here ("If you are going to steal, steal good.").

MMDF uses a limited character set for the negotiotiation:  0-9, A-F.
16-bit packet checksums are always sent as four hex digits.  The packet
type is one hex digit, and the flags (Origin, EOF, and a two-bit sequence
number) are in one hex digit.  MMDF can actually work over a link that
allows only hex digits, one escape character, and a way to send a delimited
record (like following the packet with a CR).

These are the packet types for the sacred characters (SC) negotiation:

    XPATH        SC's in my transmit path (and my xmit packet size)
    XPATHACK    acknowledge XPATH
    RPATH        SC's in my receive path (and my rcv packet size)
    RPATHACK    (guess)
    ESCAPE        I will use this escape character
    ESCAPEACK    (guess again)

An XPATH packet looks like this:

+-----+-----+-----+-----+-----+-----+-----+-----+-----+----//----+-----+
|      Checksum         |  2  |Flags|Max. Packet| Illegal Input Chars. |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+----//----+-----+
   1     2     3     4     5     6     7     8     9                40

Max. Packet is two hex digits which are the longest packet that this
host can send.

Bytes 9 through 40 are 32 hex digits which are an encoding of the illegal
output characters for the host.  The hex number is interpreted as a 128
bit vector (one bit for each ASCII character).  If the bit is on (1) in
the vector, that charcter cannot be transmitted by the host.

An XPATHACK packet carries no data.  It just acknowledges an XPATH packet.

The RPACK packet looks exactly like an XPATH.  It describes the limitations
of a hosts receive path.

After a host has successfully sent an XPACK and an RPACK, and received
one of each from the other host, it chooses an escape character based on
all this great information.  The ESCAPE packet contains the normal
header (checksum, type, and flags) and also has the chosen escape
character encoded as (you guessed it!) two hex digits.  This is the
escape character that this host will use to transmit data.  The other
host chooses its own escape character.

All illegal characters are sent escaped, either with special control
character forms (like <ESCCHAR>M for carriage return) or with the general
<ESCCHAR>## form, where ## is two hex digits corresponding to the ASCII
value of the character which has been escaped.

The protocol is used like this:

Host A        Host B
---- -          ---- -
         <--- XPATH    [Host B's xmit limitations]
XPATHACK --->
         <--- RPATH    [Host B's rcv limitations]
RPATHACK --->
XPATH    --->        [Host A's xmit limitations]
         <--- XPATHACK
RPATH    --->        [Host A's rcv limitations]
         <--- RPATHACK
         <--- ESCAPE    [Escape character that Host B will use]
ESCAPEACK--->
ESCAPE   --->        [Escape character that Host A will use]
         <--- ESCAPEACK

DATA     --->
         <--- DATAACK    [repeat as necessary]

         <--- DATA
DATAACK  --->        [repeat as necessary]

QUIT     --->
         <--- QUITACK


I threw the DATA and QUIT stuff in there so that all this wouldn't
seem so pointless.  DATA and QUIT are legal MMDF, of course.

This shouldn't be that hard to add as an attribute (or maybe a
capability bit) with some restructuring of the packet exchanges to keep
the strict packet-ack rhythm of Kermit.  Since Kermit philosophy forbids
negotiations, the ESCAPE/ESCAPEACK might not fit in too well.  The
ESCAPE/ESCAPEACK must be done somehow, though, because the normal Kermit
escape characters cannot escape arbitrary printing characters.

In my opinion, the MMDF escaping is much much cleaner than the Kermit
foobar-quoting approach, but compatability overrides elegance.  Perhaps
the Hex-quoting would be a separate mode.  Sort of a "low gear" for
weird communication paths.

walter underwood

[Ed. - This is undoubtedly a good approach.  Too bad we didn't think of it
when we designed Kermit.  Again, the problems are: (1) getting the code
into a significant subset of the Kermit implementations, and (2) educating
users about it.  The second problem is the worst -- how does a "naive" user
know that if you are connected to Datex-P via a satellite link from Tymnet
gatewayed via X.25 from an Internet host accessed through a TAC dialed
through a (vendor-name-omitted) "smart" modem, ..., what the sacred
characters are?  It's hard to tell whether the effort to handle bizarre
situations like this would be worth it.  Maybe a good first step would be
to learn exactly what roadblocks people are actually running into where
an approach like this might help.]

------------------------------

End of Info-Kermit Digest
*************************
-------
13-Feb-85 18:02:00-EST,3269;000000000001
Mail-From: SY.FDC created at 13-Feb-85 18:01:09
Date: Wed 13 Feb 85 18:01:08-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #5
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Wed, 13 Feb 1984       Volume 2 : Number  5

Today's Topics:
                        Kermit in Turbo Pascal
                        6800/6809 FLEX Kermit
                        Color vs IBM PC Kermit
                          Kermit 64 Problem

----------------------------------------------------------------------

Date: Wed 13 Feb 85 15:01:06-EST
From: Frank da Cruz <[e-mail]>
Subject: Kermit in Turbo Pascal
To: [e-mail]

A preliminary version of Kermit written in Turbo Pascal is now available.
It was written by Jeff Duncan (LSM.DUNCAN@DEC-MARLBORO) with an eye toward
portability to the many systems that run Turbo Pascal, but the initial
implementation is for the DEC VT-180 with CP/M-80.  Kermit and/or Turbo
aficionados are encouraged to comment upon it or send support for
additional systems to Jeff.

The files are in KER:TP*.*, available via anonymous FTP from host CU20B.

------------------------------

Date: Tue, 12 Feb 85 10:19 MET
From: Decus <@csnet-relay.arpa,@germany.CSNET:[e-mail]>
To: [e-mail]
Subject: 6800/6809 FLEX Kermit

The "D68 User Group" has a Kermit for the 6800 and 6809 porocessors
under the FLEX operating system.

At present it is at the Alpa-Test stage.  It is a minimal system
(connect send receive exit) and has only been tested against a VAX/VMS
Kermit by local users.

If anyone has another 68xx version, is interested in comparing
notes, or wants a copy when it is fit for release, they can contact:

    Peter Bendall
    Post Box 1313
    2359 Hensted-Ulburg
    West Germany

for more details.

[Ed. - This will be announced when it arrives.]

------------------------------

Date: Mon 11 Feb 85 22:00:37-PST
From: David L. Pike <[e-mail]>
Subject: Re: Color vs IBM PC Kermit
To: [e-mail]

    I thought I'd comment on the issue of color for ibmpc kermit
v 2.27. The reason for the white on black for the color display is that
the variable 'curattr' is set at 07h in the file msyibm.asm, so that
even if the ansi driver had a different setting this code would override
it.  It's fairly easy to insert your favorite value in there.....

------------------------------

Date:     Tue, 12-FEB-1985 01:25 EST
From:     ALLAN TEO <USERLIB@YULEO>
Subject:  kermit 64 problem
To:       KERMSRV@CUVMA

TO whom it may concern,

    I believe the current hex file for c64ker hex is corrupted
in some way.  The program will boot up on the commodore 64 but
will crash after it has been properly saved and re - loaded.
will some one in charge re-assemble another copy of c64ker m65?
Thank You. (Many others have had this strange problem)

[Ed. - The author of Commodore 64 Kermit (the CROSS version, not
the Forth version) indicates that a new, more complete release
will be available soon.]

------------------------------

End of Info-Kermit Digest
*************************
-------
15-Feb-85 18:30:42-EST,12221;000000000000
Mail-From: SY.FDC created at 15-Feb-85 18:30:18
Date: Fri 15 Feb 85 18:30:18-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #6
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri, 15 Feb 1984       Volume 2 : Number  6

Today's Topics:

              Kermit for Fujitsu Micro 16s with CP/M-86
                      Kermit for Burroughs 6800
                     Guide to MS-DOS Kermit Files
                      New Unix Kermit Bug Report
                     Feedback on "ckwart.c", etc.
                      Sacred Characters, Cont'd

----------------------------------------------------------------------

Date: Fri 15 Feb 85 13:25:22-EST
From: Frank da Cruz <[e-mail]>
Subject: Kermit for Fujitsu Micro 16s with CP/M-86
To: [e-mail]

This is to announce Fujitsu Micro 16s support for CP/M-86 Kermit contributed by
Chris Barker, World Research Institute for Science & Technology, Long Island
City, NY.  The program makes use of the Fujitsu's built-in ADM3A firmware for
terminal emulation, and runs at speeds up to 9600 baud.  The 86KERIO module
submitted was for version 2.7 of CP/M-86 Kermit; I compiled it with the current
version, 2.9, without apparent problems.  The files are:

  KER:86*.A86  Source (all unchanged, except for addition of 86KERIO.FUJ)
  KER:FJ*.*    Help and hex files

available via anonymous FTP from CU20B.  The author says he is also working on
MS-DOS Kermit support for the same machine.

------------------------------

Date: Fri 15 Feb 85 13:25:45-EST
From: Frank da Cruz <[e-mail]>
Subject: Kermit for Burroughs 6800
To: [e-mail]

This is to announce Kermit for the Burroughs 6800, written in Algol by
Randy McLaughlin, Metro-II, St Paul MN.  The following files are included:

  KER:B68KERMIT.ALG     Source of the B6800 Algol program.
  KER:B68KERMIT.NDL     NDL "request sets" to replace READTELETYPE and
                        WRITETELETYPE and associated DEFINE's.
  KER:B68KERMIT.DOC     Documentation for B6800 Kermit.

They may be anonymously FTP'd from CU20B.

------------------------------

Date:        05 Feb 85 19:54 +0100
From:        [e-mail]
To:          Info-Kermit@CU20B
Subject:     Guide to MS-DOS Kermit Files

Hi, Frank (and all the rest of the Kermit crew at Columbia)!

I miss very much a file with a complete breakdown on all the MS-prefixed
files.  Their number has grown beyond what is easy to manage. So, I made
such a file.  Here it is. My apologies for any mistakes.  Hope you can keep
it updated and include it in forthcoming releases of the tape.  Share and
enjoy!  -Per Lindberg

[Ed. - This very useful file, which guides your way through the
bewildering array of dozens of MS*.* files, is available in KER:MSAAAA.HLP
on CU20B -- the A's are so it will appear at the top of the MS*.* files in
an alphabetical listing, hopefully attracting some attention.]

------------------------------

Date: Thu, 14 Feb 85 16:13:46 est
From: Paul Placeway <[e-mail]>
To: [e-mail], [e-mail]
Subject: New Unix Kermit Bug Report

This may be old news, but I had problems bringing up Unix Kermit on a Sun
Microsystems (BSD 4.2) computer.  (This is ckermit as of Feb. 13 on BITNET.)
Kermit would compile just fine, but would dump core when run.  The fix is
simple: change line 751 of ckuser.c from

       while (feof(tfile[tlevel]) && (tlevel > -1)) { /* If end of take */
to
       while ((tlevel > -1) && feof(tfile[tlevel])) { /* If end of take */

The problem is that the Vax cc(1) changes the order of the check in the if
statement, but the Sun cc(1) dosn't, and so it trys to feof(tfile[-1]) which
gives a core dump.
                                        Paul W. Placeway
                                        The Ohio State University
                                        (UUCP: cbosgd!osu-eddie!paul)
                                        (CSNet: paul@ohio-state)

[Ed. - Thanks.  The same thing happens on Pyramid and probably other Unix
systems too.  This fix now appears in the distributed copy of ckuser.c.
Glad to hear that so little is required to make it work on the SUN.]

------------------------------

Date:     Fri, 15 Feb 85 16:14:16 GMT
From:     Chris (K) <[e-mail]>
To:       [e-mail]
Subject:  Feedback on "ckwart.c", etc.

Info & Frank:

1.  WART Preprocessor:

     This does not compile as it stands on 11/44 under Berkeley 2.8
due to use of compiler extensions:
   -   "unsigned char" not supported;
   -   the same member-name may not be used in two different
       structure declarations unless the offset is the same.
Fix is to delete line 44 and change all /CHAR/char/; and to change the
member ->nxt of struct sym to ->next in lines 537, 596, 609.

    After these changes, it compiles but bombs with core-dump due to
overlength printf string (see below).  The culprit is "char *warning" on
lines 66-70.  Split this into 3 separate single-line strings and output by
three fprintf's at line 137.

[Ed. - I ran into the same problems with Wart under Venix and they're
fixed in the current distribution copy, along with a replacement for
the index() function, which turns out not to be portable.]

2.  "printf()" lengths.

     The reason that wart bombed on Berkeley 2.8 is that printf() and its
derivatives use a 128-byte buffer, for unpacking the formatted string
into, before output.  You are in dead trouble (with a core-dump) it any
printf formats to longer than this.  I suspect that this is a more
stringent restriction than you will find in any of the micro-compilers.
For what it's worth, Aztec-C for Z80 rejects strings of more than about
150 bytes.

     Please restrict the format strings used in printf() (& derivatives)
to a single line of text; and think carefully about the resulting
formatted length when strings are inserted by %s.  In particular, you
cannot expect to include the whole of a kermit data block and always get
away with it.

[Ed. - Everyone who's been working on moving C-Kermit to
peanut-whistle Unix systems (like PDP-11's without I&D space) has been
bitten by the printf buffer problem.  As a newcomer to Unix, I must
admit I was shocked that (a) there's any limitation at all, (b) the
limit is so small on some systems, and (c) no checking is done for
overflow.  Various measures are necessary -- reducing the length of
string constants, mostly in ckuser.c; using (f)puts instead of printf
wherever possible.  Some people are already working on this.]

3.  End-of-File Markers (Visual).

     I don't think I trust file transfers in general.  It's very nice to
have some confirmation (apart from a matching closing brace) that the file
you have in your hand is the whole of the one that the remote should have
sent you.  Could we have, as standard, something like a row of 30
asterisks at the end of every kermit source file?

[Ed. - Good idea.  Some day when I have time to add them to the end of
1000 files...  30K of asterisks!]

4.  Menu for Parameters.

     The nicest way (at least to some minds) to set parameters on a micro
is an interactive menu.  I've written one (in C) for the RML 480Z Kermit;
do you want it?  It's not wholly transportable, but I can clean it up
before sending.  It uses up & down arrows to select parameter, right and
left to toggle through up to 10 preassigned settings, alters a variable
(displaying individually assigned value-description) and optionally calls
an action routine as each is changed.  5 lines of help-text available on
each parameter.  Not yet implemented is a facility to enter a hex or char
value for a parameter.  No limit (except storage) to the number of
parameters it will handle.  I'd have to get RML's permission to release
it, since they paid for the work; but I think it would be given.  Of
course, this is not a practical way to set parameters in Server mode; but
I don't see Server being of much use on a single-user micro.  I expect to
make the 480Z answer an incoming PSTN call and respond to GET/SEND; and
that's all.

[Ed. - ckuser.c does attempt to provide menus for commands and settings by
allowing you to type '?' any time in a command.  This is "menu on demand"
-- the experienced user need not be constantly confronted with menus, but
inexperienced users can get them when needed.  'set ?' gives a menu of
parameters; 'set parity ?' gives a menu of the parity settings, 'help set
parity' gives a fuller explanation of parity, etc.  All this works without
knowing anything about the terminal -- no termcap, curses, no reliance on
terminal-dependent function keys.]

5.  General.

     It'll be some time before I can do anything much with the new
C-Kermit, but it looks a fine job.  In particular, it should be very easy
to extract the whole of the protocol and parameter handlers for use on
systems whose architecture and command-language differ markedly from unix.
I will feed back info as I get on with it.  Thanks.

                                        Chris Kennington.

[Ed. - Thanks -- that's the idea.  We hope to use ckprot.w and ckfns.c as
the core of a new Macintosh Kermit -- the user and system interfaces will
be totally different.

There are a few other problems that have to be resolved, too.  Perhaps the
biggest one is reworking the logic used in switching between connect and
protocol to prevent some Unix implementations from releasing and possibly
hanging up the line whenever one escapes back to command level.  Herm
Fischer (HFISCHER@USC-ECLB) is working on this, plus some of the problems
listed above, while creating versions of C-Kermit for System III, PC/IX,
Xenix, etc.  There should be some results to announce soon.]

------------------------------

Date:  Fri, 15 Feb 85 02:21 EST
From:  Paul Schauble <[e-mail]>
Subject:  Sacred Characters, Cont'd
To:  [e-mail]

About two years ago I did a study for Honeywell on all of the then current
asynchronous communications protocols.  The conclusion was that Kermit
could not be implemented on their mainframes because they reserved @ as a
non-changeable character delete.  I believe that ARPANet users also have
problems with this character.

Because of the problems with various networks, forbidden characters have
to be specified by the user.  Just provide a SET that can be put in the
start-up and assume that the implementor will build in those that are
sacred to the operating system.

You still have to communicate them to the other end.

What I would like to see is a Kermit II protocol, that can be
non-compatable with Kermit I.  There is a lot of useful accumulated
experience now, and it would be a real shame to not be able to use it.
Kermit II would have windowing, sacred character negotiation, packet size
negotiation, and maybe multiple logical channels.  Is this politically
possible?

          Paul

[Ed. - I agree that these issues should be addressed by Kermit II --
there's not much chance of fixing all the Kermit I's out there.  And while
we're at it we could add some other things too: dynamically changing block
check types (each packet tagged with its block check type, to avoid all
the stupid negotion and confusion presently required to switch among them,
and to allow Kermits to adapt themselves on the fly to changing line
conditions), automatic detection of parity, allowance for negotiations
occuring at any time during a transaction, a mechanism to allow a file
transfer to be interrupted and continued (e.g. when a diskette fills up),
etc, etc.  But who has the time to write the specification, and who has
the time to write the many implementations?  Actually, it might not be so
bad if the new C-Kermit is used as a starting point...]

------------------------------

End of Info-Kermit Digest
*************************
-------
19-Feb-85 11:51:07-EST,8058;000000000001
Mail-From: SY.FDC created at 19-Feb-85 11:45:51
Date: Tue 19 Feb 85 11:45:51-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #7
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Tue, 19 Feb 1985       Volume 2 : Number  7

Departments:

  ANNOUNCEMENTS -
        New Release of CP/M-80 Kermit

  UNIX KERMIT -
        Os9 C-Kermit Informal Work/Dicussion List
        C-Kermit Filenames, Dialing
        Problems With C-Kermit Options

----------------------------------------------------------------------

Date: 18 Feb 1985 23:39 PST
From: Charles Carvalho <CHARLES@ACC>
Subject: New Release of CP/M-80 Kermit
To: Info-Kermit@CU20B

Version 4.05 of CP/M-80 Kermit is ready for testing.  Basically, all I did
was merge the changes I've received, with minor modifications.  There will
still be further releases after this (see below).  Here are some quick notes
on what's in v4.05:

From Hal Hostetler:
    Remember the current port, and display it in the output from the
    STATUS command.
    Fix some screen positioning errors in the file transfer commands;
    clear the screen when file transfer is aborted with ^C.
    Support Lobo MAX-80 computer.

From Paul Milazzo, Rice University:
    Extend H89 support (add SET SPEED and ability to send BREAK).
    Use BDOS version number to determine proper algorithm for disk space
    calculation.  (CPM3 users no longer have to run the generic
    version)

From Joe Smith, Colorodo School of Mines:
    Support the Northstar Horizon with Northstar CP/M and SIO-4 board.

From Vanya J. Cooper,  Pima Community College:
    Fix the checks for valid characters in CP/M filenames.  The characters
    <>.,;:?*[]_%|()/\ are not permitted; lower case letters are
    converted to upper case.  If the flag "ffussy" in the linkage
    section is set (at compile time, or by patching), we are more
    liberal.  The other special characters are always permitted;
    this means you can erase those filenames with ampersands from
    within Kermit.
    Fix problems with reparsing "?" in filespecs; also check for legality
    of wildcards.
    Add a fairness count to the input loop in CONNECT mode, so that the
    keyboard doesn't get locked out when the printer is running the
    same speed as the modem line.
    Major improvements in logging: use the large buffer; allow logging
    to be suspended (<esc>Q) and resumed (<esc>R) during CONNECT mode;
    retain the logging status and filename across multiple CONNECT
    sessions, incidentally fixing the horrendous bug where a file
    could be overwritten if the FCB was reused between the LOG command
    and the CONNECT command; add the SET LOGGING ON/OFF commands to
    control logging (LOG <filespec> enables logging and specifies the
    name of the logfile; SET LOGGING ON uses the last specified logfile
    or KERMIT.LOG if none was given).  If the logfile already exists,
    it will be appended to, rather than overwritten.
    Add connect mode <esc>P command to toggle printer on and off.
    Add separate conditional for the Xerox 820; it's just different enough
    from the Kaypro to be a pain.

    The large buffer size has been dropped to 8K bytes (from 16K); this
should help the systems that counldn't transfer larger files because of
protocol timeouts while the buffer was being written to disk.  I haven't
implemented the commands to change the timeouts yet, which is the ideal
solution.  I received a fix for the DECmate to IBM problem (where the
DECmate swallows the turnaround character), but it's not in this version.

    I also have a CP4SYS for multitudes of Apple configurations, from
Jonathan Beeson and Francis Wilson of Columbia Teachers College, but it
has persuaded me that it is time to split up CP4SYS.ASM.  Not one version
per system, yet, just per family.  Most of the "inout"-type systems could
stay together, for instance; with another file for the "iobyt" systems.

    I haven't tested version 4.05 extensively, but I have verified that it
compiles for all machines.  (I've also tried assembling some configurations
with MAC80).

    The files are available via anonymous FTP from CU20B as KER:CP4*.*.
A list of the specific files is in KER:CP4AAA.HLP.  The previous version,
4.03, will still be available for a limited time as KO:CP4*.*.  Users of
Kermit on the various CP/M systems are encouraged to get the new version,
try it out, and report how or whether it works to CHARLES@ACC, cc to
Info-Kermit.

------------------------------

Date: Sat 16 Feb 85 00:54:02-PST
From: Bob Larson <BLARSON%ECLD@ECLA>
Subject: Os9 C-Kermit Informal Work/Dicussion List
To: info-kermit@CU20B

Due to the interest in os9 kermit recently generated by the new Unix
Kermit, I have created a redistribution list for people working on os9
kermit.  If you want to be added or deleted from this list, send me mail.
(There are currently six people on this list... pretty big for an obscure
os.)  To mail to the list, send it to me and I will remail it to the list
if it is of general interest.

Systems currently represented:  3 coco's, 2 non-coco 6809 (1 level 1,
1 level ?), and 1 os9/68000.  Locations range from Los Angeles to Germany.
Networks include arpanet, csnet, and usenet.

Bob Larson
Arpa: [e-mail]
Csnet(?): Blarson%Usc-Ecl.Arpa@Csnet-relay
Uucp(??): {ucbvax,seismo,harvard,uw-beaver}!blarson{@,%}Usc-Ecl.Arpa
Others: Your guess is probably better than mine

------------------------------

Date: Sat, 16 Feb 85 11:09:53 pst
From: Mark Seager <[e-mail]>
To: SY.FDC@CU20B
Subject: C-Kermit Filenames, Dialing

    I put the new version of C-Kermit up on our Vax 11/780 running
UNIX 4.2 bsd last week.  A few users have complained that kermit is
messing around with the file names and they would like the ability to turn
this "feature" off.  Could another option be added so that no filename
translation is done?

[Ed. - You can disable the filename conversion with "set file naming literal"
-- see the documentation.]

    Also, how does one establish a connection with another host
with kermit over a modem line?  I know how to get tip to dial another host
and so forth, but when you exit tip our system hanges up the line.

[Ed. - To do dialing, just give the "connect" command, then type the
appropriate dialing commands directly to your modem (e.g. "ATD765-4321"
for a Hayes-like modem), wait for a successful return code (for Hayes, a
"1") then you're connected.  No support is included for manipulating
dialers, since there are too many different kinds, and the program is big
enough (too big) already.  By the way, even Kermit may give you some
trouble with hanging up.  The next release (this week or next, I hope)
should work better -- no hanging up until the program terminates, or the
line is changed.]
            Thanks,
            Mark ([e-mail])

------------------------------

Date:     Fri, 15 Feb 85 23:30:25 CST
From: Paul Milazzo <[e-mail]>
Subject:  Problems With C-Kermit Options
To: [e-mail]

I really like the new C Kermit, but I have a small problem with it.  At
first glance, there doesn't seem to be any way to set block check type
on the command line, or binary mode in the interactive mode.  I finally
tried "kermit -i", and then set block check type to 3 in interactive
mode, and sent a file to my CP/M system.  Sadly, the resulting file was
somehow garbaged.

Am I missing something?

                Thanks,
                Paul G. Milazzo <[e-mail]>
                Dept. of Computer Science
                Rice University, Houston, TX

[Ed. - It's true, there's no block-check changing option on the command
line.  Easy to add, but the line has to be drawn somewhere.  In
interactive mode, use "set block-check 3" and "set file type binary".
It's in the documentation.]

------------------------------

End of Info-Kermit Digest
*************************
-------
 4-Mar-85 18:06:52-EST,18796;000000000001
Mail-From: SY.FDC created at  4-Mar-85 18:06:28
Date: Mon 4 Mar 85 18:06:28-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #8
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Mon,  4 Mar 1985       Volume 2 : Number  8

Departments:

  ANNOUNCEMENTS -
    Commodore-64 Kermit V1.3
    Kermit-11 for TSX+
    Getting PDP-11 Kermit by Phone
    Unix Shell Script for FTP'ing Kermit Files

  UNIX KERMIT -
        (Next prerelease C-Kermit coming this week, watch Info-Kermit)

  MS-DOS KERMIT -
    MS-DOS Kermit .BOO Files and Translation Table Troubles
    MS-DOS Kermit Key Redefinitions
    (Version 2.28 on the way, watch Info-Kermit)

  MISCELLANY -
    Kermit-32 3.0 vs VMS 4.0
    Turbo Pascal Kermit for MSDOS systems.
    Kermit vs Sytek LocalNet 20
    Kermit and TACs
    Crosstalk, Kermit, and India

----------------------------------------------------------------------

Date: 20 Feb 85 17:10:37 EST
From: Eric <[e-mail]>
Subject: Commodore-64 Kermit V1.3
To: sy.fdc@CU20B

Version 1.3 is ready for release, along with documentation and a bootstrap
procedure for people who do not yet have Kermit. The bootstrap procedure
was written by Robert Scott Lenoil (Lenoil@Mit-XX) in CLU (available on
DEC-20s' and Vaxen running UNIX, I believe). I hope to have a Fortran
translation of the mainframe end shortly (it is really quite simple). This
version of Kermit includes the following updates and fixes:

    1) Full support for 1200 baud communications.

        a) Flow control, (XON/XOFF)
        b) Correct setting of baud rate, correcting errors
        in the standard RS232 Kernel routines.

    2) File-Warning has been implemented, a la Apple Kermit.

    3) VT52 emulation should work completely in 40 column mode.
    This includes printing of tabs!

    4) You can set the word-size for communication (7 or 8 bit)

    5) You need not exit and restart Kermit to bring into effect
    changes made in the communication parameters.

    6) Server commands definitely work the *first* time.

Enjoy!
Eric

[Ed. - The files are in KER:C64BOOT.* (the bootsrapping procedure),
KER:C64DXL.* (the hexification program), and KER:C64KER.*.  The program
itself is written in CROSS, a derivative of the PDP-11 cross assembler
which runs on the DECsystem-10 and DECSYSTEM-20 and generates code for
various kinds of micros.  The bootstrapping procedure consists of a short
CLU program on the mainframe end, and a short Basic program on the C-64
end.  Since most sites do not have the CLU language available, it is hoped
that a version in a more common language, like C, Fortran, or Pascal, will
appear soon (the CLU program is quite straightforward and should lend
itself easily to translation).  Meanwhile, executable versions of it are
available in KB:C64BOOT.EXE (for the DEC-20) and KB:C64BOOT.VAX (for the
VAX).  KB: is the Kermit-Binaries area.  Note that there is also another
Kermit program for the Commodore-64 written in FORTH, which is available
in KER:C644*.*; it has no accompanying bootstrap procedure.]

------------------------------

Date:     Tue, 26-FEB-1985 11:01 EST
From:     <BRIAN@UOFT02>
Subject:  Kermit-11 for TSX+
To:       dftcu@cuvmb

I am sending a hex file for TSX+ that works. The only restriction is that
it uses virtual overlays.
                                                brian nelson

[Ed. - The file is in KER:K11TSX.HEX.]

------------------------------

DATE: TUESDAY, 26 FEB 1985
FROM: BRIAN AT UOFT02
TO: SY.FDC AT CU20B
SUBJECT: Getting PDP-11 Kermit by Phone

I have been giving out info for people to log into my 11/70 to get current
Kermit-11's. I think I may as well publish this instead of always getting
calls about it.

Number: 419 537-4401

After carrier, hit cr until prompted with a *.  At this point type 12
followed by a carriage return.  Response is SERVICE 12 START.  Within a
couple of seconds login will come up. Account is 254/3, no password.
Instructions follow, this is a captive account running a DCL command file
on RSTS T9.0. If you get SERVICE 12 UNAVAILABLE, try later.

This procedure will change in June 1985 as the PDP 11/70 has been replaced
by an 11/44 and a 11/785.

------------------------------

Date: Thu, 21 Feb 85 12:03:40 est
From: randy@nlm-vax (Rand Huntzinger)
To: info-kermit-request@cu20b
Subject: Unix shell script for ftp'ing Kermit programs

I have a Unix shell script (Bourne shell, sh) which, when given the prefix
of a version of Kermit, or a list of prefixes, goes out and fetches those
versions of the files from CU20B.  Thus, the Unix command,

        getkermit ck cpm

will start FTP, connect to CU20B, properly fetch C-Kermit and CPM Kermit and
write the files in the current directory with Unix palatable file names.  It
properly changes modes from ASCII to TENEX when transferring binary files.

I've found this script very useful in keeping the relevant versions of Kermit
here up to date.  I'm sure you at Columbia will appreciate that it encourages
transferring only what you need.   [Actually, I think you could transfer the
entire distribution with the command "getkermit ''", but I haven't tried it]

The only problem with this script is that it depends upon a bug in the Unix
FTP program being fixed.  In the vanilla 4.2 BSD ftp program, a mget (multiple
get) command issued in tenex (binary) mode fails on the directory read.  We've
fixed that here, but it may not be fixed at all other sites.

The text of the script follows, you can do with it what you see fit.

[Ed. - It's in KT:UXFTP.SH.  KT: is the Kermit-Tools area.]

------------------------------

Date:         Thu, 21 Feb 85 14:14 EST
From:         Alan H. Holland <FEAHH@VPIVM1>
To:           Frank da Cruz <SY.FDC AT CU20B>
Subject:      BOO Files and Translation Table Troubles

In my last note to you, I mentioned that I was having a hard time using
MSPCTRAN.BAS to turn MSIBMPC.BOO into a executable EXE file.  In your
reply, you mentioned that the problem could be in a translate table
somewhere.  You will be happy to know that the trouble is at my end.

MSIBMPC.BOO gets from KERMSRV thru BITNET to my account on our VM/CMS
system intact.  It is when I download it to my IBM PC that it gets hurt.
At our particular VM/CMS site, there is a terrible confusion surrounding
the ASCII tilde, the ASCII carat, and the EBCDIC not characters.  During
the download, the characters that were originally tilde and carat all get
turned into tilde characters.  Not good, but not your problem.

I solved my problem by having KERMSRV send MSIBMPC.BOO to a VAX/VMS system
to which I have access, and then downloading the file from there.  That
also allowed me to discover how the VM/CMS system was damaging the file,
by comparing versions on the IBM PC and working backwards.

            --Alan Holland     FEAHH at VPIVM1 on BITNET

[Ed. - This sort of thing has proved a common problem on IBM mainframes.
To this day, there is no consistent, "standard", invertible ASCII/EBCDIC
translate table.  This raises the interesting question of how Kermit
packets, which themselves may contain any printable ASCII character, will
survive in such an environment (see discussions of "sacred characters" in
previous digest issues).  The Kermit User Guide and Protocol manual list
the recommended ASCII/EBCDIC translations.]

------------------------------

Date: 27 Feb 85 18:05:14 EST
From: Ken Burner <KB13@CMU-CC-TE>
To: Info-Kermit@CU20B
Subject: MS-DOS Kermit Key Redefinitions

(Using Version 2.26).  I have occasion to use both IBM and DEC systems
frequently.  I have a long list of key re-definitions for the IBM that are
not needed on the DEC.  Is there an easy way to "clear" all key bindings
to the default setting without exiting and re-running the program?

-Ken Burner

[Ed. - We'll look into putting a command into the next release to do this.
For now, the best thing is to have a key redefinition command file for
each system you want to connect to, or else keeping Kermit in a RAM disk
so that exiting and restarting isn't so painful.]

------------------------------

Date:     Thursday, 21 Feb 85 11:04:34 EST
From:     rmcqueen (Robert C McQueen) @ sitvxa
Subject:  Kermit-32 3.0 vs VMS 4.0
To:       Info-Kermit @ cu20b

The Kermit-32 processing of LOCAL commands and incoming REMOTE commands
does not work correctly under VMS 4.0.  This is because Digital has changed
how DCL and mailboxes interact.  This will be fixed in Kermit-32 3.1 which
we are now working on.

Kermit-32 3.1 will also fix the problem with the CONNECT command when the user
is on an RTA.  This is because RTAs don't work exactly like terminals in all
respects.

It is hoped that we will be able to get this out in the next couple of weeks.

------------------------------

Date:    Thu, 21 Feb 85 14:03 EST
From:    VIC@QUCDN
To:      sy.fdc@cu20b
Subject: Turbo Pascal Kermit for MSDOS systems.

I have written a Kermit in Turbo Pascal for IBM PC compatable computers.
It has most of the features of the current MsDos version.  Why reinvent
the wheel?  Why not build on the MsDos version?  Although the current
Kermit-MS has an overwhelming number of features, it is lacking in two
areas which can not be corrected by adding more code.  The two short
comings are ease of use and ease of modification.

A full feature Kermit written in turbo pascal can be completely compiled
within 2 mins. Compare that with the 15 to 20 minutes for assembling each
module of the KERMIT-MS.  In addition pascal code is much easier to read
than assembler.  I am amazed at the amount of effort and coding that has
gone into putting new features into KERMIT-MS. It must be hundreds of
man-hours of effort.

    In my version of kermit, I have attempted to minimize the number of
commands and options.  I have also minimize the number of keystrokes.  For
example all option can be specified with just one command line.  We can
also change options as we CONNECT. eg.'CONNECT 9600 Full Odd ' This will
connect modem at 9600 baud in full duplex mode and odd parity. It could be
abbreviated as 'C 96 F O'

    An attempt was made to seperate the code into three areas.  General
kermit code, MsDos dependent code, and hardware dependent code.  I expect
I will have a CP/M version within a month for an KayproII and an Apple2E.

[Ed. - This person has been put in touch with Jeff Duncan, who recently
submitted another Turbo Pascal Kermit, but for CP/M.  I hope the result
will be a common Turbo version for MS-DOS, CP/M, and maybe Apple DOS.]

------------------------------

Date: Sunday, 24 February 1985  08:06-MST
From: Jerry Lotto <talcott![e-mail]>
Subject: Kermit vs Sytek LocalNet 20
To: Info-Micro@BRL

KERMIT can work over a SYTEK net (LocalNet 20). Some problems though.  One
thing that I have found to be reliable is to set all packet sizes to 80
characters.  This is especially true of the new C-Kermit and VMS KERMIT.
For MS-DOS KERMIT, receive and send packet sizes are set individually. I
also tell the C-Kermit side that I want file type binary.  If I am sending
a 7-bit file the eighth bit does not get set anyway.  This setup has worked
transferring a file from a UNIX machine (in server mode) using telnet to
another UNIX machine (a VAX) through a SYTEK connection to a line driver
connected to a VMS vax running "vaxnet" who in turn passed everything to
an IBM-PC AT.  The transfer was a wildcard transfer of eight bit files
without quoting in both directions at 9600 baud (slowest connection, and
gave NO errors. Hats off to the KERMIT crew!)

------------------------------

Date: Wed, 27 Feb 85 14:09:34 EST
From: [e-mail]
To: [e-mail]
Message-ID: <[e-mail]>

 Our  mainframe  supports  VT52's,  but  expects them to have
 AUTOWRAP set on. That is, if the cursor is in column 80, and
 another  character arrives, the VT52 should move to the next
 line and put the character there. It turns out that MSKERMIT
 in  HEATH-19 emulation mode doesn't do this. Is there anyway
 to get MSKERMIT to do this, and if not, would it be possible
 to include this feature in a future version of MSKERMIT?

[Ed. - MS-Kermit 2.26 and later respond to escape sequences from the host
to control line wrap.  ESC v turns on line wrap, ESC w turns it off.
Maybe a future release of the program will include a command to control
this as well.]

------------------------------

Date: Mon, 25 Feb 85 15:49:04 EST
From: Edward Haines <[e-mail]>
Subject: Kermit and TACs
To: sy.fdc @ cu20b.arpa

Using Kermit with an InterNet Terminal Access Controller (TAC).

There are some conditions that must be met to successfully use Kermit on a
personal computer through a TAC.

Flow Control

The buffer size for a terminal port on a TAC is typically about 64 bytes.
(The size is a configuration parameter.)  Since the default packet size in
Kermit is about 96 bytes it is quite likely that buffer overflow will occur.

Some possible solutions:

1.  Enable flow control in Kermit on the PC and on the TAC.  Many PC
versions of Kermit implement XON/XOFF flow control.  In particular, the
new MS-DOS version does for the IBM PC.  To enable flow control on the TAC
issue the TAC commands

  @Flow Input Start
  @Flow Output Start

These are usually abbreviated @f i s and @f o s.  Note that flow control
is not compatible with binary mode (except see note below).

2.  Make the packet size on the PC Kermit small enough to not overflow the
TAC buffer, e.g.  60 bytes.  I had patched the old MS-DOS Kermit to do
this.  On the new MS-DOS Kermit, there is a command to set the packet
size.

3.  Increase the buffer size in the TAC.  This is not usually practical
and won't be considered further.


TAC Intercept Character.

The default TAC intercept character is the AT-sign.  The AT-sign is also
required by the Kermit Protocol.

Solutions

1.  Have the PC Kermit automatically double AT-signs on output.  This is
probably the best solution in general.  This feature is available on some
PC implementations of Kermit.  It is not yet available on the MS-DOS
version.  [Ed. - It's available in CP/M-80 Kermit 4.0x.]

2. Change the TAC Intercept character with the command

  @Intercept <decimal ASCII value>

I generally use @I 6 which sets the intercept character to Ctrl-F.

3.  Put the TAC into Binary mode.  This has the side effect of disabling
the Intercept character.  It also will allow you to transfer binary files
without special encoding.  The TAC can be put into Binary mode with the
commands

  @Binary Input Start
  @Binary Output Start

Some host systems allow you to engage the binary mode from the host.
[Ed. - DEC-20 Kermit has a command for this.]

There are several problems with binary mode:
   Some host systems don't support it.
   You lose the ability to control the TAC from the PC.
   You lose the ability to do XON/XOFF flow control.

Binary Files

It is sometimes desireable to be able to transmit an 8-bit binary file
between a host and a PC.  The TAC (which implements the DDN Telnet
Protocol) normally provides just a 7-bit ASCII path.

Solutions

1. Enable binary mode (if possible) as described above.

2. Enable 8th bit prefixing (if available) in both Kermits.  (This is
usually done by enabling parity.)

Notes

1.  You will probably get the best throughput for ASCII files by keeping
the packet size as large as possible and using flow control.

2.  There is not much advantage in increasing the baud rate between the PC
and the TAC beyond 1200 baud because of the realatively long turnaround
time for the acknowledgement packet.

3.  You may have problems when going through satellite hops or multiple
gateways due to the occasional very long delays.  This may result in
Kermit giving up.  I have also seen Kermit get into a sort of resonant
mode where it sends each packet twice but is otherwise succesful.
[Ed. - The resonating packets usually happen when one of the Kermit
programs is not capable of flushing its input buffer.  See the BYTE
article for an explanation of this phenomenon.  Long delays can be
circumvented to some extent by increasing the timeout interval; many
Kermits have commands to allow this.]

4.  Only the first letter of a TAC command is required.

5.  It is possible to set binary mode in only one direction.  For example
you can set Inbound binary and retain input flow control (XON/XOFF flow is
in the opposite direction).  You probably don't need outbound (input to
the PC) flow control when using the Kermit protocol.

Ted Haines

[Ed. - This file will be kept for reference in KER:DDNTAC.HLP.]

------------------------------

Date: Tue 26 Feb 85 06:30:27-PST
From: Richard H. Miller <[e-mail]>
Subject: Crosstalk, Kermit and India
To: [e-mail]

Some months ago I read a few messages concerning the use of KERMIT
with Crosstalk XVI.  Has anything come of this?  Can one use the scripting
features in Crosstalk with Kermit protocols?  If so, I'd be very grateful
for any help.

[Ed. - I have no knowledge of any progress.  We gave Microstuf our
standard permission to include Kermit with their product (see
KER:COMMER.DOC), but haven't heard anything since an announcement appeared
in PC Week a few months ago.]

Now a testimonial.  One of our clients is a consortium of international
agricultural research centers administered by the World Bank.  This group
of centers is foremost in the field, and represents the state of the
art in agricultural research.  As you might imagine, some of the centers
are located in countries without data network access.  One such center
is in Hyderabad, India.  During the past month, we have been using KERMIT
(version 2.27) on our IBM PCs and XTs to transfer files to and from
Hyderabad's VAX 780.  It would be understatement to say that the use of
international direct dial telephone between California and India
is noisy.  It's horrendous. However, by reducing the packet size and
twiddling a few other parameters, we have had very good success.

Thanks for a quality program.

Rich Miller
Telematics International
Palo Alto, CA

[Ed. - Thanks for the kind words; it's good to hear that Kermit may be
involved in actually doing something beneficial for humanity.]

------------------------------

End of Info-Kermit Digest
*************************
-------
 6-Mar-85 21:53:45-EST,3104;000000000001
Mail-From: SY.FDC created at  6-Mar-85 21:53:20
Date: Wed 6 Mar 85 21:53:20-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #9, C-Kermit Release #2
To: [e-mail], [e-mail],
    [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Wed,  6 Mar 1985       Volume 2 : Number  9

               Second Pre-Release of C-Kermit for Unix

----------------------------------------------------------------------

Date: Wed 6 Mar 85 21:43:12-EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Second Pre-Release of C-Kermit for Unix
To: Info-Kermit@CU20B

This is to announce the second "pre-release" of C-Kermit.  The first
pre-release (version 4.0) occurred a month ago; the program included
support only for Berkeley Unix.  This new release (4.2) includes support
for:

. 4.x Berkeley Unix (VAX, SUN)
. Generic AT&T System III, System V
. Microsoft Xenix for the PC/AT
. Interactive on the PC/XT (PC/IX) and other systems
. DEC Professional 3xx with Venix 1.0
. NCR Tower

All reported bugs have been fixed (or at least fixes have been
attempted), and many of the restrictions lifted.  "Dial" and "script"
commands have been added, along with code to support modem control and
dialers, uucp line locking, and the like.  The program itself has been
somewhat reorganized to be more adaptable to small environments: the
larger modules have been split; long character strings have been
shortened.

Most of the new work was done by Herm Fischer of Litton Data Systems, Van
Nuys CA (HFISCHER@USC-ISIB), and there were also contributions from many
others in the form of bug reports and/or fixes.  NCR Tower support came
from John Bray at Auburn University.  The new makefile (distributed as
CKERMI.MAK) embodies procedures for building all the different versions.

Since the program now runs on a variety computers, large and small, it
would seem relatively safe to begin adding support for other systems
without fear that the program will have to be completely reorganized
(again).  The only systems supported by C-Kermit so far are Unix systems;
rather than create a separate ckx and ckz module for each such system
(since these systems tend to differ in small places, but still have much
in common), conditional compilation was used within these modules.  If
C-Kermit is to be adapted to non-Unix systems, then a full replacement of
the ckx and/or ckz modules is probably indicated.  This is what we will
probably do in bringing the program up on the Macintosh.

The files are available via anonymous FTP from Internet host CU20B
(Internet number 192.5.43.128) as KER:CK*.*.  They will appear at
okstate (for uucp'ing) and on KERMSRV (BITnet) shortly.  If you plan to
adapt this program to a new system, be sure to let me know quickly so I
can prevent duplication of effort and can put people with similar
interests in touch with each other.

------------------------------

End of Info-Kermit Digest
*************************
-------
 7-Mar-85 18:47:41-EST,12788;000000000001
Mail-From: SY.FDC created at  7-Mar-85 18:46:59
Date: Thu 7 Mar 85 18:46:59-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #10
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Thu,  7 Mar 1985       Volume 2 : Number 10

Departments:

  ANNOUNCEMENTS -
    Old Files Moved

  UNIX KERMIT -
    C-Kermit Modules for Regulus
    Unix Shell Script for ftp'ing Kermit Programs, Cont'd
    Bug in C-Kermit
    C-Kermit 4.2 Problems

  MISCELLANY -
    TSX+ Kermit-11 Clarification
    MS-Kermit and TopView
    Series-1 Support in IBM Mainframe Kermit
    Resonating Packets, Satellite Delays to India

----------------------------------------------------------------------

Date: 7 Mar 1985 1853-EST
From: Frank da Cruz <SY.FDC@CU20B>
To: Info-Kermit
Subject: Old Files Moved

Since the Kermit distribution area on CU20B has grown sufficiently large
that it will no longer fit on a single reel of tape in ANSI D format at
1600 bpi, several old versions of Kermit have been moved to KE:, the
Kermit-Extra area.  These are:

KER:PC*.*  -  Version 1.20 of IBM PC Kermit.  Replaced by KER:MS*.*.
KER:CPM*.* -  Version 3.9A of CP/M-80 Kermit.  Replaced by KER:CP4*.*.
KER:UX*.*  -  Version 3.0 of Unix Kermit.  Replaced by KER:UX*.*.

The old files are still accessible, but now they're in KE: instead of KER:.

------------------------------

Date: 1 Mar 1985 0953-EST
From: Joe Smiley, Du Pont Co.
Via: [e-mail]
To: Info-Kermit
Subject: C-Kermit Modules for Regulus

I have transferred two source files for C-Kermit ckzreg.c and ckxreg.c
for using C-Kermit under the Regulus (Version 4.2) operating system.
These were created from the Berkeley versions and have been tested
(although not extensively). The modifications were minimal.

[Ed. - These changes arrived too late to be included in C-Kermit 4.2, and
would have been hard to add in any case, given the reorganization that the
program has suffered in the meantime.  I hope Joe can add the Regulus
support to the new release and send these modules to us again.  Meanwhile,
if anybody needs them, they're available for anonymous FTP from
KE:CK%REG.* -- note, KE:, not KER:.]

------------------------------

Date: Tue, 5 Mar 85 14:58:27 est
From: randy@nlm-vax (Rand Huntzinger)
To: Info-Kermit
Subject: Unix Shell Script for ftp'ing Kermit Programs, Cont'd

The following patch, applied to the 4.2 BSD ftp program, will allow mget
to work in TENEX mode, as required by my shell script to retrieve Kermit
versions from Columbia.  It isn't a particularly elegant solution, but
it's functional.

[Ed. - The shell script (announced in V1 #8), along with the ftp patch
(which is too long to include here) are in KT:UXFTP.* on CU20B (The
Kermit-Tools area).]

------------------------------

Date: Wed, 6 Mar 85 19:13:15 cst
From: Rusty Haddock <[e-mail]>
To: [e-mail]
Subject: Bug in C-Kermit

Problem:
    With C-Kermit (on Ultrix/BSD4.2) in server mode talking to
MS-Kermit on a TI Professional a "REMOTE DIR" command from the TIPC
will be displayed without carriage returns - just line feeds.
All of the REMOTE commands act this way.

Cause:
    What appears to be the cause is that the C-Kermit command
"SET FILE TYPE BINARY" affects ALL output from the UNIX system.
whether it's file transfer or REMOTE command.  Unfortunately,
you must terminate the SERVER, do a "CONNECT", and then
"SET FILE TYPE TEXT" to have the server output the CRLF pair for
the REMOTE commands.

Fix:
    Sorry, I have none (yet) as I'm not that familiar with
the C-Kermit source code but it may very well be easy to fix.
I would think that all that would need to be done is to have the
BINARY TRANSFER flag (or some such indicator) unset when transmitting
REMOTE command output and restored upon completion.

Your time and consideration would be appreciated.  Thanks, Rusty

ARPA:   [e-mail]
    Rusty@Maryland
CSNet:  Haddock@TI-CSL
USENET: {ut-sally, convex!smu, texsun, rice} ! waltz ! haddock

[Ed. - Diagnosis correct.  This problem will be fixed in the next release.]

------------------------------

Date:  7-Mar-85 12:29:17-MST
From: [e-mail]
To: [e-mail]
Subject: C-Kermit 4.2 Problems

I have just compiled the new ckermit on my 11/70 running Sys V. There is
one problem in ckdebu.h. The typedef unsigned long LONG caused a compile
error "misplaced long". Changing this to 'typedef long LONG' resulted in
a clean compile. I have not completly tested, but a preliminary test seems
to work o.k.

While trying to compile it on my VAX running 4.1bsd I also encountered an
error. In ckxunx.c there is a line '#include <sys/time.h>' and references
to two structures 'timevalue and timezone' that are expected to be in this
include file. I do not have that include file although I do have a <time.h>
and a <sys/times.h> neither one has either of the two referenced structures.
I don't have time at the moment to work on tracing the problem further.

Keep up the good work. Kermit is the best "free" software I have seen in
many years.
                Gene Wester

[Ed. - Thanks!  I haven't heard complaints about the typedef from other
Sys III/V places.  But that's what the typedefs in ckdebu.h are for --
change 'em to fit what your compiler can do.

This is the first I've heard about the time stuff on 4.1; sys/time.h is
used for a couple things -- getting the current date/time string (e.g. for
time stamps in the various logs) and for operation of the millisecond
timer in the function msleep.  If anyone can supply these functions for
4.1, please send them in!  Especially if there's a way to do it that works
in both 4.1 and 4.2.]

------------------------------

DATE: THURSDAY, 07 MAR 1985
FROM: BRIAN AT UOFT02
TO: SY.FDC AT CU20B
SUBJECT: TSX+ Kermit-11 Clarification

To clarify a point, there is NO such thing as K11TSX.HEX or K11TSX.SAV.
TSX+ users need to use K11XM or K11RT4, the first uses virtual overlays
the later does not. The RT version of Kermit-11 ALWAYS determines at run
time if it is on RT11, PRO/RT11 or TSX+ and loads the appropiate overlay
for terminal i/o correspondingly.
                                   brian nelson
                                   [e-mail]

------------------------------

Date: Thu Feb 28 1985 21:19:09
From: Marco Papa <[e-mail]>
To: info-kermit@CU20B
Subject: MS-Kermit and TopView

What are the recommended values of the parameters for MS-Kermit's PIF
(Program Information File) to work under TopView?

Marco
USC Computer Science Dept.

UUCP:  ...!sdcrdcf!uscvax!papa
CSNET: [e-mail]
ARPA:  [e-mail]

[Ed. - We fooled with it a little bit, but then lost our TopView disk.
Here's the best we can remember:

  Program size 100K
  Does map screen
  Can't run in background
  Doesn't use 8087
  Usurps all interrupts

It's really a little smaller than 100K, and it really doesn't usurp ALL
the interrupts.  It would be nice if it could run in the background while
transferring files, but since it fields interrupts from the port, you
can't do it.  And it can't run inside a window during connect mode because
it writes directly to screen memory (at least if you have H19 terminal
emulation "on").  If anybody wants to try this out and send back exact
instructions on how to install Kermit-MS under TopView, we'll include them
with the distribution.]

------------------------------

Date: Thu, 07 Mar 85 09:32:37 PST
From: KARL@USCVM        (Karl P. Geiger)
To:   (many people)
Subject: Series-1 Support in IBM Mainframe Kermit

[Ed. - This messages summarizes answers to a query broadcast over much of
BITnet.]

Greetings GentleBeings:

Thank you all for your answers to my letter.  I received many "I can
help" and "Please help me!" replies.

Briefly, UMDB people sent me a KERMIT module, VIC@QUCDN claims to have
a running KERMIT written in Pascal, SPGGTS@UCBCMSA has a running version
he is willing to send along, and NJG@CORNELLA has sent me some code
plus mods to CMS in UPDATE format.  Finally, Daphne Tzoar at Columbia
(DFT@CUVMA) sends word that she is incorporating all the interesting
mods for S/1 or 7171 support into Kermit and intends to release the
new version in three to four weeks.

Yale people have asked "Why aren't you using YTERM?  We wrote it to
support just what you want."   My answer, and reason for annoying
so many people on the net, is Yes, we are running YTERM in our IBM
PCs, but we have DEC-20s, VAX/VMSs, Unixes (Unices?), and PR1ME
Rabbits all which must talk to DEC Rainbows, PRO 350's, and CP/M
machines.  I use YTERM in my PC and PCTRANS to up/down load files
to VM frequently, but I would like a more general tool to gain
access to other systems.  Kermit has become the standard by consensus.

Personally, I intend to wait for Daphne to complete her work and
release the new Kermit.  I thank everyone else for their assistance,
contributions, and hard work to get Kermit running at their sites.
It makes more sense to me to use the 'standard' code which springs
from the fountainhead, however.

I will distribute the code I have received from UMDB and CORNELLA
to those who want it.

Thank you all again...

:Karl

------------------------------

Date: 6 Mar 1985 1820-EST
From: Joe Smith ([e-mail])
To: Frank da Cruz
Via: LCG.KERMIT@DEC-MARLBORO
Subject: Resonating Packets, Satellite Delays to India

I too have noticed this problem, where KERMIT sends each packed twice.  I
have seen it between KERMITs that do clear the input buffer.  It is not a
deficiency in a particular implementation of KERMIT, but instead is a
problem in the KERMIT protocol.

The current operation, that of resending the entire packet when there is a
timeout in getting an ACK, works only if the original packet got lost.  It
fails when the packet gets to the other end intact and was merely delayed
in transit.

What I have observed is the following:

  KERMIT-20 sends packet of data (call this 1A)
  KERMIT-PC sends an ACK, but it is delayed in the network
  KERMIT-20 times out, and sends a duplicate of the original (packet 1B)
  KERMIT-20 sees the delayed ACK 1A, sends packet 2A
  KERMIT-PC gets duplicate packet 1B, sends ACK 1B

At this point, the delay in the network is not present.  Therefore KERMIT-20
gets ACK 1B immediately after sending packet 2A.  Since this is not what it
was expecting, KERMIT-20 resends the data as packet 2B.  KERMIT-PC may be
confused as to why KERMIT-20 keeps sending every data packet twice, but it
stores the right data on disk and ACKs both packets.  For every other packet
that KERMIT-20 sends, it gets an ACK for packet "N-1" when expecting the
ACK for packet "N", and sends a duplicate packet "N".

The KERMIT protocol needs to be revised.  Whenever an ACK for packet "N-1"
is received, it should be thrown away, the SEND TIMEOUT value be increased
if possible, and KERMIT should resume waiting for ACK "N".

This would allow the two KERMITs to get back in sync.

I would like to make a suggestion for the KERMIT II protocol.  Only send
duplicate packets when an explicit NAK has been received.  Send a different
type of packet for timeout or user hitting the RETURN key.  This packet must
be distinct from all other packets, and come in at least 5 flavors.

  1)  HELLO, ARE YOU RECEIVING, THE LAST DATA PACKET I SENT WAS #123
  2)  YES, I AM RECEIVING, THE LAST DATA PACKET I GOT WAS #122
  3)  HELLO, ARE YOU STILL SENDING, THE LAST DATA PACKET I GOT WAS #456
  4)  YES, I AM SENDING, THE LAST DATA PACKET I SENT WAS #457
  5)  HI, I AM AS SERVER WAITING FOR YOUR COMMAND

With this mechanism, KERMIT would not have to blindly clear the input buffer.

[Ed. - Your diagnosis is correct.  But rather than wait for Kermit II, it
would be sufficient to employ the heuristic "discard redundant ACKs" which
you suggest, and which was also suggested in the BYTE article.  This is
not really a protocol issue; it's more like an implementation decision,
and can be added to any Kermit program.  The worst that can happen is that
the second ACK will not arrive within the timeout interval (which you are
free to adjust on a per-packet basis), causing retransmission of the last
data packet, which is what happens now.  Maybe this trick will show up
in the next release of C-Kermit.]

------------------------------

End of Info-Kermit Digest
*************************
-------
 8-Mar-85 17:00:29-EST,15582;000000000000
Mail-From: SY.FDC created at  8-Mar-85 16:59:24
Date: Fri 8 Mar 85 16:59:23-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #11
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri,  8 Mar 1985       Volume 2 : Number 11

Departments:

  UNIX KERMIT -
    C-Kermit 4.2 ready for UUCPing from okstate
    Oklahoma State UUCP Information
    C-Kermit vs Line Locking (2 messages)
    C-Kermit Remote Host Commands vs Binary Mode (2 messages)

  MISCELLANY -
    Resonating Kermit Packets

----------------------------------------------------------------------

Date: 7 Mar 85 23:40:01-CST (Thu)
From: Mark Vasoll <[e-mail]>
To: Info-Kermit
Subject: C-Kermit 4.2 ready for UUCPing from okstate

    Well, pre-release version 4.2 of C-Kermit has arrived safely from
Columbia and is ready for UUCP downloading.  We are planning to post this
version to Usenet's "net.sources" newsgroup tomorrow (3/8/85).  We hope
to prevent another outbreak of postings by providing this *one* posting
while C-Kermit V4.2 is hot off the presses.  We will take all possible
precautions to prevent some overzealous mailers (or News handlers) from getting
hungry.

    Please direct all questions and problem reports regarding this
message, the C-Kermit 4.2 posting, and the UUCP Kermit Distribution
service to the following address.  Your message will be routed to the
person maintaining the distribution at that time.  Mail sent to my
personal login will be answered, but could be delayed several days.

    Our UUCP line will now be available on a 24 hour basis.
Unfortunately, we still can offer only one line....  Of course we would
welcome donations of equipment.... :-)

UUCP Kermit Distribution Assistance:

UUCP:  {cbosgd, ea, ihnp4, isucs1, mcvax, pesnta, uokvax}!okstate!uucp-support
ARPA:  [e-mail]

Thanks,
Mark Vasoll
Department of Computing and Information Sciences
Oklahoma State University

------------------------------

Date: 8 Mar 85 10:00:00-EST
From: Frank da Cruz <SY.FDC@CU20B>
To: Info-Kermit
Subject: Oklahoma State UUCP Information

Here again is the information about UUCP access to the Kermit distribution
from Oklahoma State U:

UUCP access to the complete Kermit distribution is available from the
Department of Computing and Information Services, Oklahoma State University,
Stillwater, Oklahoma.

You need to set up "okstate" as a site in your "L.sys" UUCP dialing file
using the information listed below.  You can then issue the following
command on your system:

    uucp okstate\!/u/kermit/ck\* /usr/spool/uucppublic

   (this example will retrieve the Unix version of Kermit)

I chose "/usr/spool/uucppublic" as the destination on your system since
the destination must be WIDE OPEN (drwxrwxrwx) to everyone.  You should
not remove files from your uucppublic until the entire transfer is complete
including any redials that are necessary.  If you do remove some files
our system may retransmit them, resulting in a higher phone bill for
you.

There are 2 files available that contain information about the entire
distribution.  We recommend that you retrieve these files first.  They
are "00readme.txt" which explains the file name conventions used, and
"00directory" which is a complete listing (by name) of all files in the
distribution.  These files will enable you to choose the right files
the first time to save those high dollar phone bills.

-- UUCP Login information --

Site Name    :  okstate
Phone number :  [phone]  (one line only)
Login name   :  uucpker
Password     :  thefrog
Hours        :  24 hours per day, 7 days a week
Problem      :  okstate!uucp-support  (UUCP)
  reports    :  uucp-support%okstate@csnet-relay  (ARPA)

The phone number is for 300/1200 baud (bell compatible).

The following is a sample L.sys line (\r is a carriage return).
You might want to put a time restriction on Any. ("Any2100-900" in
Illinois)

okstate Any ACU 1200 405-624-6953 "" \r ogin: uucpker word: thefrog

Just a few notes on how to best retrieve parts of the Kermit distribution
using UUCP...

  -  Install the proper L.sys entry and test it using the debugging option
     of UUCICO (-x).  Repeat this step until you successfully complete a
     "no work" connection, this will verify that your L.sys entry is correct
     and will minimize frazzled nerves.

  -  Retrieve the files `00readme.txt' and `00directory' with the following
     commands:

          uucp -c -d okstate!/u/kermit/00readme.txt /usr/spool/uucppublic
          uucp -c -d okstate!/u/kermit/00directory /usr/spool/uucppublic

     You will have to escape the exclamation point if you are using the
     C shell (i.e. ...okstate\!/u/kermit...).

  -  Choose the versions of Kermit that you wish to transfer and issue the
     proper UUCP command.  Some systems don't seem to like wildcards, but
     in any case the wildcards will have to be escaped from your shell. The
     following command would retrieve the files relating to C-Kermit:

          uucp -c -d okstate!/u/kermit/ck\* /usr/spool/uucppublic

     PLEASE NOTE THE USE OF /usr/spool/uucppublic!  Unless you *really*
     understand how UUCP's protections work you should not change this!  A
     number of people have queued >100 files and had their systems refuse
     to store them in out of the way places.  This results in wasted phone
     time!

  -  If you are having problems connecting to our system PLEASE send mail
     to {cbosgd, ea, ihnp4, isucs1, mcvax, uokvax}!okstate!uucp-support

  -  Kind words also make my day!

Thanks,

Mark Vasoll
Department of Computing and Information Sciences
Oklahoma State University

UUCP:  {cbosgd, ea, ihnp4, isucs1, mcvax, uokvax}!okstate!vasoll
ARPA:  [e-mail]

[Ed. - This file is online at CU20B as KER:OKSTATE.TXT.]

------------------------------

Date: Fri, 8 Mar 85 01:23:45 est
From: Ken Yap  <[e-mail]>
To: [e-mail]
Subject: C-Kermit vs Line Locking

I like the new C Kermit but I wonder if a couple things could be made
options instead of hardwired.

The scenario: we use "tip" to do our dialing out, we are not even
allowed to know the phone numbers. After reaching the other system and
starting up a remore Kermit there, we suspend "tip" with ~^Z, then
start up a local Kermit.

Unfortunately the new Kermit gets in the way by: (1) checking for the
absence of a lock file in /usr/spool/uucp and (2) requiring a "set
speed" after the "set line" command.

Could a new settable option called say, "pre-connected", be added to
circumvent these checks? I believe others might be in the same
situation.

Thanks for a good piece of software.

    Ken

------------------------------

Date: Fri 8 Mar 85 07:51:07-PST
From: Herm Fischer <[e-mail]>
Subject: Re: C-Kermit vs Line Locking
To: SY.FDC@CU20B

I like the idea of having a "preconnected" test.  But that probably
is a site-level thing, rather than a end-user level thing.

I'd not like end-users able to set preconnected and then access lines in
an unlocked fashion.

So, I'd recommend some -D flag when compiling kermit for that, say
an augmentation to make which adds a "-DPRECONNECT" flag when it
is compiled.

Of course, this is hip-shooting, and may need some tweaking to work...

  Herm

[Ed. - Before putting this line-locking code into C-Kermit, the Unix
experts (including Herm) involved had a lengthy discussion of whether and
how it should be done.  There are many issues, and many strong opinions;
the readership of Info-Kermit was mercifully spared.  The resulting code
is a compromise, which, as Ken points out, doesn't work at sites that do
not allow users direct access to the line or modem.  Since this
arrangement is likely to be site-wide, then Herm's suggestion is probably
the best way out.  Note that the goal of this line-locking feature is to
prevent two (or more) processes (like uucp, tip, or kermit) from using the
same line at the same time, for reasons of security and data integrity.
At the same time, it is important that the line-locking feature not deny
access to a line which is actually free.  There is a fine line separating
these two requirements, and strong opinions about which side to favor in
ambiguous situations.]

------------------------------

Date: Fri 8 Mar 85 13:28:31-EST
From: Jeff Damens <[e-mail]>
Subject: C-Kermit Remote Host Commands vs Binary Mode
To: [e-mail]

In the last Kermit Digest, there was a suggestion that commands like
REMOTE HOST always do newline conversion instead of obeying the image
(set file type binary) flag.  This will make it impossible to use
kermit as a filter for binary files - for instance, one might wish to
pipe kermit output to a plot filter and issue the command "remote host
graph | spline | ..." to generate a graph on a mainframe and plot it
locally.

A more general solution to the problem would be to allow the remote
kermit to receive commands from the local kermit.  Then the user could
say something like "remote command set file type text" to change the
image setting without connecting back to the remote system and
restarting kermit.

[Ed. - This is the "remote kermit" command, which has been in the protocol
manual for a long time, but never implemented.  Maybe next release...
Meanwhile, the problem reported by Rusty Haddock in the last digest will
not be solved as easily as I thought.]

------------------------------

Date:     Fri, 8 Mar 85 14:22:25 GMT
From:     [e-mail]
To:       [e-mail]
Subject:  Resonating Kermit Packets

     A few further points on pervasive packet duplication (or, for that
matter, triplication etc.), following on Joe Smith's analysis in
info-digest 10.

     This sort of problem (caused by network congestion, satellite delays
etc.) is quite well understood by mainframe networking buffs.  There are
other ways it can get going as well as the route set out by JMS.  Once
started, with a Kermit-type protocol (which always retransmits on
timeout), it is stable and will continue until there is a network error
(which fixes it, since the lost packet will be replaced by its duplicate).

     The most authentic way to avoid it (without changing the
packet-sequences) is to ensure that the sender, acknowledger and network
have timeout/delay periods related so that:

           (2 * Tnet) < Tsend < (Tack - 2 * Tnet)

for all expected values of Tnet.  Unfortunately this is going to result in
rather long delays when a send packet is lost unless Tnet is quite small
(which it isn't).

     What happens on the network concatenation I use regularly (one X25
and one LAN with a low-performance gateway) is that there is a
transmission delay in both directions, both ends time out, and there are
then two complete sets of packets circulating.  It so happens that I am
dialling in to the X25 @ 300baud, so reception is quite slow.  The modem
lights show that reception is actually continuous, the duplicate ack being
received while the next data packet is going out (the micro has
interrupt-driven read).

     A simple and effective recovery mechanism is to flush the input
buffer at the end of the block-transmit as well as at its beginning.  This
will destroy the head of the duplicate block, which is all that is needed.
With variable network delay, it doesn't always work at once, but will in
due course.  There is a risk that this algorithm will destroy a needed
block if the other end turns around very fast, so perhaps it's better as
an option than always on.  This way the timeouts do not need to be long,
so recovery from lost data still takes place quite quickly.  Note,
incidentally, that if the micro was doing a half-duplex transmit, it would
not see the incoming duplicate block; perhaps file transfer for micros
should always be arranged to be in a pseudo-half-duplex mode!

     What seems essential to me is that the micro-Kermit keep its user
informed of the arrival of duplicate blocks.  Then at least he/she can
either take evasive action or curse and start rewriting Kermit.

                                Chris Kennington.

------------------------------

Date: 8 Mar 85 12:37:00-EST
From: Frank da Cruz <SY.FDC@CU20B>
To: Info-Kermit
Subject: Re: Resonating Kermit Packets

Timeouts are a complicated issue.  You want the timeout interval short
enough to catch missing packets without inducing undue delays, but long
enough to avoid spurious timeouts.  In order to set the optimum timeout,
you must know the speed of the communication line (the baud rate), the
length of the packet being timed, the current network delay, the packet
processing time (assembly/disassembly, data fetch/store), the load on the
host, and maybe other factors as well.  The problem is that not all of
these quantities are knowable at a given time, and on some systems not at
all -- for instance some systems provide no function to tell you the baud
rate of a line.  Network delays can appear and disappear suddenly, so a
timeout adjusted on this basis will tend to be wrong at the endpoints of
such events.  A host which can monitor its load can adjust its own timeout
accordingly (as DEC-20 Kermit does), but the Kermit on the other end has
no way of knowing about this.  A micro may have a small constant packet
processing time for n K worth of packets, but when the next packet comes,
it must take time out to dump its buffer to disk (CP/M-80 Kermit).  Etc.

The packet input buffer can be cleared at various times:

1. At the beginning of a transaction:  Important for clearing out stacked
   up NAKs from an idle server.

2. Before reading a packet:  Obviously a poor idea.

3. After reading a packet:  Can't hurt.  It will tend to work beneficially
   when the network delay or the remote system load is decreasing, and have
   no effect at other times.  Most Kermit programs do this, and it is
   often sufficient for getting resonating Kermits back in sync.

4. Before sending a packet:  Equivalent to the previous case, except that
   additional time has passed in processing the packet just received, so
   the likelihood of finding something in the buffer (like the beginning of
   an unwanted packet) is increased.

5. After sending a packet:  The likelihood of finding characters in the
   buffer is still higher, but so is the likelihood that they will be
   characters from the packet you're looking for.

The length of the switching delay between writing and reading is crucial.
If the delay is negligible, it won't hurt to clear the input buffer after
sending, providing the clear function can be executed quickly.  If the
delay is long, or unpredictable, then case 5 would be equivalent to case
2, and you'd never be able to read a packet.

C-Kermit is an excellent vehicle for experimentation with these
heuristics -- it's written in a high level language and runs on a variety
of systems from small PC's to large timesharing systems, and the next
release will most likely embody the results of our combined experience
(experiments and results welcome!).

------------------------------

End of Info-Kermit Digest
*************************
-------
12-Mar-85 19:32:17-EST,12945;000000000000
Mail-From: SY.FDC created at 12-Mar-85 19:31:56
Date: Tue 12 Mar 85 19:31:56-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #12
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Tue, 12 Mar 1985       Volume 2 : Number 12

Departments:

  ANNOUNCEMENTS -
    Info-Kermit Mail
    Corrected Apollo (Pascal) Kermit

  UNIX KERMIT -
    C-Kermit and RTU 2.2
    C-Kermit for Unix Version 7
    C-Kermit vs 8-bit Files vs Parity
    HP 9000 Series 500 Kermit, suggestions...
    New C-Kermit for VMS

  MISCELLANY -
    Resonating Packets, Cont'd
    Wanted: Disk-Full Handling for Floppy Based Kermits

----------------------------------------------------------------------

Date: Tue 12 Mar 85 18:48:24-EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Info-Kermit Mail
To: Info-Kermit@CU20B

Apologies to those who received several issues of the Info-Kermit Digest
twice.  The duplication was not caused by mail delivery problems; these issues
were directed at Info-Micro and Info-Unix as well as Info-Kermit because they
contained announcements relevant to the new Unix Kermit, which has been the
subject of some discussion on those two lists in recent weeks.

BITnet members of Info-Kermit are now addressed through the Wisconsin gateway,
WISCVM, rather than the Berkeley gateway, UCB-VAX, which is being phased out.
If you're a BITnet subscriber and did not receive this message, let me know!

------------------------------

Date: Sun 10 Mar 85 20:04:45-EST
From: PHY1.J-GROVES@CU20B
Subject: Corrected Apollo (pascal) KERMIT
To: [e-mail]

The corrected version of the apollo (pascal version) kermit, as per our
conversation of the past week, is ready.  I have been using it for about a
week now and it seems to work properly, within its original bounds.  I
expect to add a number of useful features to the present code, such as
terminal emulation (the Cyber terminal that is presently emulated is not
useful to me) and remote capabilities. I will forward these additions to
you as soon as they are complete.

                    Phil Kravitz

[Ed. - The original copy of Apollo Kermit (Pascal version) a number of
lines truncated in the source file.  Phil has figured out what the missing
characters must have been and restored them.  The updated copy is in
KER:APOLLO.PAS on CU20B, available via anonymous FTP.]

------------------------------

From: Stan Barber <neuro1![e-mail]>
Date: Sat, 9 Mar 85 14:50:03 cst
Subject: C-Kermit and RTU 2.2
To: sy.fdc@cu20b

The generic SYSIII/SYSV version of kermit 4.2 seems to compile up just
fine on RTU 2.2. I will examine the code more closely to see if there are
refinements that might take better advantage of the system.

Line locking seems to be the only problem when the /usr/spool/uucp file
is writable by UUCP and root only.

Stan

[Ed. - I've received a lot of complaints about the uucp line locking.
Before release of this version, all Unix experts agreed that
/usr/spool/uucp would be publicly writable on all Unix systems.  It turns
out not to be true.  In fact, on some systems it may not even be readable!
This whole business is a can of worms.  Why Unix did not, from the
beginning, in all its forms, allow a tty device to be opened with
exclusive access is beyond me...  The next release of C-Kermit will come
with some kinds of options as to how to handle line locking.]

------------------------------

Date:     9 Mar 85 16:43:30-CST (Sat)
From:     Gregg Wonderly <[e-mail]>
To:       [e-mail]
Subject:  C-Kermit for Unix Version 7

Frank,

   I have the Version 7 mods made to the new C-KERMIT (Release #2).  The only
necessary mods seem to be in the ck[xz]unx.c files.  I still would like to do
more testing, to make sure it really works properly.

Gregg Wonderly
Department of Computing and Information Sciences
Oklahoma State University

[Ed. - This will be incorporated into the next release.]

------------------------------

Date: Sat, 9 Mar 85 17:38:07 est
From: hipl!tony@nyu-cmcl2 (Tony Movshon)
To: [e-mail]
Subject: C-Kermit vs 8-bit Files vs Parity

If the 4.2bsd C-Kermit file-type is set to binary, parity is set to
anything other than none, and the remote kermit (in this case, the old
Unix Kermit 3.0) does not accept 8th-bit prefixing, C-Kermit goes ahead
and sends the file anyway, despite the fact that it must know that it's
stripping and throwing away all the high bits. Surely it should report an
error?

[Ed. - The behavior is correct, but you're right, C-Kermit should report
an error in order to give the user the chance to interrupt or cancel the
file transfer if this effect is not desired.  The next release will issue
a message when this happens.]

------------------------------

Date: 10 March 1985 22:57-EST
From: Yekta Gursel <YEKTA @ MIT-MC>
Subject: HP 9000 Series 500 Kermit, suggestions...
To: sy.fdc @ CU20B

I managed to get the new C-Kermit running on the HP 9000 Series 500
computers.  This is a completely different machine than HP 9000 Series
200.  The version of Unix we have is HP-UX 3.25 bqa.  We will soon get the
HP-UX version 4.  I'll make it run on that as well.  I do not mind
supplying kermit support for HP 9000 Series 500 machines.

I'll outline the changes that have to be made:  I used the "make sys3"
option with the following changes.

1) Remove the "-i" option from the CFLAGS and LNKFLAGS in the makefile.

2) In the line "wart ckprot.w ckprot.c; cc ... " replace "wart" with
"./wart" in the makefile. The reason for this is that if "." is not
in the current PATH, make will fail unable to find "wart".  We have
an open system, and "root" does not have "." in its path in order to
prevent "trojan horses".  People sometimes do funny things in an open
system.  Sigh.

3) In the file "ckxunx.c", on line 125: Comment out, or conditionalize out
the line "#include <sys/file.h>".  This file does not exist in HP-UX, the
definitions are in the kernel.  Similarly, in the same file on line 138:
Comment out, or conditionalize out the line "#include <sys/ioctl.h> for
the same reason.

4) In the file "ckzunx.c", on line 93: Comment out, or conditionalize out
the line "#include <sys/file.h>", for the same reasons stated above.

After these changes, C-Kermit will compile and run just fine.

Finally, a suggestion:  How about making the string "C-Kermit" which
appears in all error messages, disconnect messages, default prompt, etc..
user specifiable at compile time, with "-D" flag for example, so that
one can "customize" C-Kermit for a given machine by replacing it with
something that identifies the machine?  This will make life easier if
one is going through a whole bunch of kermits. Even with two of them,
it is sometimes confusing if both of the machines are running C-Kermit.

Best, Yekta  ( YEKTA@MIT-MC )

[Ed. - Good idea; perhaps the string could also be tied to "set prompt"
at runtime.  I expect your HP-9000 changes will be incorporated into the
next release.]

------------------------------

From: [e-mail]
Date: 10 Mar 85 22:52 EST
To: harvard![e-mail]
Subject: New C-Kermit for VMS

OK, everything appears to be working.  I would say it is ready for
an alpha test release.  Following is a complete list of the changes
I had to make:

CKCMD.H
    Added a #define for CR.

CKCMD.C
    Changed all putchar's to conoc's.  We want unbuffered output here,
    and that means conoc, no?  Likewise getchar -> coninc.
    conoc(CR) added under #ifdef vax11c at the end of the input line.

[Ed. - This will not necessarily be in the released version; it might
break the take command, and also interactive operation on certain versions
of Unix.]

CKCONU.C
    Wrote a version of conect() that doesn't use fork().  What it does
    instead is call a system specific function, contti(c, src), which
    returns when a character is available from either console or comm.
    line.  Also, a function, cancio(), is called at the end of the
    NO_FORK version of conect().

CKDEBU.H
    Added the parameters GOOD_EXIT and BAD_EXIT.  On VMS, exit(1) is the
    success exit, not exit(0).

CKDIAL.C
    Used a timed ttinc() rather than alarm().  On VMS, an alarm will not
    break through a pending read, so this method of timing out will not
    work.

CKFNS2.C
    Used GOOD_EXIT rather than 0 in a couple of exit()'s.

CKLOGI.C
    Used a timed ttinc() rather than alarm().  See CKDIAL.C.

CKMAIN.C
    Used GOOD_EXIT rather than 0 in a couple of exit()'s.

CKUSER.C
    Added a #define KERMRC ".kermrc" or "kermit.ini" under an
    #ifdef vax11c.  Also changed some exit()'s.

CKUSR2.C
    Added 19200 baud to the help string under #ifdef vax11c

CKUSR3.C
    Added 19200 baud under #ifdef vax11c

CKXVMS.C
    New file.  Originally, I had this combined with CKXUNX.C.  The result
    was 40K.  The original CKXUNX.C was 30K and CKXVMS.C is    under 19.5K.
    What do you think?

CKZVMS.C
    New file.  Figures are 27K (est.), 22.5K and 14.5K.

Stew

[Ed. - C-Kermit for VMS will be incorporated into a future release,
depending upon when it arrives.]

------------------------------

Date: Mon, 11 Mar 85 17:50:26 pst
From: Ken Poulton <@csnet-relay.arpa,@hplabs.CSNET:[e-mail]>
To: cc.fdc@columbia-20
Subject: Resonating Packets, Cont'd

I ran into a problem with buffer flushing which was intended to avoid this
resonating packet problem.  Kermit-32 already does a flush-after-read
operation.  However, when talking to the HP 3000, we found that it was
flushing out the XON handshake character from the 3000, causing the
transfer to go very slowly.  (It was never discovered when talking to IBM
systems because they apparently always had sufficient delay on the IBM
side to let the VAX flush before the XON came.  The 3000 can send the XON
soon after sending out a packet.)

Flushing is, of course, not needed when talking to half-duplex machines
like IBMs or HP 3000s, so the temporary fix was simple: I now have a
hacked version of Kermit-32 which simply omits the flush.

The moral of the story: if you add flushing on every packet (in addition
to the normal flush-at-start-of-transaction) PLEASE PLEASE PLEASE turn it
off when in HANDSHAKE XON or IBM_MODE.

And while I'm at it, here's another request to Kermit implementors: please
separate HANDSHAKE XON from the PARITY and ECHO options commonly lumped
into IBM_MODE.  The HP 3000 needs HANDSHAKE XON, but not the others!

Ken Poulton

[Ed. - Buffer flushing and line turnaround handshake can coexist, using
the trick found in the new C-Kermit -- If handshaking is being done, then
just redefine the packet terminator to be the handshake character.  Then,
once the packet is read, you can go ahead and clear the buffer.

"IBM-MODE" is a hack appearing in the early Kermits -- the ones that
didn't have command macros or take files or lots of different SET commands
-- to allow them to talk to IBM mainframes.  It's shorthand for "set
parity mark", "set duplex half", "set flow-control off", "set-handshake
xon", "set timer on".  It's site-dependent in that not all IBM mainframes
use mark parity, but otherwise it tends to do the trick.  More advanced
Kermits have separate SET commands for all these parameters, and also may
have TAKE commands and/or command macros to let you modify them
appropriately or set up new macros, like "SET HP3000".  Getting these
features into older Kermits is just a question of somebody doing the work.]

------------------------------

Date: 10 Mar 1985 0415-EST
From: LSM.SMITH at DEC-MARLBORO
To: SY.FDC at CU20B
Subject: Wanted: Disk-Full Handling for Floppy Based Kermits

I would like to see a new feature in KERMIT which would allow the receiving
KERMIT to tell the sending KERMIT to pause indefinitely.  If properly
implemented, this would allow the receiver to tell the sender to pause, exit
to the Operating System, format a new floppy, run KERMIT again, and allow the
sender to resume.  (This last step would probably require the user to supply
the name of the file to store the incoming data.) This way very large text
files could be stored.

[Ed. - I'd like to see it, too.  This is a tough issue because it requires
new protocol to be defined and implemented.  A workaround using present
apparatus is to "set incomplete keep" on receiving kermits that have that
feature.  When a disk fills up, go back to the sender, copy the unsent
portion of the file into a new file, and then send that.  Clumsy, but if the
file was 300K long, and 299K was sent successfully, it beats having to
resend the whole thing...]

------------------------------

End of Info-Kermit Digest
*************************
-------
15-Mar-85 17:27:57-EST,19023;000000000000
Mail-From: SY.FDC created at 15-Mar-85 17:27:11
Date: Fri 15 Mar 85 17:27:11-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #13
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri, 15 Mar 1985       Volume 2 : Number 13

Departments:

  UNIX KERMIT -
    C-Kermit for NCR Tower
    C-Kermit v 4.2 Bug Summary

  MS-DOS KERMIT -
    Kermit for DG One?

  MISCELLANY -
    Resonating Packets + Handshaking
    To Ack or to Write ...
    Kermit Packet Length

----------------------------------------------------------------------

Date:     Wed, 13 Mar 85 22:58 EST
From:     Larry Afrin <[e-mail]>
To:       [e-mail]
Subject:  C-Kermit for NCR Tower

I am pleased to report that C-Kermit compiles almost perfectly and runs
beautifully on our NCR Tower System V machines.  (The minor compilation
error was due to a global variable being defined in one place and being
redefined and initialized at a later point in the same module.)  Of
course, this compilation required the "make sys3" command, not the "make
tower1" we used for the 1.02 machines.

A note on the documentation: we're novices to Kermit, and the
documentation didn't explain too well (in our opinions, anyway) what the
relationship is between server mode and file transfers and remote
commands.  Briefly, what we were doing with Kermit was to login on two
different machines, bring up Kermit on both, have one of them dial in to
the other system's dial-in modem to which the other Kermit has already
"allocated."  Then one of us would try to "get" or "send" a file to the
other, or one of us would enter "server" and the other would try "get" or
"send".  Needless to say, this did not work.  What we finally did was to
dig out an old issue of Byte magazine, which told us that a user on one
machine should call up Kermit, dial in to another machine, call up Kermit
on the remote machine, enter "server" to the remote Kermit, escape back to
command mode in the local Kermit, and then try the "get" or "send" or
whatever.

                    -- Larry Afrin
                       Dept. of Computer Science
                       Clemson University

[Ed. - Larry also reported, and sent fixes for, many problems with the NCR
Tower OS 1.02 support.  The fixes should appear in the next release.  The
problems resulted from my attempts at fitting John Bray's Tower code for
release 4.0 into what had become 4.2, without being able to test it.

The documentation is just a chapter from the Kermit User Guide, the first
couple chapters of which are devoted to a general explanation of Kermit.
The remaining chapters, of which the Unix Kermit manual is an example,
give information for each major implementation, concentrating on the areas
where it differs from the general description.  I thought everybody had a
Kermit User Guide...]

------------------------------

Date: Fri 15 Mar 85 14:02:40-EST
From: Frank da Cruz <[e-mail]>
Subject: C-Kermit v 4.2 Bug Summary
To: [e-mail]

Many people have reported problems with (and suggested cures for) C-Kermit
version 4.2.  These reports have been (greatly) condensed into a file
CKERMI.BWR ("beware"), which is reproduced below, and which will be kept
up to date in the Kermit distribution area.  Some of the people who sent
reports or comments are John Bray (who supplied the Tower OS 1.02 support
for v 4.0, which I broke), Gregg Wonderly (okstate), James Matheson
(somewhere in England), Herm Fischer (Litton Data Systems), Monty Solomon
(Creative Concepts), Marco Papa (USC), Yekta Gursel (MIT), John Zsarnay
(CMU), Steve Grandi (NOAO), Dan Schullman (DEC), Larry Afrin (Clemson),
Scott Weikart (Stanford), Dave Robinson (JPL).  There were others too; the
pile is pretty thick.


-- SUPPORT FOR ADDITIONAL SYSTEMS: --

VAX/VMS: Added by stew%lhasa.uucp@harvard, not available yet (see below).

4.1BSD: C-Kermit built with "make bsd" does not work under 4.1.  The date/
  time stuff and line locking stuff are completely different from 4.2.
  Also, the directory format is different, so traverse() doesn't work.
  Specific support needs to be added for 4.1.  (John Zsarnay@CMUA)

Regulus: Submitted by Joe Smiley, DuPont Co.  Extensive changes to 4.0
  were too hard to fit into 4.2; hope Joe can add the Regulus support to 4.2.

NCR Tower, OS 1.02: Submitted by John Bray, based on 4.0, fitted into 4.2,
  but it doesn't work in 4.2; it will be fixed.

NCR Tower, System V: Works ok -- "make sys3"

HP9000 Series 500: (from YEKTA@MIT-MC):  Use "make sys3", but
  1. Remove -i from CFLAGS & LI
  2. In ckxunx.c, don't #include<sys/file.h> or ioctl.h.
  3. In ckzunx.c, don't #include<sys/file.h>.

Plexus P-60
  Works ok with "make sys3", but doesn't always hangup even when hupcl
  is on (Scott Weikart, Stanford).

Masscomp/RTU 2.2:
  Works ok with "make sys3" (Stan Barber, neuro1!sob@rice).

Pro/Venix 2.0 (field test):
  Works ok with "make sys3", except the "unsigned long" has to be changed
  to "long" in ckdebu.h; may be a bug in the new compiler (Dan Schullman, DEC).

SUN:
  C-Kermit 4.0 with 4.2bsd support was reported to run OK on the SUN after
  some bugs with long strings, char vs int, etc were fixed.  There is now
  a report that version 4.2 doesn't even compile on the SUN because of the
  ^L's in the source file (can this be true???), and that once compiled
  (by removing ^L's) it doesn't transfer files at all, but just times out
  after many retries of the first packet (this report from daver@cit-vax).
  Has anyone had any luck with C-Kermit 4.2 on the SUN?


-- BUG LIST --

General problems:

- Conditionalizations are not done clearly.  In some cases it might be
  better to have compile-time flags for features, rather than systems, or
  generic system names, rather than specific vendor/machine names, to
  avoid excessive nesting or OR'ing of compile-time variables.

- It might also be better to have a -D in the makefile for the system name,
  rather than hard-coding it into the ck[xz]*.c modules.

- Program's return code might be wrong in some cases (in 4.0, it was always
  zero; in 4.2 some attempt is made to return correct codes for failure and
  success).

- "quiet" (-q) flag does not turn off all error messages.  Direct use of
  fprintf(stderr,...) should be replaced by invocations of ermsg().

- The error messages should use the current prompt (changed via 'set prompt')
  rather than "C-Kermit" as a prefix, to make it easier to see which Kermit
  a message is coming from, if you have a C-Kermit on both ends of the line.

- Interrupt handling is not done particularly well, and if the program
  crashes or is halted while it has the terminal in a not-normal mode
  during command parsing or file transfer, the terminal mode is not restored.
  Code should be added to trap quit or panic interrupts and restore the
  terminal before quitting or panicking.

- Many people have asked for a system-wide startup file similar to
  the user's .kermrc file, perhaps with a conditional way to escape from
  it if the user has her own .kermrc file.  This notion might be extended
  to include the entire hierarchy system -- home -- current directory.

- A deeper problem with the initialization files is that the file is only
  taken when the program enters interactive command dialog.  To be consistent,
  it should also be taken when the program is run via command line arguments.

- Moving the program to VAX/VMS uncovered a few remaining Unixisms:
  . VMS uses program return codes with opposite sense from Unix; return
    code values must be conditionalized.
  . ".kermrc" doesn't work as a file name on most non-Unix systems.
  . There should be a more portable way of handling baud rates tables.

ckzunx.c:

- In zsout() & friends, "fprintf(fp[n], s);" should be "fputs(s, fp[n]);"
  or 'fprintf(fp[n], "%s", s)', to prevent core dumps when s happens to
  contain a '%'.

ckxunx.c:

- Many problems reported with "uucp line locking" --
  . On some systems, uucp apparently ignores the lock and breaks in anyway.
  . On some systems, the lock directory is write-protected.
  . On some systems, the lock directory is read-protected.
  . Reportedly on some systems (Sys III?), using dial commands and a login
    script pointed at a line already in use by uucp will hang up the line
    on uucp.

  Unfortunately, a lot of code will have to be added to take care of the
  many different ways that sites are set up to handle line contention and
  assignment, probably selectable by makefile compiler switches (see below).

ckdial.c:

- Some systems do not allow users to manipulate dialers directly.
- Not easy to add support for new dialers.
- Some systems never return from the 100-character rawmode read (it is assumed
  return is immediate, indicating how much was obtained from the input buffer).
- Timed read for connect/no carrier message from modem within a general timer
  on the whole operation does not work on some systems.
- Some systems need to have the modem explicitly hung up; close() isn't enough;
  e.g. ioctl(ttyfd,TIOCCDTR,0) on 4.2bsd.
- On some systems, the entire output from the dialer (e.g. "CONNECT") cannot be
  read in a single gulp, so the buffer should be appended to between successive
  reads, not overwritten.

ckus*.c:

- Some help messages still produce core dumps on some systems.  Diagnosis: the
  strings in these messages ('help remote', 'help set' are mentioned most
  frequently) are still too long for some systems.  Cure: shorten them some
  more, and maybe replace

    for (i=0; *s[i]; ++i) fputs(s[i], stdout);
  with
    while (*s[0]) fputs(*s++, stdout);

  in hmsga() to prevent possible references to tender memory.  Also, replace
  all printf(msg) with printf("%s", msg);

- The "directory" command produces a full recursive directory listing.  It
  should only list the current directory.  On bsd systems at least, the listing
  can be interrupted with a single ^C, which returns you to C-Kermit> command
  level.  Diagnosis: ???  The program just does a system("ls -l").  Why doesn't
  this behave the same as "ls -l" typed at the shell?

- Parser for the 'get' command doesn't respond well to editing; can go into
  infinite loops under some conditions.

- The filename 'transaction.log' is too long for some systems, and gets
  truncated (no harm is done, but the user is not informed and may not be
  able to find the file).

ckcmd.c:

- Some systems (such as Venix/11) swallow the erase and kill characters
  when the terminal is in cbreak mode.  If the erase and kill characters are
  are ^U and DEL, then these can't be used to edit C-Kermit interactive
  commands.  Ditto for ^R.  Diagnosis: sigh, let's hear for portability.
  Cure (if you can call it that):  Add new SET commands to allow the
  erase, kill, and redisplay characters to be redefined.

- There's no way to break a command line and continue on the next line.
  Cure: add code to allow "\" followed by CR (or LF, or FF) to accomplish
  this.  Nobody really wants to put a real CR (LF, FF) in the middle of a
  command anyway, right?  This will make take files and login scripts a
  lot more readable.

- No way to put comments in take files.  Cure: Add a ";" or "#" command?
  Trailing comments will be harder.

Protocol (ckprot.w, ckfns*.c):

- No way to interrupt a protocol transaction until after it starts
  successfully.  For instance, no way to interrupt the timeouts and
  retransmissions of the initial packet when the other side is not
  responding, except for killing the whole program.  Cure: check for
  keyboard "interrupts" during the send-init process.

- When receiving from a non-timed-out Kermit and missing the Send-Init
  packet, no NAK is ever sent, and a deadlock occurs.  Diagnosis: resend()
  is called to resend the previous packet; there was no previous packet,
  so it sends an empty line.  Cure: Initialize the packet buffer with a
  NAK for packet 0?

- When parity is in use and the other Kermit cannot do 8th bit prefixing,
  the user is not warned that binary files will not be transferred correctly.

- 'set file names literal' does not work at all.

ckconu.c:

- Doesn't do any particular kind of terminal emulation.  It wasn't meant to.
  Filters can be used for this.
- Performance is poor on systems that can't check the input buffer.
- As structured, connect mode can't include commands to toggle logging on
  and off or to change settings, because forks can't share variables.

ckwart.c:

- Has typedef for CHAR as "unsigned short" or "unsigned char".  Cure:
  Have ckwart.c use the typedefs from ckdebu.h, like the regular Kermit
  modules do.

makefile:

- Replace "wart ckprot.w ckprot.c" with "./wart ckprot.w ckprot.c" because
  "." might not be in the current path.

- It was suggested that the compound entry for making ckprot.o should be
  broken into two entries, one for ckprot.o, one for ckprot.c, to prevent
  unecessary recompilations.

- Some of the problems caused by access restrictions on the uucp lockfile
  directory might be addressed by having the makefile check and then setting
  an appropriate compile switch, e.g.

    if [ -w /usr/spool/uucp ]
    then make bsd "... -regular flags"
    else make bsd "... -DNOLOCKING"
    fi

[Ed. - This bug list will be kept up to date in KER:CKERMI.BWR on CU20B,
available via anonymous FTP.  Also, the list of who's working on what is
also updated frequently; it's in KER:CKWHO.TXT.]

------------------------------

Date: Fri, 15 Mar 85 09:17:57 mst
From: unmvax!wampler@LANL (Bruce Wampler)
To: lanl![e-mail]
Subject: Kermit for DG One?

    I have been having great success with the IBM PC version of
Kermit, then tried to run it on my new Data General One portable.  It
seems that the DG One is ROM call IBM compatible, but they apparently have
used different serial port hardware than the 8250 - thus kermit (or
Cross-Talk or ASCOM for that matter) will not run on the DG One.  I
haven't been able to get the DG tech ref manual yet.  Has anyone done the
port to the DG yet?  Does anyone know what hardware they are using at the
serial port?  I'll try the port if no one has done it when/if I get the
scoop on the hardware.  Thanks.

Prof. Bruce E. Wampler, UNM CS Dept.

[Ed. - According to previous issues of the Info-Kermit digest, the DG/1
uses an 8251 communications processor instead of an 8250 for serial i/o.
The "generic DOS" version of MS-DOS Kermit does not access the i/o chip
directly, but rather uses only DOS calls.  Thus one might expect it to
work on the DG/1, but very slowly (can anyone confirm this?).  Glenn
Everhart at RCA, who modified an old version of IBM PC Kermit to run on
the Seequa Chameleon, says that the Seequa version uses IBM ROM BIOS calls
for this, so the Seequa version (KER:SEEQUA.ASM) might work on the DG/1 if
the DG/1 emulates the IBM ROM BIOS.  Has anyone tried this?  Is anyone
working on DG/1 support for MS-DOS Kermit?]

------------------------------

Date: Wed, 13 Mar 85 12:24:37 pst
From: Ken Poulton <@csnet-relay.arpa,@hplabs.CSNET:[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Resonating Packets + Handshaking

>[Ed. - Buffer flushing and line turnaround handshake can coexist, using
> the trick found in the new C-Kermit -- If handshaking is being done, then
> just redefine the packet terminator to be the handshake character.  Then,
> once the packet is read, you can go ahead and clear the buffer.

If the read of the line terminator char is done in the packet reading
routine, I suspect that this will cause poorer performance.  Once the
packet is read, C-kermit should start preparing the next packet it will
send, so it is *ready* when the XON handshake character comes.

I will let you know whether this is a problem when I can get
the new C-Kermit running on my 4.1BSD system (it doesn't, right now).

Ken Poulton

[Ed. - This would only be a consideration in Kermits that are totally
interrupt-driven in packet processing; I don't know of any that are.
See above about C-Kermit vs 4.1bsd.]

------------------------------

Date:     Fri, 15 Mar 85 15:53:37 GMT
From:     [e-mail]
To:       [e-mail]
Subject:  To Ack or to Write ...

     A minor point which arises from the discussion of timeouts &
resonating packets.  Have you thought carefully about whether a data
packet should be ack'd before or after the data is written to disk?  The
main consideration seems to be that if the OS overlaps disk I/O with other
work, then the "write-to-disk" call will complete quickly and it's safe to
ack early; if the disk can occupy real time (during which the
communications are dead), safer to delay the ack, write to disk & risk a
remote timeout.  There is a case for a switch, either dynamic or
compile-option.
                                        Chris Kennington.

[Ed. - The decision on when to ACK varies from system to system.  Ideally,
one should only ACK a data packet after one has processed it successfully.
If there is a failure to write to disk, an error packet should be sent
instead of an ACK.  In practice, a disk write might take such a long time
(e.g. on a slow floppy with a lot of data buffered for it in memory) that
the ACK should go out first to reduce the chance that the other system
will time out before the write is completed.]

------------------------------

Date:    Thu, 14 Mar 85 12:12:13 EST
From:    Steve Carmody <STC@BROWNVM>
To:      Frank da Cruz <SY.FDC@CU20B>
Subject: Kermit Packet Length

With the advent of high speed, extremely reliable LAN's, has there been
any discussion of increasing the maximum length packet size beyond 94?
Because of the large number of existing kermit implementations, I'm
assuming that any such change would have to "negotiated" by the two
kermits during the SEND INIT sequence, in much the same way that other
optional features are negotiated.

[Ed. - It would be nice to allow longer packets, but since the packet
length is expressed as a single character, there's no way to increase it
without changing the protocol.  This could be accomplished rather
painlessly by (for example) using the currently unused lengths - 0, 1, and
2 - to specify that the first 2, 3, or 4 bytes of the data field give the
actual packet length.  This would, as you suggest, have to be negotiated
at Send-Init time.  This is just an idea; if the protocol is actually
changed to allow a mechanism like this, some more thought will have to go
into it.]

------------------------------

End of Info-Kermit Digest
*************************
-------
20-Mar-85 16:50:46-EST,20487;000000000001
Mail-From: SY.FDC created at 20-Mar-85 16:49:53
Date: Wed 20 Mar 85 16:49:53-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #14
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Wed, 20 Mar 1985       Volume 2 : Number 13

Departments:

  ANNOUNCEMENTS -
    New Release of PDP-11 Kermit
    Full-Featured MVS/TSO Kermit in PL/I from Rice University
    MVS/TSO Kermit Has Series/1 Support

  UNIX KERMIT -
    Manual Page for C-Kermit
    C-Kermit 4.2 comments
    Bad Bug in C-Kermit?
    C-Kermit on Pyramid?
    Making C-Kermit Work on the SUN
    C-Kermit on Four Phase 6300
    C-Kermit on Callan Unistar 300
    Want C-Kermit on PDP-11 with RT11

  MISCELLANY -
    Offer to Provide C-64 Kermit Diskettes
    CP/M KERMIT and Start-of-Packet
    Apple II Kermit for ProDOS?
    Please help - Tandy 2000 Kermit

----------------------------------------------------------------------

DATE: WEDNESDAY, 20 MAR 1985
FROM: BRIAN AT UOFT02
TO: INFO-KERMIT AT CU20B
SUBJECT: New Release of PDP-11 Kermit

There is a new version of Kermit-11 available, version 2.26.  The main
reason for this release is TSX+ support. The changes from v2.24 are:

1. 35% thruput improvement for RSTS/E from changes in packet reading.
2. Added ^E,^X and ^Z aborts for sending files.
3. Added SET CONSOLE 7/8 for stripping the high bit off of characters
   in terminal emulation for P/OS to avoid odd characters.
4. More info in help file, particularily for binary file transfer.
5. Fix server replies (some replies had imbedded control characters.
6. Change default output record format to stream ascii for RSTS/E
7. Support is finished for TSX+. Sorry it took so long, but I do not
   have a TSX+ system. Others had to do the work (Ned Rhodes and Tony
   Movshon)
8. Changes % to ? in filenames for RSTS/E for GET and REMOTE DIR.
   Needed since some Kermits mangle the filename if you say GET MS???.*

                                                brian nelson
                                                [e-mail]

------------------------------

Date: Tue 19 Mar 85 19:42:29-EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Full-Featured MVS/TSO Kermit in PL/I from Rice University
To: Info-Kermit@CU20B

There is an advanced version of Kermit for MVS/TSO written in PL/I (tested
in MVS/SP 1.1.1, MVS/SP 1.3, and MVS/XA) available from Rice University.
It is not included in the Columbia Kermit distribution because full source
is not provided, and the program cannot be built from the incomplete
source that is provided.  While Rice is willing to furnish the load
module, this cannot be accommodated in our most common tape formats, like
ANSI Format D, nor on non-IBM file systems (such as the DEC-20 and
VAX/Unix systems from which Kermit is distributed).  Therefore, those who
would like to obtain this version of Kermit should order it directly from:

    Andrea Martin
    P.O. Box 1892, Dept ICSA
    Rice University
    Houston, TX  77251
    Phone [phone]

If the full source becomes available, then this version of Kermit will be
included with the Columbia Kermit distribution.

------------------------------

Date: Tue 19 Mar 85 16:37:54-EST
From: Daphne Tzoar <[e-mail]>
Subject: MVS/TSO Kermit Has Series/1 Support
To: [e-mail]

The assembler version of IBM MVS/TSO Kermit, which is an adaptation by the
University of Chicago of Columbia's original VM/CMS implementation, has
had support added by Charles Painter, University of Toronto Computing
Services, for the Series/1 front end running the Yale ASCII Terminal
Communications System V2.1.  This allows PCs to transfer files using
Kermit even when they are connected to IBM MVS/TSO systems that believe
they are talking to 327x-style synchronous terminals, provided the
protocol emulation is done by the Yale IUP.

[Ed. - This replaces the Chicago TSO Kermit, since it is the same but with
the addition of Series/1 support.  It's available in the files KER:TSO*.*
on CU20B and on BITNET via KERMSRV at host CUVMA.  The documentation has
not been updated at all, and is somewhat dated.  Thanks to Philip Murton
of U of T for submitting this new release.  The forthcoming release of
VM/CMS Kermit will also have Series/1 support.]

------------------------------

Date: Mon, 18 Mar 85 16:09:43 CST
From: Stan Barber <neuro1![e-mail]>
Subject: Manual Page for C-Kermit
To: sy.fdc@cu20b

Here is a possible manual page for Unix Kermit...

Stan

[Ed. - Stan's man page is available as KER:CKERMI.NR.  We still don't have
the single source that generates both Scribe and Nroff input, but this
supplies the real man page that has been lacking up till now.  Thanks, Stan!]

------------------------------

Date: Fri, 15 Mar 85 20:22:04 pst
From: Ken Poulton <hpl-opus![e-mail]>
To: Info-Kermit
Subject: C-Kermit 4.2 comments

I brought up C-Kermit 4.2 on my HP 9000 Series 500, at last.

First of all, wow!  This is a great package.  My complements, especially
on the command interface.  It's really quite whizzy.  In fact, I like it
more than I expected I would (being a Unix die-hard).

I also have a large number of comments on things that could go smoother.
Although the list is long, remember that you have really done the job
well, and I'm just working on perfection now.

Rather than wait for time to make this a lengthy letter, I'm going to send
you my notes on C-Kermit.  Most of them are reasonably self-explanatory
(famous last words).  I expect some of them are being addressed already,
and others I will be interested in doing.

send cmd
    "send file [name]" is confusing syntax and precludes "send file file2..."
        which is what the Unix user expects
    "send file [-as name] [file [-as name]]..." more general

[Ed. - True, but the command package does not have a facility for parsing
alternates.  I had to stop somewhere...]

wildcards
    why not just use a shell to expand wildcards?
    Then wildcards are complete and consistent with normal usage.
    Surely speed is not an issue here.

[Ed. - No special reason.  The current way is more efficient, but you're
right -- you miss the compatibility with the shell.  Maybe somebody can
try writing zxpand() and znext() functions that do it with a shell.  On
systems without shells or pipes, the present do-it-yourself model will
still have to be followed.]

! cmd
    should use the shell defined by the env var SHELL, if defined
    "!cmd"     should work for Unix consistency (not just "! cmd")
    "!"        should get an interactive shell

[Ed. - The "!" command just does a system() of its argument.  Rather than
write all the code to fork and pipe the desired shell, maybe users can
just live with typing "! csh xxx" or "! ksh yyy" if they want these
effects.  A space is needed after "!" because "!" is a command keyword,
and whitespace must separate command fields.  Removing this limitation
would probably make the command package a lot hairier.  Maybe to alleviate
the confusion that this causes, the "!" should be renamed (back) to "shell".
Good point about this command invoking an interactive shell when no arg is
given -- just like it does now if you say "! sh" or "! csh".]

stat cmd
    can't we get timing info to get effective baud rate?

[Ed. - If you have given a "set speed" command (or -b option), then this
would be reasonable.  Otherwise, the program would not necessarily have a
reliable way of determining the baud rate.  I really tried to avoid all
this kind of system-dependent hair (system clocks, baud rates, etc)
because it tends to make the program grow out of proportion to its
functionality.]

space cmd
    should do a du for space used

[Ed. -  Maybe; du can produce a lot of unwanted output if there are many
subdirectories.  If you really want it, say "! du" instead of "space".]

command interface
    Use the user's line kill char rather than hardwire to ^U.
    Use the user's backspace char rather than hardwire to DEL/BS.
    Respond to the user's interrupt char rather than hardwire to ^C.
    Kermit not observing these is very annoying, since being able to
    choose them is a nice (and often used) feature of Unix.  This also
    confuses novices.

[Ed. - But the last guy said you should use something OTHER than the
user's line and char kill characters; can't please everyone.  Also,
again the point about system independence.  C-Kermit 4.0 was a pretty
clean program.  4.2 already has tons of hair added to the system-dependent
portions, and every time we add a system-related feature like this, it's
got to be added for n systems, and soon the program will be an enormous
pile of verbiage, buried somewhere in the middle of which will be the Kermit
protocol.]

interrupts
    behavior now is correct for interrupt in command-line mode
        (error packet, close line, exit)
    - you should not have to turn off interrupts in background -
        the shell is supposed to do that for you
    respond to the user's interrupt char rather than hardwire to ^C
    interrupts should be caught when running interactively !!
        (except in connect mode)
        - should act as ^B when transfer running
        - should *always* return to C-Kermit prompt after the first C-Kermit
        prompt (setjump/longjump does this rather trivially)
    - nearly every interactive program on Unix responds this way
    ^B doesn't work when send-init is failing

[Ed. - I'm not an expert on Unix interrupts.  But I don't believe the program
is hardwired to trap ^C -- rather, it tries to catch SIGINT.]

prompt
    default should be settable with cc -DPROMPT
    does "set prompt" affect error messages - especially those sent
        in error packets?
    all error messages should use the prompt-string (maybe without the >)
        to make errors easier to track down when running in the background

[Ed. - Agreed.]

line locking
    locking upon startup for -l argument is more intuitive than waiting for
        first connect command
    should allow you to connect if you own the lock file
    - maybe ask first in this case?

[Ed. - Line "locking" aficionados are enouraged to carry on this
discussion among themselves until the end of time.  I already have a stack
of correspondence on the subject about an inch thick.  It's impossible to
please everybody.  In this case, you can't please ANYBODY.]

script
    add ~d - delay for one second before sending next char
        for talking to slow network controllers (w/o typeahead)
    add ~x - XON (needed as the prompt char when talking to HP 3000 or IBM)

[Ed. -  The ~d (and maybe also a ~w for wait-for-input timeout) escapes
are being added somewhere.  Good idea about ~x.]

------------------------------

Date: Sun, 17 Mar 85 04:50:13 est
From: Ken Yap  <[e-mail]>
To: [e-mail]
Subject: Bad Bug in C-Kermit?

I have discovered that if C-Kermit is sending a file and it is interrupted
with ^C for example, that file gets deleted.  Surely this should only
happen if the file is being received and "keep incomplete" is off?

    Ken

[Ed. - You're right about what should happen, but on my 4.2 bsd system I
can't reproduce the problem.  Has anyone else seen this happen?]

------------------------------

From: trwrb!trwspp!spp3!kurisaki@Berkeley (Lance R. Kurisaki)
Date: Mon, 18 Mar 85 09:36:24 pst
To: [e-mail]
Subject: C-Kermit on Pyramid?

Am I the only one who has had problems getting C-kermit V4.2 running on the
Pyramid 90x (under 4.2 bsd)?  It compiles fine, but doesn't do transfers.

                Lance Kurisaki
                {ucbvax|decvax}!trwrb!trwspp!kurisaki

[Ed. - See the next message.  I thought this had been fixed, but apparently
it wasn't.  Sorry!]

------------------------------

Date: Wed, 20 Mar 85 14:59:12 est
From: [e-mail] (Mike O'Connor)
To: info-kermit@cu20b
Subject: Making C-Kermit Work on the SUN

I am in the process of installing 4.2 Kermit on my SUN system. There were no
problems in compilation or in using Kermit to login to our local VMS system.
File transfers, however, did not work. Kermit would send out the "send init"
packet and then time out waiting for a reply. The problem turned out to be
the definition of a local variable in the routine "ttinl". The variable "c"
is defined as an integer instead of a char.

Apparently when a byte is read and put into "c" the byte is placed in the
high order byte of the integer. But when "c" is assigned to "dest[x]" the low
order byte is used, filling "dest" with NULLs.

After making the change to "ckxunx.c" (which is where "ttinl" is located) I
used "make bsd" and am apparently up and running.

I've used this version of Kermit to move half a dozen ASCII files from the
SUN to the VMS system so far without any problems.

                Mike O'Connor

[Ed. - Thanks, Mike!  Presumably, this will also fix the Pyramid.]

------------------------------

Date:  Tue, 19 Mar 85 13:45 MST
From:  "Kevin W. Laurent" <[e-mail]>
Subject:  C-Kermit on Four Phase 6300
To:  Frank da Cruz <[e-mail]>

I just wanted to drop you a short note to let you know that we got the
new C-Kermit running on a Motorola Four Phase 6300 under UNIX.  I've
never seen a port go as smoothly as this one.  We used `make sys3' and
only had two problems--3 doubly defined variables (ncmd, nprm, nrmt) in
ckcmd, and the problem in the makefile with ckprot mentioned in Digest
#13.  Thanks for doing such a fine job, everyone!

[Ed. - Thanks to Herm Fischer for adding the Sys III/Sys V support, and
to the manufacturers for providing fairly consistent implementations.]

------------------------------

Date: Tue 19 Mar 85 17:49:40-EST
From: J. Eliot B. Moss <[e-mail]>
Subject: C-Kermit on Callan Unistar 300
To: sy.fdc@CU20B

The second pre-release version seems to work fine on a Callan Unistar 300,
which uses the Unisoft System V port to the 68000.  I have noticed nothing
strange (beyond the bugs already reported), and it compiled fine as received.
Thanks for the good work, everybody!
                Eliot

[Ed. - I assume that one builds it with "make sys3", since it runs a System V
variety of Unix.]

------------------------------

From: Dave Yost <day@rand-unix>
Date: 19 Mar 85 16:36:30 PST (Tue)
To: info-kermit-request@cu20b
Subject: Want C-Kermit on PDP-11 with RT11

Is anyone doing this port?  Thanks.

[Ed. - Somebody may try to produce a DECUS C version, nothing definite yet.]

------------------------------

Date: Sun, 17 Mar 85 20:48:14 est
From: Robert Scott Lenoil <[e-mail]>
To: [e-mail]
Subject: Offer to Provide C-64 Kermit Diskettes

I just posted the following message to USENET.  Briefly, I offered to
provide copies of diskettes containing Kermit for the Commodore 64
for seven dollars, to defray my costs (diskette, mailer, postage,
wear and tear, and my time - which will be a lot, considering that I
only own a single disk drive, and therefore will have to swap disks
back and forth to perform a copy.)

To address your problem (how to obtain Kermit) I thought I'd let you know
that I am willing to provide Kermit diskettes to those people who are
reluctant or unable to go through the downloading procedure.  For $7.00
(U.S. funds), I will provide a diskette containing the executable code and
documentation file.  (Outside North America, please enclose an extra $1.00
to cover additional mailing expense.)  Send requests and inquiries about
Commodore-64 Kermit disks to the address below.

Note that Kermit is written using the CROSS cross assembler which runs
only on DEC-10's and DEC-20's; hence enclosing the source code would not
be of much help.  An additional problem is that the source code is larger
than an entire 1541 diskette, and therefore would be too much trouble for
me to copy.

Please note that I am not conducting a business.  I am making this offer
to increase the availability of Kermit, which I hold to be a fine program.
I must stress that Kermit may be copied free of charge, so long as this
copying is not for "explicitly commercial purposes"  (Taken from Columbia
University's policy document on Kermit distribution), and those of you who
wish to do so may download it free of charge from Columbia University
machine CU20B (on ARPANET), using BITSERVE (from BITNET), or via UUCP from
host OKSTATE.

If people have questions, they can contact me by sending mail to
lenoil@mit-eddie.  Mit-eddie is on both the DoD internet and USENET, so
I'm fairly accessible.  Also note that I will not be at my present U.S.
mail address for this summer, but my network mail will forward.
Therefore, starting in June, it would be a good idea to first send me
computer mail to obtain my current mailing address, rather than suffer the
problems of delay and lossage of forwarded U.S. mail.

Yours truly,
            Robert Lenoil
            229 Commonwealth Avenue
            Boston, MA  02116  (USA)

------------------------------

Date: Fri 15 Mar 85 21:55:14-CST
From: Stuart Schmukler <STAFF.SAS@UChicago>
Subject: CP/M KERMIT and Start-of-Packet
To: sy.fdc@CU20B

I have finished modifing the CP/M 4.04 kermit to support SOP
(Start-Of-Packet) setting.  The syntax I have chosen is:

        SET START-OF-PACKET <cr>
        enter character:                !You type ^C, ^A etc.

The additional code adds about 1KB to the CP4KER.HEX file so that the
variable OVLADR is now 3600 for the CP4TYP.ASM file.

Now that I have a KERMIT that is working for our IBM, the users want to
be able to generate a BREAK.  So I'll add BREAK code to the CP4TYP.ASM
file for the MORROW MICRO DECISION I (UDI in the TYP defines) and
others _IF_ some one sends me the code to do it.  I have not been able
to findout from Morrow's doc what UART they use (the KERMIT code does
not help either).

SaS

PS: I have noticed that the RICE TSO KERMIT calls SOP 'marker'. Is there a
"standard" syntax?

[Ed. - "mark" is the term used for this field in the Kermit Protocol
Manual, chosen primarily for its shortness.  "Start-of-Packet" is a better
phrase for users.  Stuart's SOP changes for CP/M Kermit will be provided
to Charles Carvalho, the current CP/M Kermit keeper, when they arrive;
meanwhile, if anyone can help with the BREAK-sending code for the Morrow
or any other CP/M systems whose Kermits still can't send BREAK, please do.]

------------------------------

To: [e-mail]
Subject: Apple II Kermit for ProDOS?
Date: 18 Mar 85 10:31:00 PST (Mon)
From: Stephen <[e-mail]>

Is there a ProDOS version of Kermit running about somewhere?

            -- Stephen Willson

------------------------------

Date: 18 Mar 1985 23:32:31 EST
From: [e-mail]
Subject: Please help - Tandy 2000 Kermit
To: [e-mail]

Anyone feel charitable?
    I am a novice Kermit user actually attempted user that owns a new
micro (TANDY 2000 w/256K,MASM,SOFTERM2000 comm package,BASIC,LOTUS, &
MULTIMATE) on the Arpanet via ABN.BOYD@usc-isid. I have had virtually no
success with either TA2000.ASM or MSGENER.ASM (modular) Kermit versions. I
downloaded these two versions from CU20B, assembled, linked and attempted
to download text and binary files with no success. TA2000.ASM would fail
but clearly attempt to execute via timeouts. Repeated tries with KERMIT-20
in server mode were not successful. MSGENERIC assembled and linked (I
double checked to insure all files were included) but it failed to
properly open or identify the com port each time. Not sure I understand
correct response to handle: prompt, but took program prompt/suggestion to
use "3" each time. No success.
    Are there any Tandy 2000 users out there that could offer some
advice or assistance. I do have SOFTERM 2000 comm package that correctly
transfers micro to micro w/XMODEM protocol. I'll glady pay any phone
charges if someone has an executable (.EXE) version that will use MSDOS 2.0
capable kermit.

    Joe Boyd
    2109 Elvira St. Apt #902
    Fayetteville, NC 28303
    (919)-494-2203

------------------------------

End of Info-Kermit Digest
*************************

-------
22-Mar-85 18:25:13-EST,15565;000000000000
Mail-From: SY.FDC created at 22-Mar-85 18:24:29
Date: Fri 22 Mar 85 18:24:29-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #15
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri, 22 Mar 1985       Volume 2 : Number 15

Departments:

  ANNOUNCEMENTS -
    Corrections, Reminders, Notes
    New MVS/TSO Kermit Recalled
    New Kermit for Honeywell DPS-8 with GCOS
    New Kermit for TRS-80 Model 4
    New Kermit for TRS-80 Color Computer with Radio Shack DOS

  UNIX KERMIT -
    C-Kermit Suggestions, Comments
    Installing Kermit on CADMUS (system V)
    C-Kermit Comments Revisited
    More C-Kermit Line Locking Problems

----------------------------------------------------------------------

Date: Fri 22 Mar 85 13:45:54-EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Corrections, Reminders, Notes
To: Info-Kermit

The previous issue of the digest was V2 #14; it was correctly labeled in
the message "Subject:" field, but internally it said V2 #13.  Sorry.

I fell behind a little bit in mailing list additions, deletions, changes.
They should be up to date now.  There are currently 315 addresses in the
Info-Kermit list, and many of them are themselves distribution lists.  If
you get this message and didn't want it, or didn't get it but did want it,
then let me know.  Some of the people who asked to be removed were not on
in the first place, which means they must be getting Info-Kermit through a
local redistribution list.

In the previous issue I forgot to say that the new release of Brian
Nelson's PDP-11 Kermit is available, as usual, via anonymous FTP from host
CU20B.  The files are KER:K11*.* (there are about 88 of them!); the file
KER:K11FIL.DOC explains what they are.

For those who haven't seen the following information before, or for a long
time, here it is again, briefly:

A complete collection of Kermit programs, documentation, and other files
is available on CU20B, a DECSYSTEM-20, Internet host number 192.5.43.128,
using the Internet FTP (File Transfer Protocol) facility: login via FTP
(not TELNET) as user anonymous, any password will do, and GET or MULTIPLE
GET the file or files you want.  Several files are of special interest:

KER:00README.TXT tells what files are available and how they are named.
KER:VERSIONS.DOC lists existing versions and those in preparation.
KER:CURRENT.DOC  lists current versions chronologically.
KER:FLYER.DOC    gives ordering information for Kermit on magnetic tape.

Kermit files are also available via BITnet ("SMSG RSCS MSG CUVMA KERMSRV HELP")
and UUCP (from host okstate; see recent Info-Kermit messages).  New files
usually take a few days to find their way to these alternate sources.

------------------------------

Date: Fri 22 Mar 85 11:45:54-EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: New MVS/TSO Kermit Recalled
To: Info-Kermit

The TSO Kermit modified at the University of Toronto for Series/1 front
end support announced in the previous issue of the Info-Kermit digest has
been recalled.  It turns out that the modification allows it to work ONLY
with the Series/1, and does not allow it to work over ordinary asynchronous
connections.  So now, we have three MVS/TSO Kermits:

1. The original, from U of Chicago:   KER:TSOKERM.*, KER:TSODYNAL.*
2. (1), modified for Series/1:        KER:TSOS1.ASM
3. The Rice University PL/I version:  KER:TSORICE.HLP tells how to get it.

Sorry for the confusion.

------------------------------

Date: Thu 21 Mar 85 18:56:20-EST
From: Frank da Cruz <[e-mail]>
Subject: New Kermit for Honeywell DPS-8 with GCOS
To: [e-mail]

Contributed by John Huxtable of the University of Kansas in Lawrence, this
new Kermit (unrelated to the other Honeywell GCOS Kermit donated by Terry
Carlin of Honeywell) operates in remote mode only, is capable of acting as
a Kermit server, and provides options supporting the different communications
modes used on Honeywell mainframes, and all GCOS file formats.  The files,
including B language source, the executable program in packed-text form
along with a Fortran unpacker, documentation, and ROFF documentation source,
are available via anonymous FTP from CU20B as KER:HDPS8.*.

------------------------------

Date:     20 Mar 85 13:43:35-CST (Wed)
From:     Gregg Wonderly <[e-mail]>
To:       [e-mail]
Subject:  New Kermit for TRS-80 Model 4

Here, finally, is the Model 4(p) Kermit for TRSDOS 6.1.  I decided to go
ahead and let you have it before I got all of the stuff that I really want
to add, added.  I named all of the files M4* noting that this did not
confilict with any of the files we have in the distribution.

[Ed. - Thanks, Greg!  It looks like a very complete implementation,
including VT52 emulation with key mapping and session logging, a full
complement of SET commands, command and initialization files, and a script
facility based on the INPUT/OUTPUT/PAUSE/CLEAR model with some
extensions.  The files are in KER:M4*.*, available via anonymous FTP.]

------------------------------

Date: Thu 21 Mar 85 19:01:49-EST
From: Frank da Cruz <[e-mail]>
Subject: New Kermit for TRS-80 Color Computer with Radio Shack DOS
To: [e-mail]

Contributed by Wes Hubert of the University of Kansas, this new Kermit
implementation runs on the TRS-80 CoCo with the Radio Shack disk operating
system.  It requires a machine with at least 16K memory and one disk drive,
and the Radio Shack disk ROM 1.0 or 1.1.  The program is available via
anonymous FTP from CU20B as KER:CC*.*.

------------------------------

Date:     20 Mar 85 21:15:59-CST (Wed)
From:     Gregg Wonderly <[e-mail]>
To:       sy.fdc@cu20b
Subject:  C-Kermit Suggestions, Comments

    Just got a few more ideas of improvements to C-Kermit, and would also like
to hear of anything that others have sent your way since you last posted the
Bugs report.

1)  How about making SET LINE look in a file for valid devices.  We would like
    to let certain students go out through the network, and get onto other
    machines to use KERMIT.  Since you can really create a LCK.. file for
    more devices than we would like, it would seem natural to limit the valid
    outbound lines, based on a file similar to /etc/passwd, where you have
    login names, passwords, and other info.  This way, someone can not lock
    up the UUCPKER, UUCP, or CSNET lines.

[Ed. - Several objections: (1) Adds yet more hair, and associated startup
time to the program; (2) Doesn't really accomplish anything, since none of the
other programs that use tty devices would honor this convention; (3) Starts
moving Kermit into the category of software that can only be installed and
maintained by the system manager -- something I want to avoid.]

2)  After much frustration, I have decided that there probably really should
    be complete trapping of all interupts.  It seems that Mark Vasoll, and my-
    self have this habit of hitting delete (Our ^C) in the middle of a command
    line when we mistype.  If SIGINT is traped in the parser, and results in
    a parse error, than operation would be smoother.  I have said something
    to you before about this, but now I think it is manditory that it be done.

[Ed. - Yet more hair to be added to the program, but in this case, I'm
afraid I have to concur; it's really bad to leave the user with an
unusable terminal.  I hope that we can let this question ride for a while,
until after the next release.  I have to do a huge amount of work to get
the next release out -- merging in the VMS support, your own forthcoming
V7 support, and much else -- and would prefer to have the interrupt stuff
added on top of that by people who know more about these things than I do.]

3)  I have already changed all printf's, that did not require any format
    translations, i.e. no "%s", "%d", etc...  to calls to a function that I
    added in the chusr3.c module.   This function is quite simply:

outstr(s)
    char *s;
{
    while (*s)
        putc(stdout, *s++);
}

    This completely eliminates the problems associated with various systems
    different size buffers used in the printf() function.

BUGS:

    There seems to be some problems with recognition of error packets when get
    is used to retrieve a file from another server.  I found that when I asked
    for a file that did not exist, C-KERMIT kept retrying, while clearly there
    was a sequence of E%E%E%E%E% characters appearing on my screen.  Haven't
    looked at this one yet, but hope to by this weekend.

[Ed. - Strange.  I can't reproduce this one.  Please send more details.]

    Get also seems to be retrying an abnormal amount of times on certain files.
    This may be related to the double packet exchange that was recently
    discussed in the INFO-KERMIT digest.

------------------------------

Date: Thu, 21 Mar 85 14:51:12 est
From: decvax!ittvax!long@Berkeley (H. Morrow Long [Systems Center])
To: [e-mail]@sy
Subject: Installing Kermit on CADMUS (system V)

    We have been using the Unix Kermit Server Program with our
    other kermits and have found it to be very useful.  I sent you
    some implementation notes on the 4.1bsd versus 4.2bsd problem.
    Here is a new note on porting to the CADMUS.  We using 'make
    sys3' on the CADMUS the software will compile with a warning
    about truncating a pointer to an integer in the files ckwart.c
    and ckzunx.c.  When 'wart' (and 'wermit') are run they will die
    with 'segmentation violations' and core dump.

    The reason for this is the fact that the CADMUS C compiler uses
    16 bit integers and 32 bit pointers.  The routine malloc() was
    not declared as returning a character pointer (char *) and was
    therefore taken as returning a 16 bit integer (the default).
    The following change clears up the situation:

  char    *malloc();    /* Needed by CADMUS, and probably many 68000's */

                H. Morrow Long
                ITT-ATC Systems Center,
                1 Research Drive Shelton, CT  06484

------------------------------

Date: Thu, 21 Mar 85 14:55:16 pst
From: Ken Poulton <@csnet-relay.arpa,@hplabs.CSNET:[e-mail]>
To: [e-mail], [e-mail]
Subject: C-Kermit Comments Revisited

Well, I have a few responses:

> ! cmd
>     should use the shell defined by the env var SHELL, if defined
>     "!cmd"     should work for Unix consistency (not just "! cmd")
>
> [Ed. - The "!" command just does a system() of its argument.  Rather than
> write all the code to fork and pipe the desired shell, maybe users can
> just live with typing "! csh xxx" or "! ksh yyy" if they want these
> effects.  A space is needed after "!" because "!" is a command keyword,
> and whitespace must separate command fields.  Removing this limitation
> would probably make the command package a lot hairier.  Maybe to alleviate
> the confusion that this causes, the "!" should be renamed (back) to "shell".

Using the right shell is common courtesy for interactive programs on Unix.
The UW version of old C-Kermit does this, with one routine which works
on all systems, I think.

I understand about the parser, but "!cmd" is completely common on Unix.
This may be worth special-casing if the parser can be short-cicuited on just
this special case.  Seems like it might be an easy bypass.

> stat cmd
>     can't we get timing info to get effective baud rate?
>
> [Ed. - If you have given a "set speed" command (or -b option), then this
> would be reasonable.  Otherwise, the program would not necessarily have a
> reliable way of determining the baud rate.  I really tried to avoid all
> this kind of system-dependent hair (system clocks, baud rates, etc)
> because it tends to make the program grow out of proportion to its
> functionality.]

Fine, if it doesn't know, then it can't say, but *effective* transfer
speed (not line baud rate) is the main use of the stat command anyway - I
still have to use a stopwatch to figure out if it's running up to snuff,
so the stat command may as well not exist.

> command interface
>     Use the user's line kill char rather than hardwire to ^U.
>     Use the user's backspace char rather than hardwire to DEL/BS.
>     Respond to the user's interrupt char rather than hardwire to ^C.
>     Kermit not observing these is very annoying, since being able to
>     choose them is a nice (and often used) feature of Unix.  This also
>     confuses novices.
>
> [Ed. - But the last guy said you should use something OTHER than the
> user's line and char kill characters; can't please everyone.  Also,
> again the point about system independence.  C-Kermit 4.0 was a pretty
> clean program.  4.2 already has tons of hair added to the system-dependent
> portions, and every time we add a system-related feature like this, it's
> got to be added for n systems, and soon the program will be an enormous
> pile of verbiage, buried somewhere in the middle of which will be the Kermit
> protocol.]

A question of user-friendly versus "let's all use DEC-20 control chars".
The other guy had the right diagnosis, but the wrong cure: His problem
goes away if you *turn off* the line kill and backspace in the tty driver
(simple enough, while you're setting cbreak mode) and use the user's
control chars *since they are doing the same things*.

Ken Poulton

(I think we're making progress - this is shorter than my last letter.)

[Top-Level Ed. - I tend to agree with all this, but there are tradeoffs.
One is that the program has to be maintainable, and the more system
dependent features creep in, the less maintainable it becomes.  Another is
that the bigger it gets, the harder it is to shoehorn it into little systems
(in several senses -- memory segmentation a`la Pro/Venix, memory occupation,
disk space, time to load from disk, time to start up once loaded, etc etc.
Let's see how the next release turns out, if I ever get time to work on it.]

------------------------------

Date: Fri 22 Mar 85 10:34:23-EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: More C-Kermit Line Locking Problems
To: Info-Kermit

Two recently reported problems with C-Kermit "line locking" --

Problem 1:

User tries to use a given line; ttopen() opens it, then calls ttlock(), which
finds it locked, gives the appropriate message, and returns failure.  User
then exits from program.  However, the ckx module still has a valid ttyfd for
the line, so when doexit() is called, the line is closed.  This tends to hang
up the line on whoever was really using it.

Problem 2:

User does connect, which calls ttopen(), which reports the line is in use.
However, since a valid ttyfd is left around, the next time the user does
connect, it works even though someone else is using the line.

Easy cure:

If ttopen fails to get exclusive access, put the ttyfd back to -1.

Better cure:

Don't open the tty before calling ttlock.  The only reason it's opened
first is for the benefit of flock().  Just get rid of flock(); it doesn't
do anything anyway.  After calling ttlock, THEN open the tty, and then do
the ioctl(ttyfd,TIOCEXCL,...) for those systems that support it.

------------------------------

End of Info-Kermit Digest
*************************
-------
 2-Apr-85 18:49:00-EST,9759;000000000000
Mail-From: SY.FDC created at  2-Apr-85 18:48:23
Date: Tue 2 Apr 85 18:48:23-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #16
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Tue,  2 Apr 1985       Volume 2 : Number 16

Departments:

  ANNOUNCEMENTS -
    New Edition of the Kermit User Guide Available
    Commodore-64 Kermit Bootstrap Program in C
    PDP-11 Kermit Problems and a Fix

  UNIX KERMIT -
    Problem with C-Kermit 4.2 Connect Command
    C-Kermit 4.2 on 4.1 BSD

  MISCELLANY -
    VTAM Translate Tables for TSO-KERMIT?
    Prime Kermit Bug
    MS-KERMIT 2.26/MULTICS-KERMIT and LU.EXE (binary file)
    Kermit for DG Eclipse running Calma DOS?

----------------------------------------------------------------------

Date: Mon 1 Apr 85 17:58:50-EST
From: Frank da Cruz <[e-mail]>
Subject: New Edition of the Kermit User Guide Available

The sixth edition of the Kermit User Guide is now available.  The major
difference is that most of the chapters describing the specific
implementations have been brought up to date.  The introductory and main
sections have also been fleshed out a little.  The result, unfortunately,
is substantially bigger than the previous edition.  The new User Guide can
be obtained via anonymous FTP from CU20B as KER:KUSER.DOC.  The Scribe text
formatter source is in KER:KUSER.MSS (and in all the files it "@includes").

------------------------------

Date: Tue, 2 Apr 85  16:53 EST
From: [e-mail]
Subject: Commodore-64 Kermit Bootstrap Program in C

Here's "c64boot.c", a program to download files to the C64, modelled on
C64BOOT.CLU, for those who don't have CLU.  Although written on a Unix
system, the C code contains no kernel calls and should be fairly portable.
Written by: Alastair Mayer, U. of Guelph, 2-Apr-85

[Ed. - It's in KER:C64BOOT.C on CU20B, available via anonymous FTP.]

------------------------------

Date: Sun Mar 24 1985 13:52:17
From: Marco Papa <[e-mail]>
Subject: Problem with C-Kermit 4.2

I have encountered the following problem more than once now and on two
different versions of C-Kermit (the Berkeley and PC/IX).  While in
"connect" mode, using an Hayes-compatible modem, randomly the program
stops accepting input from the keyboard.  Sometimes I can at least escape
back locally and get the C-Kermit prompt, but sometimes there is no way to
get out of it.  On the other hand characters can continue to arrive from
the line and are correctly displayed on the screen.  Very distressing
under PC/IX, most of the time I cannot escape back to the C-Kermit prompt,
and the only thing that I can do is rebooting the system.  I have seen
this to happen at least once when garbage was coming in from the line. Has
anybody experienced a similar problem?

Marco Papa

------------------------------

Date: Wed, 27 Mar 85 02:58:08 pst
From: Ken Poulton <[e-mail]>
Subject: C-Kermit on 4.1 BSD

I put C-Kermit up on 4.1 BSD.  Doing it was really pretty easy: it turns
out that the Tower OS must be a 4.1 port.  Defining a general 4.1 version
was mainly a question of selecting from the Tower, BSD4, and UXIII code
already there; I only wrote two lines of C (but did lots of ifdef changes).

I'll be sending those changes along with my other changes, hopefully next
week.

[Ed. - Once these changes arrive, it will take a good amount of time to
fit them together with all the other changes -- I've got pile of notes and
contributions over an inch thick...]

------------------------------

Date:        24 Mar 85 17:35 +0100
From:        [e-mail]
Subject:     VTAM translate tables for TSO-KERMIT?

I have assembled TSO-KERMIT for MVS/XA and have now run into exactly
the problem described in the .BWR file: packets from TSO-KERMIT are
just not getting through to the terminal.

Our communications people know very little about the support of ASCII
terminals under TSO. They tolerate rather than support these as the
majority of our terminals are 3270s or compatibles, with no protocol
converters. If KERMIT is going to work, I will have to do most of the
work myself.

We are using pure IBM communications products under MVS/XA on a
3081-KX or a 3084-QX. We have very recent releases of ACF/VTAM and
ACF/NCP. I can find out the exact releases if this is needed to solve
the problem. The ASCII terminals connect either directly to the 3725
TP controllers using the NTO software or via X25 networks using the
NPSI software.

And now my question: which translate tables must be altered in order
that KERMIT will work ? I assume that we are using vanilla IBM-
supplied tables throughout. There are just so many places where
something could be going wrong that I would appreciate help in
pointing the probable places to be changed.

The TSO command TERMINAL has an operand CHAR which allows specific
translations to be specified. However setting values with this does
not seem to have the desired effect. The only hint is in the TSO
Command Language Reference which under the CHAR operand says "Do not
select characters which may be device control characters". I assume
this refers to CTRL-characters such as <CTRL-A>.

[Ed. - The IBM mainframe Kermit programs contain their own EBCDIC/ASCII
translate tables.  Data goes in and out of the program in EBCDIC, but ASCII
is used internally so that the checksum can be computed correctly.  When
the IBM system sends Kermit's EBCDIC packets out an ASCII line, it
translates from EBCDIC to ASCII (and conversely for incoming packets).
Thus, Kermit's translate table must agree with the system's.  If it
doesn't, then the Kermit translate table can be changed.  But note that
Kermit's table is invertible; if your system's table is not invertible,
you could have big trouble.  Kermit's table corresponds to the one given
in the IBM System/370 Reference Summary, GX20-1850-5.]

------------------------------

Date:     Fri, 29 Mar 85 12:08:07 PST
From:     [e-mail]
Subject:  PDP-11 Kermit

The version of Kermit-11 currently sent by KERMSRV is T2.24.  I have
installed this on our PDP-11/44 running RSX-11M-Plus version 2.1, and have
two bugs to report, one of which I fixed.

(1) In the subroutine assdev::, the starting label $1 is attached to the
statement after the save registers statement.  It should, of course, be
attached to the save statement, otherwise the subsequent unsave sticks
garbage into the registers and corrupts the stack pointer.  Unfortunately,
this did not fix the other problem, which is:

(2) Packet receiving is totally dysfunctional when Kermit-11 is operating
in local mode.  We have a hard-wired dialout modem connected to one of our
terminal lines (without the DSR and DTR lines hooked into our DZ11).
Version 2.11 of Kermit-11 sent and received files just dandy over this line,
but its terminal emulation was awful.  Version 2.24 fixed up the terminal
emulation and added several more Kermit commands, but in the process
broke the file transfer.  Debug mode of both Kermits confirms that packets
sent by Kermit-11 are received by the remote Kermit, but the reverse is
not true.

------------------------------

DATE: FRIDAY, 29 MAR 1985
FROM: BRIAN AT UOFT02
TO: SY.FDC AT CU20B
SUBJECT: kermit and rsx

Thanks for forwarding the note.  The thing regarding rsx ASSDEV:: routine
is odd, it must have been there since summer and no one caught it.
Regarding packet transfer, that's the first I've heard of it; too often
RSX systems seem to have quirks that are unique to the site -- it could be
a config problem.  After fixing the stack register save junk, I ran
Kermit-11 under RSX-11/M+ v2.1 on an 11/44 hardwired to a Rainbow at 9600
baud.  No problems were encounted using either the 11/44 or the Rainbow as
servers.

For those who need to know, in ASSDEV: move the 1$: to the save <r1,r2,r3>
line.  Only affects RSX (not P/OS) and only when the SET LINE command is
used.  File is K11M41.MAC

                                                brian nelson
                                                [e-mail]

[Ed. - The aforementioned fix is installed in K11M41.MAC on CU20B and
on BITNET KERMSRV.]

------------------------------

Date: Sun 24 Mar 85 23:14:41-PST
From: Bob Larson <BLARSON%ECLD@ECLA>
Subject: Prime kermit bug
To: [e-mail]

Prime Kermit is quoting the 8-bit character even when 8-bit quoting is not
being done.  Using defaults, this causes ampersands ('&') to be received
as lower case f's by some versions of kermit, e.g. the old Unix Kermit
that is the base of the current os9 kermit effort.

------------------------------

Date:  Sat, 23 Mar 85 14:32 EST
From:  "Eric J. Swenson" <[e-mail]>
Subject:  MS-KERMIT 2.26/MULTICS-KERMIT and LU.EXE (binary file)

I cannot seem to be able to transfer LU.EXE (on Multics) to my Z100
using MS-KERMIT 2.6.  MULTICS-KERMIT claims "wrong packet type" and
MS-KERMIT claims "unable to receive data".  I have indicated to
MULTICS-KERMIT that it should use binary mode, rather than text mode.

What am I doing wrong?

------------------------------

Date: 24 Mar 1985 2135-PST
From: FAE.WU at Ames-VMSB
Subject: Kermit for DG Eclipse running Calma DOS?
To: INFO-KERMIT at CU20B

Does anyone have a version of kermit for a Data General Eclipse running
Calma DOS?

Alex Woo

------------------------------

End of Info-Kermit Digest
*************************
-------
 3-Apr-85 15:32:32-EST,16357;000000000000
Mail-From: SY.FDC created at  3-Apr-85 15:31:44
Date: Wed 3 Apr 85 15:31:43-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #17, C-Kermit Bug List
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Wed,  3 Apr 1985       Volume 2 : Number 17

                           C-Kermit Bug List

----------------------------------------------------------------------

Here is the current bug list for C-Kermit Version 4.2, along with a list
of implementations.  This file is kept on line in the Kermit distribution
areas as KER:CKERMI.BWR, but is being sent to Info-Kermit for the benefit
of the many subscribers who don't have access to FTP or KERMSRV.  The next
release, which will incorporate fixes for most of the reported problems
and support for most of the additional systems, will still be several weeks
in coming; still plenty of time to send in more bug reports and suggestions.


-- SUPPORT FOR ADDITIONAL SYSTEMS: --

4.2BSD: "make bsd" works.

4.1BSD: C-Kermit built with "make bsd" does not work under 4.1.  The date/
  time stuff and line locking stuff are completely different from 4.2.
  Also, the directory format is different, so traverse() doesn't work.
  Specific support needs to be added for 4.1.  Apparently very similar to
  the TOWER1 support.  4.1 support being added by Charles Brooks
  (brooks@edn-vax), and also by Ken Poulton ([e-mail]).
  4.2 can be differentiated from 4.1 with "#ifdef MAXNAMLEN".

ATT 3Bx systems: works ok with "make sys3", but works better if TCSETA
  changed to TCSETAW to allow i/o to drain before changing terminal modes;
  probably applies to all sys3/sys5 systems (chris@columbia-20).

VAX/VMS: Added by stew%lhasa.uucp@harvard, not available yet (see below).

Regulus: Submitted by Joe Smiley, DuPont Co.  Extensive changes to 4.0
  were too hard to fit into 4.2; hope Joe can add the Regulus support to 4.2.

Motorola Four Phase 6300 - works fine with "make sys3" (KLaurent@DENVER)

Callan Unistar 300 (68000) with Unisoft System V -- works fine with
"make sys3" (EBM@MIT-XX).

Cadmus 68000: Compiles ok with "make sys3", but core dumps because malloc()
  not declared (in wart and in ckzunx) as returning a char pointer; see below.

NCR Tower, OS 1.02: Submitted by John Bray, based on 4.0, fitted into 4.2,
  but it doesn't work in 4.2; it will be fixed in next release.

NCR Tower, System V: Works ok -- "make sys3" (except some problems reported
  when connected to IBM mainframes; see below).

HP9000 Series 500: (from YEKTA@MIT-MC):  Use "make sys3", but
  1. Remove -i from CFLAGS & LI
  2. In ckxunx.c, don't #include<sys/file.h> or ioctl.h.
  3. In ckzunx.c, don't #include<sys/file.h>.

HP9836U Series 200, HP-UX 2.0.0, rev B (BLO2@CMU-CC-TC):
  "make sys3", but need to add the following in ckxunx.c functions ttpkt()
  and conbin();
    ttraw.c_cflag |= CS8;              /* 8-bit chars */
    ttraw.c_cflag &= ~(PARENB|CSTOPB|ISTRIP); /* no parity, 1 stop bit */
  (This probably should be done in all sys3/sys5 systems).

Plexus P-60
  Works ok with "make sys3", but doesn't always hangup even when hupcl
  is on (Scott Weikart, Stanford).

Masscomp/RTU 2.2:
  Works ok with "make sys3", except for line locking (Stan Barber,
  neuro1!sob@rice).

Pro/Venix 1.x:
  Performance improvements and ability to interrupt transfers in progress
  need to be (and will be) added.  Currently there is no "line locking"
  to prevent interference with/by uucp.  Anybody know how Venix does this?

Pro/Venix 2.0 (field test):
  Works ok with "make sys3", except the "unsigned long" has to be changed
  to "long" in ckdebu.h; may be a bug in the new compiler (Dan Schullman, DEC).

SUN, 4.2bsd:
  C-Kermit 4.0 with 4.2bsd support was reported to run OK on the SUN after
  some bugs with long strings, char vs int, etc were fixed.  There is now
  a report that version 4.2 doesn't even compile on the SUN because of the
  ^L's in the source file (can this be true???), and that once compiled
  (by removing ^L's) it doesn't transfer files at all, but just times out
  after many retries of the first packet (this report from daver@cit-vax);
  oconnor@cdn9 reports that changing the definition of the local variable
  "c" in function "ttinl" from integer to char fixes the problem.

Pyramid 90x, 4.2bsd:
  Apparently same problem (and same fix?) as reported for SUN, above.

-- BUG LIST --

General problems:

- Unnecessary timeouts occur at low baud rates when parity is being done;
  in ckfns.c, inchr() is being called by inlin() with a timeout interval
  so small that MAXTRY could be exceeded before the whole packet was read.

- Conditionalizations are not done clearly.  In some cases it might be
  better to have compile-time flags for features, rather than systems, or
  generic system names, rather than specific vendor/machine names, to
  avoid excessive nesting or OR'ing of compile-time variables (do all C
  compilers support ORing?).

- It might also be better to have a -D in the makefile for the system name,
  rather than hard-coding it into the ck[xz]*.c modules.

- Program's return code might be wrong in some cases (in 4.0, it was always
  zero; in 4.2 some attempt is made to return correct codes for failure and
  success).  Also see note about VMS return codes, below.

- "quiet" (-q) flag does not turn off all error messages.  Direct use of
  fprintf(stderr,...) should be replaced by invocations of ermsg().

- The error messages should use the current prompt (changed via 'set prompt')
  rather than "C-Kermit" as a prefix, to make it easier to see which Kermit
  a message is coming from, if you have a C-Kermit on both ends of the line.

- The default prompt should be set from the makefile with -DPROMPT.

- Program still core dumps from time to time because of (f)printf(string)
  statements; "help remote" and "help set" tend to exhibit this behavior.
  These printf's must be replaced by (f)printf("%s",string), or puts()
  statements, or something like "while (*s) putc(xxx, *s++);".

- Local mode file transfer display could be improved.  First, for systems
  like Macintosh that have fancy screen management, the screen() function
  should be provided additional information as to what the arguments are --
  filenames or whatever -- so it can display them more intelligently.
  Second, on tty-style displays, the "percent done" could be shown by
  doing something like "0...1...2...3...4...5...6...7...8...9...".

- Interrupt handling is not done particularly well, and if the program
  crashes or is halted while it has the terminal in a not-normal mode
  during command parsing or file transfer, the terminal mode is not restored.
  Code should be added to trap quit or panic interrupts and restore the
  terminal before quitting or panicking.

- The shell's interrupt, delete, and kill characters can interfere with
  those used by the Kermit command parser.  C-Kermit should use those already
  set up in the user's environment (how to get them?).

- status command needs timing info, maybe also effective baud rate.

- "!" command should not require a space after, should use the user's
  customary shell rather than sh, and if issued without an argument should
  start an interactive shell.

- Many people have asked for a system-wide startup file similar to
  the user's .kermrc file, perhaps with a conditional way to escape from
  it if the user has her own .kermrc file.  This notion might be extended
  to include the entire hierarchy system -- home -- current directory.

- It would also be desirable to have a way of specifying alternate startup
  files on the command line, so that aliases could be defined for running
  Kermit on certain lines, at certain speeds, etc.

- A deeper problem with the initialization files is that the file is only
  taken when the program enters interactive command dialog.  To be consistent,
  it should also be taken when the program is run via command line arguments.

- Moving the program to VAX/VMS uncovered a few remaining Unixisms:
  . VMS uses program return codes with opposite sense from Unix; return
    code values must be conditionalized.
  . ".kermrc" doesn't work as a file name on most non-Unix systems.
  . There should be a more portable way of handling baud rates tables.

ckzunx.c:

- ckzunx currently goes to a lot of trouble to traverse the directory in
  order to expand "*" and "?" in wildcards.  Maybe it should just fork the
  user's customary shell and have it do the expansion.  This would allow
  fancier filespecs to be given, like "~/ck*.[cwh]".  But it would slow down
  features like filename completion and menus in the interactive command
  parser.

- malloc() should be declared "char *malloc()" for systems that have pointers
  and integers of different lengths.

- In zsout() & friends, "fprintf(fp[n], s);" should be "fputs(s, fp[n]);"
  or 'fprintf(fp[n], "%s", s)', to prevent core dumps when s happens to
  contain a '%'.

- In zltor(), dc (dot count) is incremented for all dots in the filespec;
  not good if filespec is something like "../foo.bar".  Reset dc to zero
  whenever a "/" is encountered.

ckxunx.c:

- Many problems reported with "uucp line locking" --
  . On some systems, uucp apparently ignores the lock and breaks in anyway.
  . On some systems, the lock directory is write-protected.
  . On some systems, the lock directory is read-protected.
  . Using dial commands and a login script pointed at a line already in use by
    uucp will hang up the line on uucp.  Cure for this and some other similar
    problems: tty should not be opened before calling ttlock.

  Unfortunately, a lot of code will have to be added to take care of the
  many different ways that sites are set up to handle line contention and
  assignment, probably selectable by makefile compiler switches (see below).

- Under certain conditions, alarms used to timeout blocked reads are not
  cleaned up after a timeout occurs.

- There's no good way to select baud rates higher than 9600.  Most Unix systems
  don't supply symbols for them (unless you use EXTA, EXTB), and even when they
  do, the program has no way of knowing whether a specific port serial
  controller supports those rates.

- 4.2 bsd systems with dialout modems should do ioctl(ttyfd, TIOCCDTR, 0);
  sleep(1); to hang them up upon close.  Other systems that don't have a
  hangup function might need a trick like setting the speed to 0.

- Venix/11 version 1 does have a nondestructive way to inspect a tty input
  buffer after all, so the ttchk() and conchk() functions can be provided
  for Venix to speed up connect mode significantly.

ckdial.c:

- Some systems do not allow users to manipulate dialers directly.
- Not easy to add support for new dialers.
- Some systems never return from the 100-character rawmode read (it is assumed
  return is immediate, indicating how much was obtained from the input buffer).
- Timed read for connect/no carrier message from modem within a general timer
  on the whole operation does not work on some systems.
- Some systems need to have the modem explicitly hung up; close() isn't enough;
  e.g. ioctl(ttyfd,TIOCCDTR,0) on 4.2bsd.
- On some systems, the entire output from the dialer (e.g. "CONNECT") cannot be
  read in a single gulp, so the buffer should be appended to between successive
  reads, not overwritten.

ckus*.c:

- Some help messages still produce core dumps on some systems.  Diagnosis: the
  strings in these messages ('help remote', 'help set' are mentioned most
  frequently) are still too long for some systems.  Cure: shorten them some
  more, and maybe replace

    for (i=0; *s[i]; ++i) fputs(s[i], stdout);
  with
    while (*s[0]) fputs(*s++, stdout);

  in hmsga() to prevent possible references to random memory.  Also, replace
  all printf(msg) with printf("%s", msg);

- The "directory" command produces a full recursive directory listing.  It
  should only list the current directory.  On bsd systems at least, the listing
  can be interrupted with a single ^C, which returns you to C-Kermit> command
  level.  Diagnosis: ???  The program just does a system("ls -l").  Why doesn't
  this behave the same as "ls -l" typed at the shell?

- Parser for the 'get' command doesn't respond well to editing; can go into
  infinite loops under some conditions.

- The filename 'transaction.log' is too long for some systems, and gets
  truncated (no harm is done, but the user is not informed and may not be
  able to find the file).

- The variables ncmd, nprm, nrmt are doubly defined.

ckcmd.c:

- Some systems (such as Venix/11) swallow the erase and kill characters
  when the terminal is in cbreak mode.  If the erase and kill characters are
  are ^U and DEL, then these can't be used to edit C-Kermit interactive
  commands.  Ditto for ^R.  Diagnosis: sigh, let's hear for portability.
  Cure (if you can call it that):  Add new SET commands to allow the
  erase, kill, and redisplay characters to be redefined.

- There's no way to break a command line and continue on the next line.
  Cure: add code to allow "\" followed by CR (or LF, or FF) to accomplish
  this.  Nobody really wants to put a real CR (LF, FF) in the middle of a
  command anyway, right?  This will make take files and login scripts a
  lot more readable.

- No way to put comments in take files.  Cure: Add a ";" or "#" command?
  Trailing comments will be harder.

Protocol (ckprot.w, ckfns*.c):

- No way to interrupt a protocol transaction until after it starts
  successfully.  For instance, no way to interrupt the timeouts and
  retransmissions of the initial packet when the other side is not
  responding, except for killing the whole program.  Cure: check for
  keyboard "interrupts" during the send-init process.

- When receiving from a non-timed-out Kermit and missing the Send-Init
  packet, no NAK is ever sent, and a deadlock occurs.  Diagnosis: resend()
  is called to resend the previous packet; there was no previous packet,
  so it sends an empty line.  Cure: Initialize the packet buffer with a
  NAK for packet 0?

- When parity is in use and the other Kermit cannot do 8th bit prefixing,
  the user is not warned that binary files will not be transferred correctly.

- 'set file names literal' does not work at all.

ckconu.c:

- There have been reports that on some systems (e.g. NCR tower with Sys 5)
  C-Kermit stops listening for the escape character during connect.
  In one case, it was reported that this happened only with IBM mainframes
  with "set flow none".

- Doesn't do any particular kind of terminal emulation.  It wasn't meant to.
  Filters can be used for this.

- Performance is poor on systems that can't check the input buffer.

- As structured, connect mode can't include commands to toggle logging on
  and off or to change settings, because forks can't share variables.

cklogi.c:

- Script facility needs ~d for send-delays, ~x for XON, ~w for wait-for-
  input timeout; these will probably be added.

ckwart.c:

- Has typedef for CHAR as "unsigned short" or "unsigned char".  Cure:
  Have ckwart.c use the typedefs from ckdebu.h, like the regular Kermit
  modules do.

- Should declare malloc "char *malloc()" for systems that have pointers and
  integers of different lengths.

makefile:

- Replace "wart ckprot.w ckprot.c" with "./wart ckprot.w ckprot.c" because
  "." might not be in the current path.

- It was suggested that the compound entry for making ckprot.o should be
  broken into two entries, one for ckprot.o, one for ckprot.c, to prevent
  unecessary recompilations.

- Some of the problems caused by access restrictions on the uucp lockfile
  directory might be addressed by having the makefile check and then setting
  an appropriate compile switch, e.g.

    if [ -w /usr/spool/uucp ]
    then make bsd "... -regular flags"
    else make bsd "... -DNOLOCKING"
    fi

------------------------------

End of Info-Kermit Digest
*************************
-------
 4-Apr-85 18:35:51-EST,9641;000000000001
Mail-From: SY.FDC created at  4-Apr-85 18:34:37
Date: Thu 4 Apr 85 18:34:37-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #18
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Thu,  4 Apr 1985       Volume 2 : Number 18

Departments:

  ANNOUNCEMENTS -
    New Kermit for Honeywell CP6
    New Release of Kermit for Intel ISIS MDS System
    New Release of Apollo/Aegis Pascal Kermit
    Kermit for Sanyo 1100 MBC with CP/M-80 2.2

  MISCELLANY -
    UK Kermit Resposibilities
    Need KERMIT for DG/One
    Unix Questions
    MS-KERMIT 2.26/Multics-KERMIT
    KERMIT on M6800

----------------------------------------------------------------------

Date: Thu 4 Apr 85 17:05:13-EST
From: Frank da Cruz <[e-mail]>
Subject: New Kermit for Honeywell CP6

Contributed by Cheryl Ann Poostay of Bucknell University, this new Kermit
implementation is based upon the University of Toronto Pascal VMS Kermit,
and provides the basic remote Kermit services.  The files are in
KER:HCP6*.*, available, as usual, via anonymous FTP from host CU20B.

------------------------------

Date: Thu 4 Apr 85 17:02:50-EST
From: Frank da Cruz <[e-mail]>
Subject: New Release of Kermit for Intel ISIS MDS System

Submitted by Teresa Koo of Intel in Santa Clara, this releases fixes some
problems in the previous release (for instance, the previous release could
not send files to VMS), and adds some new documentation (the previous
release had none).  The files are in KER:MDS*.* on CU20B.

------------------------------

Date: Thu 4 Apr 85 17:06:59-EST
From: Frank da Cruz <[e-mail]>
Subject: New Release of Apollo/Aegis Pascal Kermit

From Steve Case of Control Data, this new release fixes some bugs and adds
a SET FILE_TYPE command to allow transfer of binary files.  The new
version (2.6) replaces the old one (2.3) as KER:APOLLO.* on CU20B.

------------------------------

Date: Thu 4 Apr 85 18:06:17-EST
From: Frank da Cruz <[e-mail]>
Subject: Kermit for Sanyo 1100 MBC with CP/M-80 2.2

Contributed by Randall Simmons of Southwest Texas State University, this
implementation is based on version 3.6 of CP/M-80 Kermit.  Since the main
Kermit distribution area is very tight on space, the files have been
placed in KE:CPMSYO.* (note, KE:, not KER:) on CU20B.  Perhaps someone who
has a Sanyo 1100 will move this support into the current version of
CP/M-80 "modular" Kermit (version 4.05).

------------------------------

Date:     Wed, 3 Apr 85 11:50:32 BST
From:     Chris-on-Fridays <[e-mail]>
Subject:  UK Kermit Resposibilities

Kermiteers:

     A meeting was held in the bar at Sheffield last Monday evening, at
which there were a number of Kermit-interested people present.  We
threshed out some policy about who looks after what.  The effect is:-

1.  Lancaster will look after Kermit sources and try to keep a list of
who-has-what.  They will get new tapes from Columbia about 4 times a year,
and pull in other stuff by ARPA-ftp.  They will keep all this (or as much
as possible) online and available by NIFTP or Kermit.  The "who-has-what"
is really a list of names of those who have running binaries on
transferrable media, and are willing to supply floppies etc.

2.  I will keep a mailing-list here (info-kermit@ucl-cs) of all known
interested parties in UK (and possibly Europe if we have connectivity).
Anybody who wants his/her name added to or deleted from this list, mail me
(cjk@ucl-cs).  Anybody who wants to distribute info to the UK Kermit
fraternity, mail it to info-kermit@ucl and our mailing system will expand
and forward.

3.  I will serve as a relay for info from Columbia which is not new
versions of Kermits. This principally means the information digests.  As
each one comes in I will move it into /44d/kermit/infodig and send a copy
of its contents-header to info-kermit@ucl-cs; you can then extract it
either by NIFTP or by Kermit.

     In line with this, I am removing the majority of the source texts
from the /44d/kermit directory.  They are in any case now about a year
old.  I will try to hold as much text information online as possible.

     If anyone has trouble importing the larger documents, let me know.  I
could split them up into chapters.

                                        Chris K.

------------------------------

Date:  Wed, 3 Apr 85 08:55 EST
From:  [e-mail]
Subject:  Need KERMIT for DG/One
To:  [e-mail]

We have need for a KERMIT for our new Data General/One portable.  These
are IBM clones with the exception of the communications UART.  In an
effort to keep power consumption to a minimum, DG opted for an 82C51
UART instead of the 8250 the IBM uses.  This precludes the DG/One from
using IBM communi- cations software.

If necessary, I can provide a driver routine (in 8086 assembler) from
the DG/One programmers manual which details the command structure for
the 82C51 as well as the DG/One power management scheme.

Thanx for your help!

Wolf Wiedemann RADC-MULTICS

[Ed. - Many have expressed interest, but no one has offered the driver
routine before.]

------------------------------

Date: Wed 3 Apr 85 16:18:25-EST
From: Frank da Cruz <[e-mail]>
Subject: Unix Questions

A couple possible solutions for C-Kermit problems:

1. Recursive directory listings produced by "directory" command, or by
server when given "remote directory" with no argument or "*" -- use "ls
-ld" rather than "ls -l".  I checked in 4.2bsd, ATT System V, and Venix
manuals, and all support "ls -ld".  Are there any Unix systems that don't?

2. It is considered desirable to use the user's shell for any system
commands, or executing "!" commands.  Can this be done in all versions of
Unix by making a string of the form "$SHELL -c " concatenated with the
desired command, and then feeding it to system()?  Not elegent, but then
neither is fork/pipe creation/deletion.

------------------------------

Date:  Wed, 3 Apr 85 18:53 EST
From:  "John C. Klensin" <[e-mail]>
Subject:  MS-KERMIT 2.26/Multics-KERMIT

Well, MS-KERMIT works, but you have probably gotten into the midst of
the Multics kermit mess.  Without reciting the history and boring
everyone else, there are four known versions of Multics kermit on the
MIT Multics machine, none completely satisfactory.  They are, in no
particular order:

   Oakland version I, as modified by MIT (the one you find if you don't
do anything special).  This version does not do binary transfers
correctly, and sometimes randomly decides that it is in eighth-bit
quoting mode, resulting in some arbitrary character being consistently
garbled.  This version understands something about Multics text files,
and translates names to lower case, and so forth.  The MIT
modifications, in addition to the text handling, include making the
thing work satisfactorily with the X.25 PDNs.

   A further modification of Oakland version I, with the 8th bit bug
fixed and some additional code to properly canonicalize text to Multics
standards.

   Oakland version II, which is believed to have a few of the same
problems for MIT use as version I, including difficulties with the X.25
PDNs and mode-setting problems for some other devices.  It also lacks
the extensive transaction-tracing facilities that were added to the
versions above in the process of getting them working.  This version is,
we believe, the version that exists as the official Multics kermit at
Honeywell.

   Calgary/Honeywell "official" kermit prerelease.  This version, which,
unlike the others, has a user interface consistent with other Multics
subsystems and quite similar to the ARPANET user ftp program on Multics,
is the precursor of what will eventually be released.  It does not have
the special text canonicalizing features of the first and second
versions listed above and is arguably not too bright about the handling
of names.  It does binary downloads correctly ONLY in seven-bit mode,
with eighth-bit quoting on; it will not do them when told to use an
eight-bit data path.  This bug is claimed to be fixed in the official
release, which will certainly get here someday.

At MIT, we are ignoring Oakland II, and have stopped work on the MIT
modifications to Oakland I (we have not even bothered to install the
second version mentioned above).  We are concentrating our efforts on
trying to find problems and suggest fixes to Calgary/Honeywell Multics
kermit, which seems to work if you are careful.

If you have further problems, or cannot figure out which version here is
which, the IS Microcomputer Center has official responsibility for
kermit on MIT-Multics and you may want to contact them.

------------------------------

Date: 23 March 1985, 20:32:28 MEZ
From: Bernhard Nebel            +49/30/314-5494      NEBEL    at DB0TUI11
      TU-Berlin
      Sekr. FR 5-8
      Franklinstr. 28/29
      D-1000 Berlin 10
Subject: KERMIT on M6800

Dear Daphne,
I've written a KERMIT for a M6800 running under MDOS (a operating
system written by myself), which is similar to MINIFLEX V1.0 (Technical
Systems Consultant). But anyway, it should be possible to rewrite
the operating system interface. Are you interested to receive the
KERMIT?

- Bernhard

[Ed. - Anyone interested?  Send him mail.]

------------------------------

End of Info-Kermit Digest
*************************
-------
 9-Apr-85 20:11:08-EST,13772;000000000000
Mail-From: SY.FDC created at  9-Apr-85 20:10:25
Date: Tue 9 Apr 85 20:10:25-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest, V2 #19
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Tue,  9 Apr 1985       Volume 2 : Number 19

Departments:

  ANNOUNCEMENTS -
    ANSI Tape Program for Prime Computers
    Commodore-64 Boostrap Program in SIMULA

  IBM MAINFRAME KERMIT -
    CMS Kermit and Linemode
    EBCDIC, ASCII, and All That
    ASCII in Kermit Docs
    Re: EBCDIC, ASCII, and All That

  MISCELLANY -
    Text vs Binary Files in Kermit
    Another CP-6 Kermit on the Way
    B6900 Version of Kermit Using NDL2?

----------------------------------------------------------------------

Date: 9 Apr 1985 1829-EST
From: LSM.DUNCAN at DEC-MARLBORO
Subject: ANSI Tape Program for Prime Computers

  Attached is a program written in Fortran-66 which will read variable
record length ANSI (Format D) tapes on a Prime computer.  Since Fortran-66
is provided with all Prime machines, all Prime customers should be able to
compile and run it.

  I have only briefly tested it, but it appears to work as advertised.
Much thanks should go to the Prime New York office.  Ron Couch, a senior
analyst there wrote it, and Dave Tichane provided me with a copy to send
to you.

  In order to help you out, I am willing to send a (paper) listing of it
to anyone who needs it.  Please send a request to LSM.DUNCAN at
DEC-MARLBORO, Prime X.MAIL DUNCAN -ON EN.C6, or U.S. mail to:

    Jeff Duncan
    Prime Computer Inc.
    492 Old Connecticut Path  MS 21-02
    Framingham, Ma. 01701

  I hope this new program will help out the many Prime people who have had
difficulty with your tapes.

  Jeff

[Ed. - Many, many thanks to Jeff, Ron, and Dave.  Prime computer sites
have had a terrible time reading the ANSI tapes we sent them up till now.
The program is in KER:PRIMET.FTN, available via anonymous FTP from CU20B.]

------------------------------

Date:        08 Apr 85 14:19 +0100
From:        [e-mail]
Subject:     Subject: Commdore-64 Boostrap program in SIMULA

Here is a version of the C64BOOT program written in SIMULA for DEC-10/20
computers. I have commented this version a little more than previous
versions of C64BOOT in other languages, to make it simpler for someone who
needs to re-write it into yet another language.

Note two important points: ALL echoing of characters from the CBM by the
HOST must be suppressed. Also the echoing of a line feed when the CBM
sends a carriage return.

The delimiter between lines sent to the CBM-64 should be only carriage
return, not carriage return-line feed.

[Ed. - Thanks, Jacob!  The program is in KER:C64BOOT.SIM, available
via anonymous FTP.]

------------------------------

Date: Fri, 5 Apr 85 10:11:03 est
From: KRAMER <[e-mail]>
Subject: CMS Kermit and Linemode

Has anyone tried to get the VM/CMS Kermit working using the LINEMODE
patches from Queens Univ with a YALE ASCII/Series 1 front end (or an
IBM4994)?  Better yet, does anyone have KERMIT working useing the
Transparent mode options with the YALE Ascii package?

[Ed. - The soon-to-be-released version 2.00 of VM/CMS Kermit will include
the ability to operate transparently through the Series/1 front end with
the Yale ASCII package.  The U of Chicago's MVS/TSO Kermit was modified at
the U of Toronto to do the same thing, but the Toronto version ONLY works
through the Series/1-Yale front end; it's in KER:TSOS1.*.]

------------------------------

Date: Thursday, April 4, 1985 at 9:36 PM EST
From:   Norman Ramsey <[e-mail]>
Subject: EBCDIC, ASCII, and all that

I am at my wits' end trying to cope with CMS, CMS-KERMIT, and the godawful
problem of ASCII/EBCDIC translation. I am working with two sites, CORNELLA
and MITVMA, that use DIFFERENT translation tables. I believe that BOTH
tables are noninvertable, and I am ready to flog the engineer who designed
EBCDIC.

All this notwithstanding, I would be happy (nay, ecstatic), if I could
somehow just send the RAW BITS from an ASCII machine (such as my IBM PC)
and an IBM mainframe. I would be happy with seven bits. I would be happy
with eight bits.  I'm beginning to think the best I can hope for is six
bits, and that only be encoding everything as alphanumeric, comma, period,
blank, and such characters as we hope will always be translated *RELIABLY*
independently of the vagaries of the various sites.

Such as, f'rinstance: my site (CORNELLA) translates an ASCII backslash
into an EBCDIC cent sign (hex 4A) and back again. Too bad no other site
seems to do that. But you don't want to hear this...

                                            Norman Ramsey
                                            [e-mail]

------------------------------

Date: 04/09/85 17:39:11 EDT
From: TS0013@OHSTVMA
Subject: ASCII in Kermit docs

I am curious about which version of ASCII is really the one on which
Kermit is based.  The KERMIT PROTOCOL MANUAL says that The 1968 version of
ASCII, X3.4, is used.  Appendix V of the same manual shows X3.4-1977.  The
major point I am aware of in the 1977 version is that the broken or
"split" vertical bar has been "fixed" back to a solid vertical bar.  The
name for it is now just "vertical bar".

Locally on our IBM systems, we have a homegrown standard for the
translation of ASCII to EBCDIC and EBCDIC to ASCII.  This local standard
is based on the fact that early development and standard- ization of PL/1
insisted on using the exclamation point, stylized like a vertical bar, for
logical OR.  A compromise was reached at some point making the code for
exclamation to be either a solid vertical bar or an exclamation.  I still
see documents around that describe this mess.  I think this was
implemented in 1968.  In 1977 ANSI decided to fix the mess and make the
broken vertical bar into a solid one, and the exclamation was to be only
that.  What resulted here was that the translations still change the CODE
for character number (octal)21 into a vertical bar in EBCDIC.

This has led to much confusion around here.  The management here was only
recently aware that there were even any such changes in ANSI.  I guess
they will learn that "standards never are".

What I am curious of is just what standard is Kermit based on.  Is it
using some specific standard, or perhaps trying to track a moving target
(ASCII) ?

------------------------------

Date: Fri 5 Apr 85 10:49:27-EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Re: EBCDIC, ASCII, and all that

My sympathies to all.  ASCII/EBCDIC translation will always plague us.
Those who are interested in the sordid history -- and there's a lot of it
-- are referred to the book "Coded Character Sets, History and
Development" by C.E. Mackenzie, Addison-Wesley (1980).  There are two
"standards" for translation between ASCII and EBCDIC:

[CACM] "Correspondences of 8-Bit and Hollerith Codes for Computer
  Environments -- A USASI Tutorial", a working paper of the ANSI X3
  Committee, published in CACM, vol.11, no.11, pp.783-789 (Nov. 1968)

[IBM] "System/370 Reference Summary", GX20-1850-5, IBM Corporation,
  6th ed. (1984) (earlier editions presumably have the same table)

The former more closely approximates a formal standard since it comes from
the appropriate ANSI committee, but the latter is used more commonly in
practice, since it is promulgated by the major manufacturer of equipment
for which ASCII/EBCDIC translation is necessary.  To complicate matters,
both ASCII and EBCDIC went through many fundamental changes over the
years; EBCDIC went through a long evolution from Hollerith and BCD to its
present state, and there have been at least four distinct ASCII alphabets:
those of 1963 (no lower case letters), 1965 (lower case letters added,
some new graphics added, others switched around), 1967 (ANSI X3.4-1968:
several graphics moved and/or redefined), and the current 1977 version
(X3.4-1977: vertical bar plugged).  Many translation tables are relics
from these early days of rapid change; they were correct (i.e. useful) in
the context in which they were created but now cause problems, most
commonly with the following characters:

            ASCII   CACM    IBM
  ASCII     value  EBCDIC  EBCDIC
 graphic   decimal   Hex    Hex   Comments

    !        33      4F      5A   4F in IBM is a solid vertical bar
    [        91      4A      AD   4A in IBM is a cent sign
    ]        93      5A      BD   5A in IBM is an exlamation mark
    ^        94      5F      5F   Listed in IBM as a "not sign"
    |       124      6A      4F   IBM has 3 vertical bars -- 4F, 6A, and FA

The Kermit translate table corresponds to the IBM table (with either 1968
or 1977 ASCII) and works at most sites.  Unfortunately, this is not to say
that sites at which it does not work are using the CACM table; many sites
have reported problems with the translation of characters where IBM and
CACM agree, including curly braces "{}", backslash "\", and tilde "~".  It
seems to be a relatively common practice for sites to "customize" their
translate tables, for reasons such as those mentioned above.

The IBM (and hence the Kermit) table is invertible, provided one sticks to
using only the EBCDIC 4F vertical bar, which is solid in EBCDIC and 1977
ASCII, and broken in 1968 ASCII (and on most current ASCII terminals and
printers).

The only way to get IBM systems (VM/CMS systems, anyway) to allow raw data
in and out a TTY line is to modify VM by adding the null translation table
along with an appropriate CP command to invoke it.  It does not
necessarily do any good to preprocess your data (e.g. hexify it), because
Kermit packets contain not only data, but also control fields which may
contain any printable ASCII character.

------------------------------

DATE: TUESDAY, 9 APRIL 1985
FROM: BRIAN AT UOFT02
SUBJECT: Text vs Binary Files in Kermit

A proposal to assist in Kermit binary file transfers.

A  common  problem  in Kermit file transfers is that of having to switch
between 'bin' (or 'fixed') modes and 'text' modes. While  some  Kermits,
such  as the MS/PC DOS and Kermit-11/RT11 versions don't care what about
this (RT makes no distinction), Kermit-11, Kermit-20 and  Kermit-32  do.
This  problem  becomes  acute when one sets up a BB for downloading text
and exe (tsk,sav,...) files to micros. We need a means to  automate  the
switching  from  text  mode  to image mode. Kermit-11 currently uses two
methods to do this, one, if the file is not sequential implied  CR  then
Kermit-11  sets  itself  to  'binary'  mode,  ie,  it uses RMS-11 direct
access macros to read the file. Also, it will check the filetype to  see
if  a match occurs, and if so, sets itself to binary mode for that file.
This is done since RSTS/E and RT can have  files  that  ARE  binary  but
have no ufd data to say so.

Additionally,  if  Kermit-11  finds that a file is 'binary' it will tell
the other Kermit (if it said it can  handle  attributes  via  the  CAPAS
field)  such.  Also,  if  Kermit-11  finds  itself  talking  to  another
Kermit-11 it will (for RSTS/E and RSX and P/OS) send a copy of the  file
header (the RMS-11 IFAB).

Now, for the problem.

We need a consistant means of setting 'binary' xfer mode.  Kermit-11 has
in it a hardwired list of filetypes that shoud be  sent  'binary'.  This
is  ok most  of  the  time,  exceptions do occur.  Like a .COM file is a
command procedure under VMS and RSTS V9 (which I am field  testing)  but
under CPM it is quite another thing.

The proposal is this:

The  Kermit  program  should  look  for  a  file that contains a list of
filetypes that the system manager considers to be  'binary'.  If  found,
switch  to image mode. Also, we should think about attribute packets, at
least in so far as 'I' format file.

                                                brian nelson
                                                [e-mail]

[Ed. - Brian's note points out a fundamental problem with Kermit, and in
fact with any file transfer mechanism, especially between unlike systems.
Brian's scheme would help a lot, but it would have to be combined with
all sorts of other heuristics, different on each system, to behave as
desired.  For instance, to tell the difference between a VMS .COM file
(a textual command file) and a CP/M .COM file (an 8-bit binary file), one
would have to examine the data itself.]

------------------------------

Subject: Another CP-6 Kermit on the Way
Date: 04 Apr 85 20:19:50 PST (Thu)
From: Mike Iglesias <iglesias@uci-icsa>

Lee Hallin at Honeywell LADC (in Los Angeles) has also got a KERMIT for
Honeywell CP-6 systems.  His has SERVER mode, some fancy debugging
features, etc.  It's not completely done yet.  He's planning on submitting
it to the KERMIT distribution when it's done.  We've been testing it for
him for about 3 weeks.  Just thought you'd like to know.

Mike Iglesias
University of California, Irvine

[Ed. - When it rains, it pours...]

------------------------------

Date: 5 Apr 1985 12:32-PST
Subject: B6900 Version of Kermit Using NDL2?
From: Geoffrey C. Mulligan <GEOFFM@SRI-CSL>

We have a B6900 running NDL2 and I am interested in getting Kermit
running.  Has anyone written a version of Kermit using NDL2?

------------------------------

End of Info-Kermit Digest
*************************
-------
17-Apr-85 10:40:34-EST,10107;000000000000
Mail-From: SY.FDC created at 17-Apr-85 10:40:05
Date: Wed 17 Apr 85 10:40:05-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V1 #20
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Wed, 17 Apr 1985       Volume 2 : Number 20

Departments:

  ANNOUNCEMENTS -
    New Macintosh Kermit on the Way
    Kermit for GUTS

  MISCELLANY -
    Changes to DEC-20 Kermit for TVT's, TAC's under Panda Monitor
    More Comments on Binary Files
    PCjr Peculiaries
    Kermit for GE Timesharing?
    CPM3 Generic Kermit on Osborne Executive?

----------------------------------------------------------------------

Date: Tue 16 Apr 85 12:17:35-EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: New Macintosh Kermit on the Way
To: Info-Kermit@CU20B, Info-Mac@SUMEX-AIM

Just to forestall any parallel development, this is to announce that
Columbia University is about to release a new Macintosh Kermit.  The
program is written in C using the SUMACC Unix-based cross development
tools, and is based on the new C-Kermit protocol modules.  It includes
VT102 terminal emulation with line and character insertion and deletion.
The terminal emulator and file transfer functions are done; the rest of
the user interface (dialog, display, and control windows) is being done
now.  We expect to announce an initial release within several weeks.

Columbia's Macintosh Kermit will be distributed on Columbia's Kermit
distribution tapes and via computer network, like other Kermit programs.
We recognize that Macintosh Kermit will be difficult to bootstrap,
especially at sites that do not have the SUMACC tools, so we would like to
place a few diskettes at sites where they will be most widely reproduced
and circulated, such as the member schools of the Apple University
Consortium.  Any other suggestions?  Unfortunately, Columbia simply does
not have the resources to get into the diskette production business, so
we are looking for sites that are willing to act as distribution centers.

------------------------------

Date: Wed 10 Apr 85 18:00:44-EST
From: Frank da Cruz <[e-mail]>
Subject: Kermit for GUTS

This is to announce an implementation of Kermit for IBM mainframes running
GUTS (the Gothenburg Universities' Terminal System), a TSO-like timesharing
system installed at about 80 sites in Europe, Africa, and the USA.  It was
adapted by Stefan Lundberg of the Gothenburg Universities' Computing
Centre, Gothenburg, Sweden (STEFAN_LUNDBERG_GD%QZCOM@MIT-MULTICS) from the
University of Chicago's MVS/TSO Kermit, which was in turn adapted from
Columbia's VM/CMS version.

The files are available via anonymous FTP from CU20B as KE:GUTS.*.  Note,
KE:, not KER:.  Unfortunately, we are no longer able to fit all the Kermit
implementations in one place, or on one tape.  At some point in the coming
months, the Kermit distribution will have to be split in two with one
area (and one tape) containing the more popular versions, the other the
more esoteric.

------------------------------

Date: 10 Apr 1985  22:17 MST (Wed)
From: "Frank J. Wancho" <[e-mail]>
Subject: Changes to DEC-20 Kermit for TVT's, TAC's under Panda Monitor

Frank,

The following are the changes I made to 20KERMIT.MAC.255 to add
support for a MONITR that doubles IACs and has new MTOPR% calls to
negotiate network binary mode.  Such support is in MRC's PANDA MONITR
which we are running now, and the MTOPR% codes are of MRC's making,
not yet DEC's.  I have made similar changes in MODEM available in the
usual place here (MICRO:<CPM.TOPS-20>).

--Frank

[Ed. - Thanks, Frank.  Rather than incorporating these changes into the
base version, I've left them in KER:20KERMIT.BWR on CU20B.  When and if
DEC ever makes up its mind how to handle this problem, Kermit-20 will be
changed to accommodate.]

------------------------------

DATE: 10-APR-1985
FROM: BRIAN AT UOFT02
TO: SY.FDC AT CU20B
SUBJECT: More Comments on Binary Files

I agree that filetype confusion will occur, thus the suggestion  that  a
system  and  user  INI file could define those types. The reason I would
like to see this is for a proposal here to archive  msdos  libraries  on
the  785  (amounting  to  several  tens of thousands of blocks) so users
could download things as they need them from the vax. The use of a  user
ini  file  with  filetype info for binary files would be able to set bin
mode for, say .COM files, only for that user.  While  it  clear  that  I
should  be able to set the attributes on the VAX side of the msdos files
and all should work right, that in itself could still be a mess.

The reason I implented  switching  to  binary  mode  via  filetype  (and
attributes)  in  the  first place was because the rt11 file system knows
nothing of attributes. Additionally, RSTS/E Basic+ 'compiled' files  are
stored  w/o  attributes,  though,  of course, RSTS/E supports the entire
FSC/RMS file structure when desired or needed. I did include a SET  FILE
NOAUTO command to disable checking for binary file transmission.

It  would  be  really  nice  if  Kermit-32  and  MSDOS  Kermits  support
attribute packets in at least the "I,"B and "A packets so the  recipient
could  decide  what action to take. I do this on Kermit-11 and it really
makes loading my PRO/350 from  my  23+  easy.  As  an  example,  William
Youngs  of  DEC/LDP  has  a  bulletin  board  on  a  730 where he places
scientific and eng software, his users that dial in  find  it  confusing
to be switching modes to get a .SAV image vs a .MAC or whatever.

One last note  (about VMS Kermit).   One problem that  comes up is  with
binary files that are fixed 512  with carriage control. These files  are
typically sav and task images loaded  onto the VAX via FLX or  EXCHANGE.
It would seem that the only (simple) way to be able to Kermit them is by
using CONVERT  on them  to remove  the 'carriage  control' attribute  to
none. I don't really care, but it may account for problems I have  heard
about from others running Kermit-32.

                                                brian nelson

[Ed. - Of course, what's needed -- and what we'll never get -- is a
"standard" for determining file attributes in a heterogeneous environment.
File types are one way, but Brian's own classic example -- VMS .COM files
(textual) vs CP/M .COM files (binary) -- points out the pitfalls of this
approach if used in isolation.  Another prominent example is TOPS-10/20
.EXE files (36-bit binary) vs MS/PC-DOS .EXE files (8-bit binary).
However, extending the file-type idea a bit might do the trick: a list
of file types and corresponding attributes such as Brian suggests could be
kept on a per-site basis, along with private lists for individual users,
but in addition a particular file could be stored along with a parallel
file having a special file type, say .KFA (Kermit File Attributes), which
would contain attribute information -- perhaps formatted according to the
Kermit Attribute Packet description in the Kermit Protocol Manual.  If
such a file were present, Kermit would use the specified attributes; if
absent, Kermit would use attributes from the user's or site's type list.
The obvious measures would also be necessary to allow a user to override
all of this on a per-file or per-file-type basis.  Specification and
coding of all this would be quite a job, but perhaps trivial compared with
explaining it to users...]

------------------------------

From: Paul Fishwick <[e-mail]>
Subject: PCjr Peculiaries
Date: Wed, 10 Apr 85 21:02 EST

I called you the other day asking a question or two about the
peculiarities of the PCjr with respect to my emulator.  After "carefully"
reading the Junior Doc. which someone sent me, it is quite clear why
Kermit works fine and mine did not: Page 2-126 tells all: "Without the
Internal Modem installed, the RS232 serial port is logically addressed as
COM1 in BIOS,DOS, and BASIC even though its address is still hex 2f8 using
interrupt level 3."

No wonder they canned the machine.  Personally, my design philosophy is to
use BIOS whenever possible then digress to lower depths if someone
specifies mark,space parity and for general interrupt handling - this is
what got me!

-paul

------------------------------

Date: Thursday, 11 Apr 85 09:37:53 PST
From: vax135!cornell!uw-beaver!tektronix!iddic!dhs@Berkeley
Subject: Kermit for GE Timesharing?

I'm looking for anyone who knows if a Kermit is running on GE
timesharing.  Apparently they use some sort of Honeywell processors with
a proprietary, non-standard operating system.  I would like to use
Kermit to upload messages for a Bulletin Board system I'm setting up.
My intuition is that somebody, somewhere has a Kermit running.  I made
the suggestion to GE, and they suggested that they are looking into what
it would take to make a Kermit available.

Thanks in advance,

Dave Straayer

------------------------------

Date:  Fri, 12 Apr 85 10:33 EST
From:  "Paul E. Woodie" <[e-mail]>
Subject:  CPM3 Generic Kermit on Osborne Executive?
To:  [e-mail]

I have gotten a copy of CPM3 generic kermit and am trying to use it on
my Osborne Executive through Telenet to a Multics machine.  I am having
trouble getting it to work at all -- it will send the first character I
type after I go into Connect mode and then die.  Is anyone using generic
cpm3 kermit sucessfully at 1200 baud on the Osborne Executive?  If there
is someone, or if you would like to share "war stories" with me, please
respond to me directly at MIT-Multics.  If the results of this episode
are successful an there is something useful resulting from this, I will
be happy to post it to Info-Kermit.

Thanks in advance,

Paul Woodie (Woodie.DODCSC at MIT-Multics)

------------------------------

End of Info-Kermit Digest
*************************
-------
25-Apr-85 16:38:05-EST,10330;000000000001
Mail-From: SY.FDC created at 25-Apr-85 16:36:48
Date: Thu 25 Apr 85 16:36:48-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #21
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Thu, 25 Apr 1985       Volume 2 : Number 21

Departments:

  ANNOUNCEMENTS -
    New Macintosh Kermit Prerelease Available for Testing
    VMS Kermit 3.1.066 Available
    Kermit-11 BITnet Server Available

  MISCELLANY -
    S-1 Mark IIA Kermit
    Commodore-64 KERMIT - a problem
    Kermit for Royal Alphatronic PC?
    Apple II Kermit Support for CCS7710 Serial Card?
    Looking for Kermit for GOULD

----------------------------------------------------------------------

Date: Thu 25 Apr 85 14:27:09-EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: New Macintosh Kermit Prerelease Available for Testing
To: Info-Kermit@CU20B, Info-Mac@SUMEX-AIM

This is to announce a pre-release version of Columbia Macintosh Kermit.  This
program is equivalent to the new C-Kermit in its capabilities, implementing the
full range of encoding, compression, and block check options, and includes a
fairly complete VT102 terminal emulator and a Macintosh-style user interface.

The program is based on C-Kermit, and shares the same C language source for the
protocol-related modules (but the version of these protocol modules is later
than the currently released version of Unix Kermit).  Macintosh Kermit is
presently built using the SUMACC Unix-based cross development environment; a
future release might also allow it to be built using a Macintosh-resident C
language development system.

This pre-release is intended primarily for evaluation at sites familiar with
Kermit.  We are soliciting helpful and constructive comments, suggestions, and
detailed, specific bug reports.  There are some features we haven't put in, but
MAY add in later releases; these are listed just so that everyone won't feel
compelled to suggest them:

. A manual (currently only short help and beware files are included)
. Key mapping, including redefinition/relocation of control and meta keys
. Somewhat more intelligence about Macintosh file attributes & structure
. XON/XOFF
. Server operation (Macintosh acts as server)
. Screen save/rollback (maybe)

The program is currently about as big as a program can get on a 128K Mac (the
SUMACC system does not provide dynamic segment loading).  Some of the missing
features, particularly screen save/rollback and key mapping, could put it over
the edge.

The files are available for anonymous FTP from CU20B as <MACKERMIT>*.*.  The
file CKAAAA.HLP tells what the files are.  The file CKMKER.HLP contains user
documentation (just a little) and installation instructions (most people will
want to simply download the binhex'd MacKermit resource), and CKMKER.BWR lists
the known bugs and limitations.

This prerelease is not really intended for wide distribution.  It is mainly to
get what we've done so far into the hands of those on the net who will be
able to make useful contributions (in the form of bug reports, criticisms, and
suggestions) which will be filtered into the first "real" release of MacKermit
for general consumption.  Please send all such reports to Info-Kermit@CU20B.

------------------------------

Date:     Monday, 22 Apr 85 21:17:41 EST
From:     nbush (Nicholas Bush) @ sitvxb.ccnet
Subject:  VMS Kermit 3.1.066 Available

I have finally put together a copy of VMS Kermit which should be suitable
for release.  This fixes all the bugs I know of (unless I forgot some minor
ones) as well as adding a couple of new features.  Here is a summary
of the changes (also found in VMSV31AN.RNO/MEM):

There have been  a  number  of  new  features  and  fixes  to  VAX/VMS
Kermit-32 3.1.065.

     1.  Send packet buffer size was increased to  allow  for  maximum
         size Kermit packets.  It was previously 4 bytes too short.

     2.  When sending FORTRAN carriage control  files,  if  the  first
         character  is not a valid carriage control character, it will
         be passed along instead of thrown out.

     3.  CONNECT no longer fails in strange ways on DECnet terminals.

     4.  Two (or more) RECEIVE commands in a row now work.

     5.  Kermit-32 now has a TAKE command (also "@").  Kermit-32  also
         performs  an automatic TAKE of VMSKERMIT.INI or whatever file
         is pointed to by the logical name VMSKERMIT.

     6.  LOCAL and REMOTE commands which spawn a subprocess  now  work
         correctly under VMS 4.x.

     7.  Terminal names longer than 7 characters now work  (VTAnnnnn).
         The  limit  for a physical terminal name is now 16 characters
         (I hope DEC doesn't up it anymore).

     8.  VMS 4.x added more bits  to  the  field  where  the  terminal
         parity was.  Ensure we only change the parity.

     9.  STATUS command had the headers  backwards.   Fix  headers  to
         correspond to data values being output.

    10.  SET IBM_MODE now  simply  sets  the  individual  items.   The
         values for IBM mode can be specified at link time by defining
         the global symbols:

         1.  IBM_MODE_CHARACTER  =  character   value   of   handshake
             character

         2.  IBM_MODE_ECHO = 1 for local echo, 2 for no local echo

         3.  IBM_MODE_PARITY = (0 = none), (1 = mark), (2 = even),  (3
             = odd), (4 = space).

         If not specified, Kermit will continue to use DC1, local echo
         and odd parity for IBM_MODE.

    11.  Kermit-32 now has a SET HANDSHAKE  nnn  command  to  set  the
         handshaking  character.   This  is  any  octal  value  or the
         keyword NONE to turn off handshaking.

------------------------------

Date: 24 APR 85 10:58-EST
From:  [e-mail]
Subject: Kermit-11 BITnet Server Available

There is a BITNET Kermit server running on node UOFT02 with username
of KERMSRV. This is intended to facilitate transfer of fixes or mods
to Kermit-11 over Bitnet. It is a very simple-minded server, all  it
can do is return file(s) and directory listings. The system is a VAX
11/785 running VMS 4.1 with jnet.  All file naming  conventions must
follow VMS rules, as in:

VMS requestor:  $ SEN/REM UOFT02 KERMSRV SEND K11CMD.MAC
CMS requestor:  CP SMSG RSCS MSG UOFT02 KERMSRV SEND K11CMD.MAC

Wildcarding is available. No directory names or logical names can be
present in the filename.  No binary files (.sav and .tsk) files  are
available via bitnet.

As always, the Kermit-11 edit history is in K11CMD.MAC.


                                                [e-mail]

------------------------------

Date: Wed, 17 Apr 85 19:36:02 pst
From: John Bruner <[e-mail]>
Subject: S-1 Mark IIA Kermit

Here at the S-1 Project at Lawrence Livermore National Laboratory
we are doing supercomputer research.  We have completed our
current generation machine, the S-1 Mark IIA and we recently
brought up multiuser UNIX on it.

The S-1 talks to the outside world through attached I/O processors.
At the present time there are no network connections and we haven't
finished debugging the magnetic tape.  We were forced to use a very
contorted path to transfer files to the S-1 from our VAXes.

Recently, however, we were successful in bringing up a very
simple KERMIT on a serial line.  Now we transfer source files in
and out via a 9600 baud link to our VAX.

The S-1 Mark IIA is probably the largest machine so far to run
KERMIT, and almost certainly is the largest machine which depends
upon KERMIT for access to the outside world.  (The S-1 Mark IIA
has an 80ns cycle time, a very complex instruction set, and
128 megabytes of main memory.)

The availability of KERMIT made life much nicer for us as we
finished our UNIX port.  While I anticipate that UUCP will supplant
KERMIT, I wanted you to know how much we appreciated having it.
(Besides, I thought you might find it amusing that such a large
machine benefitted greatly from it.)

------------------------------

Date: 21 Apr 85 14:48 +0100
From: [e-mail]
Subject: Commodore-64 KERMIT - a problem

I have been testing Commodore-64 KERMIT version 1.3 with mixed
success. Two problems ocurred:

(a) 1200 baud did not work for file transfer (but worked OK in
CONNECT mode).

(b) After having started Commodore-64 KERMIT, the SEND command
did not work. If however, I first made a GET command, then
SEND did work after that.

My test were made against a computer with CP/M-86 KERMIT.

[Ed. - Your message has been relayed to the author, who is working on a
 new release of the program.]

------------------------------

From: pur-ee!pur-phy!duncan!mike@Berkeley
Date: Thu Apr 18 15:44:19 1985
Subject: Kermit for Royal Alphatronic PC?

Does anyone know where I could get a copy of Kermit for the Royal PC?
I would really appreciate any info.
                    Mike

------------------------------

Date: 22 Apr 1985 10:08:22 EST (Monday)
From: John Shaver STEEP-TM-AC 879-7602 <jshaver@apg-3>
Subject: Apple II Kermit Support for CCS7710 Serial Card?

Is there a Kermit for the Apple CCS7710 serial card?  If not is there
an assembly source for another similar source which might be adapted?

------------------------------

Date: Mon 22 Apr 85 17:16:14-EST
From: Peter G. Trei <[e-mail]>
Subject: Re: Apple II Kermit Support for CCS7710 Serial Card?

The CCS7710 card should be supported in the next release, which is getting
near. We hope to add a number of cards in this one.
                                peter

------------------------------

Date: Mon, 22 Apr 85 14:40:50 EST
From: Pamela J. Saia <[e-mail]>
Subject: Looking for Kermit for GOULD

    I am looking for KERMIT which runs on a
    GOULD Concept 32/27 computer  operating
    system:mpx  rev 3.2A

    Prefer Fortran 77 but any information would
    be appreciated.

    Please respond to this address or call
    Gary Gustafson at [phone]  (Hanscom Airbase)


    Thank you

------------------------------

End of Info-Kermit Digest
*************************
-------
30-Apr-85 17:05:53-EDT,16209;000000000000
Mail-From: SY.FDC created at 30-Apr-85 17:04:48
Date: Tue 30 Apr 85 17:04:48-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #22
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Tue, 30 Apr 1985       Volume 2 : Number 22

Departments:

  ANNOUNCEMENTS -
    Second Pre-Release of Columbia Macintosh Kermit
    Kermit for the Burroughs B7900
    Minimum files for running VMS Kermit 3.1

  MACINTOSH KERMIT PRERELEASE #1 FEEDBACK -
    .HQX file for new Mac Kermit
    Clarification on version #'s
    Comments on MacKermit Prerelease
    MacKermit Bug Report
    Problem and question re Mackermit

  MISCELLANY -
    Rainbow 100+ Kermit-MS vs MS-DOS 2.11?
    Kermit for Grid Compass?

----------------------------------------------------------------------

Date: Tue 30 Apr 85 15:37:44-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Second Pre-Release of Columbia Macintosh Kermit
To: Info-Kermit@CU20B, Info-Mac@SUMEX-AIM

This is to announce the second pre-release of Columbia Macintosh Kermit,
version 0.6(4).  It fixes a few problems with the first pre-release that
were reported to Info-Kermit.  These are discussed in detail in the messages
below, but briefly they are:

. Version number incorrect -- 0.5(0) should have been 0.6(1)
. Bare CR's rather than CRLF's in .HQX file
. Saved settings files not correctly closed in all cases
. Transferred files not correctly closed in all cases
. Can't get back to Switcher using Apple menu
. Outgoing filenames not converted to uppercase
. Certain limitations and features not documented

The files are available via anonymous FTP from CU20B as <MACKERMIT>*.*,
and replace the earlier files in the same area.  These are the new or
changed files:

 CKAAAA.HLP    List of files
 CKMFIO.C      Macintosh file i/o
 CKMKER.BLD    (new) Instructions for building
 CKMKER.BWR    Beware file -- list of bugs, edit history
 CKMKER.HQX    Binhex'd MacKermit resource file
 CKMKER.MAK    Makefile
 CKMKER.RC     Resource Compiler input
 CKMKER.RSRC   MacKermit resource (8-bit binary)
 CKMSAV.C      Settings Saver
 CKMSUM.C      (new) SUMACC fiddling
 CKMUSR.C      User Interface
 CKMUTL.C      Utilities

The first "real" release of this program will coincide with the next
release of Unix C-Kermit, upon which it is based.  This will probably be a
few weeks hence, so in the meantime, keep sending comments and suggestions
to Info-Kermit@CU20B.

------------------------------

Date: Tue, 23 Apr 85 09:36:02 EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Kermit for the Burroughs B7900

This is to announce a new Kermit implementation written in Algol for the
Burroughs B7900 computer, contributed by Drs. B.J.M. Morselt, Technische
Hogeschool Eindhoven, Netherlands.  The files are in KER:B79*.*, available
via anonymous FTP from CU20B.

------------------------------

Date:     Friday, 26 Apr 85 17:34:04 EST
From:     nbush (Nicholas Bush) @ sitvxb.ccnet
Subject:  Minimum files for running VMS Kermit 3.1
Reply-to: SIT.BUSH @ CU20B
To:       Info-Kermit @ CU20B

It is not necessary to have all of the VMSxxx files in order to put up VMS
Kermit 3.1.

If there is no reason for the site to rebuild Kermit from sources, the only
files needed are:

    VMSMIT.HEX - "Hexified" copy of the .EXE file for Kermit-32
    VMSDEH.MAR - Source for dehexifying program
    VMSMIT.RNH - RUNOFF source for .HLP files.  Alternately,
             VMSUSR.HLP and VMSSYS.HLP can be retrieved.
    VMSV31AN.MEM - Description of changes between v3.0 and v3.1

If there is some need to rebuild Kermit from the Macro-32 sources, you will
need to include VMS*.MAR, VMS*.COM and VMS*.MSG.

If Kermit is to be rebuilt from the Bliss sources, retrieve VMS*.BLI, VMS*.MSG,
VMS*.REQ, VMS*.COM and VMSGEN.MAR.

Note:    If you do not have a Bliss compiler, there is no reason to
    get copies of the .BLI and .REQ files, since the .MAR files include
    the Bliss source listing.  Likewise, if you have a Bliss compiler
    there is no reason to get copies of the .MAR files (except VMSGEN.MAR),
    since they are just built from the Bliss sources.

Hopefully, this will cut down on the file transfer times for those who
need a new copy of Kermit-32.

- Nick

[Ed. - Note that several files were either missing or were left over from
the old version when the announcement of this new version first appeared in
the last digest; they are now correct.  The files are KER:VMSGLB.MAR,
KER:VMSMIT.MAR, and KER:VMSSYS.MAR.  Also, apologies for not mentioning in
the initial announcement that the files are available as KER:VMS*.* via
anonymous FTP from CU20B.]

------------------------------

Date: Mon 29 Apr 85 09:14:29-CDT
From: Bob <[e-mail]>
Subject: .HQX file for new Mac Kermit
To: sy.fdc@CU20B

This may be a problem on my side, but both times I transferred copies
of CKMKER.HQX to our DEC-20 here, the file came over with ONLY CR's at
the end of each text line.  A quick TECO job (showing my age) fixed it
but thought I'd mention it--just in case there's something wrong on
your side.

I've only used the new Kermit a couple of times so far and really like
what I see.  Thanks for all the good "stuff" you and your people do.

Bob Paver

[Ed. - Sorry, the .HQX file has been fixed to have CRLFs rather than just
bare CR's between the lines.]

------------------------------

Date: Mon, 29 Apr 85 01:21:44 pdt
From: Harry Saal <hjs@Lindy>
Subject: Clarification on version #'s
To: [e-mail]

I ftp'd the mackermit.hqx file from <mackermit> on cu20b and the .hlp
file that is there also. The .hlp file refers to a version V0.6(1), but
looking at the About Mackermit screen on the Apple Menu says that the
version available for beta-test is V 0.5(0). Thought you would like
to know about this so you can track down problems against the current
version.

[Ed. - The first pre-release contained all the advertised features and
bugs, but the version number was wrong.  The new release has an
appropriate version number.]

------------------------------

Date: Sat 27 Apr 85 09:19:33-PST
From: Doug Brutlag <[e-mail]>
Subject: Comments on MacKermit Prerelease
To: info-kermit@CU20B

    After using MacKermit to communicate with both a TOPS-20 system
at 1200 BAUD and MSKERMIT on an IBM PC at 9600 BAUD I have noted the
following problems which were not mentioned on CKMKER.BWR.  I should
mention that I got KERMIT.HQX from CU20B Thursday evening the day of the
announcement and I am running it on a 512 K Mac but configured with
Switcher to be in 128 K.

1)  KERMIT does not SEND/RECEIVE files from the DEFAULT disk.  Instead
it always looks at the disk from which it has been launched.  This is
inconvenient since you must always have a copy of MacKermit on the disk
which contains your data.

|    We tested SENDING from a second disk to DEC and VAX Kermit, it
|    works.  Select the file and volume you want in the SFGetFile
|    dialog.  Please Supply further information if this is still a
|    problem.
|
|    For GET you can specify the disk name when you specify the
|    file name -- "Startup:foo.c" -- this is a MAC standard done by
|    the file manager.

2)  SAVED SETTINGS files are not actually closed until after you QUIT
MacKermit properly so if you SAVE SETTINGS and then reboot and try to
RESTORE SETTINGS from that file you get an Error reading file -39.  If
you actually QUIT MacKermit and then relaunch it, you can then RESTORE
from a SETTINGS file.

|    This problem has been fixed in MacKermit V0.6(4), a FlushVol
|    was added after a close.

3)  There also seems to be a problem with properly closing transferred
files.  If one downloads a series of files to the MacKermit and then
uses switcher to move to the FINDER those files are not visible on the
desktop or in the opened Disk window.  If you RELAUNCH a new finder the
files appear.  The files are present in File Selection menus and hence
it is just their icon that appears missing from the finder.  Most other
applications I have used that create new files set something in those
files that cause the FINDER to generate their icon when you switch to it
in Switcher.

|    This has been fixed in MacKermit V0.6(2), we added a FlushVol
|    in the file close routine and now all works well.

4)  In the communications SETTINGS menu the PORT and AUTOWRAP settings
do not darken when selected.

|    Will document.  These are not supported.

5)  If one starts a file transfer and something is wrong at the other end
(like forgot to start kermit) it takes a long time for KERMIT to time
out.  It would be nice if in addition to the CANCEL FILE and CANCEL
GROUP buttons there was an ABORT button like Control-C in MSKERMIT.
Either this or to document the Command-. on the file transfer progress
window would be helpful.

|    Will display Command-. message.

6) If one types in a filename in lower case in the file transfer window
when sending to a TOPS-20 system, the file name on TOPS-20 comes out in
lower case!!  This makes it very difficult to reference the file to
delete or to type it.  One has to type control-V before every character
of the name in order to reference filenames in lowercase on TOPS-20.  Is
there any way one could prevent MacKermit from sending TOPS-20 a lower
case filename but still allow this for UNIX systems?

|    There is code to uppercase outgoing filenames.  When the "AS"
|    filename is specified in the SEND dialog MacKermit does not do
|    file name conversion.  We changed the dialog to no longer
|    stuff the "AS" filename.  Also we found a bug in the file name
|    conversion routine which failed to deposit a NULL at the end
|    of the converted name.  These two changes made to MacKermit
|    V0.6(1) should solve your problems.
|
|    We had not noticed this problem because TOPS-20 is doing
|    conversion for us, it can for you too by using the most recent
|    version of 20 kermit, 4.2(255).

7)  The Close box in the MacKermit window does nothing.  It might make a
nice way to Quit the program.

|    Matter of taste.

8)  Sending DATA files to and from other kermits worked fine but
whenever I tried to send a Resource fork (I tried sending BINHEX 4.0) it
always hung (and always on the same packet, 9 for BINHEX 4.0).

|    We tried sending Binhex 4.0 and other resource files from
|    MacKermit to a VAX/Unix and DEC-20 Kermit and could not reproduce
|    this problem.  What version Kermits are you using, what are
|    the parity settings?  Does anyone else have this problem?

9)  Terminal emulation:  The display supports all VT100 commands I tried
and works well with display programs on TOPS-20, but key board support
is lacking.  The Numeric keypad does not send standard VT100
characters, nor is the command=numeric keypad setting implemented.  Also
MacKermit does not respond to the ALTERNATE KEYPAD APPLICATION command
from the host.  The Command key works nicely for the rest of the
keyboard even with shifted characters and unshifted ones.  It would be
nice if the OPTION key worked like a META key, either setting the eighth
bit OR sending an escape character before each character typed.  The
latter implementation has the advantage that it works over 7 bit
networks.

|    All known.  Some of this may be addressed in future versions.

In general MacKermit works very well and I think you have another
winner on your hands.

Doug Brutlag

------------------------------

Date: 28 Apr 1985 1534-PDT (Sunday)
From: Elgin Lee <ehl@Navajo>
To: Info-Kermit@cu20b
Subject: MacKermit Bug Report

I just picked up MacKermit -- it looks very good!  I think I've found a couple
of bugs, though:

    1.    Double-clicking on a settings file doesn't work -- I
        get system error 02 on startup.

|    We haven't seen this problem and can't reproduce it.  It
|    sounds like your finder is running the settings file instead
|    of the CKMKER file.  This would occur for example if you
|    modified your settings file to be type APPL instead of type
|    TEXT; or you forced the finder to run the settings file by
|    using the magic command-option-shift-capslock-double-click.


    2.    With Switcher 2.0, using the Apple menu to get back to the
        Switcher doesn't work.  Command-\ does work, however.  I
        have no problem getting the Apple menu route to work
        in other applications.

|    This problem has been fixed in MacKermit V0.6(3).

    3.    Trying to switch between active MacKermit and
        MacTerminal programs doesn't work.  I either get
        system code 02, continuous rampaging through memory,
        or a never-ending sequence of alert boxes telling
        about error at the Serial Port -- error -28.  I'm
        not sure if this is a Switcher bug or MacKermit bug,
        but I thought I'd mention it anyway.  I've
        had no trouble switching between two active MacTerminal
        programs.

|    Not totally true.  If one of the two programs closes the port
|    on the other these things can happen, but otherwise we've used
|    that combination fine.  Definitely a proceed-at-your-own-risk
|    situation.  Maybe we'll install some recovery for the error
|    that occurs when the serial port is closed from beneath
|    MacKermit.

Well, that's about it.  Other than that, MacKermit looks very good.

            Elgin Lee
            [e-mail]

------------------------------

Date: Mon, 29 Apr 85 01:25:57 pdt
From: Harry Saal <hjs@Lindy>
Subject: problem and question re Mackermit
To: [e-mail]

1. I tried using MacKermit 0.5(0) (??) when I had the analog watch desk
accessory running in the corner (it is on info-mac..). I did not get
any characters from the keyboard handled by mackermit. When I closed
down the accessory, all was ok. SOmeone is guilty...

|    MacKermit only accepts input if the terminal emulator is the
|    front window.  We decided at one point that this would be
|    a good thing because otherwise typein to desk accessories is
|    accepted by Kermit.  A better solution would be to check for
|    active rather than front window.  This will be inserted in
|    our to do list.

2. Question about 9600 baud operation. Can I use it for server/host
file xfers, if I do not have a response window open, and am just
going from file to file and not the screen? The comments about 9600
baud being a problem in the HLP and BWR documents put me off....

|    9600 baud is fine, just loses some chars if a number of
|    screens are sent continuously.  No problems during protocol.

3. By the way: THANKS A LOT for this. I was struggling with the old
simple buggy MacK and this seems to do what I was looking for. Now I
am about to see about using the IBM PC-Kermit for a server implementation,
driven by MacKermit as Users. It looks like MacKermit running against
UNIX C-kermit was fine when I tried it. Next to beat on the PC.,..
wish me luck!!!!!!!!!!!!!

------------------------------

Date: Mon 29 Apr 85 08:09:06-EDT
From: Harry Berger <[e-mail]>
Subject: Rainbow 100+ Kermit-MS vs MS-DOS 2.11?
To: info-kermit@CU20B

I tried using version 2.27 of kermit on a Rainbow 100+ under MS-DOS 2.11
without any success.  Once I entered the CONNECT command nothing further
will happen.  Has anyone else come across the same problem? If so what
needs to be done to get around the problem.

[Ed. - I have had confirmation that 2.27 MS-DOS Kermit works OK on the
Rainbow under MS-DOS 2.11 on a hardwired connection.  The only problems I
can imagine would involve the pesky business of DTR dropping, detection,
etc, which seems to change with every DOS version.  Anybody out there with
DOS 2.11 and Kermit 2.27 that can shed some light on this?]

------------------------------

Date: Sun, 28 Apr 85 00:07:55 est
From: Alan Parker <parker@nrl-css>
To: [e-mail]
Subject: Kermit for Grid Compass?

Are you aware of a kermit for Grid Compass 1101?

-Alan

[Ed. - Not me.  Anyone out there working on one?]

------------------------------

End of Info-Kermit Digest
*************************
-------
 3-May-85 19:10:57-EDT,18128;000000000000
Mail-From: SY.FDC created at  3-May-85 19:10:30
Date: Fri 3 May 85 19:10:30-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #23
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri,  3 May 1985       Volume 2 : Number 23

Departments:

  ANNOUNCEMENTS -
    New Minor Release of DEC-20 Kermit

  MACINTOSH KERMIT -
    Mac Kermit bomb
    New Mackermit problem
    MacKermit V0.6(4) Comments
    MacKermit and Disk Default

  C-KERMIT -
    C-Kermit for Amdahl UTS?
    C-Kermit under Xenix? (Several Messages)
    C-Kermit with Compressed Files
    Bug in C-Kermit

  MS-DOS KERMIT -
    Kermit 2.27/Rainbow MS-DOS 2.11
    Data General D200 Terminal Emulation for IBM-PC Kermit?
    KERMIT for TI-PRO with TI Internal Modem?

  MISCELLANY -
    To Ship Files up to a Cray

----------------------------------------------------------------------

Date: Thu 2 May 85 14:31:52-EDT
From: Frank da Cruz <[e-mail]>
Subject: New minor release of DEC-20 Kermit
To: [e-mail]

This is to announce a minor new release of DEC-20 Kermit, version 4.2(256),
which fixes several small problems:

. Kermit-20 would ACK an EOF packet even if it couldn't close the incoming
  file.
. Remote directory commands with no arguments to Kermit-20 server sometimes
  crashed Kermit-20.
. I/O errors (e.g. quota exceeded) while writing debug log file would crash
  Kermit-20 .
. Incoming filenames that started with dot could not be reasonable renamed
  by Kermit-20.
. The "push" command message was misleading if "push" command issued from
  prompt level.
. The "server" command message was misleading if Kermit-20 in local mode.

The source file is in KER:20KERMIT.MAC, the binary in KB:20KERMIT.EXE, and a
list of known bugs and restrictions for this version in KER:20KERMIT.BWR, all
available from CU20B via anonymous FTP.  Other files (documentation, etc) have
not changed.

------------------------------

Date: Wed 1 May 85 01:16:37-PDT
From: Richard Furuta <[e-mail]>
Subject: Mac Kermit bomb

I have a Mac Kermit configuration file in which all I've done is set
the speed to 1200 baud.  I can start Kermit without trouble by double
clicking on that file.  If, however, I duplicate the file with the
Macintosh clover-D command and then try double clicking the copy to
start Kermit, I get a system error, ID=03.  This is repeatable.

[Ed. - The problem was that SUMACC had an erroneous definition.  A
workaround has been installed in the current release, 0.6(5), and the
problem reported to the SUMACC folks.]

I am also having difficulty convincing a VM/CMS Kermit to talk to this
one but that is probably my own fault for not being comfortable on the
IBM machine.  I can't get anything at all to happen.  We speak to the
IBM 4381 thorugh an "IBM 7171 ASCII Device Control Unit."  What should
the proper settings be on both ends?  What settings correspond to the
"IBM" setting mentioned in the Kermit User's Manual?

[Ed. - We use Mac Kermit to talk to our VM/CMS Kermit all the time.
HOWEVER...  we're not going through a 7171 (equivalent to a Series/1 with
the Yale IUP).  The reason you can't transfer files through it is that the
7171 is merrily converting your packets into the ASCII equivalent of 3270
screen commands.  The solution: wait until version 2.00 of VM/CMS Kermit
comes out (next week, I hope), which will include code to communicate
through front ends like this.]

------------------------------

Date:     Wed, 1 May 85 08:47 CDT
From:     Stewart_French <[e-mail]>
Subject:  New Mackermit problem

I am attempting to use the New Mackermit and am having an interesting problem.

I have the following setup that I use to communicate with our VAX/VMS system.
I have Kermit version 3.0.052 for VAX/VMS.

[Ed. - Diagram omitted.]

The Novation talks to the Mac at 8-bit no parity, then converts it to
7-bit odd parity to talk with the LAN  (Novation command "%F 2" converts
to 7-bit odd parity) over the phone lines.
The novation intercepts '%' characters, the LAN intercepts '~' characters.
Both can be changed.

I want to transfer simple ascii text files (at least for now).  The old
MacKermit worked just fine when I made the attention characters CONTROL-G
for the novation.  I did not have to change the LAN attemtion character '~'.
The new MacKermit will not talk at all through this set up.
It immediately attempts retransmissions until it fails.

Can you help me??

-Stewart French
 french%ti-eg@csnet-relay

[Ed. - The problem is that the new Mac Kermit does data compression using
tilde ('~') as the lead-in character for a compressed sequence.  If the
old Kermit worked at all, it was only because your data never happened to
contain a '~' character.]

------------------------------

Date: Thu, 2 May 85  9:31:32 EDT
From: Dave Swindell <dswindel@bbn-labs-b>
Subject: MacKermit V0.6(4) Comments

I just finished installing MacKermit V0.6 on a thin Mac and thought I
would pass on a few comments.  All of the major commands I tried, such
as SEND FILE, RECEIVE FILE, GET FILE, and the REMOTE commands worked
as advertised.  I was a little supprised to see that I had to open a
special window on the MAC in order to see the output from the remote
servers (I tried MacKermit with a Tops-10 Kermit as well as CKermit).
Might it be better to offer distinct 'CONNECT' and 'CLOSE Connection'
menu items on the Mac?  This would make the program more similar to
its counterparts on other microprocessors.

[Ed. - You're right about the remote command window -- it should pop up
automatically for remote commands that cause text to be sent back.
Mac Kermit is connected by default mainly because there's no reason not
to be, and this seems more in keeping with the Macintosh style.]

The VT102 (?) terminal emulation worked well, for the most part.
MacKermit correctly processed the ANSI codes for screen erase, cursor
positioning, video attributes, and scroll region select.  I was not
able to generate any of the special line drawing characters which are
present on a VT1xx terminal equiped with AVO (advanced video option).
Will these characters be supported in the final release??

[Ed. - Mac Kermit uses an ordinary system fixed-width font for terminal
emulation; no VT100 drawing characters, nor double-width/height equivalents
are available in that font, and won't be added to Kermit in the forseeable
future because of space restrictions.]

As a final comment, I noticed that when I used the RECEIVE FILE
command, I could not specify a new file name for the received data, as
is possible with Kermit-65 and MS-Kermit.  You are given this option
when you GET files from a remote server.  I think that the ability to
specify a new name for received files is important and hope that the
this feature will be added to the 'real' release of MacKermit.

[Ed. - Agreed; this will be in a future release.]

All in all, I was very pleased with the New MacKermit.  I was able to
transfer resource and data files with no problems.  Thanks for all of
the hard work!

Dave Swindell
BBN Labs

------------------------------

Date: Fri 3 May 85 10:34:14-PDT
From: Doug Brutlag <[e-mail]>
Subject: MACKERMIT AND DISK DEFAULT

    I am still having difficulties with MacKermit 0.64 not receiving
files onto the default disk.  When you use GET.. from a server at the
other end, MacKermit always saves all the files on the disk from which
Kermit was launched.  If you change the DEFAULT disk from internal to
external using DISKINFO disk utility MacKermit still stores files on the
internal disk.  Most other Mac software respects the setting of Default
disk and does all of its file i/o to the default disk.

    I tried your suggestion of GETing files and specifying the disk
name in the AS box like this:  GET *.INIT AS EXT-DISK:*.INIT.  MacKermit
stored the first file on the EXT-DISK but with the filename *.INIT (!).
Then it stored all subsequent files with there normal file names on the
internal disk.  Maybe I should have just specified EXT-DISK: with no
filename but it sure would be nice if MacKermit would save to the
default disk like WORD, FILE, MacWrite, MacDraw etc...

Doug Brutlag

PS.  I noticed that the Command-. abort was still not documented in the
file-transfer progress box, nor did the number of Kilobytes register
when GETing files from a server.

[Ed. - We're working on new send/receive dialog boxes, but they won't be
ready for a while.]

------------------------------

Date:  2 May 1985, 18:38 EDT
FROM:  ACDMAYER%UOGUELPH.BITNET@WISCVM
Subject: C-Kermit for Amdahl UTS?

    What is the state of the UTS version of C-Kermit (4.2)?  If it is
    going to be a while before it's released, maybe I will do the conversion
    myself.  (At least as best as UTS will allow).

  (ALASTAIR MAYER  <[e-mail]>)

[Ed. - We have UTS version 2.4 at Columbia, but we're about to retire it
in favor of their new system V version.  I gather that everyone else will
be doing the same, since Amdahl is "desupporting" the old one after six
months, and it doesn't cost much (at least to universities) to upgrade.
Since they seem to be shipping the new one now, it would be a waste to
adapt C-Kermit to the old one.  If you want to adapt C-Kermit to the old
UTS, be my guest.  But wait until the new C-Kermit comes out (version 4C,
probably next week).]

------------------------------

Date: Wed, 1 May 85 08:09:37 pdt
From: Bob Rendler <ren@lbl-ux4>
Subject: C-Kermit under Xenix?

Does anyone have Ckermit running on an IBM PC/AT under Xenix?  Following
the instructions in the makefile we did a "make xenix" to make kermit on
the PC.  We are having problems with 'connect'.  When the carriage-return
is typed to get the prompt to log into the remote we get "Communications
Line Failure".  We are using the same line for MSkermit and do not
experience this problem.  Thank you.

Bob Rendler

[Ed. - See below.]

------------------------------

Date: Monday, 29 April 1985  14:47-MDT
From: Jim Scardelis <ihnp4!timeinc!wcom!frodo@Ucb-Vax>
Subject: C-Kermit under Xenix?

Has anyone gotten C-kermit successfully running under Xenix 3.0?
I have given up trying to get it to run on an IBM PC/AT Xenix system...

                    Jim Scardelis

------------------------------

Date: Fri 3 May 85 09:32:57-PDT
From: Herm Fischer <[e-mail]>
Subject: C Kermit and Xenix for the IBM PC/AT

C Kermit does indeed run on the IBM PC/AT Xenix.  You should have no
problem if you use "make xenix" to make it.  The IBM PC/AT has
been one of the prime development machines for the recent versions
of C Kermit, and thus your query surprises me.

If you totally fail to be able to get C Kermit up, the only suggestion I
could make is to obtain a binary copy directly from another PC/AT which is
using it.  It has been tested on "stock AT's", "xtal-speedup AT's",
modems, modems using the old serial cards, and LANs with flow control.

  Herm Fischer

[Ed. - Versions prior to 4.2 lacked the data-carrier-detect/CLOCAL code
that overcomes the most commonly reported problems.  The next release,
version 4C, will have additional improvements in this area.]

------------------------------

From: trwrb!trwspp!spp3!kurisaki@Berkeley (Lance R. Kurisaki)
Date: Fri, 3 May 85 08:00:46 pdt
Subject: C-Kermit with Compressed Files

In volume 2 number 4 of Info-Kermit, James Woods tells us how we can use
the kermit to transfer compressed files, and increasing the effective
transfer rate.

I have been trying to use kermit in the way described and have been having
some problems.  When I receive a file "passively" with the "-k" option,
kermit seems to be adding a leading CR, so that when this is piped to
compress, it comes back with "not in compressed format".  This happens
even on text files.

Has this behavior been noticed by others, or am I doing something wrong
here?

By the way, I'm using 4.2 C-Kermit to transfer files between two Pyramid
90x's under the 4.2bsd universe.

                Lance Kurisaki
                {ucbvax|decvax}!trwrb!trwspp!kurisaki

------------------------------

Date: Thu, 2 May 85 21:16:29 edt
From: xp!tony@nyu-cmcl2 (Tony Movshon)
Subject: Bug in C-Kermit

This one may be known, but it should be fixed. A user under the
misapprehension that it is necessary to "set line" to his home tty (i.e.
if you are already on /dev/tty05, "set line /dev/tty05") will be
permitted to do this. He may also "set baud" to something other than the
current line rate. At that point, "connect" connects you to your own
terminal, at a different baud rate. !>poof<!

Fix: C-Kermit should trap the case when the argument to a "set line" command
is the same as /dev/tty (this can be done by checking the device numbers).

Tony

[Ed. - It's a bug all right, but it's not obvious to me how to determine
that /dev/tty is the same device as /dev/tty05 (in a way that will work on
most or all Unix systems).  If anybody knows, let me in on it.]

------------------------------

Date: Wed, 1 May 85 13:37:33 edt
From: xp!tony@nyu-cmcl2 (Tony Movshon)
Subject: Kermit 2.27/MS-DOS 2.11

A quick note about the problem with MS-Kermit V2.27 and DOS 2.11 on the
Rainbow that came up in the Info-Kermit newsletter, vol. 2 no. 22. I have
been using this setup happily for several months without problems, both
using hard-wired and modem lines. I suspect that you are correct in
suspecting the DTR control stuff, since I use my modems with DTR detection
disabled (DTR control has been a problem on the Rainbows all along, so I
long ago just decided to bag it).

Recommendation: don't try to use DTR on the Rainbow at all. Then everything
will work fine.

A second beware: DOS 2.11 is fussier than 2.05 about the way in which
resident utilities load themselves -- the problem may not be directly
related to Kermit, but to some other utility interfering with things.
Be sure to check out all resident utilities that used to work with 2.05
specifically for 2.11.

Tony

------------------------------

Date: 3 May 85 18:15:29 EDT
From: RL0Q@CMU-CC-TD
Subject: Data General D200 Terminal Emulation for IBM-PC kermit

I would like to connect to a Data General MV/4000 using my IBM-PC as a
terminal.  Is there any ms-dos version, out there in kermit land, that
would allow my PC to emulate a D200 terminal instead of a Heath-19?

                                                Rich Lunak

[Ed. - I'm sure there are Dasher emulators out there in PC land.  The
trick is not to put them in Kermit -- where will it end, after all? -- but
to write them as loadable console drivers (like ANSI.SYS), which can be
run in conjunction with Kermit (SET HEATH OFF).  We expect (hope) to see a
high quality VT102 driver in this vein pretty soon, lawyers willing.]

------------------------------

Date:     Fri, 3 May 85 15:59 CDT
From:     Richard_Berke <[e-mail]>
Subject:  KERMIT for TI-PRO with TI Internal Modem?

I have looked on the DEC-Marlboro system CURRENT.DOC file, but I don't
find a TI-PRO version of KERMIT for the TI-INTERNAL
modem.  Joe Smith's version 2.27 is for the normal sync/async card,
and using an external modem.

If you know of any version for the TI internal modem, please let me know.
If there is no official notice of a version, can you include my query
in a future issue of KERMIT DIGEST?

Also... I have tried Joe Smith's TI-PRO v.2.27 with Tek4010 emulation.
When I run a SAS job on our IBM4341, specifying a device type of TEK4010,
I get rows of horizontal bar characters across the top of the screen in
addition to my graphics, and if the SAS job results in normal text characters
as part of the output (such as labels on a pie chart), the text gets printed
on the screen right after the two rows of horizontal bars.  It appears that
real cursor positioning, and intended cursor position requests are not
working so good.

[Ed. - I trust you told the PC that you were talking to an IBM system,
using "do ibm" or the appropriate "set" commands.]

I understand that Joe Smith has left CSM.  Is anyone else aware of the
problem I have described?  How can a fix be pursued?

(I am not familiar with internals of the KERMIT programs.  I just enjoy
its functionality in my work with mixed computer systems at TI.)

Richard Berke
Texas Instruments
Equipment Group
PO Box 405   MS 3454
Lewisville, Texas 75067

[phone]

------------------------------

Date: Wed, 1 May 85 13:48:56 mdt
From: [e-mail] (David Wade)
Subject: To Ship Files up to a Cray

I have been getting a lot of long distance phone calls from people trying to
talk to the crays with kermit.  They don't have our mskermit.ini file to
make a few simple changes to make the cray kermit work better.

Therefore, here it is:

set baud 1200
set parity even
define cray set end 23, set send padch 26, set send padding 1

This makes a few adjustments to the "end, padch, & padding" characters.
If you adjust your kermits to:

set the "end of packet" character to ^W (Control W)  i.e. 23
set the "padding" character to ^Z (Control Z) i.e. 26
set the number of padding characters to 1

These changes will allow you to talk with the Cray kermits directly.

There is a special case at Los Alamos that applies to people coming in
over arpanet.  The front end machine runs an abbreviated Unix(tm) system
and that includes the Unix kermit.  Use that one to get your files to
Los Alamos if you are on Arpa.  Then convert the files to "Standard
Text format" and "Move" them to the Cray of your choice.

------------------------------

End of Info-Kermit Digest
*************************
-------
 7-May-85 19:42:44-EDT,2135;000000000000
Mail-From: SY.FDC created at  7-May-85 19:42:02
Date: Tue 7 May 85 19:42:02-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #24
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Mon,  7 May 1985       Volume 2 : Number 24

                Announcing Version 2.00 of CMS Kermit

----------------------------------------------------------------------

Date: Mon 6 May 85 17:49:51-EDT
From: Daphne Tzoar <Sy.Daphne@CU20B>
Subject: Announcing Version 2.00 of CMS Kermit
To: [e-mail]

Version 2.00 of Kermit-CMS is now available.  Some of the new
features are:

- Prefixing of the "8th bit".  This allows CMS Kermit to send or
  receive fixed format binary data, such as microcomputer binary files.

- The maximum record length allowed has been increased to 64K for
  both incoming and outgoing files.

- Repeat count prefixing has been added to speed up transmission.

- Support for two character checksum and three character CRC.

- New debugging mode to log packets.

- Input to command parser allowed from command line.  Multiple commands
  should be separated by the linend character.  After execution of these
  commands, Kermit returns control to CMS.

- Support for Series/1 front end with Yale ASCII package.

- Server operation.

- Upon startup, read commands from two init files: SYSTEM KERMINI and
  (USERID) KERMINI (that is the userid of the person running Kermit).
  Add TAKE command.

- Allow system manager to change ASCII/EBCDIC translation tables to
  conform to the various specifications of different systems.  Also,
  bypass user translate tables when sending and receiving data.

Work on CMS Kermit continues.

Daphne Tzoar
Columbia University Center for Computing Activities

[Ed. - The files are available on CU20B as KER:CMS*.* via anonymous FTP,
and on BITnet via KERMSRV at CUVMA.  Included is a new Kermit User Guide
chapter for CMS Kermit.]

------------------------------

End of Info-Kermit Digest
*************************
-------
10-May-85 19:11:10-EDT,8090;000000000001
Mail-From: SY.FDC created at 10-May-85 19:10:35
Date: Fri 10 May 85 19:10:35-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #25, C-Kermit 4C Announcement
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri, 10 May 1985       Volume 2 : Number 25

       C-Kermit 4C Available for Unix, Macintosh, and VAX/VMS

----------------------------------------------------------------------

Date: 10 May 1985 7:01pm
From: Frank da Cruz <SY.FDC@CU20B>
Subject: C-Kermit 4C Available for Unix, Macintosh, and VAX/VMS

Release 4C of C-Kermit is now available.  It does not embody major
functional changes over the previous version, 4.2 (note, the version
number style was changed to avoid confusion with Berkeley Unix version
numbers), but has many bugs fixed and includes support for many more
systems, including:

  . Berkeley Unix 4.2 (Columbia U)
* . Berkeley Unix 4.1 (Charles Brooks, EDN)
* . ATT System III and System V (Herm Fischer, Encino CA)
* . Unix Version 7 (Gregg Wonderly, Oklahoma State U)
* . Berkeley Unix 2.9 (based on V7)

  . Some "custom" Unix-like systems, including:
*   - PC/IX on IBM PC/XT (Herm Fischer)
*   - Xenix on IBM PC/AT (Herm Fischer)
    - DEC Pro/Venix Version 1 (improved performance & functionality) (Columbia)
*   - NCR Tower OS 1.02 (didn't work before, allegedly fixed) (John Bray)

  . And two major non-Unix systems...
    - Apple Macintosh (Columbia U)
*   - VAX/VMS (Stew Rubenstein, Harvard; Martin Minow, DEC)

Adding support for all these new systems has been a network-wide effort.
Although every attempt has been made to ensure that adding support for
system B did not break the program for system A (and adding support for C
did not break A and B, etc etc), some of the key contributors have become
unavailable since sending in their code and have not been able to test it.
The implementations marked with an asterisk above have not been tested
in the very latest edit; they worked recently and should work now, but this
cannot be guaranteed.  I would appreciate it if users of each of these
systems could report back to Info-Kermit indicating whether the program
works on their system, and if not, what the symptoms are and if possible
include fixes.

* Legalisms

Copyright notices have been added to all the source modules to reduce the
possibility that restrictions upon distribution and redistribution of the
Kermit source code could be imposed by ATT or ATT sublicensees.

* Distribution File Names

Since so many more systems are now supported, it has become necessary to
devise a more sensible naming scheme for the source files.  This was done,
and is described in the file CKAAAA.HLP.  The files have all been (re)named
accordingly.

* Protocol

Many changes have been made to the protocol modules and header files shared
by all the systems that run C-Kermit.  The changes are listed in detail in the
CKUKER.UPD file; a few of the major ones are:

. Organizational changes to allow better support for mouse/window systems.
. The method for mapping between CRLF and a system-dependent newline character
  is now selectable at compile time, rather than hardwired into the program.
. In the last release of this program, files transfer would occasionally
  omit bytes and the end of a file; this no longer happens.
. R, X, or F packets sometimes had garbage characters preceding their
  intended contents; this no longer happens.
. The file output function did not return a failure code upon i/o error or
  disk full, so failed transfers were reported as OK; this no longer happens.
. Unix-specific symbols or values (like init file name, program return code)
  that were hardwired are now compile-time symbols.

* Unix

In addition to the support for extra Unix and Unix-like systems, several
functional changes were made to the program:

. Interactive command lines and lines in take files may now be continued
  on new lines by putting a single '\' character at the end.  This can
  make long script commands more readable.
. Some attempt is made to recover from i/o or disk full errors when writing
  to the session log during connect.
. Support for new modem dialers added - Racal-Vadic, Penril, Cermetek, etc.
. Script command has a few new escapes: ~d(elay), ~w(ait), ~x(on).
. Long strings and/or (f)printf arguments have been shortened enough for
  them to work on all systems (let's hope!)
. File renaming and name collision avoidance is improved.
. Directory command is no longer "recursive".
. '!' command now invokes user's login shell instead of always using sh.

* VAX/VMS:

C-Kermit has been adapted to VAX/VMS; the result has been tested
successfully, but not extensively.  The main deficiencies are probably in
the areas of performance and intelligence about the VMS/RMS file system.
C-Kermit for VMS should not be regarded as a replacement for the Stevens
Institute of Technology Bliss implementation, but reports as to its
usefulness are solicited.

* Macintosh:

A prerelease of this program appeared a couple weeks ago.  Since then, thanks
to many helpful bug reports from the net, many improvements have been made:

. Parity settings should now mostly work.
. Improved file dialog boxes, available now for GET, RECEIVE as well as SEND.
. Many new file settings available (text/binary, data/resource, supersede/
  preserve, etc), savable in the settings file  (Note, settings files have
  new format, old ones can no longer be used).
. ASCII text files now stored correctly, so Mac applications can use them.
. Remote command window pops up automatically when needed.
. Mac Kermit can be a limited server, responding to SEND, GET, BYE, FINISH,
  and REMOTE HELP commands.
. Various changes relating to selection/specification of disk/volume/folder.
. The beginnings of a manual (CKMKER.DOC).

Several major areas will have to be attacked in subsequent releases (in order
of priority):

. Key redefinition, support for function keys, keypad, etc.
. Saving screen contents into a file.
. Support for XON/XOFF during terminal emulation.
. Support for additional VT102 features.
. Modem dialer support.
. Login scripts.
. Raw file upload.
. Printer support.
. Translation to a native Macintosh C compiler so you don't need a VAX
  to build the program (with conditional support for SUMACC left in), and
  so that the program can grow by taking advantage of dynamic segment
  loading, which SUMACC doesn't support.

We are working on the first two items ourselves; contributions in other
areas would be welcome.

Macintosh C-Kermit has been successfully tested in conjunction with DEC-20s
and VAXes (full duplex mainframes) at speeds up to 9600 baud, with IBM
mainframes (half duplex, handshake, various kinds of parity) on both ASCII
async ports and 3270-emulation ports at speeds up to 4800 baud, and with
another Macintosh in server mode at speeds up to 57.6K baud.  It runs on 128K
and 512K Macs and on the "Macintosh-XL", standalone or with the switcher.

* Distribution

The files have been placed on CU20B in the area <CKERMIT>.  The <MACKERMIT>
area has been removed.  The previous releases of C-Kermit (4.2) and MacKermit
(Steve Engel's original from Harvard) will remain in KER: until we receive
reports verifying that the new version installs and works as advertised on
all the systems listed above.  Prompt reports would be appreciated, so that
we can start putting the new C-Kermit on our distribution tapes.  The files
may be obtained via anonymous FTP from Internet host CU20B as <CKERMIT>*.*.
The file <CKERMIT>CKAAAA.HLP explains what all the files are.  Be sure to
read the appropriate "beware" (.BWR) file before installing or running the
program -- these files list all known bugs, restrictions, and peculiarities
of each implementation.

------------------------------

End of Info-Kermit Digest
*************************
-------
13-May-85 19:37:17-EDT,7482;000000000000
Mail-From: SY.FDC created at 13-May-85 19:36:47
Date: Mon 13 May 85 19:36:47-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #26
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Mon, 13 May 1985       Volume 2 : Number 26

Departments:

  C-KERMIT 4C
    Bug in New Macintosh C-Kermit
    C-Kermit 4C Bugs

  DIALUP DISTRIBUTION
    Kermit Distribution Available via Kermit Server
    Change Of Kermit-11 Update Procedure

  MISCELLANY -
    Computer Vision Kermit?

----------------------------------------------------------------------

Date: Fri 10 May 85 21:38:53-EDT
From: Bill Schilit <SY.BILL@CU20C>
Subject: Bug in New Macintosh C-Kermit
To: sy.fdc@CU20C

I sent a file from the Mac, I started a new transaction and emergency-
exited with Command-.; C kermit deleted my file.

[Ed. - Oops, sorry.  This bug effects Mac Kermit only, even though the guilty
code appears in the common protocol module -- only the Mac can cancel a
transaction before the first data packet has been sent.  The emergency exit
code should not delete any files.  The code is now fixed, see below.]

------------------------------

Date: Sun, 12 May 85 15:46:35 pdt
From: [e-mail] (Dave Tweten)
Subject: C-Kermit 4C bugs

I got a copy of C-Kermit 4C, Friday evening, May 10.  I built it on both
our 4.2 bsd Vax and on one of our System V Vaxes.  I found three new
problems, and noticed that a fourth problem I've been trying to find in
C-Kermit 4.2 is still present, though in a slightly changed form.  They
follow, in no particular order.

1.   When getting a binary file, if the local kermit is the 4C bsd
     version, all will go well except that at the end, "Z [discarded]"
     will appear.

[Ed. - This problem was introduced by adding code to zchout() to check
when putc returns an error code -- the old char/int/sign-extension mixup.]

2.   In server mode, remote commands issued by C-Kermit cause version 4C
     to hang the transfer with a continuous stream of NAKs.  The remote
     commands I tried were "rem dir" and "rem host ls -l".  The tests
     below were conducted with "rem dir".  I tested the following
     combinations:

[Ed. - This problem was introduced by adding code at the last minute to make
the Macintosh version work better and then assuming it still worked on Unix.]

3.   C-Kermit 4C Racal-Vadic modem support doesn't work with our
     Racal-Vadic modem on the System V machine.  The bsd machine's modem
     line has been munged by uucp and needs superuser service, so I
     can't test that over the weekend.  The gross behavior is the same
     behavior I observed with an early version of the dialer code, which
     was sent to me by Herm Fisher: it always times out.

     With Herm's code running on our bsd machine, I inserted prints to
     stderr, and observed that the conversation with the modem went as
     expected, until the actual dialing began (modem says "DIALING:  "),
     at which point the modem seemed to go to sleep.  My version of
     Racal-Vadic support (inserted into version 4.2) works.  As I told
     Herm, by reading his code, I couldn't see why his shouldn't work.
     It did use the input buffer flushing routine (which was a no-op
     under 4.2's Vax bsd version) whereas my code does reads, but I
     modified the 4.2 buffer flushing routine to actually do something,
     and that didn't seem to help.

[Ed. - Herm's away for the month, and I don't have a Racal-Vadic modem to
fool with.  If you or anyone can offer code that works, please send it in!]

4.   Sending a binary file to C-Kermit often doesn't work. This isn't
     new with version 4C.  I've been trying to track it down in version
     4.2.  Though it isn't entirely new, as you can see below, the
     variety of behavior has become richer.

[Ed. - Same problem with zchout().]

That's the C-Kermit bug picture as I see it.  Unfortunately, I won't be
able to pursue them further, in the immediate future.  Other deadlines
approach, you understand.  For the time being, I think we'll continue
using version 4.2.  It has fewer bugs which impact us.

[Ed. - Thanks for the quick report.  We've fixed (I think) all but the
Racal-Vadic modem support problem.  The new files are in <CKERMIT> as
CKCFN*.C, CKUFIO.C, CKVFIO.C, CKMFIO.C, CKCPRO.W, CKCKER.H, CKCMAI.C, and
CKMKER.HQX (and .RSRC) available from CU20B via anonymous FTP.  Some
reorganization was required to fix bug number 2, and it has not been tested
in the VMS version.  Again, everyone who's interested please take these
files away and try them out and report back whether they work on all the
various systems and machines.  Once the major kinks are out, C-Kermit v4C
can be added to the normal distribution -- tapes, okstate (see below), etc.]

------------------------------

Subject: Kermit Distribution Available via Kermit Server
Date: 10 May 85 12:03:41 CDT (Fri)
From: Mark Vasoll <[e-mail]>

    We have set up a specialized version of the C-Kermit server that
will allow access *only* to the Kermit Distribution area on our system.
This service will be sharing the phone line with the UUCP account, so the
line will probably be busy quite a bit.

    Anyway, access to the Kermit Distribution area is now available
using the following dialing/login information:

              UUCP                                  KERMIT SERVER

     Phone:   [phone]                 Phone:   [phone]
Login name:   uucpker                   Login name:   kermsrv
  Password:   thefrog                     Password:   piggy

The UUCP distribution will function as before.  The KERMIT SERVER login
will drop you right into a conversation with the server.  The best place
to start after logging on is "REMOTE HELP", followed closely by "REMOTE DIR".

Mark

------------------------------

Date: 13 MAY 85 11:12-EST
From:  [e-mail]
To:  info-kermit@cu20b
Subject: CHANGE OF KERMIT-11 UPDATE PROCEDURE

This to announce that Kermit-11 updates should now be obtained from  the
University  of  Toledo's  VAX  11/785 instead of the PDP 11/70, which is
being removed from service. The dialup  number  for  the  VAX  is  (419)
537-4411.  The  front  end is a Dual PACX 4, which will autobaud on a CR
and then prompt for 'Service Class ', which is VX785A. The VMS  username
is  KERMIT  with  a password of KERMIT. All source files are in KER: and
Kermit-11 binaries are in KERBIN:. Please note that  the  VMS  Kermit-32
server  should  be  set to FILE TYPE FIXED in order to transfer any .SAV
or .TSK files.  This also means that a Kermit-11 getting  files from the
VMS server should have SET FIL BIN set for task and save images.

                                                brian nelson
                                                [e-mail]

------------------------------

Date:  Thu, 9 May 85 21:58 CDT
From:  "David S. Cargo" <[e-mail]>
Subject:  Computer Vision

Does anybody out there have a version of Kermit working for Computer
Vision computer aided design systems?

David S.  Cargo (Cargo@HI-Multics)

------------------------------

End of Info-Kermit Digest
*************************
-------
14-May-85 19:36:33-EDT,7039;000000000000
Mail-From: SY.FDC created at 14-May-85 19:36:08
Date: Tue 14 May 85 19:36:08-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #27
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Tue, 14 May 1985       Volume 2 : Number 27

Departments:

  C-KERMIT 4C -
    C-Kermit 4C Bugs (Still)
    Missing File for C-Kermit VMS Make Procedure
    VMS C-Kermit 4C Works
    LCK files, parity, "backing out", aborting FINISH, make errors

  MISCELLANY -
    VM/CMS Kermit 2.00 vs IBM 7171
    MSTIPRO Kermit with Internal Modem and TEK-4010

----------------------------------------------------------------------

Date: Tue, 14 May 85 16:15:21 pdt
From: [e-mail] (Dave Tweten)
Subject: C-Kermit 4C Bugs (Still)

I just finished getting the changed source files you recommended in the
latest digest, and rebuilding on both a 4.2 bsd Vax and a System V
Vax.  I retested for the "rem dir"-hangs-on-NAKs problem.  It's still
there.  I used the bsd Vax as the local Kermit, and the System V Vax as
the remote.

[Ed. - Dave reports the other problems fixed for these systems -- binary
files transfer ok, etc.  But sending any "remote" command to the C-Kermit
4C server on the System V VAX times out.  The 4.2bsd VAX C-Kermit 4C server
handles "remote" requests just fine, no matter what system they come from,
even from itself.  Anybody who can figure this one out will be a hero.]

------------------------------

Date: 13 May 85 14:05 EDT
From: (David H M Spector) <[e-mail]>
Subject: Missing File for C-Kermit VMS Make Procedure

I found a problem with the distribution kit for C-Kermit. The VMS
com file called "ckvmak.com", which becomes "CCMAKE.COM" is a copy
of ckver.com,  the 'makefile'.  Attempting to run the make file will
cause lots of errors as the com file goes into an endless loop.

                David Spector
                NYU/acf Systems group

[Ed. - Sorry!  The correct file is now installed as <CKERMIT>CKVMAK.COM,
available via anonymous FTP from CU20B.]

------------------------------

Date: Tue, 14 May 85 13:04:15 EDT
From: [e-mail] (Stew Rubenstein)
Subject: VMS C-Kermit 4C Works

Seems to work OK;  I have not tested it extensively, but things mostly
work.  There are some problems with file name canonicalization (it doesn't
strip off version numbers before sending).  This is with the new modules
announced Monday.

[Ed. - Thanks, Stew.  I'm glad I didn't break your code too badly...]

------------------------------

Date: Monday, 13 May 1985 13:26:55-PDT
From: [e-mail]  (Dan Schullman)
Subject: LCK files, parity, "backing out", aborting FINISH, make errors

    Is it possible to clear the LCK* files on an interrupt?  When
    I accidentally leave the line as a "modem" line and can't open
    it, an interruption leaves the LCK* file for the line around.

Yes, and it is done in many cases -- e.g. when ^C is typed, when various
fatal errors occur -- the program goes through doexit(), which is supposed
to clear any lock file.  But some other interrupts are not presently caught,
and some can never be (e.g. if the process is killed from another process,
or the system crashes).  I agree this is an area that needs improvement.
The new manual (CKUKER.DOC) discusses the perils of lock files in greater
detail than the previous one did.

    I had trouble copying a binary file (but not a text one), and
    thought it was a KERMIT 4C/4.2 incompatability.  Eventually
    turned out to be a parity problem.  I don't understand why
    text files copy okay but binary ones don't.  I thought KERMIT
    "packaged" the transmission so that only ASCII graphics would
    be used.  Both "ends" were set for the same parity ("none"),
    and as stated I WAS able to copy text files.

This should be fixed in the current (circa Monday, May 13) release of
version 4C of the program.

    There seems to be some interactions with quoting from the command
    line.  For example, try:
        ! echo "this should \07 ring"
    Even escaping the backslash doesn't help.

This will have to be looked at.  Meanwhile, you can always use a real
control-G in the string -- it works both in shell commands and in Kermit's
own echo command.

    Is there a way to "abort" questions if one has "gone down the
    wrong path"?  For example, if one has answered the "from file"
    question and wants to get out of the "to file" question.  I
    tried EOF (Control-D) but that didn't work.

Currently no, short of typing Control-C, which gets you out of the program
entirely.  This too will have to be looked at.

    I often "hang" trying to do a FINISH, BYE, etc.  Is there a way
    to abort these operations without exiting KERMIT?  As mentioned
    in previous mail, this is sometimes because the remote server
    has returned to command mode for some unknown reason.

Currently, there is no way to "abort" a protocol operation before data packets
start to flow, short of typing ^C.  This is true of most Kermits.  Macintosh
Kermit is an exception.  Unix Kermit will have to have a more powerful
interrupt facility added to it to fix this and several of the other problems
you've mentioned.

    In building KERMIT on a SYS-V VAX, I got the following in addition
    to problems caused by multiple includes of types.h by ckxunx.h.
    "ckuser.c", line 916: warning: illegal combination of pointer and
         integer, op =

These problems should be fixed in the current release.

------------------------------

Date: 14 May 1985 0954-EDT
From: LCG.KERMIT@DEC-MARLBORO
Subject: VM/CMS KERMIT 2.00 vs IBM 7171

I installed CMS kermit on our 3032 system that uses a 7171 front-end.
I had to comment out two lines to get everything to work.  At
OKDEV - 3, remove 2 lines:

*    clc    cons772,temp
*    bne    baddev

After that change, everthing worked.

Thanks to Columbia for another great version,

Wade Missimer
Abbott Labs

[Ed. - Thanks; this hint has been added to the CMSKERMIT.BWR file.]

------------------------------

Date: Thu 9 May 85 21:41:48-EDT
From: Joe Smith [phone] <[e-mail]>
Subject: MSTIPRO Kermit with Internal Modem and TEK-4010

In reference to Richard Berke's questions, 3-May-85.

1) The file KERMIT:MSTIPRO.HLP on MARKET tells how to use the internal modem
   on a TI Professional.  This functionality was added before version 2.27
   was released, but appearantly did not make it to VERSIONS.DOC.

2) The Tektronix emulation is for line drawing only.  Since the system I
   developed it on drew labels using pen strokes, no attempt was made to
   make the alpha cursor track the graphics cursor.

3) Full HEATH-19 emulation is being added.  The new maintainer is:

    Dan Smith    [phone]
    Colorado School of Mines
    Computing Center
    1500 Illinois Street
    Golden, CO 80401

------------------------------

End of Info-Kermit Digest
*************************

-------
16-May-85 19:58:58-EDT,25017;000000000000
Mail-From: SY.FDC created at 16-May-85 19:58:30
Date: Thu 16 May 85 19:58:30-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #28
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Thu, 16 May 1985       Volume 2 : Number 28

Departments:

  C-KERMIT 4C -
    C-Kermit 4C Changes
    Problems with the V7 version of C-Kermit 4C
    C-Kermit 4C for 2.9bsd/xproc
    C-Kermit 4.2 OS9/68000, First Implementation Report
    C-Kermit File types, file transfer problems
    UNIX Kermit 4C Comments

  MISCELLANY -
    New mackermit--double-clicking on a saved settings file
    Re: New mackermit--double-clicking on a saved settings file
    Kermit hangs on bye/finish
    Re: Info-Kermit Digest V2 #27
    Using Kermit to back up your micro's hard disk
    Update on the OK State Kermit Server
    Kermit for TI-990?
    HP Portable (HP110) Kermit?

----------------------------------------------------------------------

Date: Thu 16 May 85 19:36:17-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: C-Kermit 4C Changes

A few changes have been made to C-Kermit 4C to solve some of the recently
reported problems.  The new files are in <CKERMIT>*.* on CU20B, available via
anonymous FTP.  The biggest modification changes the way the program determines
whether it's in local or remote mode.  Rather than just comparing strings,
which doesn't work in many cases, the program now asks the system.  This should
allow C-Kermit to function correctly in remote mode when invoked by a user
logged in on the "back port" of a workstation (like the Pro-350/380 under
Venix) which is normally used from its console in local mode.  Some other bugs
concerning "set line" were fixed at the same time -- the program now puts the
speed back to -1 when going from local to remote mode; it no longer erroneously
sets the tty name string when the desired line can't be opened (e.g. because
"Permission denied").  These changes affected many modules, because the calling
convention to ttopen() had to be changed.

The following messages mention other bugs and fixes in today's version of the
C-Kermit files.  Note that the problem reported by Dave Tweten that the
C-Kermit server on System V systems does not respond to "remote" commands
(other than "remote help") has not yet been fixed; Dave is still trying to
track it down.  On the other hand, only Dave has complained about this.  Are
there other users of C-Kermit 4C under System V that are also experiencing this
problem?  Are there any who aren't???

------------------------------

Date: Thu, 16 May 85 15:41:27 edt
From: randy@nlm-vax (Rand Huntzinger)
Subject: Problems with the V7 version of C-Kermit 4C

I had some difficulty getting the C-Kermit 4C to compile and run on our Codata
Version 7.  Here are the diffs of the ckutio.c file and the Makefile which I
ended up using.  The main problems were:

    1.    The absence of the xproc variable definition.
    2.    The nlist stuff had to be changed for our system.
    3.    A bit of fluff in the makefile.

We have a binary license, so I didn't have direct access to the name of a
variable which is a pointer to the proc table, so I had to use the address of
the proc table (which I knew from the bit of source we have to be called proc).
I also had to change the name of nproc for our version 7.  Yuk, there has got
to be a better way.

Also, why is makefile in the object list for making "wermit"?  It seems that
this would crash every make for any kind of system.

[Ed. - Oops, a mistake, now fixed.]

Here are the diffs I used.
                        Rand Huntzinger
                        randy@nlm-vax
[Ed. - Diffs omitted.]

------------------------------

Date:     Thu, 16 May 85 16:29:36 CDT
From:     Gregg Wonderly <[e-mail]>
Subject:  Re:  Problems with the V7 version of CKermit 4C

    What Randy did looks reasonable.  Seems that there is some difference
in whether his "_proc" value is the address of a pointer to the proc array,
or the address of the array itself.  Anyway, this situation makes it get
real hairy when you don't have the source I suppose.  On our system, the header
file <sys/proc.h> has the definiton of what "_proc" or "proc" really is.  I
put the documentation in the MAKEFILE for this reason.  Damn I wish someone
would choose a standard version of UN*X and use it.  Maybe SYS5R2 will help.
As soon as we get what Randy has off of your VAX, I will add a good solid
description of what is really happening, and the possible exeptions.  Maybe
this will clear some things up.  Go ahead and add his diffs to ckutio.c.
They will probably be necessary on some systems.

[Ed. - Randy's diffs added to ckutio.c.]

------------------------------

From: Paul Graham <unr70!unrvax![e-mail]>
Date: 15 May 1985 1011-PDT (Wednesday)
Subject: C-Kermit 4C for 2.9bsd/xproc
Cc: [e-mail]

Our version of the 2.9bsd <sys/proc.h>:

/*    $Header: /usr/include/sys/RCS/proc.h,v 1.2 85/01/17 11:31:30 root $ */
/*    $Log:    proc.h,v $
 * Revision 1.2  85/01/17  11:31:30  root
 * Distribution version, RCS integrated
 *      */

indicates that the struct xproc has been superseded by the union p_un.

This is an informational message at this time.  If time permits we may
undertake the changes to ckutio.c.  However after short reflection it seems
this may require a -D for 2.9 as well as V7.

Paul Graham 702/784-6007
University of Nevada Reno
UUCP (seismo, ucbvax!menlo70)!unr70!unrvax!pjg ARPA unr70!unrvax!pjg@seismo

[Ed. - Maybe the changes added above for V7, which seem to address this
proc business, might help.  In any case, any changes to make C-Kermit
actually work under 2.9bsd would be most welcome, the sooner the better so
that 4C can become the real, distributed version.  If anyone wants to help
these folks out, don't hesitate to volunteer!]

------------------------------

Date: Wed, 15 May 85 19:21 MET
From: Matthias Bohlen <[e-mail]>
Subject: C-Kermit 4.2 OS9/68000, First Implementation Report

These are the first things I noticed when trying to compile
C-Kermit 4.2 on my OS9/68000 system. If I only had time...

1.   I wrote a new makefile, because OS9 "make" is different
     from UNIX "make".

2.   Form feeds had to be eliminated (C compiler reports
     errors), back-slash for line continuation was accepted
     by the C preprocessor.

[Ed. - Presumably these can be removed by a filter in the os9 makefile?]

3.   I shortened many strings in ckmain.c, ckusr2.c

[Ed. - So have we in version 4C.]

4.   Possible programming error found in ckcmd.c (line 959,
     deals with word-delete):

         *bp++ == NUL;

     as a single statement has little effect (68000 C gives
     a warning message here), but "*bp++ = NUL;" would be an
     erroneous cure, if bp<cmdbuf after the preceding for-
     loop! I suggest:

         bp++;

[Ed. - Thanks.]

5.   Strange construct (similar to 4.) in ckuser.c:
     "*xargv++;" as a single statement; what is intended?
     Maybe only xargv++, but maybe "(*xargv)++" ?
     My compiler gives a warning here (same as 4.).

[Ed. - Thanks again -- it should be simply argv++.]

6.   Return value type mismatch in ckuser.c:
     "return(sstate);" returns a char as a default "int"
     result of "parse". Similar situations in ckfns.c and
     ckfns2.c. My compiler gives a warning here.

[Ed. - I don't think this does any harm since sstate will never be set to
a value that can be sign-extended as a result of char/int conversion.]

7.   Strange construct in ckuser.c:

        if (x = (cmcfm()) < 0) return(x);

     My compiler gives a warning here: "possible degenerate
     assignment in test". Hope, it performs the assignment!
     There are similar constructs in ckusr2.c and ckusr3.c.

[Ed. - Thanks, should be "if ((x = cmcfm()) < 0) return(x);".]

8.   ckusr3.c: Expressions with little effect:

        turnch == y;
        *s2--;

     both as single statements. Again the question: What is
     intended?

[Ed. - Again, thanks.  Changing to "turnch = y" allows the "set handshake"
command to work as advertised.  Before, it always set the handshake character
to XON, no matter what your command said.]

9.   ck?unx.c: The whole conditional compilation stuff con-
     fuses me. I think, I'll remove it and write special
     OS9/68k files ckxo9k.c and ckzo9k.c. ckz does not re-
     quire much change.

[Ed. - Good idea.  I suggest using "9" to designate os9-specific files,
as in "ck9tio.c", in the nomenclature of version 4C (in which the file names
were changed).]

10.  ckdial.c and cklogi.c need SIGALRM (undefined in all
     OS9/68000 header files).

11.  Assembler reports errors about the C-generated code,
     if a variable of storage class "extern" is called
     "cc". The compiler gives the name directly to the
     assembler, where it collides with the name for the
     condition code register of the 68000! Really funny!

[Ed. - I assume you can handle this by doing something like "-Dcc=xcc" in
the makefile.]

I have much work to do in the next weeks, so I cannot
continue on C-Kermit for some time, but I keep trying.

Matthias Bohlen <Mattes@Germany>

[Ed. - The changes marked by "thanks" above are reflected in the files
currently in <CKERMIT> on CU20B, available via anonymous Internet FTP.
The files also include some other minor changes, noted below.

Please send reports to Info-Kermit regarding either problems or success
building and/or running C-Kermit version 4C under 4.1bsd, Xenix, PC/IX, and
other as-yet unreported systems, so that I'll know when the program is
stable enough to be declared a "real" release.  Thanks!]

------------------------------

Date: Wednesday, 15 May 1985 05:48:25-PDT
From: [e-mail]  (Dan Schullman  223-7468)
Subject: C-Kermit file types, file transfer problems

    It would be real nice if I could do something like:
        REMOTE SET FILE TYPE ...
    so that as I alternate file types, I don't have to keep
    FINISHing, CONNECTing, and reSERVing in order to change
    the file type.

[I agree.  This would be an extension to the protocol that we'll probably
have to make.]

    Running VMS KERMIT V3.1.66 today with C-KERMIT 4C on
    VENIX V2 FT2 and trying to transfer a binary file on
    a line that VMS thought was /NOEIGHTBIT, I was able
    to send it to VMS okay, but kept getting Q%Q%Q's when
    trying to get it from VMS.  Eventually I told C-KERMIT
    to use "space" parity and that got it working.  Can
    you explain this?  Is this more confusion over number
    of data bits versus parity?

[To get VMS Kermit to work on a /NOEIGHTBIT line, you have to give VMS
Kermit an explicit SET PARITY command.  In your case, telling the opposite
Kermit worked too, because it told VMS Kermit that parity was being done,
and therefore to use 8th-bit prefixing.]

    Yesterday (and previously) while trying to get or send
    text files between KERMIT 4C on a Sys-V VAX and VENIX V2 FT2,
    I had problems with file specifications of "*", whereas
    "*.*" seemed to work.

[I believe that this problem can be explained as follows: The C-Kermit send
command expands its argument into a list of all files that match.  If you give
it the "*" argument, then the list will include the files "." and "..", which
are really directories.  When going through the list, C-Kermit checks each file
to make sure it's readable ("ordinary") using stat(), and it skips files (like
directories) that are not.  The trouble comes in because System V has two ways
of saying whether a file is ordinary, whereas Kermit was only checking one way.
In the file ckufio.c, function zchki() makes the following check:

    x = buf.st_mode & S_IFMT;        /* Isolate file format field */
    if (x != S_IFREG) {
    debug(F111,"zchki skipping:",name,x); /* Not readable */
    return(-2);
    }

System V will also return a 0 for a readable file, so the check should be

    if ((x != 0) && (x != S_IFREG)) {

This change is in the latest CKUFIO.C in <CKERMIT> on CU20B.  System V
experts, please speak up if there is a better way to do this!]

------------------------------

Date: 15 May 1985 1059-EDT
From: LCG.KERMIT @ DEC-MARLBORO
Subject: UNIX Kermit 4C Comments

A few remarks on Kermit 4C, which I downloaded from Market and compiled on my
Masscomp RTU 2.2 system.

1) using the "make sys3" command, the 4C kermit appears to
   work just fine on my Masscomp, no problems encountered so
   far, but all I've really tried is the "connect" mode,
   and ascii/binary file transfers to/from a DEC-20 and a VAX.
2) The new Kermit works just fine with my Racal-Vadic modem, contrary
   to what was indicated in the latest Digest?  Maybe the problem
   is in the bsd vs. sys3 compilations?
3) The only peculiarity I noticed with the new version so far is
   if I "set modem-dialer racalvadic" and then do a "show parameters",
   it still lists the modem-type as "direct" rather than "racalvadic",
   even though the "dial" command works fine?  If I set the modem
   type to something else, e.g. "hayes", and do a "show parameters",
   then the modem-type is reported as "hayes".  A bug somewhere,
   but certainly minor.

[Ed. - Code has been added to the "show command" to know about the
various modems, in <CKERMIT>CKUUSR.C on CU20B.]

Here in this building at Ford we have a DEC-20, a dozen or so
Masscomp's, about 40 assorted PDP-11's, several IBM PC's, about
50 Victor's, 2 VAX 780's, 5 VAX 730's, two Prime's, 3 Apollo's,
and several Computervision systems.  We have Kermit installed
on most of these systems and find it quite adequate for low-volume
file transfers.  Best of all, it's free!!  Keep up the good work!!

[Ed. - Which Kermit are you running on your Victors?  It would be a
great help if someone could make the necessary system-dependent modules
for MS-DOS Kermit to support the Victor, so we could discard some of
the hokey old versions that are now in use.]

        Steve Kaberline
        Ford Motor Company
        Scientific Research Labs, room S-3061
        P.O. Box 2053
        Dearborn, MI  48121
        [phone]

------------------------------

Date: Wed, 15 May 85 17:15:41 EDT
From: edwards%h-sc4@HARVARD
Subject: New mackermit--double-clicking on a saved settings file

It complains that it can't find an application to open.

                Bill Edwards
                Harvard Arts and Sciences
                Computing Services
[Ed. - See answer below.]

------------------------------

Date: Wed 15 May 85 21:28:59-EDT
From: Bill Schilit <Sy.Bill@CU20B>
Subject: re: New mackermit--double-clicking on a saved settings file
To: edwards%h-sc4@HARVARD

The problem is that either the bundle bit is not set in the kermit
application or the creator is not set to KERM -- or both of these.

If you downloaded your kermit application from the RSRC file then
you will need to set these values using the set file utility.  This
is outlined in the doc file that comes with the distribution.

You should be seeing two different icons, one for the settings file
and one for kermit itself.  If you don't see these then you need to
run setfile.

- Bill

------------------------------

Date:     Wed, 15 May 85 11:47:10 CDT
From:     Gregg Wonderly <[e-mail]>
Subject:  Kermit hangs on bye/finish

    In the latest info-kermit, I noticed some talk about kermit hanging on
a bye or finish command.  We had this problem talking to the VMS KERMIT on
our 11/780.  The problem seems to be that the server gets the bye/finish
packet ok.  It then sends an ACK.  Immediately following this, the program
terminates.  At slow baud rates, we believe that the system does some clean
up and buffer flushing before the entire packet gets sent.  This tends to
keep the entire packet from being sent.  Might be wise to get some of the
authors to put "sleeps" into the code where applicable.

[Ed. - C-Kermit has the appropriate sleeps.]

------------------------------

From: dual!ptsfa!abm@Berkeley
Date: Wed, 15 May 85 13:50:36 pdt
Subject: Re: Info-Kermit Digest V2 #27

RE: Kermit CMS & Sim3278 & Profs & PCdos Kermit 2.26

I have been using PCDOS Kermit to access PROFS with moderate success.  We
have just installed a major LAN & related network facilities that
allows a large group of users who were using Simware's AZPC2 @ 1200 baud
to move up to 9600.  Unfortunately, AZPC2 is written in basic ... and you
can guess the results at the higher line speed.  I am hoping that this will
provide an opportunity to overcome "not a supported product" phobia on a
large scale, because I don't think anything but kermit can satisfy all our
requirements in the near term.

Here are the questions/problems:

1. One requirement is the ability to download/upload from the PROFS (read
3270) environment.  This presently doesn't work because CMS release 1.0
supports only tty terminals.  Does release 2.0 use standard 3270 calls,
or does it talk specifically to the Series 1/Yale package?  What are the
odds 2.0 will work with Sim3278 and how much work do you think it will take?

[Ed. - It talks specifically to the Series/1 Yale package.  CMS Kermit will
not work with an unmodified Sim3278, but if you have source, you can modify
Sim3278 to accept the same escape codes for entering "transparent mode" that
the Series/1, 7171, and 4994 accept.  Making Kermit work over 3270-like
connections in general is a much harder problem, requiring major extensions
to the Kermit protocol itself.  This was discussed at some length in
Info-Kermit Digest V1 #11, June 84.]

I am assuming that you know more about Sim3278 than I know about the Yale
package.  Sim3278 runs on the VM host as a "diconnected process" (I think
that's the terminology), so we come through the Comten front ends like
normal async terminals until we get to CP and "dial sim3278".

2. I am using vt52 emulation under Sim3278.  I have done 'set key ~' for my
functions, etc. but since local echo is on, the escape sequences garbles
the screen.  In order to get around this problem, I plan to install the
following kludge:
    module: msyibm.asm @ trnou2:

    if the first byte of the macro sequence is a sentinal (probably 0ffh),
    check if local echo is on, and, if so, turn it off and set a flag.
    Check the flag after sending the macro, and, if on, turn local
    echo back on.  (I also plan to include a second sentinal to allow
    a macro starting with a sentinal to be echoed -- I don't know why
    you would want to do this, but its best not to fool with mother
    nature (or Bell or Blue or ...).)

I think this can be done with 20 or so statements in this one function.
Please let me know if you think there is a better way to handle this.  I
will send you the code fragment when it is working.

[Ed. - No need to add code to MS-Kermit; this is addressed by Sim3278 code
already -- each terminal definition has a flag indicating whether a
character is left by hitting a function key; if so, Sim3278 will erase it
after CR is entered.]

3. I don't have a good environment to test kermit at 9600 baud.  My limited
testing looks OK.  Do you anticipate any problems?

[Ed. - No.]

4. Sim3278 doesn't support highlighting for the vt52 (bless their hearts),
which makes PROFS' calendar system unusable (not quite everyone considers
this an improvement).  We probably have the clout to get this fixed on
our own, but do you happen to know of any easy answers.  I don't know
much about VM, and at this point our support people are very supportive
about solving kermit problems ... but thanks to them I'm starting to get
"good" at vm/cms.

[Ed. - The Heath-19 emulation in IBM PC MS-DOS Kermit will have highlighting
in the next release, 2.28, coming soon.]

I hope I haven't overloaded you with questions.  Any guidance you can
provide will be greatly appreciated.

Al Margolis
Pacific Bell, 120 Montgomery Street, Room 330, San Francisco, Ca. 94104
ihpn4,dual!ptsfa!abm

------------------------------

Date: Wed, 15 May 85 18:04:54 edt
From: xp!tony@nyu-cmcl2 (Tony Movshon)
To: [e-mail]
Subject: Using Kermit to back up your micro's hard disk

Since the prospect of backing up even a modest (10 mbyte) hard disk onto
floppies is unpleasant, I have taken to using Kermit for backups. I use a
Rainbow (MS-DOS 2.11, MS-Kermit V2.27) and a VAX 750 (4.2BSD, C-Kermit, now
version 4C), hooked over a 9600 baud line. Backing up the (full) hard disk
takes about 8 hr, and can comfortably be done overnight. This process
worked just fine after I made one small change in MS-Kermit.

As you will realize, the most convenient way to handle this particular
backup is to make an image of the MS-DOS directory tree at the Unix end,
and to make a giant MS-DOS batch file using local "cd" commands and
MS-Kermit "remote cwd" commands to move stuff. That is, the process
involves

  o Building (manually) a copy of your micro's hard disk directory tree at
    the Unix end,
  o From the top of this tree running C-Kermit (with file type binary) as a
    server, and
  o Using the command-line control available in MS-Kermit by means of a big
    batch file that looks like

    cd \
    mskermit send *.*
    cd dir1
    mskermit remote cwd dir1
    mskermit send *.*
    cd ..
    mskermit remote cwd ..
     ...
    and so on through the tree until
    mskermit finish

    Building the batch file is much eased by having a program like "tree"
    to lay out all the directory names. It is in any case easier than just
    sitting for an hour changing floppies every 3 minutes.

You will realize, however, that the impediment to all this is the fact that
the "remote cwd" command in MS-Kermit demands a password for the new
directory and will not accept input from a batch file for that purpose.
This may be a limitation in the protocol, but it seems to me that "remote
cwd" should request a password only if the other Kermit demands it (Unix,
of course, does not password-protect directories).

To solve this problem, I simply removed the code in MS-Kermit that requests
and processes the password. This is easily done, although the code is not
in front of me so I don't remember exactly where it lives. Perhaps there
should be an option in future versions of micro kermits to omit the
password request (or two commands: "remote cwd" to skip password, "remote
cwdp" for password-based systems).

In any case, backing up this way is a pleasure beyond words compared to the
bad old days, and I commend it as YACUK (Yet Another Creative Use of Kermit).

Tony Movshon

[Ed. - The next release of MS-DOS Kermit will fix the Password prompt and
input to work the same way as the rest of the command parsing, so that the
REMOTE CWD command will be usable from batch files and Kermit command files.]

------------------------------

Subject: Update on the OK State Kermit Server
Date: 15 May 85 11:19:26 CDT (Wed)
From: Mark Vasoll <[e-mail]>

I have notice some people (already) having problems with getting our server
to talk to them.  The problem is that they *must* use EVEN parity due to a
limitation of our communications equipment.  Sorry I forgot to mention this
earlier....  UUCP bypasses this limitation in a rather gross way with which
I will not clutter up the C-Kermit code.

I also forgot to mention that when people issue a REMOTE DIRECTORY command
on our system, they should be prepared for more than 600 lines of output.
It is usually better to read the 00README.TXT file (using REMOTE TYPE
perhaps) and then do the REMOTE DIR with some kind of wildcard (like
"REMOTE DIR ck*").

Mark

[Ed. - The file KER:OKSTATE.TXT now contains an up-to-date summary of how
to get Kermit files from Oklahoma State U using either UUCP or Kermit.]

------------------------------

Date: Wed, 15 May 85 11:55:23 cdt
From: ihnp4!umn-cs!ncs-med!bi@Berkeley (Bob Isch)
Subject: Kermit for TI-990?

Does anyone have a version of kermit available for TI-990 mini-computers
running DNOS or DX10?  Any pointers or ideas would be helpful.  Thanks, -bi

Bob Isch                      -bi [phone]   ihnp4!umn-cs!ncs-med!bi

------------------------------

Date: Tue, 14 May 85 19:08:42 pdt
From: Todd H. Ogasawara <ogasawar%cod@Nosc>
Subject: HP Portable (HP110) Kermit?

Is there a Kermit for the HP Portable (aka HP110) lap portable?
Thanks in advance for any leads?


Todd Ogasawara, Computer Sciences Corp.
NOSC-Hawaii Laboratories
UUCPmail: {akgua,allegra,decvax,ihnp4,ucbvax}!sdcsvax!noscvax!ogasawar

------------------------------

End of Info-Kermit Digest
*************************

-------
17-May-85 18:35:52-EDT,11036;000000000000
Mail-From: SY.FDC created at 17-May-85 18:35:13
Date: Fri 17 May 85 18:35:13-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #29
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri, 17 May 1985       Volume 2 : Number 29

                         Here is HP110 Kermit
              Omnet gives very silly criticism of KERMIT
                        C-Kermit 4C for 2.9BSD
                  Minor Kermit-11 Update On The Way
                    Printing Kermit Docs on X2700?
                          KERMIT for BBS's?

----------------------------------------------------------------------

Date: Fri, 17 May 85 14:30:34 mdt
From: [e-mail] (Dave Forslund)
Subject: Here is HP110 Kermit

Attached is the file MSXHP110.ASM which is the system-specific source for
MS-KERMIT running on the HP110 Portable.  It should be used in place of
MSXGEN.ASM in making the executable.  We have used this code for about 2
months.  The MSXGEN.ASM file from CU20B was modified by Chuck Aldrich here
at Los Alamos and allows the changing of baud rates and the selection of
the serial port or the internal modem.  However, we have not tested the
internal modem code.  The default setting is the serial port (Port 1) and
9600 baud.

The HP110 does not have built-in Basic, so the .BOO file bootstrapping
technique won't work.  But it does have a built-in terminal program which
can be used to capture a file.  The terminal program also has the XMODEM
protocol built in.  This can be used to capture binary files.

The way we brought the source over was to download it with MS-KERMIT on an
IBM-PC and move the file to the HP110 with the special IBM board that HP
makes which allows the two machines to communicate directly to each other's
disks.  We have also modified the Turbo-Pascal Kermit to run under MS-DOS
on the HP110.  If you have Turbo-Pascal, then you could use it to ship over
the MS-Kermit source, or executable.

David Forslund ([e-mail])

[Ed. - Thanks!  The source file has been placed in the Kermit distribution
area as KER:MSXHPX.ASM, and the above message (plus some parts that were
left out) in KER:MSXHPX.HLP.  Note the strange filename -- Unfortunately,
MSXHP110 is not distinguishable within six characters from MSXHP150, which
was already there.]

------------------------------

Date: 16 May 85 13:22 +0100
From: [e-mail]
Subject: Omnet gives very silly criticism of KERMIT

The following very silly and mean criticism of KERMIT was given in a
newsletter called "Sciencenet/news" published by Omnet, Inc., 70 Tonawanda
Street, Boston, MA 02124.

First a picture is given of a princess, frightened by an ugly frog, and
saying the words: "YYYYYUK! You're incompatible!".

Then comes the following text:

    Software of the Month: KERMIT The Incompatible

Trying to adjust to the fast-paced world of micro-computers instills its own
brand of future shock on everyone. What we long for is simplicity and
consistency, byt instead seem to get arbitrary rules and conventions.

Recently, a new group of users, who had been using the public comain
communications software KERMIT, signed on with SCIENCEnet.  They hoped to be
able to continue use this software package, which they had already mastered.
KERMIT is a perfectly good communications package, - providing that you
limit yourself to communicating with other systems which are also using
KERMIT!  And that's where the catch is.

Some communications software packages, KERMIT among them, only allow files
to be sent between computers using the same software.  The advantage is that
it allows for a certain amount of error checking to take place. This is
advantageous because it eliminates problems introduced by bad phone lines
over long distances. (Since calls to SCIENCEnet are local, this isn't likely
to be a problem.)

Many commercial communication packages offer the best of both worlds. For
instance, using a micro software package such as Crosstalk, micro-to-micro
file transfer with error checking over phone lines is possible. But, and
this is the critical point, with most commercially available communications
software packages, it is also possible hook up to SCIENCEnet to talk with
all other systems.

And herein lies the difference: with KERMIT, alas! the package only talks to
other KERMITs; it won't talk to SCIENCEnet -- or anybody else!

--- --- ---

My comment on the above: No file transfer protocol with error correction
facilities will be able to talk to any computer except a computer which
implements the same file transfer protocol.  The only possible way to do
something more would be to write a file transfer program which can switch
between several different protocols, and there is nothing in KERMIT which
forbids such implementations.  Because of its wide acceptance in the
scientific community, KERMIT is however certainly the protocol which has
largest changes of being possible to use between different makes of
computers.

The correct formulation of the above message in "Sciencenet/news" should
perhaps read like this "We have not implemented KERMIT on our computer,
therefore we think KERMIT is bad for you (and us)!".

[Ed. - Thanks for the kind words, Jacob.  The silliest part about the
article is that Kermit is a particular file transfer protocol -- it's not
commercial a product like Crosstalk that may embody several different
protocols -- so of course it's incompatible with other file transfer
protocols.  There are indeed many commercial and public domain programs that
provide Kermit alongside one or more other protocols, usually in conjunction
with a fancy terminal emulator and lots of menus.  In addition, many of the
Kermit programs in the Columbia distribution allow "raw file capture" for
getting files from systems that don't have Kermit; some allow "raw file
transmission" as well.  I wonder what system SCIENCEnet runs?  Kermit is
available at last count for about 120 machine/operating system combinations.]

------------------------------

From: Paul Graham <unr70!unrvax![e-mail]>
Date: 16 May 1985 1713-PDT (Thursday)
Subject: C-Kermit 4C for 2.9BSD

Ok, when I first sent in the report on the 2.9 problem I was in debug mode
and hadn't looked at ckutio.c from a global perspective.  I have since, and
understand the initrawq() stuff.  It is completely unecessary in 2.9 which
has the same tty-i/o as 4.2.  So unless someone else is looking at the
problem I will convert the 2.9 version to use 4.2 style i/o (FION etc.).
This still may require a change to the makefile (which I had no problems
with BTW).

PS - The proc table is the in-core table of process info, which can be
examined in V7 to find out how many characters are in the input queue
(yuck).

[Ed. - I guess this means we'll soon have a BSD29 conditional, which takes
the BSD4 path for tty i/o and the V7 path for everything else.]

------------------------------

Date: 17 MAY 85 09:40-EST
From:  [e-mail]
Subject: Minor Kermit-11 Update On The Way

A minor update of Kermit-11 will be sent to Columbia on 20-May.  It fixes a
problem in requesting 8bit quoting with parity, minor TSX+ problems again
(fixes thanks from Ned Rhodes), and a couple of new SET options to control
file creation superceding and determination of 'binary' files. As soon as I
put P/OS back on my pro and test it this weekend I will send it along. This
is the version that will be on all the SIG tapes at spring Decus.

Meanwhile, updates can be obtained as described earlier from my 11/785 via
either UOFT01 KERMSRV (bitnet) or the dialup procedure stated last week.

                                                        brian nelson

------------------------------

Date: Fri, 17 May 85 11:13:11 EDT
From: poole@NUSC-ADA
Subject: Printing Kermit Docs on Xerox 2700?

Does anyone know of or have public domain fonts for the XEROX 2700II laser
printer?  The Kermit docs  don't format properly with a 10 cpi font, which is
all we have.  We will be ordering more fonts form XEROX, but the internal
paperwork takes a couple of months.  Thanks for your time,
 Ken Poole
 401-841-2648.

[Ed. - Maybe this question should be sent to Laser-Lovers.  I thought that
the Scribe device drivers provided by Unilogic for any particular device
supported the minimal font set for that device and did not require you to
have any special fonts.  If the Kermit docs don't format properly with the
fonts you have, maybe your Scribe database is messed up -- wrong width
information, for instance.  By the way, at Columbia we print our Kermit
manuals and other Scribe MSS files on the Xerox 9700 in Univers10 font, on
the Imagen LBP-10 with CMR10, and on various less interesting devices --
lineprinters, Diablos, plain text for online doc files, etc -- with very
little trouble.  Of course, the fancier the device -- and the Scribe support
for it -- the better the results.  This brings up a related question: why do
we use Scribe, rather than, say, a public-domain formatter like TeX?  The
reason is simply that TeX can not produce plain text doc files for online
reading or for printing on ordinary terminals and printers.  Scribe is
widely available (implementations exist on DEC-10/20's, VAXes (UNIX and
VMS), IBM mainframes, etc), and Scribe-like formatters are also included
with various microcomputer word processing systems like Final Word, Perfect
Writer, etc.]

------------------------------

Date:     17-MAY-1985  14:58 EST
From:     [e-mail]
Subject:  KERMIT for BBS's?

Has anyone implemented KERMIT in an electronic BBS ? We would be interested in
obtaining a copy.  Here at IUPUI we have an BBS that is written in BASIC, and
runs on an IBM PC-XT and uses XMODEM.  Since we are giving KERMIT programs away
free we feel it would be nice if our BBS also allowed file transfers using
KERMIT.

Jim Griffin
Microcomputer Systems Group
IUPUI
799 W. Michigan  ET-1023
Indianapolis,  IN  46202

Incidently, we use KERMIT on all our mainframes and are very pleased with its
operation.

[Ed. - The only one I know about is FIDO, which supports Kermit, Modem7,
Xmodem, and some other protocols, and provides electronic mail via FIDONET,
using dialup between nodes at prescheduled times.  FIDONET mainly runs on
MS-DOS systems (like the DEC Rainbow, the IBM PC family, etc). The
FIDO-related files are available on ARPANET from SIMTEL20 via anonymous FTP
from the directory MICRO:<CPM.FIDO>; if you don't have FTP access to
ARPANET, I can't say how to get them, but you can mail to Douglas Good or
Scott Aschcraft, [e-mail] (FIDO SYSOPs) for more
information.]

------------------------------

End of Info-Kermit Digest
*************************
-------
27-May-85 19:35:57-EDT,27690;000000000001
Mail-From: SY.FDC created at 27-May-85 19:35:29
Date: Mon 27 May 85 19:35:29-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #30
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Mon, 27 May 1985       Volume 2 : Number 30

Departments:

  C-KERMIT VERSION 4C -
    More Changes to C-Kermit Version 4C
    File Sizes Reported by C-Kermit
    C-Kermit v4 to Apollo
    C-Kermit 4C Comments/Bugs
    C-Kermit on TRS-Xenix
    Kermit 4C Broken "Dial" Command for PC/IX 1.1
    C-Kermit 4C (16 May) Local-Remote Bug?
    Status of 4C on 2.9bsd
    Wart Mods
    C-Kermit for Eunice

  MISCELLANY -
    Lisp Machine KERMIT
    Kermit-11 BITnet Distribution: Correction
    IBM PC/AT Serial Port Compatibility
    AT Serial Port Compatibility
    IBM Asynch Adapter at 19.2Kb and Beyond
    Appeal to the Netherlands
    Kermit for IAS?
    IAS AND KERMIT
    Need Help with Kermit-TSO and 7171
    Converting New VM/CMS Kermit to MVS/TSO?
    Kermit for the NorthStar horizon and USR S-100 modem.
    Formatting documentation for Xerox 2700
    Commodore 64 Kermit Diskette Availability
    Kermit for Wang VS or OIS?
    Two Faces of Kermit

----------------------------------------------------------------------

Date: Mon 27 May 85 16:41:12-EDT
From: Frank da Cruz <[e-mail]>
Subject: More Changes to C-Kermit Version 4C

Quite a few minor changes have been made to the working (but not yet really
released) copy of version 4C of C-Kermit.  The major functional change is
that several of the 'set' parameters have been separated into 'set send'
and 'set receive' pairs to allow inbound and outbound packet parameters to
be set separately.  Some changes have been made to the command parsing
functions -- the major result is that the multiline local-mode 'get' command
now works as advertised, and in addition can be escaped from if you change
your mind in the middle of it.  Many minor bugs were fixed, some of which
are reported in the messages below.

Reportedly, problems still exist on ATT System III and System V based
systems in the areas of dialing, modem control, and so on.  A special "3bx"
makefile option was added for ATT 3B-series systems to accommodate their
special handling of uucp lock files.  Users of these System III/V systems
are encouraged to try out the new files and report problems (and fixes?), so
we can finally make version 4C "real".

The files are on CU20B, in <CKERMIT>CK*.*, as of 7:30pm EST 27 May 85.  Only
the Unix and VMS versions have been affected by the recent changes; a new
Macintosh release should be ready shortly.

------------------------------

Date: Monday, 20 May 1985 08:26:04-PDT
From: [e-mail]  (Dan Schullman)
Subject: File Sizes Reported by C-Kermit

When SENDING a file, the displayed size of the file being sent is wrong.
It appears that 32kb-->63.99kb, 96kb-->127.99kb, etc. are shown as zero.
And that 64kb-->95.99kb, 128kb-->159.99kb, etc. are shown as ( size mod 64kb ).
The actual size of the transferred file is fine.

[Ed. - The problem is that zchki() returns the size of the file as its value,
but zchki() is not declared to be long.  Also, it uses a regular int internally
to hold the size.  The files ckufio.c, ckvfio.c, ckcfns.c, and ckucmd.c have
been changed to use longs where necessary, so that file sizes will look right
on machines that have short ints.]

------------------------------

Date: Sun, 19 May 85 15:48:00 pdt
From: Neal Holtz <[e-mail]>
Subject: C-Kermit v4 to Apollo

I finally got around to doing what I said I would in early March - port
C-kermit to Apollo (Aegis) environment.  I waited for a newer version,
4.2(030).

As of this writing, I have only had it running for a few hours, so obviously
I have a lot of testing to do yet, but early results are very encouraging.
The standard Apollo C-library is very compatible with most Sys III (and some
4.2) -- the only exception is configuring serial lines and the console.  I
probably could have added about 100 lines to ckxunx.c and ckzunx.c, but I
thought they were getting unmanageable with all the IFDEF's, so I made
equivalent ckxaeg.x and ckzaeg.c mostly by ripping out most of the compile
time control.  There were couple of very trivial changes in a couple of
other places, but it went very smoothly.  When I have had a chance to do
more testing, I will forward a few comments.

Currently, the TOPS-20 style command parser is being used.  That doesn't fit
in with the Apollo environment as well as I would like (though it certainly
is usable).  Haven't decide whether I will retain it.  Will probably decide
to do whatever causes the least work and disruption (i.e. retain it).

Will gladly supply my changes to whoever wants them.

[Ed. - The modules other than ckufio (formerly ckzunx) and ckutio (formerly
ckxunx) that need modifications to accommodate Apollo Aegis now have them,
and the Apollo-specific modules will be announced when they arrive.]

------------------------------

Date: Wed, 22 May 85 09:55:41 -0100
From: hans@oslo-vax (Hans A. ]lien)
Subject: C-Kermit 4c Comments/Bugs

I had no trouble building v.4c on our vax 11/780 running 4.2bsd unix.
However, i have recognized a few problems / minor bugs.  I must apologize
for not being very familiar with neither unix nor c, so I have no definitive
fixes to offer.  But anyway:

1) It seems as some terminal output isn't printed to the terminal while the
file transfer is proceeding in the background.  As a result, the process
stops waiting for terminal output.

First of all, there are messages of the kind "Warning: ...", which are
printed on stderr. I would very much appreciate that such messages be output
similarly to messages like "filename => FILENAME ...", WHICH come through
nicely.

[Ed. - These messages only appear at the start of a transaction, and they
are generally important enough that you should want to see them -- like,
"Warning, problem getting exclusive access", meaning that somebody else
might be using the same communication line at the same time.  Once the
line is assigned to you, no further warning messages are issued.]

The other problem I have noticed, concerns indication of naks.  They are
indicated by "N", but unlike ".", they demand the process in the foreground
to proceed.  Once again, I think such output should be allowed to a job in
the background.  Hopefully, this works OK if -q (quiet) is set, but I
haven't tried.

[Ed. - I can't reproduce this, nor can I find any code that seems to exhibit
this behavior.]

2) I have recognized a minor error in the Tops20-like command parser, which
results in repetition of default items by pressing several <esc> characters.
Try for example CKermit>log trans<esc><esc><esc><esc><esc>.

[Ed. - It was an error, all right.  It's fixed now.  Thanks for spotting it.]

3) Regarding command line options, my opinion is that a "bye" option should
be included, in addition to, or if the number of options should not grow
further, instead of the "finish" (-f) option.  I think most people use such
an option to end a file transfer session, typically performed with a simple
list of commands making up a script.  Does anyone (dis)agree?

[Ed. - The major restriction on the number of command line options is that
the command line help message should fit on one screen.]

        [e-mail]
        Hans A. ]lien, Institutt for informatikk,
          University Of Oslo, Norway.

------------------------------

Date:  Tue, 21 May 85 16:04 MDT
From:  [e-mail]
Subject: C-Kermit on TRS-Xenix

I now have kermit 4C(044) running on TRS-Xenix, a Unix v7 system.
Both startup and file transfer are much slower than with kermit version 3.
The makefile parameters required are:

PROC=_proc
DIRECT=-DDIRECT
NPROC=_Nproc
BOOTFILE=/xenix

A fix was required in ckutio.c.

Robert Mark, USGS, Menlo Park, CA

[Ed. - Fix installed in ckutio.c, and the makefile (ckuker.mak) edited
accordingly.]

------------------------------

Date: Tue May 21 1985 14:11:11
From: Marco Papa <[e-mail]>
Subject: Kermit 4C broken "dial" command for PC/IX 1.1

I encountered the following problems with installing and running Kermit 4C
for PC/IX 1.1 on a PC/XT with Hayes compatible modem.

1. Makefile problem.

  PC/IX's "make" does not seem to like \'s to continue lines.
Taking out the \'s at the end of lines, and making one long line, fixes it.

[Ed. - A warning to this effect has been inserted in the .bwr file, but it's
funny we didn't here this one before, especially since a lot of development
was done on a PC/IX system.]

2. Dial feature broken.

  The "dial" command does not work any more.  Executing the following set of
commands:

> set line /dev/tty1
> set speed 1200
> set modem-dialer hayes
> dial 743-0000

will work up to the setting of the modem type.  The dial command ALWAYS
returns with the message:

"Sorry, can't hang up the line"

I have not looked up in ckdial.c yet, but I believe the message comes from
there.  I know that there is no problem with my modem switch settings,
since Kermit 4.2 runs just fine.  Also, since dial does not work, I cannot
test the script command.

[Ed. - This has been fixed.  There are still reportedly problems with DTR
during dialing on some systems.]

3. Lock file left around.

  This is related to the "dial" problem above.  When dial fails, the "exit"
command leaves the lock file around (/etc/locks/tty1 for example), so that
one has to manually delete it, before set line will work again.  The lock
file is correctly deleted on exit, when dial is not executed.

Connect, send and receive seem to work just fine.

[Ed. - The ttopen() code in ckutio has been reworked to be more careful
about leaving lock files around.]

Also, ckuus2.c makes the C optimizer run out of space under PC/IX.

Marco Papa
UUCP:  ...!sdcrdcf!uscvax!papa
CSNET: [e-mail]
ARPA:  [e-mail]

------------------------------

Date: Sat, 25 May 85 11:29:07 pdt
From: [e-mail] (David Ragozin)
Subject: C-Kermit 4C (16 May) local-remote bug?

Running C-kermit, 4C (16 May) on 4.2 BSD Unix.
Problem:
    Issue "set file type bin"
    Then  "send file" and on completion do "show para"
        mode now shows as "local" instead of "remote"

Now when I get mode back to remote by "set line", then do a send of a text
file, on return the mode is local.  Apparantly going into binary file mode
flips some flag which controls the mode setting on returns from at least the
send type transaction.

[Ed. - Oops - this bug was introduced into 4C (the 16 May version) and has
just been fixed.  It actually had nothing to do with binary mode.]

(By the way, I could find no way to "document" this via any of the log
functions, since the "session logging" only works for local mode logging
while this bug requires that I record what appears on my screen from a
remote kermit.)

[Ed. - Try "kermit | tee xxx" -- the transcript will go into file xx.  Or use
script on systems that have it.]

------------------------------

From: Paul Graham <unr70!unrvax![e-mail]>
Date: 23 May 1985 1218-PDT (Thursday)
Subject: Status of 4C on 2.9bsd

As I suspected in my heart of hearts the transition from the 7th Ed. is not
going to quite as simple as I might have liked.  Currently the 2.9 version
will not act as server or in the remote mode.  Nor will it receive files in
the local mode (it will get a file from a server).

If anybody has solved all of these problems please let me know.  Else
sometime next week it should percolate to the top of the stack, and I should
have some time for it once again.

Please drive carefully.

Paul Graham 702/784-6007
University of Nevada Reno
UUCP (seismo, ucbvax!menlo70)!unr70!unrvax!pjg ARPA unr70!unrvax!pjg@seismo

------------------------------

Date: Sat, 25 May 85 18:24:36 cdt
From: [e-mail] (Jim Knutson)
Subject: WART mods

The following are a couple of context diffs for getting wart running on an
MS-DOS machine with the CI-C86 C compiler.  The problems that were fixed
had to do with 1) not ignoring trailing text on #else and #endif 2) Stripping
comments within quotes and 3) not recognizing \f as a whitespace.

[Ed. - diffs omitted, changes installed in ckwart.c.]

------------------------------

Date:     Wed, 22 May 85 23:01 EST
From:     Larry Afrin <[e-mail]>
Subject:  C-Kermit for Eunice

I don't remember if I explained this in an earlier message, but Eunice 3.2 is a
hybrid of 4.1bsd and 4.2bsd (with a touch of Version 7 thrown in, from what I
can deduce from how the time-of-day functions work), that runs under VMS.

A new version of Eunice, version 4.0, is coming out "VERY soon", sort of in
conjunction with the brand new release of VMS 4.1.  Eunice 4.0 is reputedly
going to be a full 4.2bsd implementation under VMS.  Now, seeing as how Kermit
4C can be installed under VMS directly, and seeing as how Eunice 4.0 is
supposedly going to be 4.2bsd straight up and down the line, you may want to
defer from adding any Eunice-specific support into the next Kermit version,
which I understand from you will be version 4C.  You may especially want to
avoid using *my* mods since they're meant for Kermit 4.2, which I think you've
indicated is now obsolete, sort of.

                    -- Larry Afrin
                       Dept. of Computer Science
                       Clemson University

lbafrin@clemson                         if you're on CSNet
lbafrin.clemson@csnet-Relay             if you're on ARPANet

[Ed. - I agree with Larry -- Eunice support is probably not worth including.
This is very much the same situation as Amdahl UTS, whose new version is pure
system V, and whose old version is some kind of hybrid.  If anyone is desparate
for Larry's Eunice Kermit, they may want to contact Larry directly.]

------------------------------

Date:  Fri, 24 May 85 14:53 CDT
From:  "Mark L. Ahlstrom" <[e-mail]>
Subject:  Lisp Machine KERMIT

I now have the Lisp machine Kermit running "pretty well" on
Symbolics Lisp machines.  I should be shipping it back to George
Carrette at LMI in a couple of weeks to have him retest it on LMI Lisp
machines and incorporate some recent LMI changes.  Hopefully, the first
release to Columbia is within a couple months of being "real".

By the way, your information should be updated to show that the lmkermit
will be written in Zetalisp rather than Common Lisp.  The info that it
was Common Lisp evidently came from an earlier plan that George Carrette
had to develop the code on another machine.
  --Mark

------------------------------

Date: 21 MAY 85 10:46-EST
From:  [e-mail]
Subject: Kermit-11 BITnet Distribution: Correction

I just noticed that I said UOFT01 KERMSRV in my note about getting the
new Kermit-11. It should have been UOFT02 KERMSRV.  See Kermit Digests
numbers 2-21 and 2-26.

------------------------------

Date: 15 May 85 06:52:09 GMT
From: Pat Chewning <patch%nsc-pdc.uucp@brl>
To: Info-IBMPC@USC-ISIB
Subject: IBM PC/AT Serial Port Compatibility

I am having trouble with my AT receiving serial data at baud rates over
1200.  I suspect that it has something to do with the incompatibility of the
serial controller used on the AT versus the PC.  Here's the set-up:

    IBM AT
    AST ADVANTAGE! multifunction board that has the serial port.
        (Uses 16450 chip?)
    Kermit Software (Also tried-out a copy of Crosstalk with same results)
        [Both these software packages were written for PC]

Using the same physical RS232 line, I have no problem doing data transfers
at 9600 baud using a Compaq [IBM PC Clone].

The problem shows up at baud rates greater than 1200 (although occasionally
at 1200 baud as well).  The characters are not wrong, but the problem is
missing characters.  Transmitting characters works fine, its only on
receiving that I have a problem.

The manual that came with my serial card indicates that some incompatibility
exists between the serial controller chip used in the AT and the controller
chip used on the PC.  It suggests that some software written for the PC may
not operate properly on the AT.

Does anyone know what those differences are, and in particular, what
specific changes need to be made to Kermit [I have a source] so that it will
work on the AT?

                Pat Chewning

[Ed. - See below.]

------------------------------

Date: 16 May 1985 10:22:14 PDT
Subject: AT Serial Port Compatibility
From: Richard Gillmann <[e-mail]>

Sounds like you have the Professional Graphics display.  This has the
unfortunate effect of interfering with the serial ports at speeds over 1200
baud.

------------------------------

Date: Thu 16 May 85 13:57:53-EDT
From: Charlie C Kim <US.CCK@CU20B>
Subject: IBM Asynch Adapter at 19.2Kb and Beyond

Using an interrupt based system, as has been indicated, it is definitely
feasible to run the IBM serial card at speeds greater than 9600 baud.  (In
fact, you'll probably need an interrupt based system at any speeds above
1200 or so).  On an AT, I've been using Kermit, which is interrupt driven
for the serial IO, for file transfer to and as a remote terminal for a 4.2
Unix system (Vax 750 with DMF's--the DMF is a serial/parallel board for the
VAX which has a maximum speed ot 19.2KB on serial lines) at 19.2KB without
any problems.  I've also tried it at 56KB between two PC's (one AT, one
PC-1) and between a PC-AT and Macintosh without any problems.

I've also be able to use the COM_PKG/INT_PKG pair in the IBMPC library to
communicate from a PC-AT to the above mentioned VAX at 19.2KB; again
without any problems.

So, empirical evidence supports the results.  As as side note, I should
note that I've used communications packages which were incapable (on a
PC/XT) of going above 1200 baud without losing characters; I suppose these
were not interrupt driven.

Charie C. Kim
Columbia University
Center for Computing Activites

------------------------------

Date:     Thu, 23 May 85 14:26:27 BST
From:     [e-mail]
Subject:  Appeal to the Netherlands

To anyone in Holland (= The Netherlands):

     Is there anyone in the Netherlands running Kermit who could help
me by providing a mainframe Kermit for demonstration purposes?
This would be to demonstrate that a micro-Kermit actually works.
If so, please mail me soonest as "cjk @ ucl-cs", on either ARPA
or JANET.
                    Chris Kennington.

------------------------------

Date: 24 MAY 85 14:50-N
From: DEGROOT@HWALHW5
Subject: Kermit for IAS?

1.      Some users keep asking for a KERMIT version for the operating system
        IAS on the PDP11. I understand that IAS is an obsolete operating
        system. Previous KERMIT-versions for RSX could be generated for IAS.
        The current versions of PDP11 KERMIT give not any notice of IAS.
        Is there a KERMIT for IAS?

[Ed. - There is some hope that Kermit-11 will be adapted to IAS.  There is
at least one very large IAS site that has indicated some willingness to do
this, but there is no definite commitment or timetable -- see below.]

2.      The file CURRENT.DOC indicates version 3(124) for K10-KERMIT.
        The right version number for the DEC10-KERMIT should be 2(124).

[Ed. - Thanks for pointing out the mistake.]

                                        Kees de Groot   (DEGROOT@HWALHW5)
                                        Computer Centre
                                        Agricultural University
                                        Wageningen
                                        The Netherlands

------------------------------

Date: 24 MAY 85 09:30-EST
From:  [e-mail]
Subject: IAS AND KERMIT

I just got a call yesterday from the EPA  about  IAS  and  Kermit.  They
have  some  30  systems  running IAS version 3.1 and have volunteered to
port it to IAS. The main problem with IAS is that RMS-11  version  2  is
only  supported on IAS 3.2, which many sites seem to have decided not to
install. I expect that these  folks  at  the  EPA  will  have  Kermit-11
running  on  IAS  soon, so I would suggest that others interested in IAS
Kermit to wait a couple of weeks until I get more info on the progress.

------------------------------

Date: Fri 17 May 85 19:34:39-PDT
From: Wing Lee <WingLee%ECLD@ECLA>
Subject: Need Help with Kermit-TSO and 7171

I am experiencing a problem with the Series/1 version of TSO-KERMIT.  It
works fine with the Series/1, but here at USC we are replacing the Series/1
with an IBM 7171.  I am having problems trying to upload files through the
7171.  I am able to download files just fine, but when I upload, TSO-KERMIT
stops at the first bad packet.  I used the debug option on TSO-KERMIT and
when I looked at the debug file, it shows that TSO-KERMIT stops right after
a CHECKSUM error.  It appears that TSO-KERMIT is unable to notify the micro
KERMIT that it has received a bad packet and have the micro resend it, and
since the micro KERMIT hasn't received an acknoledement from TSO-KERMIT
telling it to that the last packet was good, a transmission lock up occurs.

I've tried everything I can think of to solve this problem, and would
appreciate any suggestions you can think of.

Thanks

Wing Lee
University Computing Services
University of Southern California

[Ed. - This is presumably the Version of TSO Kermit whose genealogy is
Columbia VM/CMS Kermit v 1.0 -> U of Chicago MVS/TSO support -> U of Toronto
Series/1 support.  Anyone else out there using it?  Also, see next message.]

------------------------------

Date: Mon 20 May 85 16:26:52-EDT
From: Frank da Cruz <[e-mail]>
Subject: Converting New VM/CMS Kermit to MVS/TSO?
To: Ron Rusnak <[e-mail]>

Hi Ron -- Do you think anybody at U of Chicago will be working on TSO Kermit
any time soon?  Ideally, I think it would be good if the new CMS release
(2.00, which has server mode, binary file transfer, CRC's, etc) could have
TSO support added to it in such a way that either TSO or CMS Kermit could be
built from it.  I don't know much about IBM assembler, but I would hope that
this would be possible using macros or conditional assembly for the system-
dependent parts.  This would simplify life a lot for both of us, not to mention
the hundreds of sites that are running TSO &/or CMS Kermit, allowing each
to benefit immediately from improvements in the system-independent areas.
What do you think?  - Frank

[Ed. - I never got a reply to this, but maybe someone else who might be
interested in TSO Kermit -- U. of Toronto, maybe? -- would be willing to take
on the task.]

------------------------------

Date: Sun 19 May 85 19:49:20-MDT
From: Jon Albers <[e-mail]>
Subject: Kermit for the NorthStar horizon and USR S-100 modem.
To: [e-mail], [e-mail], [e-mail]

I am looking for a version of Kermit that will work on a Northstar horizon
with either the second printer port, or better yet, the US Robotics S-100
internal modem.  If you have or know of such a beast, or can perhaps give
some help with writing the code to make Kermit work with an S-100 modem
board, please reply to me at the below addresses:


                        Jon Albers
                    ARPA: JALBERS@SIMTEL20
                    /..seismo!dolqci!irsdcp!albers
            UUCP: ---------<...seismo!dolqci!irsdcp!dcp1!albers
                    \..philabs!sbcs!bnl!bnl44!jalbers

------------------------------

Date: Sat 18 May 85 23:01:53-PDT
From: Bob Larson <BLARSON%ECLD@ECLA>
Subject: Formatting documentation for Xerox 2700

I had problems formatting the kermit documentation for our xerox 2700 also.
The verbatim portions of the manuals have lines to long to print at 10 cpi
with the default margins used for the 2700.  By making sure that all verbatim
areas were printed at 12cpi, and modifying "italics" to do underlining
(the only italic font we have is 10cpi)  I was able to format the manual
so only a few characters where lost.

It might work if formatted with a one character left margin.

Hope this helps.

Bob Larson <[e-mail]>

------------------------------

Date: Tue, 21 May 85 03:02:17 edt
From: Robert Scott Lenoil <[e-mail]>
Subject: Commodore 64 Kermit Diskette Availability

     Enclosed is the text of my message to USENET, re: my ability to
supply Commodore 64 Kermit diskettes this summer.  Please update the
00readme.doc file and the information that you give out over the
phone to reflect this new status.  Note that my work phone number this
summer will be [phone], effective June 1.

    Subject: Kermit diskette availability
    Newsgroups: net.micro.cbm
    Distribution: net.micro.cbm

As you may know, I have been providing copies of Commodore 64 Kermit for
$7.00 as a service for those who couldn't otherwise obtain the program.
However, I will be leaving shortly for the summer and have decided not to
take my Commodore with me.  Therefore, I do not anticipate being able to
fulfill any orders until my return August 25th.  There is always a
possibility that I find somebody at work with a 64, so if you do need a
diskette, send me netmail, and I'll let you know if I can accommodate
you. (Send to this address - my mail will forward).

Robert Lenoil
[e-mail]
[e-mail]
[e-mail]

------------------------------

Date: Friday, 17 May 1985  14:26-MDT
From: ritcv!husky!pma%rochester.uucp@Seismo
Subject: Kermit for Wang VS or OIS?

Does any one know of a "kermit" for a Wang(tm) VS or OIS system ?
Please respond to me by email.

        Thanks,
         Philip Abram, Eastman Kodak Co., Rochester, N.Y.

PATH:
     {allegra,seismo}!rochester!ritcv!-------\
                           >------husky!pma
    {eagle,astrovax,netword}!sun!sunrise!----/

------------------------------

From: tektronix!stever@Berkeley
Date: Tuesday, 21 May 85 13:01:22 PDT
Subject: Two Faces of Kermit

Kermit is both a protocol and a communications program.  One should not
ridicule people for their confusion about this point.

All communications programs whether commercial or not should be able to do
*raw* (i.e. ASCII) data file transfers using system level commands of the
computer they are talking to, as well as supporting one or more file transfer
protocals.

Kermit should not be an exception.  This feature should be a part of the Kermit
protocal definition.  Kermit implementations should not be included in the
distribution system of Kermit software unless they have the *raw* file transfer
function.

steven d. rogers
...ucbvax!tektronix!stever

[Ed. - In principle, I agree.  In practice, Kermit programs are donated by
individuals who are free to implement whatever features they like, so long as
the minimum protocol features are present.  We're not going to turn down
desparately needed contributions (we know when a Kermit implementation is
desparately needed when the number of phone calls asking about it exceeds
a hundred per day) because they lack a particular optional feature.]

------------------------------

End of Info-Kermit Digest
*************************
-------
30-May-85 17:29:15-EDT,11900;000000000001
Mail-From: SY.FDC created at 30-May-85 17:28:02
Date: Thu 30 May 85 17:28:02-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #31
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Thu, 30 May 1985       Volume 2 : Number 31

Departments:

  C-KERMIT 4C -
    C-Kermit Parity
    More Problems on Kermit 4C?
    System V C-Kermit 4C Works
    System V 4C C-Kermit Racal-Vadic Control Fixed!
    C-kermit on 4.1bsd

  MISCELLANY -
    Kermit for Atari ST
    TRS-80 III Kermit Users Wanted
    PC/AT Serial Adaptor problems
    CP4KERMIT on Superbrain

----------------------------------------------------------------------

From: <hplabs!amdahl!drivax!alan@Berkeley>
Date: Tue, 28 May 85 22:48:33 PDT
Subject: C-Kermit Parity

I hope that this is the right place to send this. I am using C-Kermit 4.2,
and I noticed that it does not set the parity on the com. line when a set
parity even/odd/mark/space command is issued.  This is a problem for me
because our VAX (System V) defaults differently than the other machines here
(iNTEL 310 w/System V, VME/10 w/System V).

Thanks,
Alan Fargusson.
DIGITAL RESEARCH INC.
60 GARDEN COURT
BOX DRI
MONTEREY, CA. 93942

[Ed. - C-Kermit certainly makes every attempt to transmit the desired
parity.  The question is whether the System V implementation sets the tty up
in an appropriate mode to allow the C-Kermit software to do this.  Some
changes have been made in this area since release 4.2 -- you may find that
release 4C does it right.  I hope so.]

------------------------------

Date: Mon May 27 1985 10:57:27
From: Marco Papa <[e-mail]>
Subject: More Problems on Kermit 4C?

I am sorry to say, but the problem reported by Yigal Arens on Kermit 4C
about timeouts on large files under System V is present also in the Berkeley
version.  I run the following test: I tried to transfer the new ckuker.mss
(34 TOPS-20 Pages) from ECLC (TOPS-20) to uscvax (Berkeley-UNIX 4.2).
Everything went well until after about 160-200 dots(.) were on the screen.
Then suddenly a sequence of T%T%T%T%T%T%T% started coming. Only way to get
out was to abort the batch transfer.  The UNIX kermit was saying it had
timed out, and the TOPS-20 kermit was back to the KERMIT-20 prompt. I tried
this twice with the same result.  Both machines were totally unloaded (I was
the ONLY user on TOPS-20 and there were 5 other users on the VAX).  This
seems to be a bug of the new 4C version of Kermit, not present in the
preceding 4.2 version (which I used to transfer all 4C files between the
above mentioned machines).

------------------------------

Date: Tue 28 May 85 13:19:16-EDT
From: Frank da Cruz <[e-mail]>
Subject: Re: More Problems on Kermit 4C?
To: [e-mail]

Were you running the very latest release, 4C(049), circa 8:00pm EST Monday?
I just used it to transfer ckuker.mss from the DEC-20 to a 4.2bsd system and
didn't get a single timeout.  Then I did it again.  Then, just to make sure
this wasn't a fluke, I sent my mail.txt file -- 205 DEC-20 pages, or 514453
characters, or 502.4K, or half a megabyte (that's about a week's worth of
mail for me).  There were 70 jobs on the 2060, the 15 minute load average
was about 6.00; there were 8 users on the VAX-11/750, load below 1.0.  The
two systems are connected by a direct line between the DH11 on the DEC-20
and a DMF32 on the VAX, running at 9600 baud.  The transfer took about 38
minutes; there were 6 timeouts -- one burst of three (%T%T%T), one of two,
and one single timeout.

I don't think a file this big could be transferred if there were some
intrinsic flaw in the program.  Maybe you're running a slightly older
version, and were hit by a bug that has since been fixed.  More likely, it's
just something in 4.2bsd.  We have seen terminals hang quite often on our
4.2bsd systems (the longer the system is up, the more it happens), and
recently installed a patch (from Usenix?) to the DMF driver that may have
alleviated the situation somewhat.

------------------------------

Date: Mon, 27 May 85 21:46:43 pdt
From: [e-mail] (Dave Tweten)
Subject: System V C-Kermit 4C Works

Good news!  The latest version has cleared up the problem with remote
commands for System V C-Kermit.  I tested them all and they now all
work.  Unfortunately, the dialer problems are still there for System V
and Racal-Vadic modems, but progress is being made!

------------------------------

Date: Tue, 28 May 85 15:49:27 pdt
From: [e-mail] (Dave Tweten)
To: [e-mail]
Subject: System V 4C C-Kermit Racal-Vadic Control Fixed!

I have found a fix for the System V Racal-Vadic modem problem.  The problem
was that tthang was dropping DTR for the modem AND LEAVING IT LOW.  After I
examined the code for ttopen, tthang, and ttpkt, I concluded that if ttopen
needed the "close(open( . . ." magic, tthang probably did too.  The magic is
there, but it is surrounded by "#ifdef PCIX".  I removed the "#ifdef PCIX",
and the problem went away!

[Ed. - Good news!  Change installed.]

By the way, while playing with C-Kermit 4C, I noticed that the bsd version
is compiled without optimization.  I tried compiling it with optimization,
and it seems to work well, while generating a somewhat smaller executible
file.  Why no "-O" for bsd?

[Ed. - You're free to add -O if you want; I'd rather distribute without it
so there's one less thing to blame when things break.]

------------------------------

Date:           Tue, 28 May 85 10:06:38 PDT
From:           Dave Flamm <[e-mail]>
Subject:        C-kermit on 4.1bsd

The latest version of C-kermit still won't "make" successfully on our 4.1
bsd.  It still looks for "time.h" without success.  It would seem that
whatever means is used for detecting 4.1 versus 4.2 is not foolproof?

> I think I see the problem.  It's in ckutio.c...  all the nested #ifndefs
> around "#include <sys/time.h>" need an additional #ifndef BSD41...#endif.
> Try that and let me know if everything else is ok for 4.1bsd.  Thanks!

(later...)

That seems to have done it.  Thank you.

Dave

[Ed. - It looks now as if 4C pretty much works as advertised on all systems
except 2.9bsd.  The next issue of Info-Kermit will announce it "for real".]

------------------------------

Date: Tue 28 May 85 13:52:27-EDT
From: Frank da Cruz <[e-mail]>
Subject: Kermit for Atari ST
To: [e-mail]

I got a call from someone in Canada who said that Atari is distributing what
appears to be the old Unix Kermit (command line operation only) in the
developer kit for the new ST computer system, source not included.  The caller
wanted to know why it wouldn't transfer binary files in "image mode" -- it
seems it stops sending as soon as it hits a control-Z in the file.  Sounds
like the file system must be in the CP/M style.  It's nice that Atari is
promulgating Kermit, but if they also included the source then maybe some of
their developers could fix the bugs, or even adapt the new C-Kermit...

------------------------------

Date: Tue 28 May 85 13:55:52-EDT
From: Frank da Cruz <[e-mail]>
Subject: TRS-80 III Kermit Users Wanted

John A Ball of the Northeast Radio Observatory Corporation, Haystack
Observatory, Westford MA 01866, 617-692-4764, would like to make contact
with users of TRS-80 Model III TRSDOS Kermit.

------------------------------

Date: Tue, 28 May 85 09:35:36 PDT
From: [e-mail]
To: [e-mail],    [e-mail]
Subject: PC/AT Serial Adaptor problems

There is a lot of misinformation going around about the serial ports on a
PC/AT and their compatibility with the PC. The 16450 chip (and 8250A chip
from National Semiconductor) has quite a few bug fixes compared to the 8250
and 8250B. One of those bug fixes breaks many interrupt-driven PC
communications programs.  The typical result is missing characters at speeds
of 1200 bps and above.

Now, the bug is that the 8250 pulses (low) its interrupt line when the
condition causing the interrupt is satisified even if there is another
interrupt condition pending. NatSemi thought that action was incorrect so
they fixed it in the 8250A and 16450 - for those chips the interrupt line
will stay high until ALL pending enabled interrupts are satisfied.

The problem this causes with PC communications programs is that many of them
assume the interrupt handler will get entered for every interrupt
individually. This happened because the pulsing interrupt line would make
the PC's 8259 interrupt controller think there was a new interrupt pending,
so it would present it to the CPU chip immediately upon receiving the EOI
(end of interrupt) for the previous interrupt. With the interrupt line not
pulsing on the new chips, the 8259 doesn't think there is a new interrupt
pending even though the 16450's interrupt line remains high. That is because
the 8259 is in edge-triggered mode.

Now, the solution is to poll either the 8250 status register or the
interrupt identification register before exiting from the interrupt handler.
For instance, the following logic works for the receiver data ready
interrupt:

    Interrupt handler:
        save whatever is necessary
        while status register says data ready
           process data
        whend
        send EOI to 8259
        restore whatever was saved
        exit

You might now be saying "But I only enable received data interrupts so there
can never be more than one interrupt pending at a time so I don't need to
worry about this." Well, I thought so too, but the situation is that if the
next received character is ready to be transferred to the receiver buffer
register by the time the CPU reads the receiver buffer register, then the
receiver data ready interrupt will remain pending. Hence you need logic like
the above.  (I've tried this and it does solve the problem.)

There are other bug fixes in the 8250A/16450 which can cause troubles, but
they are much more obscure and much less likely.  They have to do with
transmitter interrupts but I can't recall the details right now and I don't
have my copy of the NatSemi errata sheet handy to refer to.

I hope this helps all you people out there. For those who seem to think all
these problems are caused by the IBM Professional Graphics Controller,
please note that while it may cause some, it is not the ONLY cause, as
should be evident from the above description.

------------------------------

Date:  29 May 1985 08:03:15 IST (GMT+2)
To:  [e-mail]
From: [e-mail]
Subject: CP4KERMIT on Superbrain

Hello Frank !

I was delighted with Version 4 which together with Version 2 under CMS makes
the use of KERMIT even more efficient than it was before.  Also I was very
happy to find a version tuned to my Lobo MAX-80, although I had been happy
before with the CPM-Plus version.  The availability of server mode is great,
and I take this occasion to thank you again.

The version running on Superbrain does not generate a break.  I did not look
into the source code to see why, but I thought that the following listing of
a tiny dumb terminal program I have written here may help clear out the
problem, IF there is a problem (perhaps I missed something).

                                            Regards \ Jacques

[Ed. - Jacques' code forwarded to Charles Carvalho for inclusion in the next
release of CP/M-80 Kermit.  No estimate when it will appear.]

------------------------------

End of Info-Kermit Digest
*************************
-------
30-May-85 19:29:35-EDT,5278;000000000001
Mail-From: SY.FDC created at 30-May-85 19:29:10
Date: Thu 30 May 85 19:29:10-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #32
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Thu, 30 May 1985       Volume 2 : Number 32

         C-Kermit Version 4C for Unix, VMS, and the Macintosh

----------------------------------------------------------------------

This is to announce version 4C of C-Kermit for Unix, the Apple Macintosh,
and VAX/VMS.  C-Kermit is a version of Kermit written modularly in C,
implementing the entire Kermit file transfer protocol (except for attribute
packets), designed for modularity and transportability.

This version of Kermit has been in "field test" for about a month, and
is being released at this time because most of the major goals for it have
been met, namely:

. Most known bugs in release 4.2 fixed
. Support for new systems added and tested
. A few new functions incorporated

At this point, C-Kermit should be considered a fairly stable base upon which
to add support for new systems -- the interface between the system-dependent
and portable modules seems to have settled down -- and to add new features.

A few highlights:

Systems Supported:
  . Berkeley Unix 4.1 and 4.2 (but not yet 2.9)
  . AT&T Unix System III and derivatives (Xenix/286, PC/IX, etc)
  . AT&T Unix System V and derivatives
  . Bell Unix Version 7
  . DEC Pro-350 with Venix Version 1
  . NCR Tower 1632, OS 1.02
  . VAX/VMS
  . Apple Macintosh

New features since version 4.2, common to all implementations:
  . Many features redesigned to promote portability.
  . Compile-time options to eliminate debugging and logging code to reduce
    size and boost performance.
  . Packet parameters separately settable for inbound & outbound packets.
  . Protocol operation improved here & there, many bugs fixed.

New features for Unix implementation (and VMS):
  . Command line continuation
  . Support for additional modem-dialers
  . Improved performance for Pro/Venix
  . Better (but still not perfect) determination of local vs remote mode
    in 'set line'
  . User's preferred shell is used for "!" commands, rather than always sh.
(A complete list of Unix/VMS updates is in CKUKER.UPD.)

New Features (since 0.7) for Macintosh:
  . A key redefinition package is now provided.
  . I/O errors, such as disk full or write protected, now handled better.
  . Separate boxes for inbound & outbound packet parameters in protocol
    settings dialog.
(A complete list of Macintosh updates is in CKMKER.UPD.)

The Macintosh implementation is built using the Stanford University Medical
Center's SUMACC cross development system, which runs on VAX computers under
Unix (or VMS with Eunice).  MacKermit fits on a standard 128K Mac, but just
barely.  The key configurator is a separate program, because this additional
functionality added to Kermit itself would not fit into a 128K Mac.  The memory
restriction is a problem only because the SUMACC system cannot produce
swappable segments.  If someone wants to take the trouble to translate the
Macintosh-specific modules to one of the native Macintosh C development systems
that supports segment loading, then additional functionality can be added
without worrying about exceeding memory.  (If you want to volunteer to do this,
please contact us first!)

The VAX/VMS implementation is more an exercise in portability than a real
Kermit implementation.  It mostly works, but does not possess the intimate
knowledge of the VMS environment that the Stevens Institute of Technology
Bliss language implementation has.  Still, it may be useful to sites that
do not have a Bliss compiler but do have the VAX-11 C compiler.

Documentation includes a Unix Kermit manual (CKUKER.DOC, Scribe source
CKUKER.MSS), a Macintosh Kermit manual (CKMKER.DOC,.MSS), various help files
(CK*.HLP), program update histories (CK*.UPD), and "beware" files (CK*.BWR).
The Unix and Macintosh manuals are new chapters for the Kermit User Guide,
but the Guide itself has not yet been reissued to include these chapters;
a new revision of the manual will appear after MS-DOS Kermit 2.28 is announced.

The files are in KER:CK*.*, available from host CU20B via anonymous FTP
on the Internet.  Within a few days, they will also be available from BITnet
via KERMSRV at CUVMA.  In addition, Macintosh Kermit diskettes will be sent
out to selected sites (Apple University Consortium schools and a few others;
our capacity to reproduce diskettes is limited, so we can't do mass
mailings).  And of course, the new files will be included henceforth on our
Kermit distribution tapes.

The files that had been in <CKERMIT> for testing purposes have been removed.
Thanks to all the folks on the network who participated in the test and helped
to work out the bugs, particularly Dave Tweten (AMES-NAS), Marco Papa (USC),
Dan Schullman (DEC), Lawrence Afrin (Clemson U), and many others too numerous
to mention.

Please report any problems to Info-Kermit@CU20B.

------------------------------

End of Info-Kermit Digest
*************************
-------
 7-Jun-85 15:42:40-EDT,17134;000000000001
Mail-From: SY.FDC created at  7-Jun-85 15:41:57
Date: Fri 7 Jun 85 15:41:57-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #33
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri,  7 Jun 1985       Volume 2 : Number 33

Departments:

  ANNOUNCEMENTS -
    Kermit Distribution Reorganized
    Kermit for Perkin-Elmer OS/32
    Corrections to Burroughs 6800 Kermit

  C-KERMIT 4C -
    Problem with Remote Commands to C-Kermit Server in Binary Mode
    Problem with C-Kermit for Version 7 on PDP-11

  MISCELLANY -
    FTP'ing from CU20B
    Formfeeds, tabs, etc in C programs
    DEC-20 Kermit in Local Mode
    CPM-86 Kermit Dies after 64K
    Need Kermit for NCR WS-300
    Kermit for Cromemco?

----------------------------------------------------------------------

Date: Fri 7 Jun 85 15:18:29-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Kermit Distribution Reorganized

As contributions of Kermit programs continue to arrive, the Kermit
distribution area grows larger and larger.  This week, the collection finally
grew so large that it would not fit on a 1600bpi labeled tape.  The past
several days have been spent reorganizing the entire Kermit distribution
operation.

The biggest change is that there are now two major Kermit distribution areas,
which correspond to two Kermit distribution tapes (Tape A and Tape B).
Area/Tape B contains all the mainframe and minicomputer ("host")
implementations; Area/Tape A contains everything else -- the microcomputer
(PC, workstation) implementations, the manuals, and miscellany.  Splitting up
the files this way allows room for a good amount of growth, and also lets
several versions (notably the U of Toronto Pascal Kermits for RT-11 and
VAX/VMS) be resurrected from the "Kermit-Extra" area.

Even though the files have been split into two directories, they still all
have (and must have) UNIQUE PREFIXES.  No files with the same prefix will
appear in more than one directory (except the new AA files, about which see
below).

Many files have been renamed in a more sensible way.  Previously, all the
"bureaucratic" files like VERSIONS.DOC, 00README.TXT, etc, were mixed in with
all the other files.  Now (in addition to being rewritten), they have new
names, all starting with AA.  In fact, all filenames now start with a letter,
since it turns out that some systems require that.

Old             New          What

(none)          AAAREAD.ME   Explains what all the AA files are.
00README.TXT    AATAPE.HLP   Talks about tapes (replaces ANSITAPE, OSSLTAPE)
(none)          AANETW.HLP   Instructions for getting Kermit via network
00README.TXT    AAFILES.HLP  Explains what the Kermit files are
CURRENT.DOC     AAVNEW.HLP   List of current versions, chronological
VERSIONS.DOC    AAVSYS.HLP   List of current versions, alphabetical by system
(none)          AAWAIT.HLP   List of versions we're waiting for
FLYER.DOC       AAXFLY.DOC   Flyer (now also includes order form)
COMMER.DOC      AAXCOM.DOC   Commercial policy, only the name has been changed
KLTR.TEX        AAKLTR.TEX   Cover letter, rewritten

The files that used to be VERSIONS.DOC and CURRENT.DOC been combined into
AAVERS.HLP.  This is a list of versions, one on each line, showing the
following information:

Prefix,                 Operating  Program   Program  Released
 Tape  Machine          System     Language  Version  yy/mm/dd  Contributor

for example:

CMS B  IBM 370 Series   VM/CMS     Assembler    2.01  85/05/20  Columbia U

Whenever a new version is installed, this file is updated and then sorted
several different ways to produce the following files:

AAVNEW.HLP -- Listed in reverse chronological order of release date
AAVOPS.HLP -- Listed alphabetically by operating system only
AAVPFX.HLP -- Listed alphabetically by prefix, regardless of tape
AAVSYS.HLP -- Listed alphabetically by machine and operating system
AAVTAP.HLP -- Listed by tape (A or B), then alphabetically by file prefix

The AA*.* files will appear in both Kermit distribution areas/tapes.  A glance
at the appropriate file will make it easy to answer questions like "Is there a
Kermit for xxx?", or "Has there been a new release of Kermit for xxx since
yyy?", or "What is the prefix for zzz Kermit?", or "What tape is such-and-such
a Kermit on?"

Some Kermit program files were renamed:

    Old             New

  20KERMIT        K20MIT (needed to start with a letter)
  170KERMIT       CDCKER    "
  800KER          LUXKER    "
  86KERMIT        C86KER    "
  CMSKERMIT       CMSKER (so Scribe could deal with the .MSS better)

Those who use the Internet, CCnet, or BITnet to get Kermit files from Columbia
should read KER:AANETW.HLP for details about network access.  The BITnet area
(KERMSRV@CUVMA) is not yet reorganized -- that will take another week or two.
Those who use FTP or NFT to get files from CU20B should notice no difference
in the procedure, since the "logical name" KER: has been redefined to include
the new area in its search path; the fact that no prefix (except AA) appears
in more than one area should allow network file transfer to work as before,
except when you try to get ALL the Kermit files (would anybody really do
that?) -- if you tried to "MULTIPLE GET KER:*.*", you would wind up with only
the files from area A.  If you need to refer to the B area explicitly, its
logical name is K2:, as in "MULTIPLE GET K2:*.*".

And a minor complication -- Macintosh Kermit is part of the CK*.* files, which
are on Tape B.  But since the Mac is a micro, people will be upset if they
order the "micros" tape (A) and there's no Mac Kermit on it.  So just the .HQX
files for CKMKER and CKMKEY have copies KER:, along with the CKMKER.DOC file.
However...  since these files were also in K2:, their names have to be
something that doesn't start with CK; otherwise, people who tried to FTP CK*.*
would only get those three files and nothing else (because DEC-20 logical names
don't step).  So they are called KER:MCKER and MCKEY...

------------------------------

Date: Mon 3 Jun 85 15:58:29-EDT
From: Frank da Cruz <[e-mail]>
Subject: Kermit for Perkin-Elmer OS/32

From Paul Mamelka, Genetics Dept, Southwest Foundation for Biomedial Research,
San Antonio, Texas:

[Here is] "Kermit-PE" for the Perkin-Elmer 3200 series computer under OS/32
operating system.  We've been using the program for the past 3-4 months to
transfer data files between our various micros and a PE-3210, with good
success.  It's also currently in distribution through the Perkin-Elmer
INTERCHANGE library, and we've had no reports of any serious problems yet.

As noted in the .DOC file, revision level 7.2.1, or higher, of OS/32 is
required to run Kermit-PE successfully, and any difficulties people have
with it will probably be related to the OS level they're using, or to some
special customization they've done to OS/32's BIOC device driver.  Questions
relating to this might best be directed to:

    Ron Stordahl
    c/o INTERCHANGE Library
    Perkin-Elmer Data Systems
    2 Crescent Place
    Oceanport, NJ  07757

Ron is fairly knowledgeable on the subject of BIOC, having implemented some
of the "unofficial" upgrades to the driver which let Kermit-PE run much more
efficiently under OS/32.  He's distributing these upgrades through the
INTERCHANGE Library, along with Kermit-PE.  I'll also be happy to answer
whatever questions I can from P.E. users who receive Kermit through your
channels.

                Paul Mamelka
                512-674-1410 x353

------------------------------

Date: Mon 3 Jun 85 16:00:23-EDT
From: Frank da Cruz <[e-mail]>
Subject: Corrections to Burroughs 6800 Kermit

The first release of Burroughs 6800 Kermit that was released 15 Feb 1985 had
a few bad lines.  The following changes are necessary to the original
version; the version being distributed currently (KER:B68KERMIT.ALG, as of 3
Jun 85) incorporates them:

1) Delete the three lines containing the following sequence numbers:
    12010600, 12012900, 12013000

2) Add the following lines between those numbered 12099000 and 13000000:

      END                                                          12099200
    UNTIL  RM:=*-CTS  = 0                                          12099400
  END   D E B U G W R I T E ;                                      12099600

This should allow a clean compile of Kermit.

    Randy McLaughlin
    MetroII
    360 Colborne St
    St Paul, MN 55102
    [phone]

------------------------------

Date:     Tue, 4 Jun 85 08:46:49 PDT
From:     [e-mail]
Subject:  Problem with Remote Commands to C-Kermit Server in Binary Mode

We have set up a PC/AT running Xenix as a file server using C Kermit server
mode.  Users on our LAN can login and retrieve public domain software , etc.  I
have set kermit server up using the switches "iwx" so binary files can be
xferred.  The problem I now have is since no LF to CR LF conversion is done,
when PC-DOS machines connect and issues commands to the server ( like remote
help, etc. ) they get output with no CRs and hence get a jumbled display.  Any
ideas on how to work around this?
Thanks..
Richard Fagen
Caltech Computing Support Services
rich@hamlet

[Ed. - Unfortunately, you can't have it both ways.  C-Kermit could be changed
to always insert CR's when responding to remote commands (temporarily turn off
the "binary" flag), but unfortunately, it's impossible for the program to know
WHY the user put it in binary mode.  It may be that she wants to run a program
that sends binary data to the screen for cursor control or even graphics.  If
you're sure your users will never do that, then you can add a couple lines of
code to save and turn off the binary flag before doing a remote command, and
restore it when done.]

------------------------------

Date: 5 Jun 1985 15:21-PDT
Subject: Problem with C-Kermit for Version 7 on PDP-11
From: Geoffrey C. Mulligan (USAFA) <GEOFFM@SRI-CSL>

I compiled the 4C version of c-kermit under my v7 system on an 11/70 and when I
tried to run it I got a program too big error.  Can anyone help?

        geoff

[Ed. - The Pro/Venix version runs on what amounts to an 11/23 with no i&d
space with no problem, but it uses the "core-mapping" feature provided by the
Venix compiler and linker, which may or may not be available under V7 on the
PDP-11.  If not, then you'll probably have to resort to overlays.]

------------------------------

Date: Sat, 1 Jun 85 00:32:00 PDT
From: Dave Flamm <[e-mail]>
Subject: FTP'ing from CU20B

I have a question regarding my ftp'ing from cu20b on the arpanet: I would
like to use "mget" to save effort, but it seems that I need a password to
change directories to <KERMIT>.  Otherwise the filenames prefixed with
"<KERMIT>" are what get written to my directory, and these are so long that
the ends get truncated.  The result is that the files overwrite each other.

I'd appreciate any advice in this regard.

Thanks,
Dave

[Ed. - You can't CD to a DEC-20 directory when logged in as ANONYMOUS through
FTP -- CD means something different to a DEC-20 than it does to UNIX (on a
DEC-20 CD, or "connect", gives you ownership rights).  I'm having our network
gurus look into making FTP send only NAME.TYPE, rather than
DEVICE:<DIRECTORY>NAME.TYPE.N;P775252;AFOO etc etc.  Does anyone know any
reason why the FTP server should send the fully qualified name?  Of what
possible use could it be to a foreign system?]

------------------------------

Date: Fri 31 May 85 14:30:07-PDT
From: Bob Larson <BLARSON%ECLD@ECLA>
Subject: Formfeeds, tabs, etc in C programs

One of the unportabilities of C-kermit is formfeeds and tabs in the source
code.  They aren't hard to remove, but it can be slightly painful if such
a utility does not exist on the machine of interest.  Here is a short program
to expand tabs, replace formfeeds with newlines, and remove line continuation
from C programs.  (The line continuation is removed due to a documented lack
in Microwares Os9 C compiler, and should not be needed for other systems.)
It's not fancy, but it works.  Input is from standard input, and output is
to standard output.  (Please make sure not to convert spaces to tabs if you
make this program available.)

Bob Larson  <[e-mail]>

/* dpp.c by Robert A. Larson */

/* dumb pre processor */

/* designed to convert C programs to a more usable format for Os9.
   Microware C (6809) accepts tabs and formfeeds, but they make the
   file hard to edit.  Microware C does not accept macro or string
   continuation.
*/

/* Expands tabs to spaces (tab=1 to 8 spaces, same as dec terminals)
   Replaces FormFeeds with Newlines
   Removes Backslash Newline sequences  (Macro or string continuation)
*/

#include <stdio.h>

main(){
  int c;    /* c is the character being processed */
  int p=0;  /* p is the count of the number of characters in the current line */
  while((c=getchar())!=EOF){
    switch(c){
      case('\\'):
        if((c=getchar())!='\n'){
          putchar('\\');
          ungetc(c,stdin);
          ++p;
        }
        break;
      case('\n'):
      case('\f'):
        putchar('\n');
        p=0;
        break;
      case('\t'):
        do{
          putchar(' ');
        } while(++p&7);
        break;
      default:
        putchar(c);
        ++p;
    }
  }
}

------------------------------

Date: 06/02/85 22:12:56 EDT
From: TS0013@OHSTVMA
Subject: 20KERMIT in Local Mode

I am running TOPS-20 Kermit version 4.2(254)-1 in local mode talking to a
VM/CMS system.  When I connect to the other host (VM) and after that host
sends a XOFF but before it sends a XON, I cannot seem to transmit a BREAK to
it using ^\B.  This works fine when VM is reading input, but when VM is
doing output, it sends an XOFF to hold back input data.  BREAK should not be
among that held back.  Is this problem in Kermit or in our system, which is
version 5.3(5721)-5, front end version unknown.  This problem is NOT
experienced with MS-DOS/IBM-PC Kermit.
                                  ...Phil Howard

[Ed. - Right, Kermit-20 should clear any XOFF'd condition when the user
tells it to send a BREAK.  This will be in the next release.]

------------------------------

Date:     Mon, 3 Jun 85 17:36:46 CDT
From:     Gregg Wonderly <[e-mail]>
Subject:  CPM-86 Kermit Dies after 64K

While trying to transfer a rather LARGE file from our VAX to a rainbow with
a hard disk, we keep getting an abort with a message saying that the disk
directory space is full.  There is over 2 Meg free when this message is spit
out.  A STAT of the file reveals that the file is 64Kbyte long.  Could this
be the evil 64K segment problem that the Intel chip is so widly known for???

Gregg Wonderly
Department of Computing and Information Sciences
Oklahoma State University

[Ed. - Answer from Ron Blanford, CONTEXT@WASHINGTON: "If the message says
the directory space is full, then this has nothing to do with the amount of
room left on the disk.  Depending on how the Rainbow defines the hard disk,
there is probably an upper limit of 512 or 1024 directory entries that can
be used, each mapping 32 or 64K of disk storage.  A large number of small
files on the disk could explain the problem; getting rid of some would
probably fix it."]

------------------------------

From: Bob Paver <PAVER@DELILAH>
To: info-kermit%cu20b@mcc
Subject: Need Kermit for NCR WS-300

We've got some NCR Worksaver 300's that need to talk to our VAX.  NCR's
solution is something called ATE-2 which requires extra VT-100 modules and
which doesn't support RELIABLE file transfers.  Therefore I'm looking for a
Kermit.

The hardware is actually made by Convergent Technologies.  The OS is a
modified version of CTOS.  The processor is an Intel 80186.  Supposedly the
system will run MS-DOS, but we don't have it and I'd rather not mess with
another operating system in this application.

Any suggestions?

Bob Paver, MCC, 9430 Research Blvd., Austin, TX 78759, [phone]

------------------------------

Date: Thu 6 Jun 85 21:55:43-PDT
From: L. Brett Glass <G.GLASS@[36.48.0.2]>
Subject: KERMIT for Cromemco?

Does anyone know of a KERMIT (especially, one with a server) which will run
on a Cromemco System 300 under Cromix or CDOS?  In particular, it would be
useful to get a version which already knows how to use the Z-80 front-end
cards supplied with these systems (Quadart, Octart, etc.).  Please send
ANY information to <[e-mail]>....

[Ed. - Isn't Cromix a kind of Unix?  Maybe C-Kermit could be tricked into
doing the job.  Has anyone tried it?  Is anyone working on Kermit for CDOS?]

------------------------------

End of Info-Kermit Digest
*************************
-------
10-Jun-85 17:31:47-EDT,4162;000000000001
Mail-From: SY.FDC created at 10-Jun-85 17:31:21
Date: Mon 10 Jun 85 17:31:21-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #34
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Mon, 10 Jun 1985       Volume 2 : Number 34

               MS-DOS Kermit Version 2.28 Now Available
               Need Pointer to Victor 9000 Kermit Disk
                       Kermit-MS under Topview?

----------------------------------------------------------------------

Date: Mon 10 Jun 85 17:22:15-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: MS-DOS Kermit Version 2.28 Now Available
To: Info-Kermit@CU20B, Info-IBMPC@USC-ISIB

This is to announce Version 2.28 of MS-DOS Kermit.  MS-DOS Kermit provides
terminal emulation and Kermit protocol file transfer for the following
systems:

. IBM PC, PC/XT, PC/AT and compatibles
. IBM PCjr (RS232 port only)
. DEC Rainbow Series
. Hewlett-Packard 150
. Hewlett-Packard 110
. NEC APC
. Sanyo MBC
. Texas Instruments Professional
. Wang PC
. Heath/Zenith 100
. Generic MS-DOS

The program has been tested at Columbia on the IBM PC, XT, and AT, the DEC
Rainbow, and the HP-150.  Since the system-dependent modules were not noticably
altered, it is expected that it will work on the other systems too -- but
confirmation (to Info-Kermit@CU20B) would be appreciated.

The changes are in several major areas:

1. Bug fixes (many)
2. Size -- new version is much smaller on disk, at the cost of DOS 1.x support.
3. New commands - CWD, TYPE, VERSION
4. Better unique-filename manufacturing algorithm.
5. Additional Heath-19 terminal emulation features and controls.

The files are in KER:MS*.* on CU20B, available to Internet via anonymous FTP:

KER:MS228.UPD  -- List of specific changes from 2.27 to 2.28
KER:MSAAAA.HLP -- List of all the MS*.* files, with brief explanations
KER:MS*.BOO    -- .BOO-format programs for downloading (see documentation)
KER:MSKERM.DOC -- New Kermit User Guide manual chapter for V2.28
KER:MSKERM.BWR -- "Beware File" (list of known bugs & limitations)
KB:MS*.EXE     -- 8-bit binary format Kermit programs for the various systems

The files will also appear at the other Kermit distribution points within
a week or two (BITnet KERMSRV, okstate, etc) and will be submitted to PC SIG
for the benefit of those who want to order MS-DOS Kermit on floppy disk.

------------------------------

Date: Sun, 9 Jun 85 14:25:52 cdt
From: ihnp4!shell![e-mail] (Lester Buck)
Subject: Need Pointer to Victor 9000 Kermit Disk

Could you direct me to a source for a version of kermit that runs on a Victor
9000 that is actually on a Victor 9000 format disk?  I would gladly pay some
$$$ to anyone and I am not in a terrific hurry (next three or four weeks).  I
would like to avoid downloading the versions I have on the distribution tapes.
I note that the Victor versions have changed around alot from the distribution
tape last August to the tape this March - no more vic*.* files for msdos, but a
bunch of new ones called sir*.* which I guess are identical (?).

Thanks for any pointers,

A. Lester Buck @ Shell Development Co.
{ihnp4, pur-ee, ut-sally}!shell!buck

[Ed. - There were actually several different Victor/Sirius Kermit
implementations, based on various releases of Version 1.x IBM PC Kermit.
We're only distributing the latest one.  Can anyone help him out?]

------------------------------

Date: Mon 10 Jun 85 13:28:03-PDT
From: Jim Celoni S.J. <[e-mail]>
Subject: Kermit-MS under Topview?

What are the correct program parameters to give Topview so that Kermit-MS 2.27
runs best under it?  Is there a .pif file for Kermit?  If Kermit can transfer
files in the background and not mess up the screen, that would be great...

Thanks.  +j

[Ed. - Has anybody really gone through the bother of doing this?  If you have,
please feel free to contribute your work to Info-Kermit!]

------------------------------

End of Info-Kermit Digest
*************************
-------
14-Jun-85 20:00:33-EDT,11944;000000000001
Mail-From: SY.FDC created at 14-Jun-85 20:00:11
Date: Fri 14 Jun 85 20:00:11-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #35
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri, 14 Jun 1985       Volume 2 : Number 35

                     Known Bugs in MS-Kermit 2.28
     Fixes to C-Kermit 4C Available for Unix, VMS, and Macintosh
                       Why is C-Kermit So Slow?
                      Kermit for Fortune 32/16?

----------------------------------------------------------------------

Date: Fri 14 Jun 85 18:30:52-EDT
Subject: Known Bugs in MS-Kermit 2.28
To: [e-mail]

There are two major problems with MS-Kermit version 2.28:

1. When doing a GET command, incoming filenames are randomly truncated.

2. On the IBM PC family only, when escaping back from a terminal connection,
   the system hangs.

We have a fix for problem 1 -- it's just a coding error (thanks to Dave
Tweten at NASA for pointing out the error and the fix).  Problem 2 is more
serious: it comes from the use of incompatible assemblers and linkers.  The
program depends upon its segments being in a certain order, and it instructs
the linker to put them in that order using the MSDMB and MSFINAL dummy
modules.  However, it seems that certain assemblers defeat this technique.  A
method is needed for insuring that the segments are in the desired order, no
matter what assembler and linker are used.  While this problem is being
worked on, it should be noted that a version of the program that does not
have this bug is available in the .EXE and .BOO files we distribute, which
were built with an assembler/linker combination that ordered the segments as
desired.

A new release fixing problems 1 and 2 should appear within a few days.
Meanwhile, here's Dave's prescription:

    Change 1 --

    (original msfile.asm)
        jne gofil4              ; No - get the filename.
    ; this bogusity copies the filename from the fcb into the data

    (modified msfile.asm)
        jne gofi4a              ; No - get the filename.
    ; this bogusity copies the filename from the fcb into the data

    Change 2 --

    (original msfile.asm)
        cmp flags.destflg,0     ; writing to printer?
        jne gofil5              ; no, go on

    (modified msfile.asm)
    gofi4a: cmp flags.destflg,0     ; writing to printer?
        jne gofil5              ; no, go on

------------------------------

Date: Fri 14 Jun 85 19:35:21-EDT
Subject: Fixes to C-Kermit 4C available for Unix, VMS, and Macintosh
To: [e-mail]

The many messages reporting bugs in and/or suggesting fixes for Unix Kermit
4C(050) will not be reproduced here.  Thanks to all those who sent them in,
particularly (in no special order) Bradley Smith at UCLA, Jim Bernard at U of
Delware, Kelvin Nilsen at U of Arizona, Larry Afrin at Clemson U, Dan Schullman
at DEC, Randy Huntziger at NLM, Frank Prindle at NADC, Martin Minow at DEC,
Marco Papa at USC, Jim Knutson at U Texas, Chris Maio at Columbia CS, Robert
Mark at USGS, Neal Holtz at UBC(?), David Ragozin at U of Washington, Dave
Tweten of NASA, and (of course) Herm Fischer (I think that's all of them;
apologies to anyone I missed).  If you think this list is long, you should see
the messages themselves...

It should be apparent that this program has not settled down as much as was
hoped, and still further releases may appear over the summer.  So if anyone
was thinking of posting it to net.sources... please don't!


C-KERMIT FOR UNIX, CHANGES FROM 4C(050) TO 4C(052), 14 JUNE 85:

. Fixed 8th-bit prefixing negotiation; sometimes C-Kermit would agree to do
  it and then not really do it (applies also to Macintosh Kermit).

. Added minimal 2.9bsd support (further improvements solicited!).

. Trap and ignore QUIT signal, trap SIGHUP and handle like SIGINT.
  This prevents lock files from being left behind after hangup or quit.

. Ignore SIGQUIT and SIGINT signals while inferior shell active -- let
  inferior shell handle them.

. Allowed "-a name" to work when sending from stdin.

. Change hlptxt[] to contain less than 256 characters (for Xenix)

. Fixed bugs in determination of remote vs local mode.

. When stdin redirected, and remote/local status cannot be definitely
  determined, assume local rather than remote so that local-mode commands can
  still be used.

. Fixed bug that was making 16-bit machines erroneously report files not found.

. Change makefile symbol 3BX to ATT3BX (has to start with letter)

. Remove line continuations in the middle of strings in makefile.

. Fixed a couple errors in the Tower OS 1.02 support.

. Fixed a minor problem in V7 support.

. Got rid of the (void) casts in strxxx() invocations.

. For Sys III/V, open terminal in 7-bit, parity-enabled mode rather than 8-bit,
  no-parity mode (some sites actually use parity).

. Change message "status report..." to "status report:" to avoid dot confusion.

. Replace Herm Fischer's ckudia.c with Dan Schullman's reworking of it, which
  features support for more modems (in particular, the DEC DFxxx modems) and
  more structured organization of the modem info, so support for new modems can
  be added by making relatively straightforward table entries.

. Script command now accepts scripts that were continued on the command line
  using \ (as advertised).

. Fixed minor syntactic problems in ckvtio.c for VAX/VMS.


The files are in KER:CK*.* on CU20B, available via anonymous FTP.  Also
included is a new release of Macintosh Kermit, described briefly
below.  Thanks to Doug Brutlag at SUMEX and Mike Meyer at U of
Wisconsin for pointing out the problems, and in some cases offering
fixes, and of course to Bill Schilit, now of Columbia CS, for doing
the work:


C-KERMIT FOR MACINTOSH, CHANGES FROM 0.8(28) TO 0.8(31), 14 JUNE 85:

. Built with new protocol modules from C-Kermit to fix 8th-bit-prefixing
  negotiation.

. Added dragging and selecting of main window, for better coexistence with
  desk accessories.

. Fixed COMMAND-SHIFT-1..COMMAND-SHIFT-9 problem.  Since these keys are
  special (they eject the diskettes, dump screens to files/printer, etc)
  they were being ignored.  This caused things like Control-@ and Control-^
  to be ignored also.  Add a new item to the SETTINGS menu that allows you
  to enable or disable this action.  The default is disabled.

. Fixed some default keymap definitions: Control-Y and Control-T were mapped
  incorrectly.  Control-' was mapped incorrectly.  Functions were defined for
  VT52 instead of VT100 keypad: Changed "?" to "O" in function definition
  strings.

. Errors during and/or after CKMKEY save, decompile now handled better.

WARNING: A serious bug exists in Macintosh Kermit (this new release as well
as previous ones) which should be fixed in a forthcoming release (soon, I
hope): parity operations simply do not work correctly.  Example: when parity
is set to "mark", Macintosh Kermit will discard any incoming underscore
characters; this prevents the Mac from receiving a file that requires more
than 63 packets, or from sending one that requires more than 33, assuming
said files contain no underscores (if they do, the hangup may occur sooner).
The problems fixed above were distracting enough to warrant early fixing, but
those who can live with them for another week or two are encouraged to wait
until an announcement can be made that the parity problem is fixed.

------------------------------

Date: Tue, 11 Jun 85 21:09:08 edt
From: xp!tony@nyu-cmcl2 (Tony Movshon)
Subject: Why is C-Kermit So Slow?

I've just been timing my backup from the Rainbow to the VAX (lightly loaded).
It's on a 9600-baud line, but is only transferring characters at about 140/sec.
By my lights, that's 14.5% efficient. Where'd the other 85.5% go?

I realize that the Kermit protocol expands the bytecount by about 25%, but
where's the rest of the time going?

Specifics:

to    VAX 11/750, 2 MB memory, RA81 disk, 4.2BSD, no fancy
    floating-point hardware, DMF32 port (DMA). Load average
    about 1.7, 3-5 users. C-Kermit 4C (049), file type binary,
    no parity.

from    Rainbow 100A, 512k memory, RD51 10 MB Winchester. MS-Kermit
    2.28.

I haven't timed it, but transfers seem to go considerably faster to my
11/24 running TSX-Plus using Kermit-11 V2.29.

Yours in puzzlement ...

Tony

------------------------------

Date: Wed 12 Jun 85 10:08:00-EDT
From: Frank da Cruz <[e-mail]>
Subject: Re: Why is C-Kermit so slow?

You have exactly the same setup as I do, except my VAX has more memory.  I've
seen the speed vary a lot, and can't always explain it.  In some cases, it's
appropriate to point the finger at 4.2bsd.  Sometimes, the longer our system
is up, the slower it gets.  Also, there are bugs in the DMF drivers that need
fixing (fixes are available from Usenix if you don't have them).  Also,
sometimes the system will get VERY slow if one of the idle tty lines is being
blasted by noise -- that seems to happen to us a lot.  The reason I mention
these items is that my measurements are a lot different from yours -- using
4.2bsd Kermit 4C(050) on a VAX-11/750 with load around 1.00 (with no special
line discipline, see below) against the Rainbow 100B running Kermit-MS 2.28,
transferring a 11372 character file with few repeated characters (so as not
to deceptively boost throughput because of run-encoding compression), I get:

    Unix to PC:  28 seconds, or 406.0 cps (42% efficiency)
        PC to Unix:  42 seconds, or 277.4 cps (29% efficiency)

These figures are not great, but they're better than your 140 cps by a good
bit.

Beyond the possible problems mentioned above, there's one inherent design
problem in BSD and probably most other Unixes as well -- the line is open in
raw mode for file transfer, but raw mode also turns on cbreak mode, which is
very expensive (more so when receiving data packets than when sending them).
BSD provides an alternate line discipline called "Berknet", which would have
been a LOT better for Kermit except that (a) it strips the 8th bit of
incoming characters, preventing efficient transfer of binary files, and (b)
it's hardwired to use LF as its only break character, whereas all the Kermit
programs in the world use CR.  At Columbia, we fooled with modifying the
Berknet discipine to not strip the 8th bit, to be double-buffered, and to
allow specification of the break character; you can see some code in ckutio.c
under the KERLD conditional that evokes this line discipline.  We found the
result was a Kermit that indeed ran a lot faster, but unfortunately we can't
really distribute the kernel modifications because we're too busy sending
ordinary Kermit shipments to get into the "send me your ATT and Berkeley
source licenses and we'll send you the code" business.

Short of fooling with the kernel, you should be able to speed C-Kermit up
perceptibly by recompiling with DEBUG not defined, to eliminate the many calls
to DEBUG that occur during normal operation, even when debugging information is
not being logged (and if you want to see sloooow, try transferring files with
debug logging turned on!).

- Frank

------------------------------

Date:  Thu, 13 Jun 85 09:22 MDT
From:  "Kevin W. Laurent" <[e-mail]>
Subject:  Kermit for Fortune 32/16?

We have a user with a Fortune 32/16 running FORPRO (similar to UNIX
version 7) who wants to use Kermit.  Unfortunately, he doesn't have a C
compiler.  Do you have a contact running Kermit on a Fortune?  Thanks.

- Kevin Laurent <KLaurent@DENVER>

------------------------------

End of Info-Kermit Digest
*************************
-------
21-Jun-85 20:17:55-EDT,9177;000000000001
Mail-From: SY.FDC created at 21-Jun-85 20:17:23
Date: Fri 21 Jun 85 20:17:23-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #36
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri, 21 Jun 1985       Volume 2 : Number 36

Departments:

  ANNOUNCEMENTS -
    Another New C-Kermit for Unix (4C(53)) and Macintosh (0.8(32))
    New FTP server up on CU20B: CWD fixed
    Okstate Dialup Repaired

  C-KERMIT -
    C-Kermit Very Slow on TRS-Xenix
    C-Kermit Runs on Heurikon Mini-Box
    Mapping Keys in Mac Kermit

  MS-DOS KERMIT -
    Generic MS-DOS Kermit Runs on the DG/1
    Kermit-MS under Topview

----------------------------------------------------------------------

Date: Fri 21 Jun 85 20:00:27-EDT
From: Frank da Cruz <[e-mail]>
Subject: Another New C-Kermit for Unix (4C(53)) and Macintosh (0.8(32))
To: [e-mail]

C-Kermit 4C(053) fixes a major problem for both Unix and the Macintosh:
it now does parity right.  There were two areas in which problems showed
up:

1. Macintosh Kermit could not transfer files using mark or space parity.
Furthermore, when using any kind of parity other than none, occasional
incoming characters would be lost during terminal emulation.  This was
because Mac Kermit was letting the serial i/o chip handle parity, and the
chip is simply not flexible enough to be relied upon.

2. Unix Kermit could not transmit odd parity correctly.  If you "set parity
odd", it was equivalent to "set parity mark".

The Unix Kermit software parity generation function dopar() was fixed to
generate all kinds of parity correctly.  Then Macintosh Kermit was changed
to use dopar() rather than its chip to generate parity.

Several other minor changes were made to Unix Kermit, in particular in the
determination of whether it is in local or remote mode.  The changes are
detailed in KER:CKUKER.UPD and KER:CKMKER.UPD; known bugs are listed in
KER:CKUKER.BWR and KER:CKMKER.BWR (U for Unix, M for Macintosh).  The
complete collection of C-Kermit files for Unix, VMS, and the Macintosh are
in KER:CK*.*.

These files are all accessible via anonymous Internet FTP from host CU20B.
A message about CU20B's FTP server follows.  Also, the file KER:AANETW.HLP
has been updated to provide more complete information on access to CU20B's
Kermit distribution area.

------------------------------

Date: Thu 20 Jun 85 23:39:51-EDT
From: Ken Rossman <[e-mail]>
Subject: New FTP server up on CU20B: CWD fixed
To: [e-mail]
Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025
Phone: [phone]

CU20B is now running a new version of the CMU TOPS-20 FTP server.  The
major enhancement which will be important to most users is one which
(indirectly) makes multiple file transfers easier in some cases.

One problem (particularly with originating Unix systems) was that an mget
would return a list of files with fully qualified TOPS-20 pathname
prefixes, which in turn would be the way those files were created on disk
(i.e. the Unix filenames would contain the entire TOPS-20 path prefix).
While this is merely annoying on Berkeley 4.2 systems, this is a real
problem with 4.1 systems (and perhaps others), which have shorter file
names and can lose some of the name information.

Due to the new enhancements to the FTP server, a CWD command may now be
issued to connect the user to the desired Kermit directory (with or without
a password), so that the file list that FTP retrieves for a multiple file
transfer will not contain the entire directory path (just the filenames).
If no password is supplied at the time the CWD command is issued, no "owner
access" is granted to the target directory, and files are only accessible
according to their individual file protections (in the case of the Kermit
directories, this translates to read-only access).  If a password is
supplied, full owner access is granted to the target directory.

Many thanks to Vince Fuller of CMU for the new FTP server.  /Ken

------------------------------

To: [e-mail]
Subject: Okstate Dialup Repaired
Date: 11 Jun 85 18:14:52 CDT (Tue)
From: Mark Vasoll <[e-mail]>

Some of you have been reporting problems with the dialup access that we
provide to the Kermit Distribution.  The problem has been traced to a
flakey modem and the offending unit has been replaced with a new unit.
Please continue to direct problem reports and suggestions to one of the
"uucp-support" addresses.

UUCP:  {cbosgd, ea, ihnp4, isucs1, mcvax, pesnta, uokvax}!okstate!uucp-support

ARPA:  [e-mail]

Mark Vasoll
Department of Computing and Information Sciences
Oklahoma State University

UUCP:  {cbosgd, ea, ihnp4, isucs1, mcvax, pesnta, uokvax}!okstate!vasoll

ARPA:  [e-mail]

------------------------------

Date:  Mon, 17 Jun 85 09:38 MDT
From:  [e-mail]
Subject:  C-Kermit very slow on TRS-Xenix
To:  [e-mail]

I just installed 4C(052) on TRS-XENIX and timed a file transfer to a
very lightly loaded VAX/VMS.  With a 4800 baud connection, the transfer
averaged 13 chars/sec.

[Ed. -- Wow, does everybody else with TRS-Xenix have the same performance?]

------------------------------

Date: 18 Jun 85 08:28:10 PDT (Tuesday)
From: [e-mail]
Subject: C-Kermit Runs on Heurikon Mini-Box
To: [e-mail]

C-Kermit has been sucessfully installed on two Heurikon Mini-Boxes.
  (68010, Unisoft System V 5B 4/85;  HK68 CPU - 10 MHz)

only two minor problem areas:

1.  Tabs were converted to spaces at some point along the transfer route.

2.  the " \ " characters had to be removed in the initial Make line.

Recommendation:

Since there are so many entries for a "3" type installation, change the
name of sys3 to sys5.  I found that some non-unix types had trouble with
this as they have System 5 Unix and all through the documentation Unix V
is the more common term used.

Note:    Time to complete the make process 27 minutes.

Thanks to all for a fine job on the software.

------------------------------

Date: Thu, 20 Jun 85 11:22:09 EDT
From: Greg Lauer <glauer@srn-vax>
Subject: Mapping Keys in Mac Kermit
To: [e-mail]

I used the kermit key map program to put control characters on the Option key
and meta characters on the Command key.  The problem is that Option-e,i,u,n
still act like option keys: they "expect" another character.  Thus to send a
control-n requires typing option-n option-n.  Otherwise, this seems like a
great program.

Greg

[Ed. - The lowercase vowels "aeiou" are treated specially in the translation
routine /usr/mac/ws/local/init0.  init0 is also the routine which was doing the
shift-clover-1..9 stuff.  Mac Kermit currently has a command for disabling
the shift-clover-1..9 keys, but adding one for the option-vowels would be a
lot harder.  For now, this goes into the .BWR file.]

------------------------------

Date: Wed 12 Jun 85 14:08:13-CDT
From: Aaron Temin <[e-mail]>
Subject: Generic MS-DOS Kermit Runs on the DG/1
To: [e-mail]

We have a copy of MSGENE.EXE running on our Data General/One.  File transfers
work fine at 1200 baud through an external modem.  Internal modem doesn't seen
to respond, and screen emulation, even with the vt100 ansi.sys installed,
doesn't seem to work.  But this is entirely satisfactory until someone can
modify Kermit appropriately for the beast.

Hope this is helpful.  Thanks.
Aaron Temin

------------------------------

From: Jim Gillogly <jim@rand-unix>
Date: 12 Jun 85 14:38:00 PDT (Wed)
Subject: Re: Kermit-MS under Topview?

Yes, MS-Kermit v. 2.27 will run under Topview.  I haven't bothered with
a .PIF file, but it works fine in the background.  For 2.27 on the IBM PC
I used 96K for the min memory, 96K for max, and 7K for system.  I left
the interrupts at 00-FF, although I'm sure they don't all need to be swapped
(if any) ... keep it simple.  Use "n" for "program writes to screen", since
writing to the screen and running in the background are linked.  The
disadvantage of telling it "n" is that it intercepts everything, giving you
a "galumphing" scroll.  However, "n" is necessary for background, and if
you're transferring long files it's worth it.

I used 2.27 in background mode to pull Webster's 2nd over while doing a
half-day's worth of real work on my PC in the foreground.  I normally don't
use Topview because it's not compatible with the Tall Tree RAMdisk ... and
since I have 2.5 meg of RAMdisk, that's a big loss.

It also works with MS-Kermit v.2.28, which needs only 85K for min/max size.

    Jim Gillogly (jim@rand-unix)

[Ed. - Thanks for the information.  Since 2.28 does dynamic memory allocation,
it will probably have to be defined differently to TopView.]

------------------------------

End of Info-Kermit Digest
*************************
-------
24-Jun-85 18:19:09-EDT,5902;000000000001
Mail-From: SY.FDC created at 24-Jun-85 18:18:37
Date: Mon 24 Jun 85 18:18:37-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #37
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Mon, 24 Jun 1985       Volume 2 : Number 37

                       Commodore-64 Kermit V1.6
               MS-Kermit Support Module for ACT Apricot
                    Kermit for the Acorn BBC Micro
                  New Release of Sperry 1100 Kermit
                  Kermit for ND Series Minicomputers
            Another Kermit Implementation for the ICL/Perq
                        New HP-3000 SPL Kermit

----------------------------------------------------------------------

Date: 8 Jun 85 17:59:50 EDT
From: Eric <[e-mail]>
Subject: Commodore-64 Kermit V1.6

Is ready for distribution.  There are a few minor annoyances, like the disk
command parsing routine not working entirely correctly and the timeout
implementation is far from complete (though it can timeout), and not
handling the lack of an init file on the disk elegantly.  The documentation
describes all the features of this new Kermit, I'm sure people will find it
a major improvement over previous versions.  All known bugs in the
communications routines have been fixed and eight-bit-quoting works.

ARPA:    LAVITSKY@RUTGERS
UUCP:    ...{harvard,seismo,ut-sally,sri-iu,ihnp4!packard}!topaz!eric
SNAIL:    CPO 2765, CN 700
    New Brunswick, NJ  08903

[Ed. - The new files are in KER:C64KER.* on CU20B, available via anonymous
FTP, as are all the other new files announced below.]

------------------------------

Date: Mon 24 Jun 85 17:05:20-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: MS-Kermit Support Module for ACT Apricot

The file KER:MSXAPR.ASM contains the system-dependent functions for the ACT
Apricot, suitable for inclusion in MS-DOS Kermit 2.27 or later.  It comes
from Ralph Mitchell, Computer Centre, Brunel University, Uxbridge UK.  There
is no documentation to speak of, so nothing can be said at this point about
its capabilities (maximum baud rate, screen scroll, printer control, key
redefinition, etc).  Reviews, contributions of documentation (or a .BOO
file) welcome.  Note that there was already a version of the old IBM PC
Kermit version 1.20 that was modified for the Apricot at the
Rijksuniversiteit Groningen, which has been available as KER:APRICOT.* since
November 1984.  If anyone knows any reason why this new version should not
replace the old one, please speak up.  Thanks to Alan Phillips of Lancaster
University for sending it on tape.

------------------------------

Date: Mon 24 Jun 85 17:15:47-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Kermit for the Acorn BBC Micro

This is to announce the initial release (version 0.53) of Kermit for the Acorn
BBC micro under the operating system OS1.20, by Alan Phillips, Department of
Computing, Lancaster University, UK.  The source, in 6502 assembler, is in
KER:BBC*.ADE, and a binary dump of the compiled code is in KER:BBC053.ROM.
KER:BBCBUILD.HLP describes how to construct a BBC Kermit, and KER:BBCKERMIT.BWR
lists known problems with this release.  A printable form of the user guide is
in BBCKERMIT.DOC.  Inside the UK, this program will be available on diskette
and via the UK university network from Lancaster University.

------------------------------

Date: Mon 24 Jun 85 18:05:55-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: New Release of Sperry 1100 Kermit

Version 2.2 of Sperry (Univac) 1100 Kermit (the assembler version, not the
Pascal or the Ratfor version) has been sent in by the author, Paul Stevens
of the University of Wisconsin.  Version 2.2 includes 8th-bit and repeat-count
prefixing, server operation, and supports wildcards in filenames (server and
wildcard code mostly from Grant Gilmour of Guld Canada Resources Inc).  The
program is in KER:UNIVAC.ASM on CU20B.

------------------------------

Date: Mon 24 Jun 85 17:21:39-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Kermit for ND Series Minicomputers

Announcing the initial release of Kermit-ND (version 3.1b) for the
Norwegian ND family of minicomputers (ND-10/100/500), by H. Eidnes and A.
Lie, Norwegian Institute of Technology and others, written in ND Pascal
version J / MAC.  The files are in KER:ND*.* on CU20B.

------------------------------

Date: Mon 24 Jun 85 17:28:55-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Another Kermit Implementation for the ICL/Perq

Here is a second Kermit program for the ICL/Three Rivers Perq workstation.
This one is by A. Lie, formerly of the Norwegian Institute of Technology,
written in POS Pascal for POS version D6/R2.  Like the other Pascal-based
Perq Kermit (from Peter Thew in Australia), it has a pop-up menu user
interface.  This new version of Perq Kermit is in KER:PQ2*.* on CU20B (the
old one is in KER:PQK*.*).  Unbiased comparisons by Perq users of the two
programs would be welcome, so that the less favored one can be retired to
make space.  Thanks to Frithjov Iversen of the Computing Centre at the
University of Trondheim for sending this to us on tape.

------------------------------

Date: Tue, 4 Jun 85 08:29:49 edt
From: Steve Archer  <[e-mail]>
Subject: New HP-3000 SPL Kermit

Here is a new version of HP-3000 Kermit in SPL, version 1.1, to replace
version 1.0 originally from Ed Eldridge, Polaris Inc. (POLARIS@USC-ISI).
It adds the capability to show parameters, changes the "serve" command to
"server".  Help messages have been added, and some short-form commands.
Also added parity, a FINISH command, and a very primitive connect mode.

steve archer

------------------------------

End of Info-Kermit Digest
*************************
-------
26-Jun-85 19:42:39-EDT,14990;000000000000
Mail-From: SY.FDC created at 26-Jun-85 19:42:11
Date: Wed 26 Jun 85 19:42:11-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #38
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Wed, 26 Jun 1985       Volume 2 : Number 38

                           C-Kermit Issue:

                    C-Kermit 4C for Amdahl UTS 2.4
                    C-Kermit 4C for Fortune 16:32
           Fixes to C-kermit for the Valid Scaldstar System
             C-Kermit on Whitechapel MG-1 with Genix 1.3
               Unix-Like Systems Supported by C-Kermit
             Transporting C-Kermit to Eurosys-16 with Os9
                   Dialing from C-Kermit on a 3B2?
                   C-Kermit 4x vs Line Locking, etc

----------------------------------------------------------------------

Date: Thu 20 Jun 85 02:23:04-PDT
From: Jean-Pierre Dumas <[e-mail]>
Subject: C-Kermit 4C for Amdahl UTS 2.4

We have compiled Kermit 4.2 on UTS 2.4. It works very well (with "make v7";
we use a dummy function that always return 0 for initrawq in ckutio.c )

[Ed. - Thanks for the news!  I've added a comment to this effect to the
makefile.]

------------------------------

Date: Wed 26 Jun 85 04:32:52-PDT
From: Jean-Pierre Dumas <[e-mail]>
Subject: C-Kermit 4C for Fortune 16:32

Frank,

I insert ckuker.mak ckufio.c ckutio.c as modified for the fortune 16:32 by
Gerard Gaye.

[Ed. - The Fortune support has been fitted into KER:CKUKER.MAK, KER:CKUTIO.C,
and KER:CKUTIO.C.  It's mostly the same as 4.1bsd.]

As we are connected through an x25 network it should be possible to safely
by-pass some packet assembly/deassembly/coding... of kermit and rely on the
x25 pad to do the work...anybody working on that ???

[Ed. - The Kermit protocol is not layered well enough to do things like this.]

Jean-Pierre Dumas

------------------------------

Date: Thu, 20 Jun 85 17:32:51 pdt
From: psivax!woof (Hal Schloss)
To: ttidca!randvax![e-mail]
Subject: Fixes to Ckermit for the Valid Scaldstar System

We have a VAX 11/750 running BSD 4.2 that we talk to with Intel MDS's and
VALID Scaldstars.  We use the VAX to develop code that we download to the
MDS's and to provide remote services for the Scaldstars. In the course of
getting these to work I had to make changes to existing kermits to allow
communication to C-kermit on the VAX.

For the VALID systems I had to change all references to the variable cc in
the file ckucmd.c.  These were changed to ccx, the problem is that cc is
an internal variable for the VALID's assembler which blows up in an ugly
fashion if you declare a second time. I also had to replace a reference
to FREAD in ckutio.c as the VALID does not have this in it's include files.
I hope this works, it seems to so far.  To compile for the VALID include
the changes listed in diff -c format below (using patch?) and make bsd.

[Ed. - diffs omitted.]

By the way, I have implemented a remote line printer server for the VALID on
our vax, but I have to run kermit at 300 baud as the VALID has problems
above that speed. I don't know why though.

        Hal Schloss
        (from the Software Lounge at) Pacesetter Systems Inc.
{trwrb|allegra|burdvax|cbosgd|hplabs|ihnp4|sdcsvax|aero|uscvax|ucla-cs|
 bmcg|sdccsu3|csun|orstcs|akgua|randvax}!sdcrdcf!psivax!woof
 or {ttdica|quad1|scgvaxd|nrcvax|bellcore|logico}!psivax!woof
 ARPA: ttidca!psivax![e-mail]

[Ed. - This can be handled by adding an entry like this to the makefile:

#Valid Scaldstar
valid:
    make wermit "CFLAGS= -DBSD4 -Dcc=ccx -DFREAD=1"

I've added this to KER:CKUKER.MAK.  At some later time, perhaps some
of the commonly-objected to variables, like "cc" and "data" can be
renamed.]

------------------------------

Date:     Fri, 21 Jun 85 18:33:06 BST
From:     [e-mail]
Subject:  C-Kermit on Whitechapel MG-1 with Genix 1.3

I have managed to compile and run C-Kermit 4C(050) on a Whitechapel MG-1
workstation (See Byte magazine from first quarter '85).  This machine is
basically a Unix engine running Genix-1.3 which is essentially a bsd 4.1
system.  Only hitches were:

1) single call to getppid in ckufio.c was hardwired to 0 due to
   lack of this system call in Genix.

[Ed. - Sounds a lot like the Fortune support mentioned above.]

2) wart compiles fine but refuses to process ckcpro.w  stating
   that one of the defined dynamic states is undefined.  Older
   version of wart from c-kermit 4.2 also gives a similar error
   but a couple of states later.  Lex also wouldn't process it.
   I suspect that it is an obscure bug in my operating system.
   I haven't had the time or energy to chase it down.  Instead
   I worked around the problem by using the distributed ckcpro.c.
   I haven't the foggiest idea of what is wrong since wart seemed
   happy on a vax running bsd 4.2 and previous versions (4.2) of
   wart and ckprot.w worked fine.

Thus far, I have done only basic send/receive functions on the
Whitechapel using only text files.  Everything for the present
seems to be in order.   THanks for kermit!

Les J. Wu

[Ed. - I've added Les's hints to the makefile comments section.]

------------------------------

Date: Wed 26 Jun 85 17:45:38-EDT
From: Frank da Cruz <[e-mail]>
Subject: Unix-Like Systems Supported by C-Kermit
To: [e-mail]

The following list shows all the systems that C-Kermit has been reported to
work on (the Fortune, Valid, and Whitechapel changes announced above are
confined to the files KER:CKUKER.MAK (makefile), KER:CKUTIO.C, and
KER:CKUFIO.C).  I'd appreciate hearing from anyone who has it working on any
systems not listed here, so that I can add their machines and operating
systems to the list:

   Machine          Operating System      Machine          Operating System
    AT&T 3B Series   Unix Sys V            IBM PC/AT        Xenix/286
    Cadmus 68000     Unix Sys V            IBM 370 Series   VM/UTS 2.4
    CallanUnistar300 Unix Sys V            IBM 370 Series   VM/UTS v5
    Codata           Unix V7               NCR Tower        OS 1.02
    DEC VAX          Ultrix-32             NCR Tower        Unix Sys V
    DEC VAX, ...     Unix 4xBSD            PerkinElmer 3200 Unix V7
    DEC PDP-11       Unix 2xBSD            Pyramid 90x      Unix 4xBSD
    DEC PDP-11, ...  Unix V7               Masscomp         RTU 2.2
    DEC Pro-3xx      Venix V1              Motorola 4 Phase Unix Sys V
    DEC Pro-3xx      Venix V2              Plexus P60       Unix Sys V
    Fortune 16:32    For:Pro1.7            SUN              Unix 4xBSD
    HP-9836 S/200    HP-UX 200B            TRS-80 Model 16  Xenix
    HP-9000 S/500    HP-UX 3.25            Valid Scaldstar  Unix 4xBSD
    IBM PC/XT        PC/IX                 Whitechapel MG-1 Genix 1.3

Also, if anyone can claim that the current version does NOT work on any of
these systems, I'd also like to find out about that.  Thanks!  - Frank

------------------------------

Date: Fri, 14 Jun 85 13:20:15 -0300
From: mcvax!hut![e-mail] (Kimmo Laaksonen, Helsinki U of Technology)
Subject: Transporting C-Kermit to Eurosys-16 with Os9

Hi,
I'm forwarding the following mail (excerpt of) for your info:

    Date: 14 Jun 1985 1006
    From: SAHKOL.TAKALA
    To: LK.LAAKSONEN

    We are planning to transfer CKERMIT into a system called EUROSYS-16.  The
    operating system is OS9/68000.  The C-compiler we have running is done by
    Microware.  The version of CKERMIT we have got is 4.2(030).

    Petri Alhola, Lauri Aarnio
        Robcon OY
        Hankasuontie 9
        P. O. Box 9
        SF - 00391 HELSINKI
        Finland

    Juha Takala
        Helsinki University of Technology
        Power Systems Engineerin Laboratory
        Otakaari 5
        SF - 02150 ESPOO
        Finland

Electronic mail can be routed to the implementors through me.
Kimmo Laaksonen, mcvax!hut![e-mail].

[Ed. - Bob Larson, BLARSON%ECLD@USC-ECLA, is coordinating an effort to bring
up C-Kermit under Os9 on a variety of systems.  Maybe these two groups can
make contact, especially since Bob has access to the up-to-date C-Kermit
sources.]

------------------------------

Date:     Wed, 26 Jun 85 11:50:42 EDT
From:     Dr. Joseph M. Leonard <jmleonar@crdc>
To:       info-kermit@cu20b
Subject:  Dialing from C-Kermit on a 3B2?

This, hopefully, will be an easy one.  I have C-Kermit going on our 3B2, but
cannot get the dialer feature to work.  The "set modem racal" seems to work
(with the addition of an extra \r), but the "instant" that dialer tries to
do its stuff, DTR is dropped by the 3B2.  What I need is anybody who has
set up the /etc/inittab file to do this.  OR, if somebody using SysV.2.2 has
used racal modems to dial out, please let me know what I've missed...

                                                Joe Leonard
                                            <[e-mail]>

[Ed. - Has anyone done this?  If not, a new dialer module is expected soon
that might help in this area.]

------------------------------

Date: Tue, 28 May 85 11:53:40 pdt
From: hpl-opus![e-mail] (Ken Poulton)
Subject: C-Kermit 4x vs Line Locking, etc

Questions:
   1)     How does kermit do uucp line locking on 4.2 systems that
    (I understand) generally have /usr/spool/uucp owned by uucp
    and protected as 755 ?  Our system manager suggests that
    we should make kermit setuid uucp; is this commonly done?

   2)    Some of my uses of Kermit (a spooled print server, for instance)
    require that one script do the login, the next does a transfer,
    more transfers occur if they are queued, and then a script
    logs out.  Obviously, there needs to be a way to leave the
    line locked and open *between* Kermit invocations.
    I have addressed this with an eXIT command, (like berkeley mail)
    which exits the program without unlocking the line or dropping DTR.

    To make this work, I changed look4lk to swallow an existing lock
    file if the user is the owner.  (This, however, provides no
    protection if kermit is setuid!  This may require some id inside
    the lock file.)

[Ed. - This is probably a good idea, provided Kermit not setuid'd.  If I were
a Unix system manager, I'd think twice about making a program as big and
complex as C-Kermit setuid'd anyway.]

    To alleviate the problem of users leaving the line locked,
    I print a warning message and create a script in the user's home
    dir ("UNLOCKtty04") which can delete the lock and drop the line.
    To avoid confusion, I have disabled the 'exit' command.

[Ed. - Well...  Not to rehash all the old arguments, but there's simply NO GOOD
WAY to handle this situation over the entire family of Unixes.  Unix stupidly
lets anyone assign an appropriately protected tty, regardless of whether
someone else may also have it assigned.  Reasonable multiuser operating systems
allow access to devices like terminals and tape drives to one job or process at
a time, since there's no practical way that serial devices such as these can be
shared.  Many operating systems even have a tough time letting users share disk
files!  Anyway, because Unix blithely grants a tty device to as many users who
ask for it, the whole business of "line locking" came about.  Whoever it was
that invented uucp decided for the rest of us how lines should be locked: by
writing a file into a particular directory like /usr/spool/uucp or /etc/locks.
This requires that the user's process must have write access to that directory.
This is accomplished by (a) protecting the directory so that the public can
write into it (which opens the door to potential security problems); (b)
protecting the directory so that members of certain groups can write into it
(which requires the system manager to keep track of who's in what group); (c)
setting the process's user id to a privileged id or one that has owner access
to the lock directory (more security loopholes).  All of these approaches
require some action of the system manager in order to install a program that
wants to create locks, meaning that such a program is not user installable,
at least not unless condition (a) already prevails.  If one wants to find out
who is currently using a device, option (c) is not viable, since the user's
name will not appear as the creator of the lock file.

Assuming that all this can be set up, there still remain ___ major problems
with line locking:

1. Programs will always appear that do not honor the locking conventions,
defeating the entire purpose of the locking mechanism by simply ignoring it.

2. Programs that do honor the locking convention will occasionally leave lock
files behind (because the process was killed, the system crashed, or the
program itself crashed), preventing other users from using the device even when
it is free.

The trade-off, then, is whether it is better to err on the side of security
or on the side of letting users get their work done.  C-Kermit, in its present
form, makes various compromises.  If read or write access to the lock
directory is denied, the program issues a warning but allows the user to
proceed.  If a lock file exists for the specified device, the user is not
allowed to proceed, but is given an "ls -l" listing of the lock file to show
the file's creator and creation time.  Since C-Kermit does not allow access to
a locked line, it is very careful to get rid of lock files whenever it exits,
whether because a command-line invocation was completed, an "exit" command was
given, or an interrupt or quit signal was raised.

If users are given the ability to exit Kermit without releasing the line or
closing the lock file, many lock files will be left behind.  This is especially
likely because the intention of this feature is to facilitate running Kermit
from unattended scripts.]

    The other problem is that on Bell systems,
    we have no job control (sigh).  This means that we can't
    put a long transfer into the background after it starts.
    The eXIT command allows you to be using Kermit CONNECT
    for doing work, eXIT and do a transfer in the background,
    and re-CONNECT when the transfer is done.
    Perhaps Kermit should support background transfers directly...

[Ed. - I can see that the proposed eXIT command has its uses, but it really
supposes a friendly environment where everyone knows everyone else and can
chase them down when they leave a lock file behind.  But what happens when you
have Unix running on some huge timesharing system like a VAX 8600 or an IBM
3081 with 5000 users, and they're all leaving lock files behind, perhaps even
on purpose (maybe they're premed students...)?]

------------------------------

End of Info-Kermit Digest
*************************
-------
27-Jun-85 18:39:37-EDT,23374;000000000000
Mail-From: SY.FDC created at 27-Jun-85 18:39:12
Date: Thu 27 Jun 85 18:39:12-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #39
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Thu, 27 Jun 1985       Volume 2 : Number 39

Departments:

  ANNOUNCEMENTS -
    BITNET KERMSRV Reorganized
    IBM VM/CMS Kermit in Pascal

  MISCELLANY -
    MS-Kermit 2.28 H-19 Emulation for IBM
    Kermit Talk at National Prime Users Group
    Kermit-TSO and the IBM 7171 Front End
    About Commodore 64 Kermit V1.6
    Apple II Kermit Status
    C-Kermit Line Locking Problems, Cont'd
    C-Kermit Problems: HP-9000, Racal-Vadic Modems, etc

----------------------------------------------------------------------

Date: Thu 27 Jun 85 13:50:57-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: BITNET KERMSRV Reorganized

BITNET users who get files from the Kermit file server, KERMSRV at CUVMA,
will notice that the BITNET Kermit distribution area has been split in two
in the same way as the CU20B area, as described in Info-Kermit V2 #33.

Those who may have missed the announcement are encouraged to read the file
KER:AAAUPD.HLP on CU20B (AAAUPD HLP on KERMSRV) to see what was done.  In
particular, it should be noted that all the "bureaucratic" files (like lists
of versions, flyers, order forms, etc) have all been renamed to have names
starting with AA.

------------------------------

Date:    Fri, 7 Jun 85 16:47 EDT
From:    [e-mail]
Subject: IBM VM/CMS Kermit in Pascal

I have just sent you an updated version of my Pascalvs version of
KERMIT-CMS.  This version eliminates the use of the LINEMODE call and
thus can be run as a self-contained module and should work with any
other Kermit without modification.  There is a quick comparison of the
Assembler and Pascal version below.

COMPARING ASSEMBLER AND PASCALVS KERMIT FEATURES.

CMS Kermit Capabilities :        ASSEMBLER            PASCALVS

  Local operation:                   No                Yes
  Remote operation:                  Yes               Yes
  Transfers text files:              Yes               Yes
  Transfers binary files:            Yes               Yes
  Wildcard send:                     Yes               Yes
  ^X/^Y interruption:                Yes               Yes
  Filename collision avoidance:      Yes               No
  Can time out:                      No                No
  8th-bit prefixing:                 Yes               Yes
  Repeat count prefixing:            Yes               Receiving only
  Alternate block checks:            Yes               Yes
  Terminal emulation:                No                No
  Communication settings:            No                No
  Transmit BREAK:                    No                No
  Transaction logging:               Yes               No
  Session logging:                   No                No
  Raw transmit:                      No                Yes
  Act as server:                     Yes               Yes
  Talk to server:                    No                Yes
  Advanced server functions:         No                Yes  ****
  Advanced commands for servers:     No                No
  Local file management:             Yes               Yes
  Handle Attribute Packets:          No                No
  Command/init files:                Yes               No
  Command macros:                    No                No

 **** Advanced server commands DIR,ERASE,and TYPE have been
      implemented.   All of the advance server functions will
      respond if only to tell you it has not been implemented.

[Ed. - The files are in KER:CM2*.* on CU20B available via anonymous FTP
and as CM2* * via BITNET KERMSRV.]

------------------------------

Date: Wed, 19 Jun 85 17:36:58 pdt
From: [e-mail] (Dave Tweten)
To: Info-Kermit@CU20B
Subject: MS-Kermit 2.28 H-19 Emulation for IBM

MS-Kermit 2.28 msyibm.asm seems to have a bug, and what I interpret as
two "misfeatures".

The bug is that a line-wrap which requires a scroll-up does not produce
the scroll.  As a result, the wrapped portion of the line overwrites
the first part for as many wrappings as are required.  I observed this
by running "vi" on our 4.2 bsd system, using MS-Kermit 2.28 in H-19
emulation mode.  I viewed a file with long lines.  Line-wrap in the
middle of the screen worked properly.  So did scroll-down (backward)
through multi-line lines.  However, when I had "vi" scroll-up (forward)
through the file, each multi-line line that entered at the bottom of
the screen overwrote itself.  When I used ^L to tell vi to repaint the
screen, overwritten lines were displayed correctly.  When I repeated
the test, using MS-Kermit 2.27, everything worked correctly.  I haven't
yet had time to find the source of the problem.

The first of the "misfeatures" is the addition of line-wrapping backspace.
My copy of the H-19 Operation Manual says clearly (on page 12) that
backspace:

    Moves the cursor one space to the left.  If the cursor is at
    the start (left end) of a line, it will not move when you type
    a BACK SPACE.

I believe that if Kermit is going to be advertized as emulating an
H-19, it ought to do so.  I don't think this is a very serious
deviation, though, because I can't imagine a program sending a useless
backspace, confident that the H-19 will ignore it.  Still, why
introduce incompatibilities?

The other "misfeature", though, is serious.  H-19s will work in either
native or ANSI mode.  Almost all of Kermit's escape sequences are from
the native set.  Kermit's new "Enhanced Character Support" sequence
(ESC [ p1 ; . . . ; pn m) is the sole exception, being an extension of
one from the ANSI set.  Unfortunately, it conflicts with the native set
"ESC [" sequence (Enter Hold Screen Mode), which is not implemented in
Kermit.

Both sequences are correctly interpreted by a real H-19 because it has
two more sequences which are not implemented in Kermit, "Enter ANSI
Mode" (ESC <), "Enter ZDS Mode" (ESC [ ? 2 h).  To implement "Enhanced
Character Support" correctly, without stumbling over "Enter Hold Screen
Mode", the sequence should be honored only in ANSI mode.  That would
require it to become "ESC < ESC [ p1 ; . . . ; pn m ESC [ ? 2 h".  I
don't think the sequence is worth it without a general implementation
of ANSI mode.

One very good reason for Kermit to emulate an H-19 is that many systems
believe they already know about H-19s.  If this advantage is not to be
lost, Kermit must stay as close to the H-19 as possible.

------------------------------

Date: Thu 20 Jun 85 13:50:57-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Re: MS-Kermit 2.28 H-19 Emulation for IBM

One of our problems is that we don't have a real H19, and the H19 manual
that we once had has disappeared (anybody want to donate one to the cause?).
Our PC's get used a lot as terminals to our IBM mainframes, and it is common
on those machines to display files that contain lines a full 80 characters
long, with a CRLF at the end.  If you don't suppress LF after autowrap, then
these come out looking double spaced.  We made the change mainly to make our
IBM mainframe users happy.  Since this is inconsistent enough with the H19
definition to break "vi", we'll have to back out of this change; the next
release (2.28a, which contains fixes to the most glaring problems with 2.28,
namely the "get" filename truncation and the segment reordering) will
have this feature put back the way it was -- should be ready within a week
or so.

Having backspace wrap to the previous line was a suggestion from Greg Small
at Berkeley; I don't remember his motivation (Greg?).  Aside from the the
fact that this deviates from the H19 definition, can you think of any
functional reason not to do it?

We thought about the ANSI mode business a bit before we put it in.  It was
added because we needed the different kinds of highlighting for use with
3270 protocol converters (front ends for our IBM mainframes).  We noticed
that there was a potential conflict between native ESC [ and the ANSI
lead-in sequence.  But, we reasoned, since we don't support native ESC [
(can you think of any software that would send a hold screen command?), and
since we ignore unknown escape sequences (like Enter and Exit ANSI mode),
and since we're not trying emulate an ANSI terminal in all its glory, we
figured that no harm would be done.  If some software wants to use the
character highlighting and does that by sending "ESC < ESC [ p1 ; ... ; pn m
ESC [ ? 2 h" then it will work just fine.  It will also work if they just
send ESC [ p1;...;pn m by itself.  If they really want to send a hold screen
command, it will have no effect (unless, I guess, the following characters
can be interpreted as p1;...pn m).  But then, will any software that exists
ever actually send a hold screen command?  You'd think that if the software
did not want additional characters to be displayed on the screen, it would
simply not send them, but perhaps I'm naive...

I realize these are touchy issues, but in my view the H19 emulator in Kermit is
just a stopgap.  Soon, we expect to have a fully functional ANSI (VT102)
emulator available in the form of a loadable console driver, separate from
Kermit but distributed with it on the same terms.  At that point, I think the
H19 code will become superfluous and will eventually wither away.

- Frank

------------------------------

Date: Sat 22 Jun 85 04:00:45-PDT
From: Bob Larson <BLARSON%ECLD@ECLA>
Subject: Kermit Talk at National Prime Users Group
To: info-kermit@CU20B

A talk was given at the National Prime Users Group (NPUG) in Saint Louis
this week entitled "Kermit on the Prime: One shop's experience" by
Harvey J. Friedman of the International Pacific Halibut Commission.

The bug in Prime Kermit discussed in the talk was configuration dependant,
it only affects systems with printing characters for erase and or kill.
(It is also documented at Columbia in a .bwr file, but that file is not
in the distribution from Pulse (Prime users library...))

Apparently there is a need to cooridante the Pulse distribution with the
Columbia distribution.  I have heard that there is a new version on Pulse
that supports assigned lines.

Bob Larson <[e-mail]>

[Ed. - Prime Kermit has always been one of the most difficult to manage.
Another problem has been that Prime computers can't read any of the tape
formats in which we distribute Kermit, including ANSI labeled ASCII (the
standard format for information interchange agreed upon by all major
manufacturers).  Finally, in desparation, people in Prime's New York office
wrote a short Fortran program to read ANSI tapes, and we have to include a
copy of it on paper every time we send a tape to a Prime site.  Even if
Prime refuses to support industry standard tape formats, you'd think the
user group (Pulse?) could solve problems like this.]

------------------------------

Date: Wed 25 Jun 85 11:51:32-EDT
From: Wing Lee <WingLee%ECLD@ECLA>
Subject: Kermit-TSO and the IBM 7171 Front End
To: [e-mail]

I have the TSOS1.ASM file and it works fine with the Series/1.  But when we
replaced the S/1 with an IBM 7171, we started having problems.  The problem
was that when you were uploading to the TSO host, the file transfer would be
hung at random places.  When I used the debug option, on TSO kermit, I found
that the transfer would stop right after the first CHECKSUM error.
Downloading works fine, and KERMIT is able to handle CHECKSUM errors just
fine, but when uploading, it just stops.  I was wondering if anyone else was
experiencing problems similar to my, and if so, if anyone was going to add
support for the 7171 in the next release of KERMIT-TSO.

wing

------------------------------

Date: Wed 26 Jun 85 11:51:32-EDT
From: Daphne Tzoar <[e-mail]>
Subject: Re: Kermit-TSO and the IBM 7171 Front End
To: [e-mail]

It sounds like the problem you are having should be a protocol issue and
shouldn't be related to whether you are using a S/1, 7171 or 4994.  I'm not
sure why a bad checksum should affect the upload to TSO and not the download
from it.  But, I will forward your message to Info-Kermit and the author of
the S/1 TSO Kermit.  /daphne

[Ed. - To the best of our knowledge, the new VM/CMS Kermit works equally
well through straight ASCII async tty connections through 3705 and
equivalent front ends, through the Series/1 (4994?) front end doing 3270
protocol conversion, and likewise the 7171 front end.  We hope that someone
at a TSO site will find a way to convert VM/CMS Kermit to TSO in such a way
that it can be built for either VM/CMS or MVS/TSO, either by conditional
assembly or by moving system-dependent primitives to a special module,
like C-Kermit or MS-DOS Kermit.  Then, whenever the program gets fixed or
improved, everyone will benefit at once.]

------------------------------

Date: 26 Jun 85 19:08:07 EDT
From: Eric <[e-mail]>
Subject: About Commodore 64 Kermit V1.6

I neglected to include a suitable .INI file in the kermit distribution,
which is losing since it really needs an init file right now to startup in a
sane manner.  You can instruct people with older versions of kermit to
download this file as an ascii seven-bit file before starting up the new
Kermit.

[Ed. - This file is now in KER:C64KER.INI on CU20B.  It contains a strange
looking sequence of control characters -- don't be alarmed when you see them.]

By the way I thought I'd take this opportunity to address some of the
questions you've been sending my way lately (I've been really busy with a
new job and all):

Using C64 Kermit with a tape drive:

Very simply put, you can't.  That is not without adding to the program and
not without huge delays in transmission.  The C64 operating system uses the
same memory locations for the RS232 routines and the tape drive timing (both
of which are critical).  I do *not* plan on adding any support whatsoever
for the tape drive.

Using Kermit with the C128 (no one's asked yet, but just in case):

It should be easy to use Kermit in C64 mode on the C128.  There *should*
also be no problem with using it in 128 mode, but it would make more sense
to use the native screen mode for 80 columns.  Since I don't have a 128 (and
don't plan on getting one), I cannot evaluate what is necessary to take
advantage of this.  Anyone else who is interested in doing this should feel
free to give it a crack.  The C128 should work nicer in native mode due to
the faster disk drive.  On the other hand, you may just want to use CP/M
Kermit on it.

Eric

------------------------------

Date: Thu 27 Jun 85 00:20:45-EDT
From: Peter G. Trei <[e-mail]>
Subject: Apple II Kermit Status

>Date:  Mon, 24 Jun 85 14:09 MDT
>From:  "Mike Armstrong {mba}" <[e-mail]>
>Subject:  Apple 2 kermit

>Would you please tell me the current status of the Apple 6505 version of
>kermit.  The latest version I have is V2.1 (V2.1A??) updated 30-JUL-84
>by Peter Trei (original by A.N.J. Moine)

Version 2.1a is still the latest released version. Development has is
currently rather slow: both Anton's and my real-world workload have
substantially increased in the past year, and I have been able to do rather
little for 4-5 months, and Anton none. (I am still distributing several
copies a week by mail).

If you feel like contributing code, my only request is that you inform me
and Anton about it before you start, to advoid duplication of effort.
Outstanding desired features and bugfixes include:

[Ed. - Anton indicates that he is out of the Apple II Kermit business now
and Peter should be regarded as the sole proprieter.]

    1: On Apple 2c's, the cursor produces a bogus character when placed
       over a lowercase alpha character. (Its ok after you move again).
    2: Command files, so you can set up and dial your kermit more easily.
    3: Support for the Videx and Apple 2c/e 80-column cards. (This is more
       easily said than done. If you want to know why, ask me.)
    4: Support for more varieties of serial interface (my current project).
    5: A better bootstrapping procedure.
    6: Server capability (a real toughie, since most apples have no clock).
    7: VT102 emulation.
    8: ProDos kermit. I am currently awaiting the arrival of my
       order for a 'native code, optimising, ProDos Pascal compiler'.
       6502 assembler can be macho, but its also a pain in the b*tt.

If you feel like taking any of these on, please tell me about it. I have a
number of ideas (and some code) for most of them.  Everything being equal, I
expect to have a release out late summer/early fall with at least 3 and 4
fixed, more if possible.

>I am looking for a version that, in addition to the capability of V2.1,
>also handles the 80 col screen card and has the "insert-line",
>"delete-line", "delete-chars" and the "insert-chars"/"end-insert-chars"
>capability in the terminal emulation (for use with Multics full screen
>editing and menu features).  Kermit65 acting as a server would also be
>very nice.  However I don't have access to a Dec Tops/20 system to run
>the CROSS assembler so I cannot modify the source.  (And I'm not
>convinced of my capability of doing it properly anyway.)

This is the VT102 emulation I mentioned earlier. I agree, it would be nice,
and I would like to include (I use Emacs too).

>Mike Armstrong - Honeywell, Canada (from University of Calgary's Multics
>                 system).

                Peter Trei
                oc.trei@cu20b
                h: 212-5692371
                w: 212-8153711

------------------------------

Date: Wed, 26 Jun 85 20:52:43 pdt
From: Scott Weikart <cdp!scott@Glacier>
Subject: C-Kermit Line Locking Problems, Cont'd

Instead of setuid, I think it would be much better to operate setgid.  Then the
ownership of the lock file would be intact.  I put uucp, cu, kermit, etc in a
group called dialer, for such situations.  But then you have to convince your
administrator to allow /usr/spool/uucp to be writable by group (in my opinion,
this is much safer than making kermit setuid, especially if you keep regular
users out of the group).  This has one annoying side-effect; kermit will no
longer be able to create a file in a directory that's not writable by the user
but is writable by the group that the user's shell is in [this is fixable for
system 3 and 5 - i'll send the code along - but not in v7 or BSD].

Another thought; if you did something like the above which would allow the user
to own the lock file (or if you write the uid into the lock file), then maybe
you could do the following to do a multi-stage kermit.  start up a kermit,
connect, pop back to kermit and fork a sub-shell, then allow the user to start
up another kermit as long as she owns the lock file.  I think this will work,
even though the original kermit still has the tty open.  The user would not be
able to log out without exitting the original kermit.  Of course, once the user
pushes a subshell she might forget about the open line until she logs out; it
would be nice to change the prompt in the subshell, but i'm not sure how to do
it in an exec.

[Ed. - Further contributions to this discussion are welcome.  If the WHOLE
WORLD can come to a concensus about how Unix line locking should work, we can
make the program abide by it.  But then somebody has to write the installation
manual, the user manual, and the environmental impact statement...]

------------------------------

Date:  Thu, 27 Jun 85 15:22 EDT
From:  [e-mail]
Subject:  C-Kermit Problems: HP-9000, Racal-Vadic Modems, etc

I was able to get the kermit package working on our HP-9000's.  They
have a problem, however.  I can call a foreign host (even myself),
login, run kermit on the foreign host and get files from the foreign
host OKAY.  However, when I try to send stuff to the foreign host, I
have problems with packet sizes larger than 70 characters.  I viewed the
data flow through the modem with a protocol analyzer and it seems that
everything looks okay:  the sender keeps resending packets that are
NAK'ed by the foreign host.  Even with packet sizes of 70, the sender
has to resend each packet something like ten times.  At packet sizes of
around 40, the situation is much better.  i don't THINK my lines are
excessively noisy (running "log packets" on either machine seems to
support this), but I'm confused.

[Ed. - Sounds to me like HP-UX has small input buffers for its serial
ports, and can't accept bursts longer than 40-70.  Not much you can do about
this short of fooling with the kernel, or complaining to the vendor.]

Another thing:  we have racal-vadic modems that do not conform to the
protocol that ckudia.c employs.  Apparently, the old Racal Vadic's used
to send "ON LINE", and the new ones (at least the Maxwell series, as
well as the -PA and -PAR series) send "ONLINE" (your code searches for
"ON LINE").  Secondly, your code "acknowledges printout of dialing string"
by sending an extra <CR> after "(number)<CR>" when dialing the number.
The old Racal Vadic's required the extra <CR> --- the NEW ones, however,
do not.  IN FACT, the new ones abort the dialing sequence when they
receive the extra <CR>.

Obviously, I had to change these two things when I wanted to get kermit
working -- I felt you might want to pass some of this information on to
others.  The "ON LINE" vs.  "ONLINE" discrepancy is not guaranteed by
Racal Vadic to be cleared up:  some models MIGHT use one, and others
might still use the other.  The business with the extra <CR> will go
away:  I was guaranteed that Racal Vadic's won't require it from now on
(the newer models, that is).

[Ed. - Yuk.  I guess this means we another modem type has to be added to
ckudia.c -- "NewRacalVadic".  Alternatively, the code can be changed to do
something like what is done for the Hayes, which also has two ways of
answering ("verbal" and "nonverbal") -- feed it some innocuous command whose
response will tell you if it's a new or old style modem, and then set a flag
to that effect, which is used to control further interactions with it.  This
method is preferable to simply adding "NewRacalVadic" as another modem type,
because how is the poor user to know whether her Racal-Vadic is new or old?]

One question:  is there any effort by you folks to support Codex short-
haul modems in the near/distant future?  Is there any perceived need?
(actually, I guess that's two questions)

[Ed. - The new ckcdia.c module is much easier to add new modems to than the
old one was, thanks to reorganization by Dan Schullman.  Dan is currently
working on yet another release of that module; when that's ready, I'd
encourage you to add support for "NewRacalVadic" and "Codex" to it and send
it back to us.]

Thanks for your help.  ---Matt G.

------------------------------

End of Info-Kermit Digest
*************************
-------
28-Jun-85 18:10:53-EDT,10393;000000000000
Mail-From: SY.FDC created at 28-Jun-85 18:10:22
Date: Fri 28 Jun 85 18:10:22-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V2 #40
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri, 28 Jun 1985       Volume 2 : Number 40

Departments:

  C-KERMIT -
    Yet Another Unix Kermit Release (minor)
    MacKermit Observations

  MS-DOS KERMIT -
    Bug in MS-Kermit 2.28 and Tandy 2000 support
    MS-Kermit Reverse Wrap at Column 1

  MISCELLANY -
    FTP Problems on CU20B

----------------------------------------------------------------------

Date: Fri 28 Jun 85 17:12:33-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Yet Another Unix Kermit Release (minor)
To: Info-Kermit@CU20B

This is to announce C-Kermit 4C(055).  No major changes, mainly just some
enhancements to the dial command, support for a some additional systems and
modems.  Here, for those who understandably have a hard time keeping up with
all this, is a list of changes since 4C(052) was announced on June 18:

C-KERMIT FOR UNIX, CHANGES FROM 4C(054) TO 4C(055), 28 JUNE 85:

ckudia.c (all changes by Dan Schullman, DEC):
. Add support for US Robotics modem (untested) from Joe Orost at Berkeley.
. Reorganize MDMINF data structure to accommodate US Robotics (some char
   fields had to become strings).
. Allow interrupts (SIGINT, e.g. ^C) to cancel dialing in progress.
. Ring bell when connection made successfully.
. Close line on failures.
. Allow stored numbers with DF100 and 200 modems.

ckudia.c now supports the following modems:
. Cermetek Info-Mate 212 A
. DEC DF03-AC
. DEC DF100 Series
. DEC DF200 Series
. General Data Comm 212A/ED
. Hayes Smartmodem 1200 & compatibles
. Penril
. Racal Vadic
. US Robotics 212A
. Ventel
Plus "unknown" modems and direct (modemless) connections.

C-KERMIT FOR UNIX, CHANGES FROM 4C(053) TO 4C(054), 25 JUNE 85:

ckuker.mak (makefile):
. Add "make ft17" for Fortune 16:32 For:Pro 1.7.
. Add "make uts24" for Amdahl UTS 2.4
. Add "make valid" for Valid Scaldstar CAD system
. Add "make c70" for BBN C/70 IOS 2.4

ckcmai.c:
. Add call to sysinit()

ck[uvm]tio.c:
. Add sysinit() function.  For VMS, open console.  For others, null for now.

ckutio.c, ckufio.c:
. Add support for Fortune 16:32, mostly like 4.1bsd.
. Ditto for Amdahl UTS 2.4, mostly like V7.

ckuus2.c:
. Expand a couple tabs in hlp1 (-h help message) so things line up right.


C-KERMIT FOR UNIX, CHANGES FROM 4C(052) TO 4C(053), 21 JUNE 85:

ckcfn2.c:
. Change dopar() to be of type CHAR.
. Fix dopar() to calculate odd parity correctly.

ckucon.c, ckuscr.c:
. Add "extern CHAR dopar();" declarations.

The files, as usual, are in KER:CK*.* on CU20B, available via anonymous FTP.
There's no real need to get them unless one or more of the changes listed
above is of use to you.

------------------------------

Date: Fri 28 Jun 85 10:32:33-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: MacKermit Observations
To: manis%ubc.csnet@CSNET-RELAY
In-Reply-To: Message from "Vincent Manis <manis%ubc.csnet@csnet-relay>"
 of Thu 27 Jun 85 22:49:46-EDT

    >Date: Thu, 27 Jun 85 19:42:15 pdt
    >From: Vincent Manis <manis%ubc.csnet@csnet-relay>
    >To: info-kermit@CU20B
    >Subject: MacKermit
    >
    >I've been using MacKermit for a week or so (0.8 (28)), and would like
    >to know whether the following are intended to be fixed:

We're up to 0.8(32) now...

    >1) If I tell my local Unix that I'm a VT100, emacs has difficulty
    >   refreshing the screen properly. Is the VT102 emulation imperfect,
    >   or simply different enough from the VT100 that I should make a new
        >   termcap entry?

We use Mac Kermit with EMACS (both CCA and GNU) at 9600 baud on our VAX/Unix
system and have not seen this problem.  We tell it we're a VT100 since our
EMACS's (or termcaps) don't yet have support for VT102.  See if 0.8(32)
exhibits the same behavior.

    >2) I'd like the ability to include an initial character string to send
    >   automatically when I fire up a settings document. This would
    >   provide some modem support (even if not terribly well).

A reasonable idea; we'll add it to the list of things to do.  A lot of other
things have higher priority though, like screen save/print, saving lines off
the top, cutting/pasting the screen, sizing the screen, allowing international
character sets, etc.

    >3) Any possibility of mouse support (clicking the mouse somewhere away
    >   from the current cursor position would send the requisite cursor
    >   positioning string)?

I doubt it.  The program is already straining the limits of a 128K Mac.

    >4) Why doesn't KerKey have the ability to create a new settings
    >   document?  Why can't the settings menu from MacKermit be included
    >   in KerKey as well?  This would allow one to create a complete
    >   settings file at one time.

Simply a question of not having enough time to write the code.

    >5) I've had some sort of transient behaviour in which the first file
    >   transfer in a session works ok, but subsequent ones just hang.
    >   Firing up MacKermit again seems to cure the problem, but it's a
    >   nuisance. (On the Unix end, this happens with both CKermit and the
    >   old Unix Kermit, but not with enough regularity for me to pin it
    >   down).

You're not using parity, are you?  If so, get 0.8(32), which fixes problems
with parity.  Otherise, it's hard to know what to say about this without more
details about what machine, what Unix, what version of C-Kermit, what kind of
connection, what baud rate, etc etc.  This kind of behavior is always a
possibility between any two Kermits and usually has more to do with the
operating systems or communications equipment that Kermit itself.  For
instance, if you're running 4.2 bsd on a VAX with DMR's, you might be suffering
from problems in Berkeley's DMR driver.  Some other systems just get tired of
allocating tty buffers after a while...  We've used MacKermit to transfer very
large batches of files at high baud rates without observing any consistent kind
of failure.

    >6) The key in the upper right hand corner is labelled ``Backspace''.
    >   By default it should generate a backspace.

Matter of taste.  You can always type a backspace using CTRL-H, but how do you
type a DEL if there's no DEL key?  Anyhow, that's what KerKey is for -- so
people who don't like the defaults can change them.

To be perfectly honest about the situation, Mac Kermit is "between maintainers"
just now.  The last two people who worked on it have both left, so I expect it
will stay pretty much as it is for quite some time.

- Frank

------------------------------

Date: Thu, 27 Jun 85 19:04:46 cdt
From: [e-mail] (Phil Goldberg)
Subject: Bug in MS-Kermit 2.28 and Tandy 2000 support

When you type 'C?' from the command prompt, instead of getting a 'Confirm with
CR' message as in 2.27, you get a list of all commands from C-Z displayed.
Since C is a valid command, isn't this a bug.  I looked, but I couldn't figure
it out.

[Ed. - Hmmm... must have something to do with C being a synonym for CONNECT
(necessary because of the addition of the CLEAR command).  Added to the list of
bugs, KER:MSKERM.BWR.]

Steve Alexander has done mods to MSX/YIBM to get a Tandy 2000 module for
v2.28.  He swears up and down that this time he will send them in.

                    Phil Goldberg
                    goldberg@Uiuc
[Ed. - Hope so...]

------------------------------

Date: Thu, 27 Jun 85 17:44:22 pdt
From: gts%ucbpopuli.CC@Berkeley (Greg Small)
To: info-kermit@cu20b
Subject: MS-Kermit Reverse Wrap at Column 1

The backspace from column 1 to column 80 of the previous line was added for
UNIX.  For normal input echoing, UNIX assumes that the terminal handles all
margin wraping.  This includes both the normal forward wrap at the right margin
and the less known reverse wrap at column 1.  Many newer terminals do both.
ANSI X3.64 enumerates some margin actions but does not specify any.

Of course this only impacts those who enter and then wish to erase characters
from lines longer than 80 characters.  I had thought than no one would care,
but our beta test release of MS-Kermit 2.27 turned up a number of users who
complained that they could not erase characters accross the line wrap.

I confess that I am not overly concerned with exact emulation of the
limitations of the H19, our priority is delivering functionality.  However we
do try to avoid extensions which are likely to cause dificulties.  Actually,
we have abandoned pretending that a particular program emulates a real
terminal.  We now treat each emulator and version thereof as a seperate
terminal type.


Greg Small                              [phone]
Microcomputer Communications            [e-mail]
214 Evans Hall CFO                      ucbvax!ucbpopuli!gts
University of California                [e-mail]
Berkeley, Ca 94720

------------------------------

Date: Thu, 27 Jun 85 17:16:57 pdt
From: [e-mail] (David Ragozin)
Subject: FTP problems on CU20B

Today I tried to FTP some of the vms*.mar files on k2:.  None of them
would come.  Each time I tried (with "TYPE ASCII") I received the
error message: File not 7-bit - not text file.  That sounds to me like
a problem at your end, not mine.  Could you have someone check it out?

[Ed. - Oops!  The bytesize was indeed 36, rather than 7.  This is fixed
now.  Surprised nobody reported this before.  In fact, all the following
files had 36-bit bytesizes, which are now changed to 7:

    AP2KER.ASM
    AP2KER.TXT
    APPLEK.M65
    CP4CPT.HEX
    CPMH8.HEX
    CPMPRO.HEX
    K10MIT.CCL
    K10V3.MEM
    MTSKERMIT.ASM
    MTSKERMIT.DOC
    MTSKERMIT.PAS
    PROV1.MEM
    RTED.TXT

Sorry for the confusion; most of these files were created by TOPS-10
utilities that run on our DEC-20 system.]

Also, is there some reason you know why I haven't been able to get any
response from KERMSRV on BITNET for many days?

[Ed. - KERMSRV has been undergoing reorganization the last few days.
Should be up now.]

------------------------------

End of Info-Kermit Digest
*************************
-------