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

Text File | 2020-01-01 | 554KB | 13,286 lines

2-Jul-85 19:54:13-EDT,10370;000000000000
Mail-From: SY.FDC created at  2-Jul-85 19:53:39
Date: Tue 2 Jul 85 19:53:39-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #1
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Tue,  2 Jul 1985       Volume 3 : Number  1

                  New Release of Kermit-11 Available
        Unix Program for Converting CU20B FTP Server Filenames
                      Mac Kermit & Caps Lock Key
              IBM PC Kermit and National Character Sets
                  MS DOS Memory Allocation in Kermit
                         More about ND-Kermit
                       Kermit Versus 9600 Baud

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

Date: Tue 2 Jul 85 19:50:57-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: New Release of Kermit-11 Available
Keywords: Kermit-11

Brian Nelson of the University of Toledo (BRIAN@UOFT02) has sent in version
2.29 of Kermit-11, replacing version 2.26 of March 1985.  The changes include:

. Fix losing attribute packets in case timed out or nak'd.
. Fix ASSDEV: for stack problem
. Added SET BINARY-TYPE .xxx for overriding the built-in binary file type list.
. Kludge if RT system does not have a clock.
. Ignore TYPE in SET FILE [TYPE] arg.
. Final mods by Ned Rhodes for TSX+
. Add support for server REM DIR command for RT and TSX+.
. Fix bug for setting 8bit prefixing (quite noticable on PRO/RT version).
. Add SET FIL [NO]SUPERCEDE to protect files that already exists.
. Update packet types to symbolic names

The files are available via anonymous FTP from CU20B as K2:K11*.* (many files).
General information is in K2:K11AAA.AAA.  The files are listed and explained
in K2:K11FIL.DOC.  Installation instructions are in K11INS.DOC.

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

Date: Tue 2 Jul 85 15:50:57-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Unix Program for Converting CU20B FTP Server Filenames
Keywords: FTP Server, UNIX

Many have complained that when getting (especially "mget"ing) files to a Unix
system from the CU20B FTP server, the resulting filenames are not what would
be desired.  This problem is partially fixed by the installation of a new FTP
server that allows users to CWD (CD) to a given directory for read access, so
that the fully qualified file name need not be sent back for each file gotten
with an "mget".

However, even if you CWD to KER: or K2: before issuing an mget command, the
files will still show up with uppercase names and will include "generation"
(version) numbers.  And of course, if you fail to CWD first, you still get
the directory name too, so that you are likely to find files with names like

<KERMIT>CKUFIO.C.3

in your Unix directory, rather than the ckufio.c you might have wanted.

A new program, xxu (20-to-Unix filename converter), is available in KER:XXU.C
which will fix the names of all files sent to a Unix system from a DEC-20 FTP
server.  It should work on VMS and DEC-20 filenames alike -- it strips DECnet
node names, device names, directory names, generation numbers, and it
lowercases the uppercase letters.  When renaming to the name thus formed, it
takes care not to write over any existing files.  See comments in the source
for further details.

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

Date: Fri 28 Jun 85 15:52:03-EDT
From: Mauricio Matiz <US.MATIZ@CU20B>
Subject: Mac Kermit & Caps Lock Key
Keywords: MacKermit

Now that Kermit for the Macintosh has a keymap program that allows mapping of
the control key to the caps lock key, the locking mechanism becomes a
nuisance.  There have been postings about taking the whole keyboard apart and
using a soldering gun, etc. in order to remove the locking mechanism.  I have
come up with a simpler and easier method that does not void your warranty.

Remove the key using a small screwdriver.  There is a spring and the end of
it goes through the plastic that supports the key. Stick a piece of paper or
soft putty (very small) between the tip and the bottom of the keyboard.  This
will prevent the key from depressing all the way and locking, but still allow
contact of the key.  It even works for repeating control characters.  If you
come up with a better substance to stick in there let me know (or the Kermit
people at Columbia).  I have been using this for some time with no problems.
I imagine that after a while I will need to change the paper because of the
continued pressing on it.

Maurice Matiz
Columbia University
User Services

[Ed. - As usual, neither the author of this message nor Columbia University
acknowledges any liability for damage or loss of warranty incurred by anyone
who follows these directions.]

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

Date: Sat, 29 Jun 85 14:43:27 -0200
From: Frithjov Iversen <iversen%vax.runit.unit.uninett@NTA-VAX>
Subject: IBM PC Kermit and National Character Sets
Keywords: MS-DOS Kermit

A suggestion for IBM PC Kermit: You must be aware of that many european
characters have a different internal representation on the IBM PC and other
computers.  The norwegian alphabet, for example, has 3 extra characters,
which in normal ASCII replaces [\] (upper) and {|} (lower case).  On the IBM
PC, all these characters are represented with values in the range 128-255.
This means that every terminal emulation program (to have a chance on the
Norwegian market) must include an option to convert between the two
standards, both when acting as a terminal and when transferring files.

We have a local mod to MSSET and MSYIBM which fixes the terminal problem,
and provide a converting program on the Kermit diskette to convert the text
files.  However, I feel that this must be a problem in other European
countries, and I was hoping for a more general solution.

The SET KEY feature will make it possible to do terminal emulation with a
"national" keyboard, but the right characters will not appear on the screen.
Why not include a SET FONT command?  For Norway, all that would be needed,
was 6 SET KEYs and 6 SET FONTs in a macro defined in MSKERMIT.INI, and we
could do without the local mods.  As to transferring files, I prefer the
"raw" approach, and leave conversion to the user.  When transferring MASM or
PASCAL programs, I do not like to see my square brackets turn into
you-know-what.

[Ed. - Good idea, though I'm not sure if you mean "set font" or "set
character".  A font would be a whole character set, presumably some
alternate character set in ROM, invokable by changing some pointer.  This
would probably be easy to implement, though the details would be very
system-dependent.  Changing how individual characters display would be
harder, not so much to implement, but to design the command -- the user
would need to say something like "if I get a character whose ASCII value is
x, then display character y from font z in its place..."]

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

From: [e-mail]
Date:   30 Jun 85 14:19 EDT
Subject:  MS DOS Memory Allocation in Kermit
Keywords: MS-DOS Kermit

Well, I finally found the problem with memory allocation and (Microsoft) I
was missing something crucial. KERMIT as part of its memory initialization,
gives extra memory back to DOS explicitly. Unfortunately, the calculation of
the image end assumes that the stack segment is not last.  My apologies to
those people that I confused from an incomplete investigation of the
problem. I still object to the IBM versions of Micro- softs programs being
built with new defaults, but in this case it only confused matters instead
of being the root of the problem.

To address the issue of memory allocation directly, if segment ordering
becomes so important, perhaps the required space should be calculated from
the load module image size and not from the offset of a specific object file
in KERMIT.  Is there some reason why this is undesireable?

Jerry Lotto     [e-mail]      inhp4!harvard!lhasa!lotto

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

Date: Sat, 29 Jun 85 14:43:27 -0200
From: Frithjov Iversen <iversen%vax.runit.unit.uninett@NTA-VAX>
Subject: More about ND-Kermit
Keywords: ND Kermit

The operating system of the ND series computers is SINTRAN III.  Versions are
numbered with the letters A,B,..  The Kermit I sent you runs under version J,
and needs the Pascal-J compiler and library.  The binary program,
KERMIT:PROG, should run under previous versions, at least back to H.

Anyone who sends us a self-adressed diskette envelope with one 148-page 8" ND
diskette (two if you need source code), will receive the latest version of
ND-Kermit for free.  There are plans to include SERVER and CONNECT later this
summer.

          Frithjov Iversen
          RUNIT Brukerkontakt
          N - 7034 Trondheim-NTH
          NORWAY

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

Date:  Sat, 29 Jun 85 22:56 EDT
From:  [e-mail]
Subject:  Kermit Versus 9600 Baud
Keywords: Modem, Sliding Windows Kermit

I've been experimenting with a 9600 bps dialup modem.  It is cheap (about
$800).  It is really a half duplex modem that provides a full duplex
interface and a reliable byte stream.  This is fine, except when one uses
protocols such as Kermit and Xmodem which have only a single packet in the
stream at a time.  It takes .5 seconds or more to turn around the line.  Thus
sending a packet, acking and sending the next one reduce one to 1 second/
package or about 900 bps for kermit and about 1200 for Xmodem.  This is the
same as the problem of satellite links.

Given that such modems make a lot of sense since they make more effective use
of the bandwidth for file transfering than true full duplex modems, what
thought has been given to upgrading Kermit to allow for a protocol that can
have multiple packets active at once?

I presume that there has already been much discussion of this, but now that
it is my ox being gored, I have a special interest in this issue.

[Ed. - For a couple years, people have been asking for (a) a sliding window
extension to the Kermit protocol, and (b) a way to have longer packets.
Some people are working on a sliding window protocol, and a proposal will
be posted to Info-Kermit some time soon.  At the same time, I'll also post
a proposal for a way to allow longer packets.]

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

End of Info-Kermit Digest
*************************
-------
 9-Jul-85 18:04:18-EDT,20303;000000000000
Mail-From: SY.FDC created at  9-Jul-85 18:03:13
Date: Tue 9 Jul 85 18:03:13-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #2
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Tue,  9 Jul 1985       Volume 3 : Number  2

                 KERM and KERK Registered with Apple
                           Okstate Downtime
               Re: MS-Kermit 2.28 Wraparound Backspace
                            MASM & Kermit
                       C-Kermit on HP-9000 S500
                        C-Kermit Line Locking
                          UUCP Line Locking
              Running Pro-3xx P/OS Kermit from Tool Kit
                         Bug in Prime Kermit
                      More about 9600 bps Modem
             More about PC-Kermit and National Characters
                   Z100 Comunications Program Query
                        Kermit on MicroVAX-1?

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

Date: Mon 8 Jul 85 18:04:31-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: KERM and KERK Registered with Apple
Keywords: Macintosh

The Macintosh application names KERM and KERK have been registered with
Apple for Macintosh Kermit and for the Macintosh Kermit Keyboard
Configurator, respectively.  These names allow "documents" (e.g. settings
files) created by these programs to be associated with the programs
themselves so that double clicking such a document will invoke the program
with the indicated settings.

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

To: [e-mail]
Subject: Okstate Downtime
Date: 09 Jul 85 06:43:11 CDT (Tue)
From: [e-mail]
Keywords: Okstate

The system `Okstate' will be down for hardware and software upgrade from
8:00 a.m. July 17th until 5:00 p.m. July 22 (all times central).  During
this time the UUCP and Kermit Server line used for the Kermit Distribution
will not be available.

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: Tue, 2 Jul 85 18:20:31 pdt
From: [e-mail] (Dave Tweten)
Subject: Re: MS-Kermit 2.28 Wraparound Backspace
Keywords: MS-DOS Kermit, UNIX

In Info-Kermit Digest, volume 2, number 40, Greg Small writes:

    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.  Of course this only impacts
    those who enter and then wish to erase characters from lines
    longer than 80 characters.

That confuses me.  My impression is that bsd UNIX uses curses and termcap
entries to perform terminal independent smart terminal operations.  This
includes simulation of wrap-around backspace for terminals whose termcap
entries do not contain the "bw" ("backspace wraps") specifier.

My impression is reinforced by observation of "vi" behavior with long lines.
I used MS-Kermit 2.27 (which correctly emulates H-19 backspace behavior) in
linewrap mode.  On multi-row lines, right arrow and space moved me from
column 80 on one row to column 1 on the next.  Left arrow and backspace
moved me from column 1 to column 80 of the previous row.

    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.

This seems to me to be a sad commentary on the current state of design and
implementation of most terminal emulation packages.  It is also a little
frightening to consider what this means if you multiply the number of
available terminal emulators (say, for just the vt-100) times the number of
different operating systems which think they know about the terminal being
emulated.

Particularly in the case of Kermit, where Columbia and the user community
have control over the quality of the emulation, it seems to me to make much
more sense to emulate the H-19 well enough that it fools (almost) all the
systems which think they know about it.  Users whose systems require a more
faithful emulation than is currently provided should be encouraged to
contribute Kermit code modifications.

Finally, let me reiterate that though I believe strongly in faithful
emulation, and though I can't see how UNIX could require wrap-around
backspace, I don't think wrap-around backspace represents a serious
deviation from the ideal H-19 emulation.  I can't imagine that it is common
for programs to send column-1 backspaces to H-19s, realizing that they will
be ignored.

[Ed. - We have received a couple H-19 (Z-19) manuals in response to our plea a
couple issues ago (thanks to those who sent them!), so we should now be able to
emulate this terminal more faithfully...]

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

From: [e-mail]
Date:   28 Jun 85 11:18 EDT
To: harvard![e-mail]
Subject: MASM & Kermit
Keywords: MASM

If you are building KERMIT with the Microsoft assembler (any version) or the
IBM release (pre 2.0) all will work as written.  If however, you are using
MASM 2.0 or later (IBM release) you must specify the /S switch on the command
line for MSXDMB.  Be sure the Linker you are using does not predate the
version of DOS by too much.  Also, make sure you actually DO have enough
memory to run KERMIT in.  A fairly significant chunk of RAM is used by the
new KERMIT, but unlike the previous version, it is allocated by the program.

Gerald Lotto - Harvard Chemistry Dept.

 UUCP:  {seismo,harpo,ihnp4,linus,allegra,ut-sally}!harvard!lhasa!lotto
 ARPA:  [e-mail]
 CSNET: lotto%harvard@csnet-relay

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

Date:  Wed, 3 Jul 85 12:16 EDT
From:  [e-mail]
Subject:  C-Kermit on HP-9000 S500
Keywords: C-Kermit, HP9000

I solved that packet-size problem I was having (calling out and trying to
send from my HP9000 Series 500).  Apparently, I have to tell the remote host
that I am a vt100, or I get into problems.  At least, when I did call myself
a vt100, I was able to send with no problems.

The obvious inconvenience hewith this is that since I really am using an
HP2392A terminal, fun things like EMACS die big if I'm trying to use Kermit
in the same login session.  Oh, well.

[Ed. - Could it be that by telling the host you are a VT100, you turn on
its XON/XOFF flow control?  Maybe you could tell it you're an HP terminal,
and also tell it to use XON/XOFF, and all will work well.]

A note to HP9000 users out there ( if there are any!):  Kermit cannot
use an ASI card interface to a modem if it is to call outside.  It needs
to be talking to a MUX board port (properly addressed by read-writeable
ttyxx, cuaxx and culxx files in /dev).  Since the ASI board took care of
neat items such as telling the modem to hang up when it's done with it
(using signal lines), and the MUX board cannot, we installed new chips
in our Racal-Vadic's (from them) to interpret a ^C^D sequence flanked by
3 seconds of dead air on either side as a "hangup".  Thus, I modified
the Kermit code to echo a "^C^D" to the communications port when exiting
Kermit.  Perhaps the best way to do this, would be to modify the
ckudia.c MDMINF struct to include a "hangup_str" parameter.  Unless of
course, this is too obscure a scenario...

One further note: ^\^F still doesn't abort a file transfer that is hung up;
neither does ^\^B, for that matter.  Does the transfer have to be at least a
little successful ( a few packets here and there) for this to work?  If so,
perhaps it is suboptimal?

[Ed. - Right, interrupting a transfer with [^\]{^F,^B} only takes effect
after the first data packet has passed.  So there's no good way to interrupt
a Unix Kermit that's stuck trying to start a file transfer, short of ^C'ing
it to stop the program all together.  This is noted in the .BWR file.]

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

Date: Sun, 7 Jul 85 10:14:48 pdt
From: [e-mail] (Dave Tweten)
Subject: C-Kermit Line Locking
Keywords: C-Kermit

In Info-Kermit Digest, volume 2, number 39, Scott Weikart writes about
Kermit line-locking:

     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.

I agree that the group mechanism is the appropriate tool to use.  On our Vax
780, 4.2 BSD system, the system administrator has established a similar
group.  The dial-out ttys are owned by the group and are given owner and
group access, and so is /usr/spool/uucp.  That way, using /etc/groups, we can
admit users to the group who have a valid need to dial out.  We thereby
reduce our exposure to the phone bills which would result from someone
dialing into his favorite Timbuktu bulletin board all day.

To make this system as consistant as possible, we have modified C-Kermit
to make the /usr/spool/uucp "no read access" and "no write access"
warning messages be preventive messages instead.  That way, if an access
specification mistake has been made, there is less likelyhood of Kermit
users, tip users, uucp, etc. stomping on one another.

As I see it, the problem can be resolved for all sizes of systems.  In a
small system, with a tight group of users, make /usr/spool/uucp and the ttys
publicly accessible.  With a larger system, make them group accessible, and
only admit to the group those with a legitimate need to contribute to the
size of the phone bill.

The concern over users' ability to get their work done is resolved by
realizing that on a system which is small and tight-knit enough for public
access to be appropriate, the "system administrator" is likely to be very
accessible (if "he" is not, in fact, just a hat worn by any of several users
when doing system administration tasks).  In a larger system, the
administrator has a legitimate need to control access.

I do believe, though, that Kermit's /usr/spool/uucp access warnings should be
made preventive.  I believe this for the very reason you (the Info-Kermit
Digest editor) stated in volume 2, number 38:

     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.

With its current access warnings, C-Kermit is just such a program.

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

Date: Sun, 7 Jul 85 14:53:48 pdt
From: "Scott Weikart; Community Data Processing; 415-322-9069"
 <cdp!scott@Glacier>
Subject: UUCP Line Locking
Keywords: UUCP, C-Kermit

Ken Poulton had talked about wanting to have one kermit process open a
circuit, and then have other kermit processes use that same circuit.  His
scheme was to have a kermit exit command that wouldn't close the line.  This
scheme has the problem that people will forget to release the tty.  I had
suggested an alternative scheme of having subsequent kermits run in a
subshell of the kermit that opened the circuit, so that when you tried to
log off you would pop back into the parent kermit and then exit it and
release the line.  I had also suggested that on those systems where
lock-file directories are not accessible by the world, that kermit be run
setgid in a group which has write accesss to the lock-file directory, so
that a) kermit wouldn't have to be setuid and b) the lock file would be
owned by the user account so that subshell kermits could see if their user
owned the tty lock-file.  If people wanted kermit to run setuid, I had
suggested writing the account name into the lock-file, so that subshell
kermits would just read the lock-file to see if their user had reserved the
tty.

What follows is a discussion in usenet about a similar problem.  The last
note indicates that Honey Danber UUCP uses a similar scheme: it writes
the process ID (PID) into the lock-file.  So if kermit used this scheme,
a subshell kermit could read the lock-file and see if its contents match
kermit's PPID (parent PID), as gotten by getppid().

[Ed. - Kermit actually does write the PID into the lock file, but currently
does not use it for anything.  Note that not all Unix systems have getppid().]

>>The problem with tip is that, after locking the modem port, it
>>setuid's back to the original invoker's uid/gid.  This is
>>supposed to patch the security hole surrounding shell escapes
>>and file transfers.  Fine but; alas; it doesn't read /etc/phones...

    Another problem this causes involves /usr/spool/uucp security and LCK
    files.

    It is desirable to have /usr/spool/uucp NOT WRITABLE by the world, as
    this leaves a hole for (admittedly clever) vandalism.

    However, with the 4.2BSD version of `tip', this causes the LCK files to
    be left around after `tip' exits, preventing use of the port until
    manual intervention by a "privileged user".

    `tip' creates the LCK file while SUID, and no longer has write
    permission in /usr/spool/uucp once it changes the UID.  The LCK
    file therefore remains.

    For binary sites the only "solution" seems to be to leave this
    directory writable.  Yuck.

    /+\ Keith F. Pilotti

        (UUCP) {decvax,ucbvax}!sdcsvax!telesoft!pilotti
        (ARPA) Pilotti@UCSD

a possible solution is to follow honey danber's lock file treatment.
assuming tip's lock files have the same format as uucp's, the lock file
contains the pid of the process that created it.

write a program that reads the lock file and issues signal 0 to the named
pid.  if the return is 0 or EPERM, the lock file is valid, otherwise it
should be removed.  if binary license is a problem, make tip a shell script
that calls tip, then this program.  i leave the details to your imagination.

    peter

[Ed. - Let's keep this discussion going until some kind of concensus is
reached.  My concern is that whatever mechanism is settled upon is rational,
humane, simple, installable, maintainable, and explainable.]

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

Date: 7 Jul 85 19:01:41 EDT
From: D. M. Rosenblum <DR01@CMU-CC-TE>
Subject: Running Pro-3xx P/OS Kermit from Tool Kit
Keywords: Pro-3xx P/OS Kermit

Users of PRO/Kermit may be interested to know that PRO/Kermit can be run from
PRO/Tool Kit, instead of from the main P/OS menu.  This is useful if you are
in the habit of going directly into PRO/Tool Kit and doing everything from
there.  Here's how to do this.

Suppose you have installed PRO/Kermit in a menu on a hard disk system.
KERMIT.TSK will be in a directory of the form [ZZAPnnnnn], where nnnnn is a
system-dependent five-digit number (you will have to do some hunting to find
which such directory KERMIT.TSK is in).  PRO/Tool Kit's START.CMD and
EXIT.CMD files will also be in a directory of the form [ZZAPmmmmm] (where
mmmmm is not equal to nnnnn).  You should APPEND the following lines to
[ZZAPmmmmm]START.CMD, replacing [ZZAPnnnnn] throughout by the name of the
directory in which KERMIT.TSK resides.

;
;    Install PRO/Kermit Version 1.0
;
;    Note that the reference to [ZZAPnnnnn] in the line that installs
;    KERMIT must be changed if PRO/Kermit is removed from the menus and re-
;    installed there.
;
    .DISABLE QUIET
    .IFNINS KERCON INSTALL [ZZKERMIT]KERCMN
    .IFNINS KERCON INSTALL [ZZKERMIT]KERCON/NOREMOVE
    .IFNINS KERFIL INSTALL [ZZKERMIT]KERFIL/NOREMOVE
    .IFNINS KERMIT INSTALL [ZZAPnnnnn]KERMIT
    .ENABLE QUIET

(the PRO DCL indirect command processor has no way of testing to see whether a
common region has been installed, so you have to instead check to see whether
some task, that you're careful to have installed if and only if that common
region is installed, has been installed in order to determine whether the
common region has been installed -- this makes the order of the commands in the
START.CMD file important).

You should also append the following lines to [ZZAPmmmmm]EXIT.CMD.
;
;    Remove PRO/Kermit Version 1.0
;
;    Note that we do not remove KERCON, KERFIL, or KERCMN (which is a
;    common region), since the first two are normally installed with the
;    /NOREMOVE option (when Kermit is run from the menu in P/OS), and the
;    third is not normally removed when Kermit is exited.
;
    .DISABLE QUIET
    .IFINS KERMIT REMOVE KERMIT
    .ENABLE QUIET

If you are on a diskette system, all references to directories [ZZAPmmmmm] and
[ZZAPnnnnn] should be replaced by [ZZAPPL].  Otherwise, as far as I can tell,
the procedure is the same (I don't have access to any diskette-based PROs, so
I can't tell if this really works -- in other words, it's untested).

Once you have made these additions to the .CMD files, all that you have to do
in Tool Kit to run PRO/Kermit is issue a RUN KERMIT command.  You will then be
in Kermit's top-level menu, and you may proceed as usual.  When you exit
PRO/Kermit, you will be back in Tool Kit.

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

Date: Wed 3 Jul 85 00:13:21-PDT
From: Bob Larson <[e-mail]>
Subject: Bug in Prime Kermit
Keywords: Prime Kermit

Testing the new os9 kermit, I found another bug in Prime kermit.  When in
server mode, Prime kermit will Ack an 'R' packet, then send a Send-Init
packet.  According to the protocol manual, it is not suposed to send the
'Y' (Ack) packet.  I had to modify the os9 kermit to ignore the extra Ack.

[Ed. - If Prime Kermit really does this, it's a bug.  I've forwarded Bob's
message to the Prime Kermit authors.]

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

Date:  Wed, 3 Jul 85 21:24 EDT
From:  [e-mail]
Subject: More about 9600 bps Modem
Keywords: Modem

Since a few people are asking me about the modem I mentioned, I will pass on
the information.  This is for informational purposes only and is not a
comment pro or con:

It is the UPTA96 modem from Electronic Vaults, Inc.  Their phone number is
703-883-0332.  It presents a full duplex interfaces but transmits half duplex
using its own error correcting protocol.  It can drop back to 7200 or 4800
under program control.  It uses either XON/XOFF or CTS/DTR flow control.

It is available as a standalone modem or as a board for the IBM PC.  It uses
a standard RJ11 jack.

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

Date: Fri, 5 Jul 85 15:46:22 -0200
From: Frithjov Iversen <iversen%vax.runit.unit.uninett@NTA-VAX>
Subject: More about PC-Kermit and National Characters
Keywords: MS-DOS Kermit

What I had in mind, is what you refer to as SET CHARACTER.  Anyway, the
feature need not include the ability to switch between different font sets in
ROM.  It could be implemented as a simple 256-byte lookup-table.  When ASCII
<xxx> comes in,look it up, and it turns into <yyy> before sending it to the
screen.  One may assume that the National character ROM already is in effect.

-fi

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

Date: Tuesday, 2 July 1985  11:43-MDT
From: Dave Shanks <[e-mail]>
Subject: Z100 Comunications Program Query
Keywords: Z100 Kermit

Does anyone out there know of a good communications program for the
Heath/Zenith H/Z100 under MS-DOS which supports both the serial ports?
I am specifically looking for a program which will allow me to switch
ports on the fly.  It would be nice if the program were in the public
domain, but not necessary.  Thanks in advance.

Dave Shanks    ..!tektronix!reed!teneron!shanks
Teneron Corp.
6700 SW 105th   Suite 200
Beaverton, OR  97005
[phone]

[Ed. - Does anyone have experience using MS-DOS Kermit on the Z100 with
two ports?]

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

Date: Mon, 8 Jul 85 11:56:14 EDT
From: John Shaver STEEP-TM-AC 879-7602 <jshaver@apg-3>
Subject: Kermit on MicroVAX-1
Keywords: MicroVAX-I

Is there any experience with Kermit on the MicroVAX-1?

[Ed. - Comments appreciated, of course, about either VMS or Unix on the
MV-I, or the MV-II for that matter.]

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

End of Info-Kermit Digest
*************************
-------
12-Jul-85 18:01:20-EDT,10612;000000000000
Mail-From: SY.FDC created at 12-Jul-85 18:00:56
Date: Fri 12 Jul 85 18:00:56-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #3
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri, 12 Jul 1985       Volume 3 : Number  3

Departments:

  ANNOUNCEMENTS -
    Another Release of C-Kermit 4C for Unix, VMS, and Macintosh
    Commodore-64 Bootstrap Program in Fortran
    Assembling Apple II Kermit (AP2KER) with Apple Assembler?
    New Apple II Cross Assemblers

  OLD QUERIES ANSWERED -
    Re: Kermit on MicroVAX-I
    Re: Z100 Communications Program Query

  NEW QUERIES -
    IBM 3270/PC and Kermit?

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

Date: Fri, 12 Jul 85 16:58:22 EDT
From: SY.FDC@CU20B (Frank da Cruz)
Subject: Another Release of C-Kermit 4C for Unix, VMS, and Macintosh
Keywords: C-Kermit, UNIX Kermit, VMS Kermit, MacKermit

Yet another release of C-Kermit 4C, this one is 4C(056), for Unix, VAX/VMS,
and the Apple Macintosh.

Major differences from 4C(055), affecting all systems:

. Various file transfer performance improvements.
. Another bug with 8th-bit-prefixing negotiation fixed.
. Some bugs fixed concerning interrupted file transfers.
. Incoming Z (EOF) packet now ack'd only after file successfully closed.
. Allowance made for ACK to F packet containing alternate file name.
. "Blank lines" in packet stream no longer NAK'd.
. Test for echoed packets fixed.
. Input buffer now flushed only after desired packet is read.
. Many minor fixes and cleanups.

Unix and VMS only:

. "statistics" and transaction log now include timing information.
. "set incomplete {keep,discard}" is now implemented.
. "show parameters" redesigned and has some inaccuracies fixed.
. "echo" now accepts \ooo octal escapes, e.g. "echo foo\007bar" will now beep.
. "set prompt" now accepts argument in doublequotes to allow blanks.
. Command parser now accepts comment lines starting with "%".
. It is now possible to exit protocol at any time by typing ^A^C^C<CR>.
. Manual chapter updated to reflect above changes.

Unix only:

. 4.xBSD performance improved by doing nonblocking reads, own buffering
  (Herm Fischer's Sys III/V code adapted to work for BSD).

VMS only:

. Version numbers should now be stripped from outbound file names.
. Improved build procedure (CKV*.COM).

Macintosh:

. No Mac-specific changes were made, but the changes made to the system-
  independent protocol modules should fix a couple problems that reportedly
  prevented all C-Kermits from communicating with systems that send "blank
  lines" between packets, with systems that echo packets, and with Kermits
  that know about 8th-bit prefixing but refuse to do it.  The new Mac Kermit
  release is numbered "0.8(33)".

The new release has been tested under 4.2bsd, Pro/Venix V1, and on the
Macintosh against normal systems like DEC-20's and VAXes as well as against
IBM mainframes both in line mode and with full screen 3270 protocol
conversion (thru Series/1).  The VMS version has not been tested (feedback
welcome).

Thanks to Larry Afrin, Gary Algier, Todd Booth, Kelvin Nilsen, Ken Poulton,
Dan Schullman, Ed Schwalenberg, and others for reporting problems and/or
suggesting fixes since the last release of C-Kermit 10 days ago.

The new files are in K2:CK*.* on CU20B, available via anonymous FTP.
The updates are listed in greater detail in the files K2:CK*.UPD.  The files
K2:CK*.BWR list known bugs and restrictions.  K2:CKUKER.DOC is the new
Kermit User Guide chapter for Unix Kermit (not yet integrated into the
monolithic Kermit User Guide, KER:KUSER.DOC).

Since C-Kermit continues to change, it is not recommended that you get these
files unless:

(a) You are having problems with your present version that might be fixed
    by the changes listed above;
(b) You are doing development work based on the C-Kermit source (always try
    to work from the latest sources!).

It is expected that these new files, along with others recently announced,
will be available via uucp at okstate shortly after okstate comes back up on
July 22 or thereabouts, and will also be available on BITnet via KERMSRV at
CUVMA probably next week.

As usual, send comments, suggestions to Info-Kermit@CU20B.

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

Date:      10:23:48 07/11/85 (85.192)
From:      Jeff Balvanz <GM.JLB @ ISUMVS>
Subject:   Commodore-64 Bootstrap Program in Fortran
Keywords: Commodore 64

This is a Fortran version of the download program C64BOOT designed to
bootstrap the Commodore-64 version of Kermit from our VAX system.  It should
work with minor modifications with any system running Fortran-77.

[Ed. - Thanks, now we have one in each of Fortran, C, Simula, and Clu --
quite a collection -- in KER:C64BOOT.* (.FOR, .C, .SIM, .CLU; pick your
favorite.)]

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

Date: Fri, 12 Jul 85 08:52:18 MST
From: slesh@FTH-1
Subject: Assembling Apple II Kermit (AP2KER) with Apple Assembler?
Keywords: Apple II DOS Kermit

    Assembling and using the Apple Assembler/Editor version of Kermit
is NOT a straightforward proposition.  (The following comments are based
upon as little expertise with Apple 3.3 DOS and the assembler as I could
acquire in the process of getting an Apple DOS Kermit.)  A few of the little
quirks I have discovered THE HARD WAY follow:

    1-     if you obtain the source ( ap2ker.asm ) using a
    communications program which runs under another operating system
    and permits text files larger than 32K (e.g. CP/M 80), you will not
    be able to convert the resulting file to an Apple text file without
    splitting it.  My Applicard file conversion utility ADOSXFER
    converted the first 32K all right then went right on cheerfully
    whirring disks and flashing text on the screen.  When I attempted to
    assemble the resulting product there were 81 errors.

    2-    the Apple Assembler documentation mentions something about
    'chaining' - "CHN" - but I couldn't get that to work.  What did
    work was naming two source files on the "asm" command line.  I
    couldn't find anything in the documentation to indicate WHY it
    worked.  (The binary file takes the name of the second source file
    named - an undocumented feature of the Apple Assembler?)

    3-    the 'ap2ker' version does NOT have some of the features
    documented in the DEC 20 version (e.g. talking to servers, setting
    slots or defining keyboard type).

    A little help from anybody out there who really knows what's going
on would be appreciated.

[Ed. - AP2KER is a "hand crafted" translation of the original Stevens
Institute of Technology "CROSS" cross-assembler source into Apple assembler,
done by Olaf Pors of the University of Virginia.  It is, indeed, based upon
an older version of Apple Kermit; the CROSS version continued to change
after Olaf contributed this version, and Olaf made a few changes during
translation that may or may not have shown up in the "master copy".  CROSS,
for those who don't know, is a general-purpose cross assembler written in
PDP-10 assembly language (and hence can be run only on DEC-10 and DEC-20
systems).  The input syntax closely resembles PDP-11 Macro assembler,
perhaps because CROSS is based upon MACY11, the DEC-10 PDP-11 cross
assembler.  Unlike MACY11, however, CROSS can generate output for a wide
variety of micros from basically the same input syntax.  But since CROSS
only runs on PDP-10 style processors, these benefits are not widely enjoyed.
To complete the cycle, it would be interesting if someone could write a new
CROSS that accepts PDP-10 Macro-10 for input and produces output in a
variety of formats; then CROSS itself could be CROSS-assembled to form a new
CROSS that could then cross-assemble APPLE.M65 on other machines.  But wait,
maybe there's a better way ... ]

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

Date:  08 Jul 85 AT 15:37:30
From: Ted Medin <MEDIN-T%cc82@NOSC>
Subject: New Apple II Cross Assemblers
Keywords: Apple II DOS Kermit

I have two Apple II cross assemblers written in C.  One can handle the M65
CROSS-format source for Apple II DOS Kermit and the other can handle Apple II
assembler (AP2KER).  These assemblers are available in source asis if any one
wants them; I got them from the net and then hacked them.  I will mail them in
three parts each as Unix shell archives; cut and execute to produce the files
which include test cases.  The test cases are the best documentation on what
the syntax is.

[Ed. - Thanks!  The files are available in the Kermit-Tools area on CU20B as
KT:APX*.* (Apple II assembler) and KT:M65*.* (CROSS M65 format), via anonymous
FTP, along with CROSS which is also still there.]

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

Date: Wed 10 Jul 85 23:12:09-EDT
From: Richard Garland <[e-mail]>
Subject: Re: Kermit on MicroVAX-I
Keywords: MicroVAX-I Kermit

Kermit was the first means we used to load stuff into our microVAX-I last
October under microVMS V1.0.  We down-loaded the Stevens Kermit .HEX file
(using raw terminal capture with XON/XOFF flow control), did the same with
the DEHEXIFY Macro source, assembled DEHEXIFY, dehexified KERMIT, and used
it for weeks getting our applictions down from our VMS VAX 780.  It was a
mainstay until DECnet over Ethernet got installed.  It was hardwired
port-to-port at 9600 bpi.  The current version of Kermit works equally well
with microVMS V4.1
                    Rg

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

Date: Wed, 10 Jul 85 09:58:22 cdt
From: [e-mail] (Jim Knutson)
Subject: Re: Z100 Communications Program Query
Keywords: Z100 Kermit

I had thought long and hard about a way to access both ports when I was
getting the Z100 version up.  The problem has to do with using the BIOS
routines for character output.  These only support one AUX device.  To be
able to use the other serial port, a rewrite of the I/O module would need to
be done and some interrupt driven I/O routines would have to be written.
Unfortunately, I don't have the time to do this but it shouldn't be too hard
if you use the IBM-PC I/O module as an example.

Jim Knutson

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

Date: Fri 12 Jul 85 11:00:54-PDT
From: Wing Lee <WingLee%ECLD@ECLA>
Subject: IBM 3270/PC and Kermit?
Keywords: IBM 3270/PC

Will the IBM-PC kermit work on an IBM 3270/PC using its RS-232 port?  We
currently have version 2.26 of IBM-PC Kermit.

wing lee

[Ed. - Anybody have experience with this?  My guess is that it would work
just fine, but have never had any reports either way.]

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

End of Info-Kermit Digest
*************************
-------
15-Jul-85 16:27:31-EDT,11222;000000000001
Mail-From: SY.FDC created at 15-Jul-85 16:26:36
Date: Mon 15 Jul 85 16:26:36-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #4
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Mon, 15 Jul 1985       Volume 3 : Number  4

                 Kermit Protocol Extension Proposals
                 Proposal for Extended Packet Lengths

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

Date: Mon 15 Jul 85 16:12:15-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Kermit Protocol Extension Proposals
To: [e-mail]
Keywords: Kermit Protocol

This week, two new extensions to the Kermit file transfer protocol will be
proposed.  Both address one of Kermit's weakest areas: performance.  Both
extensions are designed to allow extended Kermits to work transparently with
older Kermit programs that are ignorant of the extension; this has always
been the rule for extensions added to the protocol.

The two extensions are:

1. Longer packets.

2. Continuous transmission of packets in a "sliding window".

As originally designed, Kermit is a "stop and wait" protocol; each packet has
to be acknowledged before the next one is sent.  A Kermit packet includes a
single-byte length field expressed as a printable ASCII character, limiting
the packet length to 94.  The original design has been quite effective for
several reasons:

   a. Kermit programs are simple to write.

   b. The restriction on packet length guaranteed that Kermit would work on
      practically every system, including the many whose terminal input buffers
      cannot tolerate long bursts of input.

   c. The stop-and-wait strategy gives the operating system time to consolidate
      its input buffers.

As Kermit grows in popularity, it has found use in situations where its basic
design results in poor performance.  Two examples:

   a. Connections with built-in delays, like public networks or satellite
      links.  Unlike direct or dialup connections, these connections do not
      have a dedicated channel; response varies with the current load on the
      medium, and also with the "diameter" of the network.  Delays can slow
      down the performance or stop it all together if they exceed Kermit's
      timeout parameters.

   b. Direct, clean connections, to systems with big input buffers.  When
      the error rate is very low, throughput is unreasonably impeded by
      stop-and-wait for short packets.

At first glance, it would seem that a single solution could address both
situations.  First, note that any performance extension must require the
receiver of a file to have big input buffers (and since many many systems
don't, any extensions will have to be negotiable).  The question is whether to
send one long packet or a bunch of short packets end-to-end (or both).

Assuming that each packet must be acknowledged, the advantage would seem to
go to long packets, since fewer acks would be required per unit data.  But
when errors occur the amount of data to be retransmitted is less with short
packets, so a sliding window with short packets would be better in a
potentially noisy environment.  But sliding windows work best on a full
duplex communication channel, which certain key systems do not provide.

It is still possible to do packet windowing on half-duplex connections, but
in this case the windows lurch rather than slide -- a batch of packets can be
sent, responded to by a batch of ACKs and NAKs.

Some random observations:

Longer packets are simpler to specify and program.

Windowing is harder to specify and program, and for true full duplex operation
also requires either multiprocessing (e.g.  separate input and output forks) or
else interrupt-driven i/o.

Long packets need a rigorous error-detection mechanism like the 16-bit CRC.
The normal 6-bit checksum just won't do.  Windowing with short packets, on the
other hand, should work well even with short block checks.

Currently during initial connection, two present-day Kermits tell each other
the longest packet they are prepared to accept, up to the maximum of 94.
Each computer bases this number on some knowledge about its input buffers.
But there are also external factors which may be unknown to the computers;
for instance, the connection has been made through a public packet-switched
network or a local area network whose interface devices might have smaller
buffers than the computers themselves.  These factors have rarely interfered
with original ("classic"?) Kermit, because even its biggest packets are
acceptable to most of these devices.  But if Kermit is extended to allow
transmission of much longer bursts of continuous data, all bets are off.  The
burden will shift to the (often naive) user to understand the communications
environment enough to elect the best parameters and options.

The biq question is:  Are the benefits in performance worth the cost in
complexity for specification, programming, and "user education"?  Especially
in view of the likelihood that even if adopted, the extensions will
probably not be made to more than a few of the existing Kermit programs.

Assuming extension is desirable, which extension should be made: long packets,
sliding windows, or both?

The first proposal follows.  The next one will appear in a forthcoming
Info-Kermit (most likely the next one).  By the way, it should be noted that
long packets and windowing should probably be mutually exclusive, since the
proposal for windowing (in its present form) expresses window sizes in numbers
of packets, assuming the current maximum length.

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

Date: Mon 15 Jul 85 16:12:44-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Proposal for Extended Packet Lengths
To: [e-mail]
Keywords: Long Packets

A method is proposed to allow the formation of long Kermit packets.
Questions as to the desirability or appropriateness of this extension to the
Kermit protocol are not addressed.  All numbers are in decimal (base 10)
notation, all arithmetic is integer arithmetic.

In order for long packets to be exchanged, the sender must set the LONGP bit
in the CAPAS field of the Send-Init (S or I) packet, and also furnish the
MAXLX1 and MAXLX2 (extended length 1 and 2) fields, as follows (the value for
the LONGP bit and the position of the MAXLX1,MAXLX2 fields have not yet been
settled):

    ---+-------+-     -+--------+--------+
       | CAPAS |  ...  | MAXLX1 | MAXLX2 |
    ---+-------+-     -+--------+--------+

where MAXLX1 and MAXLX2 are each a printable ASCII character in the range SP
(space, ASCII 32) to ~ (tilde, ASCII 126), formed as follows:

    MAXL1 = char(m / 95)
    MAXL2 = char(m MOD 95)

    (where m is the intended maximum length),

to indicate the longest extended-length packet it will accept as input.  The
receiver responds with an ACK packet having the same bit also set in the CAPAS
field, and with the MAXLX1 and MAXLX2 fields set to indicate the maximum length
packet it will accept.

The maximum length expressible by this construct is 95 x 94 + 94, or 9024.

Since the sender can not know in advance whether the receiver is capable of
extended headers, the Send-Init MAXL field must also be set in the normal
manner for compatibility.

If the receiver responds favorably to an extended-length packet bid (that is,
if its ACK has the LONGP bit set in the CAPAS field), then the combined value
of its MAXLX1,MAXLX2 fields is used.  If the the LONGP bit is set but
MAXL1,MAXL2 is missing, then the value 500 will be used by default.

If it responds unfavorably (the LONGP bit is not set in the CAPAS field),
then extended headers will not be used and the MAXL field will supply the
maximum packet length.

After the Send-Init has been sent and acknowledged with agreement to allow
extended headers, all packets up to and including the B or E packet which
terminates the transaction (and its acknowledgement) are allowed -- but not
required -- to have extended headers; extended and normal packets may be freely
mixed by both Kermits.

The normal Kermit packet length field (LEN) specifies the number of bytes
to follow, up to and including the block check.  Since at least 3 bytes must
follow (SEQ, TYPE, and CHECK), a value of 0, 1, or 2 is never encountered
in the LEN field of a valid unextended Kermit packet.  When extended packets
have been negotiated, the LEN field is treated as follows for the duration of
the transaction:

    If unchar(LEN) > 2 then the packet is a normal, unextended packet.
    If unchar(LEN) = 0 then the packet has a "Type 0" extended header.
    If unchar(LEN) = 1 or 2, the packet is invalid and should evoke an Error.

"Lengths" of 1 and 2 are reserved for future use in Type 1 and 2 extended
headers, yet to be specified.

A Type 0 extended packet has the following layout:

+------+-----+-----+------+-------+-------+--------+----       ----+-------+
| MARK |     | SEQ | TYPE | LENX1 | LENX2 | HCHECK |  DATA ....    | CHECK |
+------+-----+-----+------+-------+-------+--------+----       ----+-------+
                          | Extended Header        |


The blank length field (SP = char(0)) indicates that the first 3 bytes of
what is normally the data field is now an extended header of Type 0, in which
the number of bytes remaining in the packet, up to and including the block
check, is

    extended-length = (95 x unchar(LENX2)) + unchar(LENX2)

and HCHECK is a header checksum, formed exactly like a Type-1 Kermit block
check, but from the sum of the ASCII values of the SEQ, TYPE, LENX1, and
LENX2 fields:

     s = SEQ + TYPE + LENX1 + LENX2

     HCHECK = char((s + ((s AND 192)/64)) and 63)

Since the value of the extended length field must be known accurately in
order to locate the end of the packet and the packet block check, it is
vital that this information not be corrupted before it is used.  The header
checksum prevents this.

The extended header, like the normal header itself, is NOT prefix-encoded.
This implies that the entity responsible for building packets must leave 3
spaces at the beginning of the data field, form the rest of the packet
(encode the data), and then go back and fill in LENX1, LENX2, and HCHECK
based upon the data actually entered into the packet, after encoding.
Similarly, the packet receiver must allow the extended header to be treated
as prefix-encoded data.

The packet block check is formed in the usual manner, based on all packet bytes
beginning with LEN and ending with the last character in the data field.  The
block check may be Type 1, 2, or 3, depending upon what was negotiated, but
longer packets are more likely to be corrupted than shorter ones and should
therefore have higher-order block checks if possible.  This proposal does not
change the way block check type is negotiated, and does not require that Type
2 or 3 block check be implemented.

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

End of Info-Kermit Digest
*************************
-------
18-Jul-85 19:24:33-EDT,13170;000000000001
Mail-From: SY.FDC created at 18-Jul-85 19:23:23
Date: Thu 18 Jul 85 19:23:23-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #5
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Thu, 18 Jul 1985       Volume 3 : Number  5

Departments:

  KERMIT PROTOCOL EXTENSIONS -
    Kermit Extension Proposal Feedback
    Re: Proposals
    Checksum versus CRC
    Kermit Extensions
    Kermit Extended Packet Lengths Proposal
    Kermit Protocol Enhancements
    New vs Classic Kermit

  MISCELLANY -
    Re: IBM 3270/PC and Kermit
    RSX Kermit Warning
    Kermit for Mac L Running Unix
    Terminal Emulator w/Kermit:  Beta-test Site Query
    MS-Kermit 2.26 and Hercules Graphik Card

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

Date: Thu 18 Jul 85 19:09:55-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Kermit Extension Proposal Feedback
Keywords: Kermit Protocol Proposal

The following messages are in response to the first Kermit extension
proposal, presented without comment.  The second proposal (sliding windows,
an effort which is being coordinated by people at The SOURCE Telecomputing)
is not quite ready yet, but should appear shortly.  If you sent a response
that doesn't appear below, send it again -- we lost our file system on CU20B
last night and some messages may have been lost.

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

Date: Tue, 16 Jul 85 02:12:32 pdt
From: Scott Weikart <cdp!scott@Glacier>
Subject: Re: Proposals
Keywords: Kermit Protocol Proposal, Sliding Window Kermit, Long Packets

I would definitely like to have either sliding window protocol or long
buffers, but I'm not sure which one (or if I need both).  We're working with
some other non-profits to setup long-distance telecommunications between UN*X
and MS-DOS machines, and would like to use kermit as our transport mechanism,
but we're worried about kermit efficiency with long round-trip times (eg
packet-switched networks) or long-distance high-speed modem connections.  The
packet-networks should be error- corrected so that long packets would seem to
make sense, but I don't know if you'll get hing up by buffer sizes in the
network (the nets I'm thinking of are Uninet, and maybe Tymnet or Telenet).
We may also be using some of the new high-speed pseudo-full-duplex modems,
and I don't know enough about their error rates or buffer size factors
either; if it's error rate is high and and it doesn't do partition a block
and use its own sliding window protocol, it might be good to use half-duplex
lurching window with small packets.

I'm not so worried that many/most kermits won't be able to handle either
extension.  For people like us who are interested in using kermit for the
transport mechanism of sophisticated telecommunications services, probably
only the more capable machines will be considered as part of the system
(although one may argue that an MS-DOS machine is not very capable).

As for user education about large packets, people could maybe implement an
adaptive mode that would try a 1/3 or 1/2 smaller packet each time a
transport media truncated a packet.  But that's more hairiness.

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

Date: 15 Jul 1985 1941-EDT
From: B.Eiben LCG Ext 617-467-4431 <EIBEN at DEC-MARLBORO.ARPA>
Subject: Checksum versus CRC
Keywords: Kermit Protocol Proposal, Checksums

I haven't seen a single clear review of the above - I STILL BELIEVE THAT
Checksumming of mostly analog based circuits is SUPERIOUR. CRC [ and all
quasi-mathematical "analysises" assume BIT-drops] is SUPERIOUR in catching
missing BITS [one typically can be "reconstructed" depending on the "polynom"
- two or [sometimes more] can be "detected". CHecksumming is good for
"detecting" single-bit changes [no chance to "reconstruct" - since the
position of the "change" is not known - and [obviously.. only a 50% chance to
"catch" double-bit errors].... HOWEVER - and here lays the "settle"
difference -- ANALOG CIRCUITS TEND NOT TO DROP BITS - THEY DROP MINIMALLY
WORDS and TYPICALLY "SENTENCES" -- AND CHECKSUMMING HAS A HIGH CHANCE TO
"catch" these DROPS or MODIFICATIONS - since typically [on ANALOG CIRCUITS]
FULL [either ON- or OFF-Bit sequences are substituted] -- this [by the way]
also explains my long-standing objection to CRC-protocol in MODEM
[acknowledged by the experience - that ON "BAD" lines switching from
CHECKSUMMED PROTOCOL to CRC-PROTOCOL DOESN't make a "bit of a difference". -
Yeah, I know; there's an even more serious flaw in MODEM- protocol - in that
ACK/NAK msgs are NOT encased into "message-protocol" and thereby on a "bad"
line MODEM looses typically in ACK/NAK traffic.]

Let me clarify [after re-reading] the above SUPERIOUR - it summs up the
"expended CPU-time {and number of program instructions}" - as compared to the
achieved results {I.e. probability to detect an ERROR}.

Rgds,
Bernie.

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

Date: Tue 16 Jul 85 21:07:07-EDT
From: Richard Garland <[e-mail]>
Subject: Kermit Extensions
Keywords: Kermit Protocol Proposal, Long Packets

I perked my ears up at one statement in your introduction to the extensions
you outlined:  "Each packet must be ACKed" and you even gave an example of
a half duplex "lurching" window where a bunch of packets are sent and then
a bunch of ACKs are returned.

I would suggest two ideas for ACKs that DECnet uses:

    o  ACKing only the last good packet and
    o  piggyback ACKing.

In the first case if, packets 9, 10, 11, and 12 are sent successfully, the
receiver ACKs 12 and this *implies* 9, 10, and 11 were also good.  If 9, and
10 were good and 11 was bad on the other hand, the receiver NACKs 11, and
this implies 11 is bad, but 9 and 10 were good.  Then the sender resends
starting at 11.  This scheme allows a lot less reverse traffic.  Usually
there is a limit on the number of packets that will be sent before getting
some ACK but that is the sliding window protocol which you are working out
and I won't bother about that part of it. (DECnet uses about 3 versions of
it).

piggyback ACKing simply means that an ACK or a NAK can be combined with
another packet going in the right direction and is relavent for full duplex
data streams.  Perhaps Kermit will never have full duplex data (as opposed
to packets) so this idea may be irrelavent.  But if on the other hand you
want to send a bunch of packets, then send an END packet, a type of
piggybacking would allow the receiver to ACK the last n packets and the END
packet all at once.

By the way, I don't think sliding windows and large packet extension ideas
are mutually exclusive ways to improve performance.

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

Date: Tue, 16 Jul 85 20:24:42 PDT
From: [e-mail]
Subject: Kermit extended packet lengths proposal
Keywords: Kermit Protocol Proposal, Long Packets

Overall this looks pretty good, but I'd recommend a couple of small changes:

1. Change the extended length specification to be simply 12 bits transmitted
   the same way as the 2-byte checksum. This limits the maximum packet size
   to 4096 bytes, but that is plenty when the best checksum is CRC-CCITT.
   It is also as big as any host's usual input buffer as far as I know.

2. Include the LEN byte in the header checksum so that both checksums start
   at the same byte. Having the header one start 1 byte later than the packet
   one doesn't make any sense and will confuse the implementator.

I believe that the last sentence of the second-to-last paragraph is missing a
"NOT". As it stands, it contradicts the first sentence of the same paragraph.
(That is the paragraph about the extended header not being prefix-encoded.)

Finally, I think there is a small bug in the advanced state table shown in
the 3 April 84 protocol manual (there may be a newer one but that is the
newest I have). The Send_Gen_Cmd state should allow for receiving an F packet
in the case that it was entered from the Send_Server_Init state and sent a R
command. That is because the server will, I expect, conclude that it doesn't
need to send a S(0) because of receiving and Acking the I(0). (I haven't
tried this with a server to be sure, but the Rec_Server_Idle state
description sure implies to me that is how the server will work.)

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

Date: July 17, 1985, 09:15 CEST
FROM:  <#[e-mail]>
Subject: Kermit Protocol Enhancements
Keywords: Kermit Protocol Proposal

Hi,
 I hope my questions are not too late for this stage of the
discussion.
 1.) which kind of systems would be able to use the large
     packets?
 2.) which kind of systems can afford (pgm size, complexity)
     the necessary changes to the software?
 3.) how does the proposal fit the rules of the early days
     of Kermit development (to have a simple, cheap to implement
     protocol for connecting especially small systems)?
 4.) where are the ends, or in other words, wouldn't it be better
     to develop a new protocol with enhanced performance (e.g
     larger packet, high speed lines, parallel activities on the
     lines)?

Martin Knoblauch
TH-Darmstadt, D-6100 Darmstadt, West Germany
EARN/BITNET: #D15 at DDATHD21 (the number sign is really part of my UID)

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

Date: 17 JUL 85 09:34-EST
From:  [e-mail]
Subject: New vs Classic Kermit
Keywords: Kermit Protocol Proposal

The proposals for large packets (and likely sliding windows) are not going to
work out well on pdp-11's as the buffers in all the execs are fairly small,
ranging from a max of 36 for rsx, 255 for rsx11m+, 140 for rt, ??? for p/os,
and max of about 500 for rsts/e (depending on available small buffer pool).
Thus xon/xoff would come into play rather soon.  Of course, xonxoff control
is no better (much worse,really) that send/ack for each packet.

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

Date: Mon, 15 Jul 85 12:42:33 edt
From: Paul Placeway <[e-mail]>
Subject: Re: IBM 3270/PC and Kermit
Keywords: IBM 3270/PC

We have been running kermit for IBM PCs and clones for 6 months on our 3270
PC with no problems whatsoever.  We run a 9600 baud line between the 3270 PC
and our Vax to do file transfers (9600 is very nice, but the Unix version is
too slow (no, we havn't gotten the latest version of Unix kermit)).  I have
one suggestion, however: get a normal PC keyboard for your 3270 PC.  The
position of ESC, Control, and some other keys is a PAIN.

                Paul Placeway
                OSU CIS Dept. Lab
                ...!cbosgd!osu-eddie!paul
                paul@ohio-state  (CSNet)

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

Date: 16 JUL 85 09:28-EST
From:  [e-mail]
Subject: RSX Kermit Warning
Keywords: Kermit-11, RSX Kermit

A problem with RSX Kermit-11 has been  resolved  in  that  the  outgoing
line  (via  SET  LINE) must NOT have the /RPA setting enabled (read pass
all). If set, it must be disabled via  the  mcr  command  SET/NORPA=TTn:
The  characteristic is not one that would be normally set. The effect of
having it set is to force the terminal driver to pass all  flow  control
(xon   and   xoff)  characters  directly  to  Kermit,  which  is  highly
undesirable. The call to disable /RPA will be added to Kermit-11  source
in the future.

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

Date:  Tue, 16-JUL-1985 08:55 EDT
From:    Ronald A. Jarrell  <[e-mail]>
Subject:  Kermit for Mac L Running Unix
Keywords: MacKermit

Our CS department is going to be having all incoming freshman purchasing
Macintosh-L's with Unipres System V.  Has anyone tested, or suspects that
one of the flavors of kermit will work under that combination?  We plan on
setting up some semi-automated software for file transfer for them, and the
most desirable alternative would be for them to connect to a VMS Vax that
has Kermit on it.

-Ron Jarrell
 Systems Programming Dept,
 Va Tech

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

17-Jul-85 11:36:50-EDT,869;000000000001
Mail-From: EXT1.FUCHS created at 17-Jul-85 11:36:47
Date: Wed 17 Jul 85 11:36:46-EDT
From: Michael Fuchs <[e-mail]>
Subject: Terminal Emulator w/Kermit:  Beta-test Site Query
To: [e-mail]
Keywords: Terminal Emulation

Would anyone in net.land be interested in beta-testing the latest release
of a commercial terminal emulator (full VT102) for the IBM PC incorporating
a complete implementation of Kermit?

Features include:

    * Kermit including CRC, server commands, etc.
    * XMODEM, Proprietary protocols with host software provided
    * Software (and hardware) 132 column support
    * Scrolled-off screens capture buffer (80 screens' worth)
    * Terminate-stay-resident Hot key feature
    * Programmable softkeys

Anyone interested please contact me through net mail or at 212-777-6707.

Michael Fuchs
Coefficient Systems Corp.

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

Date: Thu 18 7 85 23:30 GMT
From: Eberhard W. Lisse <[e-mail]>
Subject: MS-Kermit 2.26 and Hercules Graphik Card
Keywords: MS-DOS Kermit, Hercules Card

Have you heard of any problems caused by the Hercules monochrome graphik card
on an XT DOS 2.11 ?

Since they installed it on our XT, Kermit does not connect any more.

[Ed. - Can anyone help?]

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

End of Info-Kermit Digest
*************************
-------
22-Jul-85 15:18:45-EDT,8780;000000000001
Mail-From: SY.FDC created at 22-Jul-85 15:08:51
Date: Mon 22 Jul 85 15:08:51-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #6
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Mon, 22 Jul 1985       Volume 3 : Number  6

Departments:

  ANNOUNCEMENTS -
    Kermit-11 User Manual
    Kermit Distribution Updated on Okstate

  MISCELLANY -
    Long Packets and Sliding Windows
    Kermit Problem with Z100 MS-DOS2 Solved
    MacKermit 0.8, UNIX C-Kermit Problems
    Tools for Ascii/Ebcdic Conversion Tables for TSO Kermit
    MS-DOS Kermit vs Professional Graphics Adapter?

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

Date:     Thu, 18-JUL-1985 16:53 EST
From:     <BRIAN@UOFT02>
Subject:  Kermit-11 User Manual
Keywords: Kermit-11

I will send two files, K11USR.DOC and .RNO, to you after this; this is the
Kermit-11 User Manual, shaped like a Kermit User Guide chapter but written
using Runoff rather than Scribe.  You folks can do with them what you may,
though they should be placed with the rest of the k11 files on cuvma, cu20b,
and your vax that you make the tapes on.

[Ed. - The files are installed with the other K11 files in K2:K11USR.* on
CU20B, and on CUVMA for KERMSRV.  Thanks, Brian! ]

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

Date: 20 Jul 85 00:23:32 CDT (Sat)
From: [e-mail]
Subject: Kermit Distribution Updated on Okstate
Keywords: Okstate

I have received and installed the latest Kermit tapes (thanks for sending
them) on our system.  I have moved the distribution area into a more
"normal" location (/usr/spool/uucppublic) on our system and I have split it
into two areas, one for each tape.  The area that was generated from TAPE A
(the micro Kermits) is called /usr/spool/uucppublic/kermit-a and the area
that was generated from TAPE B (the mainframe Kermits) is called
/usr/spool/uucppublic/kermit-b.

The default directory for our "kermsrv" login will be changed to
/usr/spool/uucppublic/kermit-a and users will be allowed to CWD to
/usr/spool/uucppublic/kermit-b.  UUCP users will just have to specify the
full path (although ~uucp/kermit-a and ~uucp/kermit-b should also work on
most systems...).  To summarize:

 -  The files that were on TAPE A are in /usr/spool/uucppublic/kermit-a/*

 -  The files that were on TAPE B are in /usr/spool/uucppublic/kermit-b/*

 -  The Kermit server login "kermsrv" has been modified to use the kermit-a
    area as its default directory and

    REMOTE CWD /usr/spool/uucppublic/kermit-b

    will take you to the other area.  For those systems not supporting
    REMOTE commands, the server will also accept full pathnames in GET
    requests.

Mark

[Ed. - Thanks Mark, and thanks again for providing this service.]

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

Date: Fri, 19 Jul 85 09:19:04 EDT
From: [e-mail]
Subject: Long Packets and Sliding Windows
Keywords: Sliding Windows Kermit, Long Packets

We use Kermit here for host to host transfers over Telenet and Datapac, and
the long packet extension seems ideal for this purpose.

Unfortunately, our operating system (MTS) doesn't really allow asynchronous
reads, which might cause problems with a sliding window scheme.  I'm
interested in seeing the actual proposal.

[Ed. - It will appear in the next digest.]

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

Date: Fri, 19 Jul 85 10:17:49 PDT
From: klee@sri-spam (Ken Lee)
Subject: Kermit Problem with Z100 MS-DOS2 Solved
Keywords: Z100 Kermit

Thanks to all those who responed to my request for help with Kermit on
MS-DOS2.  My version of Kermit worked fine on ZDOS, but failed when I
tried to use it with DOS2.  Apparently, DOS2 causes the Z100 to drop
the data terminal ready (DTR) signal to the modem when Kermit attempts
to receive a file.  The modem interpets this as a signal to quit and
drops the telephone line.  By optioning the modem to ignore the DTR
signal from the Z100, I now have kermit working properly.

Ken Lee

[Ed. - Thanks for the pointer; I've placed it in MSZ100.BWR so others can
benefit from it.]

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

Date: Sun, 21 Jul 85 12:24:17 pdt
From: westjw%frog@Nosc (Joel West c/o NOSC San Diego)
Organization: CACI, Inc. (home of SIMSCRIPT II.5)
Subject: MacKermit 0.8, UNIX C-Kermit Problems
Keywords: MacKermit, C-Kermit, UNIX Kermit

Before I nit-pick, I'd like to say how much I like the keymap program, even
if it was only designed for EMACS hackers. :-) I've chosen the assignment
BS=^H; Shift-BS=DEL; Ctl-BS, Enter=<esc>; although I may change this for vi
later.  (in BSD, you use ~ and ` a lot, and the Ctl-Shift-~ of MacTerminal
is a real pain).

[Ed. - Of course, you can have as many different settings files as you like;
just double-click the one you want to start up Kermit with the appropriate
settings and key map.]

Two problems with MacKermit:

    #1  files never go into folders, always desktop.  This must
    be a "feature", since it's easier to default the file to
    the disk (FlFldr=0) than to the desktop (FlFldr=-2)

[Ed. - Like it says in the manual, they go into whatever folder the settings
file was in that you started Kermit from, otherwise on the desktop.]

    #2    if you receive a file (interactive), toggle disk drives
    and insert a new disk, it bombs during initialization.
    The only time this happened was using RAM Disk "RamStart"
    off of net.sources.mac.

[Ed. - This will be added to the beware file.]

Also, I'm using the April C-Kermit (BSD 4.2) off of mod.sources.  When I
upload files from UNIX to the Mac, I'm not getting a size packet -- or at
least, the Mac isn't printing the expected size.  This is the only thing I
like better about MacTerminal than Kermit -- but the keymap and more
reliable transfers means I've thrown MacTerminal away.

[Ed. - Unfortunately, this requires the sender to include an "attribute
packet", which C-Kermit does not yet do.]

Keep up the good work.

    Joel West    CACI, Inc. - Federal

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

Date: Thu, 18 Jul 85 21:18:22 PDT
From: VSS7853@UCLAVM
Subject:  Tools for Ascii/Ebcdic Conversion Tables for TSO Kermit
Keywords: TSO Kermit, ASCII/EBCDIC Translation Tables

Enclosed are three Fortran 77 programs I wrote as aids to installing TSO
Kermit when non-standard TCAM tables are used by MVS to communicate with
Ascii terminals.

The first two programs, ATOE.FOR and ETOA.FOR take the actual tables used by
TCAM, which are obtained from the communication's people at one's
installation, and generate assembler source code to replace the tables in
Kermit.  The third, TCAM.FOR, takes the output of the first two and checks
whether the ETOA table is indeed the inverse of the ATOE on the printable
subset as required for Kermit to operate.

If the test fails, Kermit will not run with the existing TCAM tables.  I
suspect, however, that so long as all of the Ascii printables map to
distinct Ebcdic representations, and so long as the range of the Ebcdic-
to-Ascii contains all the Ascii printables, that Kermit could still be made
to work by employing an ETOA which is the inverse of TCAM's Ascii-to-Ebcdic,
an ATOE which is the inverse of TCAM's Ebcdic-to-Ascii, and an additional
ETOA with range contained in the printable subset (and null).  This would
require a bit of analysis and a modest amount of reprogramming on someone's
part but it might add to the number of mvs systems which support Kermit.

The listings include actual output which includes an echo of the input.  The
programs were developed on VAX but the language should be standard 77 except
for the Z format extension.

I hope this helps someone.

 Glenn E. Thobe
 EE dept. UCLA
 iva3get.uclamvs (bitnet)

[Ed. - Listings omitted; they're collected together in K2:TSOETOA.FOR.]

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

Date: 22 Jul 1985 1354-EDT
From: LCG.KERMIT@MARKET
Subject: MS-DOS Kermit vs Professional Graphics Adapter?
Keywords: MS-DOS Kermit, Professional Grpahics Adapter

We are having trouble with MS-DOS Kermit V2.27 on an IBM AT with the
professional graphics adapter/display.  At speeds above 1200 baud characters
are lost in terminal emulation mode.  Has anyone else seen this problem?

Carl Houseman
GENICOM Corporation
703-949-1323

[Ed. - On the IBM PC/AT, terminal emulation is very slow if EGA card is
present because the program waits for the vertical retrace operation to
complete, which should not be done with the EGA.  Apparently the same is true
of the Professional Graphics Adapter.  Until this is fixed in the next
release, EGA (and PGA?) users can patch the routine SCRWAIT in MSYIBM to
just return.  If anyone with the PGA tries this, please report the results
to Info-Kermit.]

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

End of Info-Kermit Digest
*************************
-------
23-Jul-85 11:22:17-EDT,23765;000000000001
Mail-From: SY.FDC created at 23-Jul-85 11:21:26
Date: Tue 23 Jul 85 11:21:25-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #7
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Tue, 23 Jul 1985       Volume 3 : Number  7

                    Kermit Sliding Window Proposal

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

Date: Tue 23 Jul 85 10:30:00-EDT
From: Frank da Cruz
Subject: Kermit Sliding Window Proposal
Keywords: Sliding Windows Kermit

This digest presents a proposal from a group at The SOURCE Telecomputing in
McLean, Virginia, for a sliding window extension to the Kermit protocol
(if you're not interested in protocol issues, skip the rest of this digest).
Like other extensions, this one is designed for "upward compatibility" with
Kermits that do not support this extension.  It may be viewed as an
alternative to the long-packets extension proposed in V3 #4, or as
complementary to it.  The question raised by the latter proposal also applies
here: Is the cost in complexity worth the improvement in performance? --
complexity not only in program size and logic, but also in explaining the
options to the user: even when Kermit programs implement windowing, when and
to what degree should it be used?  When must it not be used?

The following proposal is not the only way to do sliding windows or to adapt
windows to Kermit.  The method outlined is certainly not cast in concrete,
although Leslie's group is working on some prototype implementations.  The
proposal is being put forth now to solicit ideas, suggestions, and opinions
from the world at large.  Some areas to think about include:

. What is the effect on the portability of current Kermit programs?  Since
  windowing implies packets flowing in both directions at once, it will be
  necessary to run separate input and output forks or else to handle packet
  i/o at interrupt level.  Neither of these techniques will be as portable
  as the simple input-output sequences now used by most Kermit programs.

. What will be the effect in the many and varied environments in which
  Kermit operates, and will operate in the future?  These include public
  networks, satellite links, local area networks, terminal concentrators,
  TACs, PBX's, high-speed full-duplex error-correcting modems, ATT 56Kb
  digital service, etc etc.  In some cases windowing (or long packets)
  could boost performance dramatically, in others it could prevent Kermit
  from working at all.

. Does the particular method suggested strike the best balance among
  improved performance, upward compatibility, and simplicity?  Are there
  obvious simple improvements to the proposed algorithms and heuristics?

. Can sliding (lurching) windows be done on half-duplex channels?  Are
  any modifications to the proposal required?

This digest will be followed closely by another, which will contain some
questions and answers about this proposal.  Please read both digests before
responding.

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

Date: Mon 22 Jul 85 11:29:46-EDT
From: Leslie Spira <OC.SOURCE@CU20B>
Subject: Kermit Sliding Window Proposal
Keywords: Sliding Windows Kermit

                      KERMIT WINDOWING PROTOCOL

                         DRAFT SPECIFICATION

                Hugh Matlock, The SOURCE Telecomputing

                            June 12, 1985


1 INTRODUCTION

The windowing protocol as defined for the Kermit file transfer protocol
is based on the main premise of continuously sending data packets up to
the number defined by a  set  window  size.   These  data  packets  are
continuously acknowledged  by  the  receive side and the ideal transfer
occurs as long as they are transmitted with good  checksums,  they  are
transmitted in  sequential  order and there are no lost data packets or
acknowledgements.  The various error conditions define the  details  of
the windowing protocol and are best examined on a case basis.

There are  five  stages that describe the overall sequence of events in
the Kermit protocol.  Three of these stages deviate from  the  original
protocol in order to add the windowing feature.  Stages 1 through 5 are
briefly described on the following page.  The three stages (1, 3 and 4)
which deviate  from the original protocol are then described in greater
detail in the pages that follow.


2 OVERALL SEQUENCE OF EVENTS

STAGE 1 - Propose and Accept Windowing

The send  side  requests  windowing  in   the   transmission   of   the
Send-Initiate (S)  packet.   The  receive  side  accepts  windowing  by
sending an acknowledgement (ACK packet) for the  Send-Initiate  packet.

STAGE 2 - Send and Accept File-Header Packet

The send  side  transmits  the File-Header (F) packet and waits for the
receive side to acknowledge it prior to transmitting any data.

STAGE 3 - Transfer Data

The sending routine transmits Data (D)  packets  one  after  the  other
until the  protocol  window  is  closed.   The receiving side ACKs good
data, stores data to disk as necessary and NAKs bad data.

When the sender receives an ACK, the window may be rotated and the next
packet sent.  If the sender receives a NAK, the data  packet  concerned
is retransmitted.

STAGE 4 - Send and Accept End_of_File Packet

As the  sender is reading the file for data to send, it will eventually
reach the end of the file.  It then waits until  all  outstanding  data
packets have  been  acknowledged,  and  then  sends  an End-of_File (Z)
packet.

When the receive side gets the End-of-File packet it stores the rest of
the data to disk, closes the file, and ACKs the End-of_File packet.

The protocol then returns to Stage 2,  sending  and  acknowledging  any
further File-Header (F) packets.

STAGE 5 - End of Transmission

Once the  End-of-File  packet  has been sent and acknowledged and there
are no more files to send, the sender transmits the End-of-Transmission
(B) packet in order to end the ongoing transaction.  Once the  receiver
ACKs this  packet,  the transaction is ended and the logical connection
closed.


3 PROPOSE AND ACCEPT WINDOWING (STAGE 1)

The initial connection as currently defined  for  the  Kermit  protocol
will need  to change only in terms of the contents of the Send-Initiate
packet.  The receiving Kermit waits for the sending Kermit to  transmit
the Send-Initiate  (S)  packet  and the sending packet does not proceed
with any additional transmission until the ACK has been returned by the
receiver.

The contents  of  the  Send-Init  packet,  however,  will  be  slightly
revised.  The data field of the Send-Init packet currently contains all
of the configuration parameters.  The first six fields of the Send-Init
packet are fixed as follows:

   1        2        3        4        5        6
  +--------+--------+--------+--------+--------+--------+
  | MAXL   | TIME   | NPAD   | PADC   | EOL    | QCTL   |
  +--------+--------+--------+--------+--------+--------+

Fields 7  through  10  are  optional  features  of  Kermit and fields 7
through 9 will also  remain  unchanged  as  defined  for  the  existing
protocol:

   7        8        9        10
  +--------+--------+--------+--------+
  | QBIN   | CHKT   | REPT   | CAPAS  |
  +--------+--------+--------+--------+

Field 10  is  the  capability  field  and  requires  N  number of bytes
depending on the number of capabilities defined for kermit.   Each  bit
position of these 6-bit fields corresponds to a capability with the low
order bit  used  to  indicate  whether  or  not another capability byte
follows.  If the low order bit is  "1"  then  another  capability  byte
follows.  If the low order bit is "0" then the current byte is the last
capability byte.   The  second  through  sixth  bit positions represent
capabilities in the same way.  If a bit position is set to 1  then  the
capability it  represents  is present.  If the bit position is set to 0
then the capability it represents does not exist.  Currently, there are
only 3 capabilities defined for Kermit as follows:

    #1  Reserved
    #2  Reserved
    #3  Ability to accept "A" packets (file attributes)

The windowing capability will constitute a fourth  capability  and  the
fourth bit  of  the  capability  field  will  be set to 1 if the kermit
implementation can handle windowing.

    #4  Ability to handle windowing.

The remaining fields of the Send-Init packet are  either  reserved  for
future use  by  the standard Kermit protocol or reserved for local site
implementations.  The four fields following the  capability  field  are
reserved for the standard Kermit protocol.  We propose the use of field
11 to be used to specify the "Window Size" for all kermits

   11       12       13       14       15       16 - N
  +--------+--------+--------+--------+--------+------------------+
  | WINDW  | RESV1  | RESV2  | RESV3  | RESV4  | LOCAL Reserved   |
  +--------+--------+--------+--------+--------+------------------+

11. WINDW - The window size to be used encoded printably using
    the char() function.  The window size may range from 1 to 31
    inclusive.

The sender  will  specify  the  window  size  it  wishes to use and the
receiver will reply (in the ACK packet) with the window size it  wishes
to use.   The window size actually used will be the minimum of the two.
If the receiver replies with a window size of 0 then no windowing  will
be done.


4 TRANSFER DATA (STAGE 3)

The sequence  of  events  required for the transmission of data packets
and confirmation of receipts  constitute  the  main  functions  of  the
windowing protocol.   There  are  four  main  functions  which  can  be
identified within this stage.  These are:

     - the sender's processing of the data packets,
     - the receiver's handling of incoming packets,
     - the sender's handling of the confirmations,
     - the error handling on both sides.

The following discussion details the specific actions required for each
of these functions.  Refer to the  state  table  at  the  end  of  this
document for  the  specific  action taken on a "received message" basis
for the full protocol.

   4.1 The Sender's Processing of Data Packets

   The sender instigates the transmission by  sending  the  first  data
   packet and  then  operating in a cyclical mode of sending data until
   the defined window is closed.

   Data to be sent must be read from the file, encoded into the  Kermit
   Data packet, and saved in a Send-Table.  A Send-Table entry consists
   of the  data  packet itself (which makes convenient the re-send of a
   NAKed packet), a bit which keeps track of  whether  the  packet  has
   been ACKed (the ACKed bit), and a retry counter.  The table is large
   enough to hold all the packets for the protocol window.

   Before each transmission, the input buffer is checked and  input  is
   processed, as  described  below.   Transmission  is  stopped  if the
   protocol window "closes", that is, if the Send-Table is full.

   4.2 The Receiver's Handling of Incoming Packets

   The receiver keeps its  own  table  as  it  receives  incoming  data
   packets.  This  allows  the  receiver  to receive subsequent packets
   while it is waiting for a re-send of an erroneous  or  lost  packet.
   In other  words,  the incoming packets do not have to be received in
   sequential order and can still be written to disk in order.

   A Receive-Table entry consists of the data packet, a bit which keeps
   track of whether a good version of the packet has been received (the
   ACKed bit), and a retry counter for the  NAKs  we  send  to  request
   retransmissions of  the  packet.   The table is large enough to hold
   all the packets for the protocol window.

   The different possibilities for a received packet are:

      1. A new packet, the next sequential one (the usual case)
      2. A new packet, not the next sequential one (some were lost)
      3. An old packet, retransmitted
      4. An unexpected data packet
      5. Any packet with a bad checksum

   These are discussed separately below.

   1.  The next new packet has sequence number  one  past  the  <latest
   table entry>.  The packet is ACKed, and the Receive-Table is checked
   for space.   If  it  is  full (already contains window_size entries)
   then the oldest entry is written to disk.  (This entry  should  have
   the ACKed  bit set.  If not, the receiver aborts the file transfer.)
   The received packet is then stored in the  Receive-Table,  with  the
   ACKed bit set.

   2.  If the packet received has sequence number  in  the  range  <two
   past the  latest  table entry> to <window_size past the latest table
   entry> then it is a new packet, but some have been lost.  (The upper
   limit here represents the  highest  packet  the  sender  could  send
   within its  protocol  window.  Note that the requirement to test for
   this case is what limits the maximum  window_size  to  half  of  the
   range of  possible  sequence numbers) We ACK the packet, and NAK all
   packets that were skipped.  (The skipped packets are those from <one
   past the latest table entry> to <one before  the  received  packet>)
   The Receive-Table is then checked.  The table may have to be rotated
   to accomodate the packet, as with case 1.  (This time, several table
   entries may  have  to  be written to disk.  As before, if any do not
   have the ACKed bit set, they will trigger an abort.)  The packet  is
   then stored in the table, and the ACKed bit set.

   3.  A retransmitted packet will have sequence number  in  the  range
   <the oldest table entry> to <the latest table entry>.  The packet is
   ACKed, then placed in the table, setting the ACKed bit.

   4.  A packet with sequence number outside of  the  range  from  <the
   oldest table  entry> to <window_size past the latest table entry> is
   ignored.

   5.  If the packet received  has  a  bad  checksum,  we  must  decide
   whether to  generate  a  NAK,  and if so, with what sequence number.
   The best action may depend on the configuration  and  channel  error
   rate.  For  now,  we  adopt  the  following heuristic:  If there are
   unACKed entries in our Receive-Table, we send a NAK for  the  oldest
   one.  Otherwise  we ignore the packet.  (Notice that this will occur
   in a common case:  when things have  been  going  smoothly  and  one
   packet gets  garbled.   In this case, when we later receive the next
   packet we will NAK for this one as described under Case 2 above.)

   4.3 The Sender's Handling of Confirmations

   The sender's receipt of confirmations controls the rotation  of  the
   Send-Table and  normally returns the sender to a sending state.  The
   sender's action  depends  on  the  packet  checksum,  the  type   of
   confirmation (ACK  or  NAK),  and whether the confirmation is within
   the high and low boundaries of the Send-Table.

   If the checksum is bad the packet is ignored.

   When the sender receives an ACK, the sequence  number  is  examined.
   If the  sequence  number is outside of the current table boundaries,
   then the ACK is also ignored.  If the sequence number is  inside  of
   the current  table  boundaries then the ACKed bit for that packet is
   marked.  If the entry  is  at  the  low  boundary,  this  enables  a
   "rotation" of  the  table.   The low boundary is changed to the next
   sequential entry for which the ACKed bit is  not  set.   This  frees
   space in the table to allow further transmissions.

   When the sender receives a NAK, the table boundaries are checked.  A
   NAK outside  of  the  table boundary is ignored and a NAK inside the
   table boundary indicates that the sender must  re-send  the  packet.
   The sender  first tests the packet's retry counter against the retry
   threshold.  If the threshold has been reached, then the transfer  is
   stopped (by going to the Abort state).  Otherwise, the retry counter
   is incremented and the packet re-sent.

   4.4 Error Handling for Both Sides

   Three situations  are  discussed  here:   Sender  timeout,  Receiver
   timeout, and invalid packets.

   If certain packets are lost, each side may "hang", waiting  for  the
   other.  To  get  things  moving  when  this  happens each may have a
   "timeout limit", the longest they will wait for something  from  the
   other side.

   If the sender's timeout condition is triggered, then  it  will  send
   the oldest  unACKed  packet.   This  will  be  the  first one in the
   Send-Table.

   If the receiver's timeout condition is triggered, then it will  send
   a NAK  for the "most desired packet".  This is defined as either the
   oldest unACKed packet, or if none are unACKed, then the next  packet
   to be received (sequence number <latest table entry plus one>).  The
   packet retry  count  is  not  incremented  by  this NAK;  instead we
   depend on the timeout retry count, discussed next.

   For either the sender  or  receiver,  the  timeout  retry  count  is
   incremented each  time a timeout occurs.  If the timeout retry limit
   is exceeded then the side  aborts  the  file  transfer.   Each  side
   resets the retry count to zero whenever they receive a packet.

   In addition, as with the existing Kermit, any invalid  packet  types
   received by either side will cause an Error packet and stop the file
   transfer.


5 SEND AND ACCEPT END_OF_FILE PACKET (STAGE 4)

There are  several  ways  to  end  the file transfer.  The first is the
normal way, when the sender encounters an  end-of-file  condition  when
reading the  file  to  get  a  packet  for transmission.  The second is
because of a sender side user interrupt.  The third  is  because  of  a
receiver side user interrupt.  Both of these cause the received file to
be discarded.   In  addition  either side may stop the transfer with an
Error packet if an unrecoverable error is encountered.

   5.1 Normal End of File Handling

   When the sender reaches the end of file, it must wait until all data
   packets have been acknowledged before sending  the  End-of-File  (Z)
   packet.  To  do this it must be able to check the end-of-file status
   when it processes ACKs.  If the ACK  causes  the  Send-Table  to  be
   emptied and  the  end-of-file has been reached, then a transition is
   made to the Send_Eof state which sends the End_of_File packet.

   When the  receiver  gets  the  End_of_File  packet,  it  writes  the
   contents of  the  Receive-Table  to  the file (suitably decoded) and
   closes the file.  (If any entries do not have the ACKed bit set,  or
   if errors  occur  in  writing the file, the receiver aborts the file
   transfer.)  If the operation is successful, the  receiver  sends  an
   ACK.  It  then  sets  its  sequence number to the End_of_File packet
   sequence number and goes to Rcv_File state.

   5.2 Sender User Interrupt

   Whenever the sender checks for input from  the  data  communications
   line, it  should  also check for user input.  If that indicates that
   the file transfer should be stopped, the sender goes directly to the
   Send_Eof state and sends an  End_of_File  packet  with  the  Discard
   indication.  It  will not have to wait for outstanding packets to be
   ACKed.

   When the receiver gets  the  End_of_File  packet  with  the  Discard
   indication it  discards  the  file,  sets its sequence number to the
   End_of_File packet sequence number, and goes to RcvFile state.

   5.3 Receiver User Interrupt

   Whenever the receiver checks for input from the data  communications
   line, it  also  should check for user input.  If that indicates that
   the file transfer should be stopped, the receiver sets an "interrupt
   indication" of X (for "stop this file transfer") or of Z (for  "stop
   the batch  of  file  transfers").   When the receiver later sends an
   ACK, it places an X or Z in the data field.

   When the sender gets this ACK, it goes to  the  Send_Eof  state  and
   sends the  End_of_File packet with the Discard indication, as above.

   When the receiver gets  the  End_of_File  packet  with  the  Discard
   indication, it  discards  the  file, sets its sequence number to the
   End_of_File packet sequence number, and goes to RcvFile state.

   5.4 LOW LEVEL PROTOCOL REQUIREMENTS

   The Kermit windowing protocol, as defined in  this  document,  makes
   certain assumptions  about the underlying transmission and reception
   mechanism.

   First, it must provide a full-duplex channel so that messages may be
   sent and received simultaneously.

   Second, it will prove advantageous to  be  able  to  buffer  several
   received messages  at  the  low  level before processing them at the
   Kermit level.  This is for two  reasons.   The  first  is  that  the
   Kermit windowing  level  of the protocol may take a while to process
   one input, and meanwhile several  others  may  arrive.   The  second
   reason is  to  support XON/XOFF flow control.  If Kermit receives an
   XOFF from the data communications line, it  must  wait  for  an  XON
   before sending  its  packet.   While  it  is  waiting, the low level
   receive must  be  able  to  accept  input.   Otherwise  a   deadlock
   situation could  arise  with  each side flow controlled, waiting for
   the other.

   5.5 KERMIT WINDOWING PROTOCOL STATE TABLE

   The following defines the inputs expected,  the  actions  performed,
   and the  succeeding  states for proposed new Send_Data_Windowing and
   Rcv_Data_Windowing states.

   If both sides agree on windowing in the  Send  Init  exchange,  then
   instead of  entering  the  old  Send_Data  or  Rcv_Data  states from
   Send_File or Rcv_File,  we  enter  the  new  Send_Data_Windowing  or
   Rcv_Data_Windowing.


   SEND_DATA_WINDOWING

   Rec'd Msg  Action     Next State
   ---------  ------     ----------

   No input/Window closed  (1) Wait for input     SDW
   No input/Window open    (2) Read file, encode packet, SDW
   Place in table, mark unACKed,
   Send packet

   ACK/ X or Z      (3) set interrupt indicator (X/Z)  Send_Eof
   ACK/outside table -ignore-SDW
   ACK/inside table (4) mark pkt ACKed,  SDW or Send_Eof
   if low rotate table,
   if file eof & table empty
      then goto Send_Eof

   NAK/outside table -ignore-SDW
   NAK/inside table (5) test retry limit,  SDW
   re-send DATA packet

   Bad checksum     -ignore- SDW

   Timeout   (6) re-send oldest unACKed pktSDW

   User interrupt   (7) set interrupt indicator (X/Z)  Send_Eof

   Other     (8) send Error Abort


   RCV_DATA_WINDOWING

   Rec'd Msg  Action     Next State
   ---------  ------     ----------

   DATA/new  (1) send ACK    RDW
   if table full: file & rotate
   store new pkt in table
   DATA/old  (2) send ACK, store in table  RDW
   DATA/unexpected  -ignore- RDW

   Z/discard (3) discard file     Rcv_File
   Z/ (4) write table to file & close    Rcv_File
   if OK send ACK, else Error     or Abort

   Bad checksum     (5) send NAK for oldest unACKed      RDW

   Timeout   (6) send NAK for most desired pkt    RDW

   User Interrupt   (7) Set interrupt indicator X or Z   RDW

   Other     (8) send Error pkt    Abort

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

End of Info-Kermit Digest
*************************
-------
23-Jul-85 17:11:31-EDT,16806;000000000001
Mail-From: SY.FDC created at 23-Jul-85 17:10:57
Date: Tue 23 Jul 85 17:10:57-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #8
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Tue, 23 Jul 1985       Volume 3 : Number  8

Departments:

  PROPOSAL FEEDBACK -
    Sliding Window Proposal, Cont'd
    Sliding Window Proposal Q & A

  MISCELLANY -
    Conversion Tables, Liberalized Requirements
    More about IBM Professional Graphics Controller (several msgs)
    Using Kermit with Ungermann-Bass Net One?

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


Date: Tue 23 Jul 85 13:12:23-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Sliding Window Proposal, Cont'd
Keywords: Sliding Windows Kermit

The proposal in Info-Kermit V3 #7 should have been dated July 19, not June
12, and the formatting of the state table at the end appears to have been
messed up -- apologies.

The next message (about 10K long) gives some informal information about
the proposal in the form of questions and answers.  Comments, reactions,
suggestions on both the long-packets and the windowing proposals encouraged.

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

Date: Mon 22 Jul 85 09:30:00-EDT
From: Leslie Spira <OC.SOURCE@CU20B>
Subject: Sliding Window Proposal Q & A
Keywords: Sliding Windows Kermit


                           KERMIT WINDOWING PROTOCOL

                 DRAFT PROPOSED DEFINITION DATED JULY 19, 1985

                             QUESTIONS AND ANSWERS

                    John Mulligan, The SOURCE Telecomputing

                                 July 19, 1985

Q.  What is the purpose of the "windowing" extension?

A.  The object is to speed up file transfers using KERMIT.  The increase
    will be especially noticeable over the data networks (such as Telenet
    and Tymnet) and over connections using satellite links.  This is
    because there are long communications delays over these connections.


Q.  How does it work?

A.  Basically, it allows you to send several packets out in a row before
    getting the first acknowledgment back.  The number of packets that can
    be sent out is set by the "window size", hence the name windowing.


Q.  Could you explain in more detail?

A.  Right now, a system sending a file transmits one packet of data, then
    does nothing more until it gets back an acknowledgment that the packet
    has been received.  Once it gets an acknowledgment, it sends the next
    packet of data.  Over standard direct-dial land-based phone lines, the
    transmission delays are relatively small.  However, the public data
    networks or satellite links can introduce delays of up to several
    seconds round trip.  As a result, the sending system ends up spending
    much more time waiting than actually sending data.

    With the new windowing enhancement, the sending system will be able to
    keep sending data continuously, getting the acknowledgments back
    later.  It only has to stop sending data if it reaches the end of the
    current "window" without getting an acknowledgment for the first
    packet in the current "window".


Q.  What size is the "window"?

A.  The window size can vary depending on what the two ends of the
    connection agree on.  The suggested standard window size will be 8
    packets.  The maximum is 31 packets.

    The KERMIT sequence numbering is modulo 64 (it "wraps" back to the 1st
    sequence number after the 64th sequence number).  It is helpful to
    limit the maximum window size to 31 to avoid problems (ambiguous
    sequence numbers) under certain error conditions.


Q.  Is windowing in effect throughout a KERMIT session?

A.  No, it is only in effect during the actual data transfer (data
    packets) portion of a file transfer.  Windowing begins with the first
    data packet (D packet type), and stops when you get an End-of-File
    packet (Z packet type).


Q.  Why does it stop when you get to the End-of-File packet?

A.  This is done primarily to avoid having more than one file open at
    once.


Q.  Why will windowing be especially helpful at higher baud rates over
    communications paths that have delays?

A.  As you increase the baud rate, the transmission speed of the data
    increases, but you do not change the delay caused by the
    communications path.  As a result, the delay becomes more and more
    significant.

    Assume, for example, that your communications path introduces a delay
    of 1 second each way for packets, for a total delay of 2 seconds round
    trip.  Assume also that your packets have 900 bits in them so it takes
    you 3 seconds to send a packet at 300 baud (this is roughly equivalent
    to a typical KERMIT packet).

    WITHOUT windowing, here is what happens:

    If at 300 baud you transmitted data for 3 seconds (sending 900 bits),
    then waited 2 seconds for each acknowledgment, your throughput would
    be roughly 180 baud.  (Total time for each transmission = 5 seconds.
    900/5 = 180).

    Howver, if you went to 2400 baud, you would transmit data for 3/8
    second, then wait 2 seconds for an acknowledgment.  (Total time for
    each transmission = 2 and 3/8 seconds).  The throughput would increase
    only to about 378 baud. (900 / 2.375 = 378).

    The delay becomes the limiting factor; in this case, with this packet
    size, the delay sets an outside limit of 450 baud (900 / 2 second
    delay = 450), no matter how fast the modem speed.

    WITH windowing, the throughput should be close to the actual
    transmission speed.  It should be possible to send data nearly
    continuously.  The exact speed will depend on the window size, length
    of transmission delays, and error rate.


Q.  Are there any new packet types introduced by this extension?

A.  No, the only change is to the contents of the Send-Init packet, to
    arrange for windowing if both sides can do it.  If either side cannot,
    KERMIT will work as it does now.  Adding an extension such as this was
    provided for in the original KERMIT definition.  See section 3 of the
    windowing definition for details.


Q:  On the receive side, in section 4.2, why does the definition say that
    writing to disk is done when the Receive-Table becomes full rather
    than as soon as you get a good packet?

A:  The definition was phrased this way because it makes the logic of the
    receive side clearer and simpler to implement.

    Actually, you could also write a packet to disk when it is a good
    packet and it is the earliest entry in the receive table.  This
    approach has the disadvantage that you don't know at this point that
    the sender has received your ACK, so you have to be prepared to handle
    the same packet later on if the sender never gets the ACK, times out,
    and sends the same packet again.  Thus you have to be prepared to deal
    with packets previous to the current window; you will have to ACK such
    a packet if it has been received properly before.

    By writing packets to disk only when the receive table becomes full,
    (the oldest packet) you know that the sender has received your ACK
    (otherwise the sender could not have rotated the window to the n+1
    position to send the current packet, where n is the window size).
    This makes it very easy to stay in synch with the sender.  The
    disadvantage of this approach is that when you receive the End-of-File
    packet, you have to take the time to write all the remaining packets
    in the Receive-Table to disk.


Q.  Could you briefly explain what happens if a single packet gets
    corrupted?

A.  In essence, the receiver will ignore the bad packet.  When it gets the
    next good packet, it will realize (because packets are numbered) that
    one or more packets were lost, and NAK those packets.  The receiver
    continues to accept good data.

    As long as the sender's window does not become "blocked", the only
    loss of throughput will be the time it takes to transmit the NAKed
    packets.

    For a full description, see section 4.2 of the windowing definition.


Q.  There are currently two proposals for KERMIT extensions: the Windowing
    extension and a proposal for extended packet lengths.  What are the
    relative advantages and disadvantages of sliding windows and extended
    packet lengths?

A.  What is best depends on the exact conditions and systems involved in a
    particular file transfer.  There are some general rules however.

    Windowing helps more and more as the communications path delays get
    longer.

    Windowing is also more and more helpful as the baud rate goes up.

    Increased packet length is most helpful on circuits with low error
    rates.  If the error rate is high, it is difficult for a long packet
    to get through uncorrupted.  Also, it then takes longer to re-transmit
    the corrupted packet.

    On some machines, the CPU time to process a packet is relatively
    constant no matter what the packet length, so longer packets can
    reduce CPU time.


Q.  Are extended packet lengths and sliding windows mutually exlusive?

A.  No, there is no real reason that they would have to be.  As a
    practical matter, it is slightly easier to implement windowing if you
    know the maximum packet size ahead of time, since you can then just
    use an array to store your data.  In standard KERMIT, you know
    automactically that your maximum packet length is 94, so you can just
    go ahead and dimension an array at 94 by Window-size.

    If you are going to use both extended packet length and windowing, you
    need to select the maximum packet length and window-size so that the
    combination does not exceed the available memory for each side of the
    transfer.

    In addition, it is possible to see the desired relationship between
    packet size and windowing for various baud rates and communications
    delays.  For the common case of an error corrected by one
    retransmission of the corrupted packet, the minimum window size needed
    for continuous throughput (the window never gets "blocked") can be
    calculated by:

                    4 x delay x baud rate
      WS  >   1 +  ------------------------
                       packet-size x 10           ;(this is the # of bits)


    Windowing always helps (the minimal continuous throughput window size
    is always greater than 1).

    In the above equation, the "4" derives from the fact that a corrupted
    packet has 4 transit times involved:

         Original (bad checksum) packet
         NAK for the packet
         Retransmission of packet
         ACK for retransmission.

    All of this must happen before the window becomes blocked.

    The "delay" is the effective maximum one-way communications path
    delay, which includes any CPU delays.

    Strictly speaking, the "packet-size" should have the length of the ACK
    packets added to it.

    As an example, if you assume a 2-second (one-way) delay, at 1200 baud,
    with a packet size of 94, the minimum window size for continuous
    throughput would be:

              4 x 2 x 1200
       WS  >  ------------    =   10.2
                94 x 10

    Under these circumstances, a window size of at least 11 should be
    chosen, if possible.


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

Date: Sat, 20 Jul 85 10:47:19 PDT
From: VSS7853@UCLAVM
Subject: Conversion Tables, Liberalized Requirements
Keywords: ASCII/EBCDIC Translation Tables

Regarding the message I sent the other day with the programs for
constructing and analyzing ATOE and ETOA tables, I think I could have
expressed my thesis a bit more clearly.

Kermit-TSO and Kermit-CMS require that the TCAM (or whatever) tables
be, loosely speaking, inverses of one another.  I claim that this
requirement is too restrictive and prevents Kermit from working on
systems where it otherwise might.

On Ebcdic machines, Kermit performs the following four translations:

1. (e to a) predict the Ascii form of an outgoing message so that a packet
            can be constructed in Ascii.
2. (a to e) map the packet back to Ebcdic for outputting and final
            reconversion by TCAM.
3. (e to a) reconstruct the Ascii form of an incoming packet already
            converted by TCAM, so that the packet can be analyzed in Ascii.
4. (a to e) map the incoming message back into its final Ebcdic form.

Presently these four internal transformations are done with only two tables,
each identical to the corresponding TCAM table.  Whence the requirement that
the two TCAM tables be inverses of one another.

I claim that by constructing four tables, one for each of the above numbered
functions, two benefits would accrue:

1. The requirements on the TCAM tables would be weakened.  Each table would
   have to be invertable separately, but they would no longer have to be
   inverses of each other.

2. Kermit could guarantee a standard correspondance between the two character
   codes for messages transmitted from Ascii machines to Ebcdic and vice
   versa, instead of accepting the correspondance imposed by the local TCAM
   tables.

In the other message I attempted to give precise weakened mathematical
requirements for the TCAM tables so that this method would work.

Also tools would have to be developed to construct the necessary translation
tables to be used by Kermit.  These tools ought to be included in the
distribution.

What do you think?

Glenn Thobe
EE dept., UCLA
818-888-8434

p. s. Please address replies to both IVA3GET@UCLAMVS and VSS7853@UCLAVM
(BITNET).

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

Date: Mon 22 Jul 85 16:55:26-EDT
From: Charlie C Kim <US.CCK@CU20B>
Subject: IBM Professional Graphics Controller
Keywords: Professional Graphics Card

It's called a Professional Graphics Controller (not Adapter).  Waiting for
the vertical retrace on the EGA isn't a bad thing to do--it's just
unnecessary in the enhanced mode.  It isn't so clear that it's the wrong
thing to do when it is emulating the CGA.

The problem with losing characters above 1200 baud on the PGC is well known.
The following message from the IBM-PC bulletin board should clarify the
issue:

  Date:  Thu, 4 Jul 85 13:54 EDT
  From:  "Roger C. King" <[e-mail]>
  Subject:  Professional Graphics Controller Fix

We have had IBM replace more than a dozen Professional Graphics controllers
with corrected units which work correctly with previous communications
packages at 9600 baud. The old unit did not work correctly at all, but sort
of worked on an AT at 2400 baud (sort of means some dropped characters) and
sort of worked on an XT at 1200 baud. It takes an individual, case by case,
interface with IBM to get this resolved, but it is possible for a field
office to get someone at Boca to send out corrected boards for a swap. A
good controller can be recognized as follows:

    Looking at a controller with the output on the right, the top left
    corner of the board has a 'REV' number, probably 6323698, whited out
    with white paint or something similar. A bad board(s), does not have
    this number modified.

As an aside, we have found the Professional Graphics Controller to be an
almost perfect emulator of the old Color Graphics controller. Even
low-res software seems to work correctly.

Roger King

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

From: Herm Fischer <hermix!fischer@RAND-UNIX>
Subject: Professional Graphics Controller
Date: Mon Jul 22 16:02:42 1985
Keywords: Professional Graphics Card

Carl Houseman reports problems over 1200 baud with this display.  He should
be aware that the async ports dont work over 1200 at all unless he gets
replacement PGA cards from IBM.  The original cards had hardware/firmware
problems which interfered with comm activity; IBM has "recalled" those
cards.

I am using the EGA on Xenix and on MSDOS with kermit.  So far no problems,
but have not tried EGA with MSDOS above 1200...

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

Date: 23 July 1985 1350-PDT (Tuesday)
From: [e-mail] (Marcelo Germar)
Subject: Using Kermit with Ungermann-Bass Net One?
Keywords: Ungermann-Bass Net One

Does anybody have experience using ibm pc kermit with ungermann-bass net one
to transfer files between a vax with 4.2bsd unix and an ibm pc?

What should be the configuration of the ungermann-bass hardware/software
to enable a successful file transfer?

All your help will be sincerely much appreciated.

thanks,
marcelo

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

End of Info-Kermit Digest
*************************
-------
26-Jul-85 17:53:40-EDT,15845;000000000000
Mail-From: SY.FDC created at 26-Jul-85 17:53:06
Date: Fri 26 Jul 85 17:53:06-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #9
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri, 26 Jul 1985       Volume 3 : Number  9

Departments:

  ANNOUNCEMENTS -
    Kermit for the PDP-8

  PROPOSAL FEEDBACK -
    Lurching Windows?
    About the New Proposals
    Kermit Windowing Questions and Answers...Continued

  MISCELLANY -
    Tranferring a MacPaint or MacDraw Document
    MS-Kermit and the Hercules Monochrome Graphics Card

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

Date: Fri 26 Jul 85 17:07:42-EDT
From: Frank da Cruz <[e-mail]>
Subject: Kermit for the PDP-8
Keywords: PDP-8 Kermit

This is to announce Kermit-8 for the DEC PDP-8 with OS8 or RTS8, written in
the PAL-8 assember by Jerry Sands and Randy Hippe of the Bureau of
Engraving, Inc., Minneapolis, MN.  It works in local mode only, includes
CONNECT, BYE, EXIT, SEND, GET, and RECEIVE commands, and can do wildcard
sends.  There is no documentation to speak of.  The program is in
K2:K08MIT.PAL (and .HLP) on CU20B, available via anonymous FTP.

This means that Kermit is now available for every single existing DEC
machine operating system, with the exception of IAS-11 (soon to be
contributed, I hope).  (I hope there aren't any PDP-1's, -4's, -6's, -7's,
9's, -12's, or 15's left out there...  If you have one, why haven't you
written Kermit for it?)  And if you count WPS-8 as an operating system,
maybe someone who knows something about it could convert this program for
the benefit all the poor DECmate users who need to transfer their WPS
"documents" to systems that don't have DX.

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

Date: Thu, 25 Jul 85 12:49:49 pdt
From: hpl-opus![e-mail]
Subject: Lurching Windows?
Keywords: Lurching Windows

I didn't see any discussion of how to extend this to half-duplex lines
("lurching windows").  Is any forthcoming?

Ken Poulton

[Ed. - See below.]

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

Date: 24 Jul 1985 1257-EDT
From: B.Eiben LCG Ext 617-467-4431 <EIBEN at DEC-MARLBORO.ARPA>
Subject: About the New Proposals
Keywords: Kermit Protocol Proposal

Yes, I have seen the stuff only "fly by" on the screen - so my comments will
be "fast and [maybe] not fully founded".  [By the way, I like both proposals
and believe, they both will work together.]

I would like to introduce the "bulk" ACK from the Receiver [didn't see that
mentioned - or "lost it on the screen"], i.e. the Receiver has the freedom
to "ACK" every X packets, where X can be between 1 and the agreed upon
maximum window-size.

Receipt of the "BULK" ACK forces a "sliding" of the SENDER's window, so that
it "starts" after receipt with the next packet.

The Receiver will discard packets with packet-nr's LESS than current "BULK"
ACK and "BULK" ACK minus MAX Window-size.  I will regard receipt of packets
with even smaller numbers a "serious errror" - i.e. stop receiving.

[To be "discussed more" : It might be also a good rule to FORCE an ACK on the
last two PACKETS BEFORE crossing the 64-magic to make sure, that the SENDER's
window slides nicely..]

I believe, that the above rules "get rid" of the receivers duty to keep a
"table" plus a relatively large buffer - it also leaves it open for the
receiver to "write to the 'disk' whenever he feels necessary"

It doesn't complicate SENDER behaviour - but the hightest overall "gain" is
anyhow at the 90% of down-loads from distribution-points, which typically
are slightly larger than "micro's" - and can afford the "extra" coding.

It also [as a side effect] eases handling of "larger packets" on the micro
[I just hate to debug the logic of a "floating table" depending on memory-
limits {relatively easy} plus "agreed upon" package size {slightly more
muggy} aggravated by [either] unexpected RE-Sends because I was too long
occupied didling the floppy or expected - i.e. I saw a bad packet , sent
a NAK but was not allowed to "throw away the rest".

Which leads to an "addendum" for the SENDER - all in the view of keeping
the coding EASY for all the micro-versions...

On receipt of a NAK - all PACKETS INCLUDING the NAKed one and [maybe already
sent other ones] will be re-sent.

If we are clever - remember the "bulk" number for the ACK didn't have to be
established - we can "train" the receiver to "trim down" the "bulk" number
depending on the amount of NAKs per X packets - thereby allowing a "macro"
adjustment to line-quality.

I will not go into "calculations" - but as a rule of thumb:

On SLOW channels [300 Baud] - there typically will be only ONE MORE packet
sent after the receiver sees the NAK - and its NOW the msg "Lets redo it
after the last good one" - so thats tolerable.

On "faster" channels [4800 Baud and UP] - there "might be" another packet
"sneaking in" - but "channel quality" typically tends to be better anyhow,
so "better quality" and "higher speed" make the overhead of above
simplification tolerable again.

... and last not least - one probably can even under CP/M with ist 64K
limitation handle both LARGER PACKETS and "floating ACKs"

Rgds,
Bernie.

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

Date: Fri 26 Jul 85 16:50:48-EDT
From: Leslie Spira <[e-mail]>
Subject: KERMIT Windowing Questions and Answers...continued.
Keywords: Sliding Windows Kermit

FORWARD:

The two proposed extensions to KERMIT, Windowing and Extended Packet
Length, are both useful.  They seem to me to be complementary, and each
solves certain problems that the other cannot.

The purpose for the development of the windowing protocol was to solve the
problem of how to increase throughput over circuits with long delays that
also had a potentially noisy section of the circuit.

The discussion of the Windowing protocol, and of Extended Packet Lengths,
should keep in mind the environments in which each would be useful.  In
some cases, a combination would provide optimum performance.

The extensions will only be implemented for situations that make sense.
In all cases, KERMIT Classic will still be available, with all its utility
of being able to handle varied enviroments.

While reading the following questions and answers, keep in mind that this
windowing definiton was developed to handle a common situation of long
circuit delays with possible moderate error rates.  KERMIT does not need
this type of extension for clean lines with insignificant delays - KERMIT
could be left alone, or use Extended Packet Lengths, in such environments.

Long delays with significant error rates will occur under two obvious and
common conditions:

    A.   Local phone line (of uncertain quality) to Public Data Networks
         (such as Telenet).

    B.   Satellite phone links.  These often occur with the lower-priced
         phone services, which often also have noisier lines.  In
         addition, satellite links will increase as more people need to
         transfer data overseas.

The above conditions will become more common, as well increased baud
rates, which make the delays more significant.

As an aside, note that the benefit of Extended Packet Lengths over the
Public Data Networks is limited by the number of outstanding bytes the PDN
allows.  (Internally, the PDNs require end-to-end acknowledgement.  They
use their own windowing system within the network.)  I don't currently
know the exact impact of this.

Now on to the questions...

Q.  Can sliding windows be done on half-duplex channels?  Are any
    modifications to the proposal required?

A.  An underlying assumption in the development of windowing was that
    there was a full-duplex channel.  (See section 5.4, "Low Level
    Protocol Requirements")

    The intent of windowing is to try to keep the sender continuously
    sending data.  Obviously, this is not possible on a half-duplex
    channel.  A better solution for half-duplex channels would be to use
    an extended packet length.

    An attempt to use windowing on half-duplex really is just a way of
    doing extended packet lengths.  The sender would send out a group of
    packets, then wait and get a group of ACKS.  It would be better to
    simply send out a large packet, which would have less overhead.


Q.  Is the cost in complexity for sliding windows worth the increase in
    performance?

A.  Under the conditions described above (long delays and possibly
    significant error rates) windowing can increase performance by a
    factor of 2, 3, or more, especially at higher baud rates.  This
    increase is necessary to make KERMIT viable under some conditions.
    With classic KERMIT over the Public Data Networks, I have had
    througput as low as 250 baud over a 1200 baud circuit (with a
    negligible error rate).  Windowing should allow throughput close to
    the maximum baud rate.

    Windowing is most helpful when the delay is significant in relation to
    data sending time.  Any delay becomes more significant as users move
    to higher baud rates (2400 baud and beyond).

    The complexity of implementing windowing has yet to be fully
    evaluated.  The first implementation (for the IBM PC using C-KERMIT)
    proved to be fairly manageable.  It appears that the windowing logic
    can be implemented so that KERMIT Classic uses the same code, but with
    a window size of 1, which should avoid having to keep separate
    sections of code.

    The windowing definiton was developed with the idea of keeping changes
    to KERMIT to a minimum.  No new packet types were developed, ACKs and
    NAKS were kept the same, and windowing is in effect only during actual
    data transfer (D packets).  We tried to define the protocol so that a
    window size of 1 was the same as the current classic KERMIT.

    These factors should help reduce the complexity of implementing
    windowing.  We currently have a working implementation of KERMIT for
    the IBM PC going through testing.

    It's fun to see the modem "Send" light stay on constantly!


Q.  Why doesn't the Windowing proposal use a "bulk ACK"?

A.  There are a couple of possibilities for ways to use some sort of
    "bulk" or combined ACK.  We looked at them when developing the
    Windowing definition.  We did not see any advantages that outweighed
    the disadvantages.

    Here are two possible ways of changing how ACKs would work:

    1.   An ACK for any packet would also ACK all previous packets.

    2.   A new "Bulk ACK" (BAK?) packet could be developed.

 1. The concept that an ACK would also ACK all previous packets seems
    attractive at first, since it would appear to reduce overhead.
    However, it has a major drawback in that you then must re-synch when
    you get errors.  This is because, once you have an error, you have to
    send a NAK, then stop and wait for a re-transmission of the NAKed
    packet, before you send out any more ACKs.  (If you sent out an ACK
    for a later packet, it would imply that you had received the NAKed
    packet.  Not until you safely get the re-transmission can you go ahead.)

    This would negate one of the nicest parts of windowing as it is
    defined now, which is that the sender can transmit continuously,
    including during error recovery, as long as the window does not become
    blocked.

    It does not appear to us that the reduction in the number of ACKs sent
    is worth this penalty.

    In addition, this is a departure from the way ACKs in KERMIT work
    now.  It seemed best to make as few changes to KERMIT as possible.  If
    this facility turns out to be useful, it would be better to introduce
    a new packet type (or other means of distinguishing regular ACKs from
    "Bulk ACKS").

 2. A new "Bulk ACK" packet type could be developed.  This did not seem to
    us to be a good idea, since it required defining a new packet type.
    We were trying to fit windowing in with as few changes to KERMIT as
    possible.

    A "Bulk ACK", in which one packet could contain a whole string of ACKs
    and NAKs, also seems like a good idea at first.  The penalty here is a
    little more subtle.  First, if you lose a "Bulk ACK" packet, you lose
    more information and it takes longer to get things flowing smoothly
    again.

    Second, and probably more importantly, efficient windowing depends on
    the window never becoming "blocked" (i.e., the sender can always keep
    sending).  A "Bulk ACK" interferes with this to some extent, because
    if you have a long delay, the "Bulk ACK" with its multiple individual
    ACKs may not get back to the sender in time to prevent the window from
    becoming blocked.

    With the current definition of windowing, returning an ACK for each
    packet gets the ACKs (or NAKs) to the sender as soon as possible.
    This provides the best chance for keeping the window open so that the
    sender can transmit continually.

    Once again, remember the conditions under which windowing is most
    useful: long delays with significant error rates.  Under these
    conditions, individual ACKs have advantages.

    If these conditions don't apply, it may not be necessary to use
    windowing, or it may be better to use extended packet lengths.

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

Date: Thu, 25 Jul 85 16:41:22 PDT
From: ucsfcca.ucsf![e-mail] (Joe DeBattista)
Subject: Tranferring a MacPaint or MacDraw Document
Keywords: MacKermit

I have a question about whether it is possible to upload and/or download a
MacPaint or MacDraw document.  When I use macput or macget with Versaterm or
MacTerminal this works ok, as it seems to grab the data and resource files
together.  When I try to upload to our VAX 750, I can only specify the data
or resource from the settings menu.  When I try to download a macpaint
document, I tried sending the data file first and then the resource, but
that didn't work.  I've checked the MacKermit documentation for hints, and
have asked people around here if they have a solution.  I am currently
running version 08(32).  Thanks.

                               Joe DeBattista
                               BITNET: jd9014@ucsfcca
                               UUCP: ucbvax!ucsfcgl!ucsfcca.ucsf!jd9014

[Ed. - It says somewhere in the Mac Kermit documentation that you can only
send one fork of a file at a time.  I think what you need to do is send each
fork separately, giving each a different name (like FOO.DATA and FOO.RSRC).
When bringing them back to the Mac, get the two files separately, each into
the appropriate fork of the same file.  I realize this is less than
satisfactory, but Kermit was not designed to anticipate that a file could
actually have more than one part; the other programs you mentioned are
Mac-specific and designed to know about this.  In general, I think the
safest way to treat arbitrary Mac files is to run them through Binhex before
transmitting to a foreign system, and unBinhex them upon return.]

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

Date:     Tue, 23 Jul 85 19:17:35 BST
From:     [e-mail]
Subject:  MS-Kermit and the Hercules Monochrome Graphics Card
Keywords: MS-DOS Kermit, Hercules Graphics Card

In response to query on MS-KERMIT with the Hercules card (vol 3
#5), I must say that I have encountered no problems, at least with
version 2.27.  Our configuration is an XT, DOS 2.10, and a fully
populated QuadRam expansion card.  We dedicate 360K to a RAM disk
using AST support though.  Good luck!

Les Wu

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

End of Info-Kermit Digest
*************************
-------
31-Jul-85 12:01:33-EDT,11240;000000000000
Mail-From: SY.FDC created at 31-Jul-85 12:00:20
Date: Wed 31 Jul 85 12:00:18-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #10
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Wed, 31 Jul 1985       Volume 3 : Number 10

Departments:

  ANNOUNCEMENTS -
    Summer Vacation
    Release 4C(057) of C-Kermit for Unix
    Update of Pascal/VS Kermit for IBM VM/CMS

  PROPOSAL FEEDBACK -
    Windows Considered Harmful
    Re: The New Proposals

  MISCELLANY -
    DDJ Article on Asynchronus Protocols
    TTSynch in VMS kermit
    VMS-Kermit and VMS 4.0
    Bug in Prime Kermit Shows Up with Kermit-MS 2.28
    Generic CP/M-80 Kermit Question (& Answer)
    Kermit-11 and IAS

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

Date: Wed 31 Jul 85 11:18:21-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Summer Vacation

After this week, I'll be on vacation until the first week in September.
While I'm gone, some of the other people at Columbia will moderate the
Info-Kermit digest as time permits (we're all quite busy on other projects).
Let's keep the discussion of long packets and sliding windows going and see
if some concensus will emerge.  Meanwhile, address all Kermit-related
correspondence to Info-Kermit@CU20B or Info-Kermit-Request@CU20B, not to me
personally, so that it can be routed to whoever is handling the digest while
I'm gone.  - Frank

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

Date: Mon 29 Jul 85 20:15:03-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Release 4C(057) of C-Kermit for Unix
Keywords: C-Kermit, UNIX Kermit

This is to announce Yet Another Release of C-Kermit for Unix, 4C(057).
The changes, like last time, are minor:

. "set send packet-length" now overrides negotiated value, so that
  packet lengths in both directions can be controlled from one side.

. The Unix Kermit server now responds to all generic commands (but not
  "remote host" commands) in text mode, even if the file type is
  currently set to binary.  Remote host commands continue to obey the
  file type setting.

. Support for 4.1BSD, 2.9BSD, and BBN C/70 that was apparently broken
  in recent edits is (or should be) fixed again.

. A bug that sometimes prevented 14-character filenames on non-4.2bsd
  systems from being recognized is fixed.

. Several other bugs fixed relating to modem control, dialing, etc.  But
  reportedly some problems still remain -- see the .BWR file.

Thanks to Herm Fischer and Dan Schullman for reporting and/or fixing the bugs
corrected by this release.  The files are in K2:CKU*.* and K2:CKC*.* on CU20B,
available via anonymous FTP.  CKUKER.UPD lists the changes in greater detail,
CKUKER.BWR lists the known bugs and restrictions, CKUKER.DOC (and .MSS) is an
updated Kermit User Guide manual chapter.

This should be the last release of C-Kermit until some time in September.
In the meantime, send suggestions, comments, complaints, bug reports and fixes
to Info-Kermit@CU20B, as usual.

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

Date:    Mon, 29 Jul 85 11:23 EDT
From:    [e-mail]
Subject: Update of Pascal/VS Kermit for IBM VM/CMS
Keywords: VM/CMS Pascal Kermit

I have made a few changes to the Pascal/VS version of Kermit-CMS to correct a
few bugs.  So I am sending you updated source code for it.

Victor Lee, Queen's University

[Ed. - The updated program is in K2:CM2MIT.*.]

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

Date: Tue, 23-Jul-85 11:44:51 xDT
From: (anonymous)
Subject: Windows Considered Harmful
Keywords: Sliding Windows Kermit

The windowing stuff looks far too complex; I think it will greatly
decrease one of the Kermit's main points -- its fundamental simplicity.
The interrupt stuff to make such things work can be a tremendous pain on
many systems, and it really is probably not worth the effort.

Large packets are OK, but I don't think people are going to see as much
of an advantage as they think, even on long hauls.

With every one of these mods, things get a little less compatible and a
little less universal.  I personally think that efforts in this area are
starting to show signs of "feature-itis" that would best be avoided.

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

Date:  Sat, 27 Jul 85 00:48 EDT
From:  [e-mail]
Subject:  Re: The New Proposals
Keywords: Kermit Protocol Proposal, Sliding Windows Kermit, Long Packets

Hi.  I vote for both proposals, in my environment I can use both, though
probably separately.  The sliding window proposal would be great for our
communications Boston -> Tymnet -> Transpac -> Versailles which is plagued
by long long delay ... and won't allow long packets either.  Meanwhile, in
house our poor VAX is swamped when Kermit is going at 9600 baud due to
its lousy TTY input interrupt handling (per character) and at least long
packets would reduce the number of task switches and I suspect lead to
better interactive performance for the non-Kermit users.  Assuming of course
it'll eat a long package without losing characters ... that remains to be
tested.  [Anyway, the easiest way to test it would be for someone else
to implement long packets in Kermit and then ...]

I wanted to point out that although in kermit-digest V3 #9 it
was mentioned that long packets wouldn't be good given fast error-free
communication I disagree:  I think timesharing hosts would benefit by the
fewer task switches from OS read to application Kermit.

-- Dave (Bakin -at mit-multics)

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

Date: Wed 31 Jul 85 01:28:11-PDT
From: Bob Larson <BLARSON%ECLD@ECLA>
Subject: DDJ Article on Asynchronus Protocols
Keywords: Asyncronous Protocols

Kermit is mentioned in the article "Asynchronous Protocols" in the
August 1985 issue of Doctor Dobbs Journal.  The article is an overview
of several asyncronous protocols.

It does state "It [Kermit] may become a widely used standard in the near
future," but devotes much more space to discussing versions of [x]modem[7].

Bob Larson <[e-mail]>

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

Date: Mon, 22 Jul 85 09:11:50 edt
From: Steve Archer <[e-mail]>
Subject: TTSynch in VMS kermit
Keywords: VMS Kermit

We find here locally, that we have to do a 'set term /noTTSynch' before
we use the VMS kermit with any half duplex machine that uses Xon/Xoff
protocol.  Apparently the machines that VMS kermit was written for are that
way by default.  Having to do the set term confuses many of our casual
users of kermit.  Kermit could very easily do this automatically for the
user.  Could this be incorporated in the next VMS kermit release?

steve {seismo,allegra}!rochester!kodak!archer

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

Date: Thu, 25 Jul 85 09:33:31 edt
From: <decvax!cincy![e-mail]>
Subject: VMS-Kermit and VMS 4.0
Keywords: VMS Kermit

VMS-Kermit (Version 3.1.066) was running fine under VMS 3.6, but shows
annoying habits under 4.0: in connect mode, long outputs from the remote
host are echoed by ^G (BEL) (going to the remote host). This obviously
confuses the remote host. I conjecture that the bell is the same as
the one now heard on logging in. (We set the line protections of regular
terminal lines so that they can be allocated by WORLD.)

I would be grateful for any suggestions.

Henning Schulz-Rinne
Univ. of Cincinnati

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

Date:     Friday, 26 Jul 85 17:11:47 EDT
From:     rmcqueen (Robert C McQueen) @ sitvxb.CCNET
Subject:  Re: VMS Kermit Problems
Keywords: VMS Kermit

Ok, noted.  First person to have free time will look into them.

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

Date: 26 Jul 85 09:15:06 ADT
From: CGP@UNBMVS1
Subject: Bug in Prime Kermit Shows Up with Kermit-MS 2.28
Keywords: Prime Kermit, MS-DOS Kermit

Prime Kermit can not be used in server mode with Kermit-MS 2.28.
The problem is that Prime kermit NAKs the Init-Info packet, instead of
responding with an Error packet as specified in the Protocol Manual.

Kermit-MS 2.26 does not seem to use the Init-Info packet, and did
work with Prime Kermit.  I have not tested it with 2.27.

I have modified Prime Kermit to honor the Init-info packet.  What is the best
way to forward the corrected source?

                             Carl Pottle
                             University of New Brunswick
                             Saint John, N.B.
                             Canada
                             CGP@UNBMVS1

[Ed. - Just send the new code by electronic mail to Info-Kermit@CU20B.]

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

Date: 16 Jun 1985 11:33:08 EDT (Sunday)
From: Tom Reid (MS W932) <treid@mitre-gateway>
Subject: Generic CP/M-80 Kermit Question
Keywords: CP/M-80 Kermit

To make a long, sad story short, I have an Ithaca Intersystems Z80/CPM
system with an interrupt driven serial board.  This makes the usual
direct port addressing schemes of communication packages impossible
to install.  Generic Kermit's only requirement of an installed IOBYTE
seemed a perfect solution.

However, Kermit goes direct to the devices crt:, tty:, etc. rather than
at the virtual CON:, RDR:, and PUN:.  I have tried to hook the II to a
Kaypro 2x direct connect through the modem port and with the KP being the
II's terminal.  (As a terminal, it is fine, but cannot establish
communication when a file transfer is initiated).

Any ideas of how to proceed from here?  Thank you in advance for your
help.  Please reply directly to me as I am not on the info-kermit mailing
list.  If there is interest, I will summarize and post any replies
and solutions to info-kermit.  Tom Reid.

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

Date: 27 Jul 1985 00:12 PST
From: Charles Carvalho <CHARLES@ACC>
Subject: Re: Generic CP/M-80 Kermit Question
Keywords: CP/M-80 Kermit

Generic Kermit has to know what physical devices are in use because the
only way it can test the modem port for data available is to make it the
console and use the "get console status" bdos call.

The console port and the modem port must be different ports; if your
system doesn't have a builtin console, you'll need a terminal connected
to the console port, and the Kaypro connected to the serial port.

Given the physical device names (TTY/CRT/UC1/PTR/etc) of the console port
and the serial port, the proper argument for the SET PORT command may
be found in the CP/M Kermit chapter of the User's Manual.  /Charles

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

Date: 30 JUL 85 10:52-EST
From: [e-mail]
Subject: Kermit-11 and IAS
Keywords: Kermit-11, IAS

Status of Kermit-11 for IAS v3.1:

I have just talked with an EPA site and they plan to have Kermit-11
running on IAS 3.1 by Sep 1. This version of Kermit-11 will not be able to
do wildcard file operations (at least at first) and some of the mcr/dcl
interface will be lost. Addtionally, sources will be separate from
Kermit-11's source as IAS 3.1 does not support some of the assembler
directives I used thus forcing the EPA to merg some source files and make
other minor (but very numerous) changes.  They are working from a very
recent copy of Kermit-11, so there should otherwise be a good measure of
compatibility.

                                                brian nelson
                                                [e-mail]

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

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

-------
 1-Aug-85 14:51:21-EDT,23882;000000000001
Mail-From: SY.FDC created at  1-Aug-85 14:48:27
Date: Thu 1 Aug 85 14:48:26-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #11
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Thu,  1 Aug 1985       Volume 3 : Number 11

SPECIAL SLIDING WINDOWS ISSUE --
    Comments on Comments on Lurching Windows
    Sliding Windows -- When to Write to Disk?
    Mutual Exclusivity of Sliding Windows and Long Packets?
    Implied ACKs, Half Duplex Windows
    Full-Duplex Windowing vs CP/M, et al
    Proposal for Half Duplex Windows
    Examination of Proposals
    Full Duplex Sliding Windows -- Let's Give Them a Try

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


Date: Sun, 28 Jul 85 21:32:40 pdt
From: "Scott Weikart; Community Data Processing;
 415-322-9069" <cdp!scott@Glacier>
Subject: Comments on Comments on Lurching Windows
Keywords: Sliding Windows Kermit

> Date: Fri 26 Jul 85 16:50:48-EDT
> From: Leslie Spira <[e-mail]>
> Subject: KERMIT Windowing Questions and Answers...continued.
>
>     The intent of windowing is to try to keep the sender continuously
>     sending data.  Obviously, this is not possible on a half-duplex
>     channel.  A better solution for half-duplex channels would be to use
>     an extended packet length.
>
>     An attempt to use windowing on half-duplex really is just a way of
>     doing extended packet lengths.  The sender would send out a group of
>     packets, then wait and get a group of ACKS.  It would be better to
>     simply send out a large packet, which would have less overhead.

Actually, this is not quite true.  If the channel is noisy, then longer
packets won't increase the data rate.  Tha advantage of a lurching window
scheme is that the receiver could NAK all the small packets that didn't
make it, and then the sender could resend the NAKed packets plus some new
packets in the next bundle.

I think that lurching windows would be a good idea.

-scott

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

Date: Thu, 850725 15:11:20-EDT
From:   Peter Marshall  <[e-mail]>
Subject: Sliding Windows -- When to Write to Disk?
Keywords: Sliding Windows Kermit

I would like to add a question to the group produced by John Mulligan
produced in a recent Kermit-digest.  I wonder if someone could explain
why it would be so much more difficult to write a received packet to
disk, when you have correctly received it?  His explaination does not
make sense to me.  Just because you write a packet to disk does not mean
that you have to clear it from the receive table at that time.  When you
actually clear the oldest message from the receive table for a new
message, then you can be assured that the sender has received the ACK.
So I don't see his argument about keeping things synchronized.  The ACKed
flag  in the table could also act as a "written to disk" flag.

Is it not a little unsafe to assume that you have received a packet
correctly (and send off an ACK to that effect) until you have actually
got it safely to disk?

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

Date: Tue, 30 Jul 85 20:41:16 EDT
From: [e-mail]
Subject: Mutual Exclusivity of Sliding Windows and Long Packets?
Keywords: Sliding Windows Kermit, Long Packets

I'm not sure that I understand what was meant by long packets and sliding
windows being mutually exclusive.  If it means that both would not be used
at the same time, that seems fairly reasonable (although packets a bit longer
than 96 characters wouldn't seem to be especially harmful).  If it means that
only one of the two proposals should be adopted, I disagree.  They are not
technically incompatible and each solves some problems that the other does not.

Sliding windows are best if the environment can support them.  However, some
major systems, such as the IBM 370 (TSO and, I think, CMS), do not support
the necessary full duplex channel.  TSO, at least, will support long packets.
The UCLA File Transfer Package sucessfully uses a 1K packet size on TSO and
CMS (using their own protocol).  We very much want improved Kermit performance,
but will never be able to support sliding windows on our TSO system.  On the
other hand, we also have a DECsystem-10, which can support sliding windows.
Those users would benefit from the extra performance of sliding windows over
long packets.

Lurching windows for half duplex channels were not addressed in the sliding
windows proposal.  It seems like sender and receiver would have to agree on
how many packets would be sent before the receiver would acknowledge.  The
sender would have to know not to try to send more packets until the previous
group was acknowledged.  I suppose that this number could be the window size.
Also, in a lurching windows environment, a way to acknowledge multiple
packets would be beneficial, as acknowledgements are not overlapped with
data.  The main difference between lurching windows and long packets seems
to be that lurching windows have more overhead bytes and that less data
might be retransmitted in case of an error.

One further point on lurching windows: I'm pretty sure that TSO would require
a delay of a charcater time or more between packets so that they would be
recognized as separate "lines" of input.  Otherwise, I think that everything
after the carriage return at the end of the first packet would be lost.
Also, when TSO detects a parity error it sends out a transmission error
message, which means that it would not be listening for the following packet,
so it would be lost too.  All in all, I think long packets are better for
half duplex channels and sliding windows are better for full duplex.

In the sliding windows proposal, I do not understand why the sending of
the end of file packet is delayed until all previous packets have been
acknowledged.  It seems to introduce an unnecessary delay.

Both proposals are optional -- no one would have to implement either, if they
don't care about the improved performance or want to defer the additional
complexity to a later version of their Kermit.

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

Date: Sat, 27 Jul 85 18:18:19 pdt
From: hpl-opus![e-mail]
Subject: Implied ACKs, Half Duplex Windows
Keywords: Sliding Windows Kermit, Long Packets

I have two comments on Leslie's Q+A in info-kermit #9.

On implied-ACKing:
    Leslie states that getting a NAK forces the protocol to
    stop sending.  I don't agree.  There's no reason for the sender to stop
    sending just because a NAK came.  The retry for the NAK'ed
    packet can be inserted (ASAP) into the stream of first-try packets.

    ACK's for packets successfully received after the NAK'ed packet
    will have to wait until the NAK'ed packet is successfully received.
    But this does *not* change window requirements: the window has to be
    long enough to cover the time for NAK and retransmission of packets anyway.

    Note that although ACK's must wait until all packets up to that point
    have been received correctly, NAK's for unsuccessful packets can
    be sent as soon as they are detected as being unsuccessful, i.e.
    upon successful receipt of the following packet.  This will help
    keep the protocol running smoothly.

    The only penalty is that since ACKs will be bunched by the receiver,
    the window must be longer by the number of packets implied by each
    ACK to keep the window from filling.

On windows in a half-duplex environment:

    This is dismissed as being just long packets, with the implication
    that one should just use long packets in a half-duplex environment.

    This is not true!  Half-duplex connections have exaclty the same problem:
    how to get good efficiency over long-delay + moderate error rate
    connections.

    I would like to have half-duplex sliding windows seriously considered!

Ken Poulton
hplabs!poulton

I know it's dumb, but half-duplex is the way many systems work...

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

Date: 27 Jul 1985 1334-EDT
From: B.Eiben LCG Ext 617-467-4431 <EIBEN at DEC-MARLBORO.ARPA>
Subject: Full-Duplex Windowing vs CP/M, et al
Keywords: Sliding Windows Kermit, CP/M-80

Since KERMIT-protocol has been invented and is successfully used in data
transfer between "micro's" and larger machines, let me take a look at the
"windowing" proposal as seen from the "micro's".

As is probably known, none of our current 'Van Neuman' machines can handle
more than one task at any given instant of time.  The illusion of
'time-sharing' and 'multi-tasking' or even 'multi-processing' are only
possible with the existence of a sophisticated interrupt-structure
[typically combined with 'hardware assisted' context-switching] and software
delivering the book-keeping services.

The currently most 'popular' micro-systems [CP/M and MSDOS or derivatives]
are SINGLE-tasking systems.  Although the used micro-processors typically
support a basic interrupt-structure, the lack of buffered and hardware
assisted I/O devices limits the interrupt-structure basically to ERROR
intercepts and clock-service.  -- Or in laymans terms, "A typical micro
CANNOT accept characters on the Input-port, as long as its reading or
writing to the floppy".

How, might You ask, did MODEM or KERMIT survive this basic flaw at higher
communication speeds ??  -- Very easily with a "trick" in ACKing a received
packet ONLY AFTER it had been written to storage [ - thereby making sure,
that NOTHING {except NOISE} could arrive at the input-port - and therefore
nothing could be lost ].

In view of these "basics", I would like to treat a "Window of Packets" as
one Very Large Packet, which just happens to be sliced into smaller packets
for ease of error-recovery.  And the micro only has to make sure, that it
can store the combined DATA-content of the Window in a buffer.

Following Frank's concerns of portability, I would like to propose "fixed"
windows ["fixed" in their "agreed upon" starting packet-Nr and their size -
in contrast to "sliding windows" , where an ACK for the first packet in a
window of packets can slide the starting-point downwards].

In comparison to the "large packet" proposal this technique is probably of
more immediate interest to micro-users since:

    a. Most Communication media are NOT totally error-free

    b. Most micros are quite limited in sustaining any baud-rate above
       4800 Baud between Communication-Port and File-storage [ infact
       some have even problems to sustain above rates between Comm-Port
       and terminal].


Here the "changes" in detail:

1.  Extend current KERMIT-Heuristic that "A NAK for the current packet is an
implied ACK for the previous one" to "A NAK for the current packet is an
implied ACK for all previous packets inside the current window".

2.  Introduce a rule, that the next [ fixed ] window of packets can ONLY be
sent, AFTER receipt of the LAST packet of the previous window has been
ACKed.  [This will guarantee the needed "silence on the input-port" during
'buffer-write to file-storage' on the micro.]

3.  Change the proposed Error-Recovery rule to "On a receipt of a NAK the
SENDER will re-send packets starting with the NAKed one".  [This will remove
the need to keep a "transfer-table" AND make re-synchonisation possible for
the micro without hefty recoding].

I believe, that with above changes, we only encounter a minimal "extra
overhead" in case of error-retransmission - probably NO extra overhead
time-wise at all , if the MAIN-Kermit can be written to be effectively
"interrupted" by receipt of a NAK from the micro - if he only can check for
NAK's between sending of packets, we'll incur a slight degradation timewise
as compared to the current protocol - since the NAK probably will arrive in
the middle of a not fully sent packet, which has to be re-sent again
according to the above changed rules.

We will however enjoy even "faster" transmission in the more prevailing case
of having NO ERRORS, since the single ACKs for each packet collapse into a
single ACK per window - and we will enjoy the same savings [or better] on
packet-based channels.

Rgds,
Bernie.

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

Date: Sat, 27 Jul 85 18:18:41 pdt
From: hpl-opus![e-mail]
Subject: Proposal for Half Duplex Windows
Keywords: Sliding Windows Kermit, Long Packets

A quick proposal for half-duplex sliding windows:

    Kermit negotiates both packet size and super-packet size
    (i.e., N packets per super-packet, where
    N should be less than half the window size).
    The sender then sends <=N packets, then the end-of-line character
    to delimit end-of-super-packet (NO end-of-line chars inside
    the super packet - this is a must for half-duplex receivers).

    The receiver sends back a super packet of
    ACKs and NAKs.  This could use either the implied-ACK scheme
    discussed above, or an explicit ACK or NAK for each packet
    in the super-packet.  The implied-ACK scheme has the advantage
    that, on clean lines, the returning super-packet consists of just
    one ACK packet.

    The sender then sends the next super-packet, starting with the
    outstanding NAK'ed packets, and filled up (to N packets max) with
    new (first-time) packets.

    This kind of protocol can't obtain the efficiency of the
    full-duplex sliding window protocol, since it must incur
    an overhead of one round-trip delay per super-packet.
    This can, however, still gain a factor of 2 or 3 over the
    current situation with 1200 baud lines with 2 second round trip
    delays.  It's *essential* for improvement over poor half-duplex
    connections where the error rates preclude getting long
    packets to work at all.

    I think what I have outlined is close enough to the
    full-duplex sliding windows to allow them to coexist in the same
    code.  All the full-duplex version needs to do is:
    1) negotiate half-duplex status and super-packet size along
        with window size (maybe we can negotiate handshake at
        the same time?)
    2) bunch packets without end-of-lines to form a super-packet
    3) wait for the replying super-packet before sending the next.

    Another advantage to allowing this half-duplex option is that
    this opens up greater flexibility for the implementation of
    sliding window Kermits, since this protocol can be implemented
    without multiprocessing.  This might make it a good choice
    for non-multi-processing systems or systems which make that difficult.

Ken Poulton
hplabs!poulton

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

Date: Thu 1 Aug 85 12:44:55-EDT
From: Leslie Spira <[e-mail]>
Subject: Examination of Proposals
Keywords: Sliding Windows Kermit, Long Packets

Dear Frank,

    Hugh Matlock and I sat down last night and studied in detail the
discussion about the proposed extensions.

    It seemed to us once again that there is a fundamental difference
between full-duplex environments and half-duplex environments.

    Looking at it, it appears that the problems in half-duplex can best be
solved by a large packet size with smaller sub-units that can be NAKed and
retransmitted as necessary.

    The attempts to modify windowing all ended coming around to this
concept.  We looked at three things that indicated this:

    1. Ken Poulton's suggestion of a way to do "super-packet" half-duplex
    (message dated July 27).  This is a effectively a super-packet with
    segmentation.  Hugh agrees with Ken Poulton that the coding on this
    suggestion would parallel well with the full-duplex coding.

    2. Bernie Eiben's "rewritten" reply dated 27 July.  As he notes: "...
    I would like to treat a 'Window of Packets" as one Very Large Packet,
    which just happens to be sliced into smaller packets for ease of
    error-recovery."

    3. The original extended packet length proposal, which could be
    modified so that checksums are placed after every 94 characters.  If
    you look at that definition, MAXLX1 simply becomes the number of
    sub-units in this view.


    Note what happened as people looked at "windowing" in the half-duplex
environment:  the choice of terminology was confusing at first, but
gradually sorted itself out into the fact that true sliding windows only
works in a full-duplex environment, and the equivalent in half-duplex is a
long packet with sub-units for ease of error-recovery.  This suggests that
the extended packet length proposal can be modified to include sub-units.

    I believe there is something of a philosophical turning point in
KERMIT's development appearing.  The Sliding Windows proposal provides
"high-end" performance for those higher capability environments (operating
system and communications channel) that are truly able to be full-duplex.
This "high-end" situation generally reflects the capabilities of later
systems on the market, which deserve to have their power taken advantage
of.

    On the other hand, I think that a Super-Packet with segmentation
proposal could reflect Classic KERMIT's concern with being able to operate
in all environments.  This proposal would need to take more enviroments
into account.  In some ways it is harder to define, because it may require
more changes to the existing KERMIT definition since it is more dependent on
KERMIT and less dependent on the operating system environment for
performance gains.

    This philosophical difference is just a way of analyzing the fact that
the two proposals have somewhat different intents, both of which I think
are valid.

    With this in mind, I think it might be helpful to change the name of
our proposal to "Full-Duplex Windowing Extension", in order to make it's
intent clear.  This definition is more dependent on the operating
environment, but its changes to the KERMIT definition are limited, in
that windowing is only in effect during transfer of data packets, there
are no new packet types, and the ACK and NAK stay pretty much the same.

    The criticisms of our proposal have been with our underlying decision
to operate in a full-duplex environment, rather than with the internal
consistency of the proposal.

    I'm putting the following points forward in our favor:

    1.   We have a complete, usable definition.

    2.   We have a working implementation for the IBM PC, and it is based
         on CKERMIT.  We are about to finish the PRIME implementation.

    3.   We will be making the code available to Columbia, and will be
         actively distributing it to communications software producers.

    4.   We have put lots of hard work into this. (Does that count??)

    5.   We have some unfortunate, but real, deadlines.

    6.   The sliding window definition can starting making some very great
         improvements in transfer times over the public data networks,
         where there currently is no other good solution to the throghput
         problem.

    7.   We (at The Source) currently have a chance to build additional
         momentum for KERMIT.  In a lot of ways, this opportunity
         (or window?) is much better now than it will be later.

    We would like to have the definition approved this week.  In
addition, we would then like to continue to contribute to the definition of
"super-packets with segmentation".

    I also would like to apologize for not having more time to approve
this; it was not our intent.  This is not a casual proposal however; it
has been pretty carefully thought through (indeed, the refinement of the
definition delayed it).

                                       Sincerely,

                                       John Mulligan

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

Date: Thu 1 Aug 85 14:17:00-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Full Duplex Sliding Windows -- Let's Give Them a Try
To: OC.SOURCE@CU20B, OC.Jordan@CU20B, Info-Kermit@CU20B
Keywords: Long Packets, Sliding Windows Kermit

John, Hugh, Leslie, Larry... Your arguments are persuasive.  You've clearly
done a lot of work (in a project like Kermit, that's usually what counts
most!).  I'd like to state my misgivings for the record, and then go ahead
grant you permission to use Bit #4 in the CAPAS field to indicate Full Duplex
Sliding Window Capability, and the field immediately after the CAPAS field
(remembering that the CAPAS field can grow) to designate window size, as you
have proposed.

My biggest misgiving is that we (you, I, and the Info-Kermit community) have
not had sufficient time to consider the proposal, and I will always have
nagging doubts that there may have been ways to improve it that would have
made more people happy.  As proposed, this capability requires true full
duplex operation.  In order for any computer to support this style of i/o,
it must be capable of EITHER multiprocessing OR fully interrupt-driven i/o
(or both).  Multiprocessing is something most micros can't do; it requires
certain hardware features like memory protection.  On the other hand, almost
any operating system allows access to its interrupt structure by the
programmer.  Unfortunately, the mechanisms for getting at interrupts vary
considerably among machines, operating systems, and even operating system
versions.  So a Kermit program that manages to "steal" the system's
interrupt vector in order to work correctly under version x of the operating
system might suddenly stop working when the user installs version y...  To
make matters worse, information about interrupt programming tends to be hard
to come by -- it's missing from the manuals, it's proprietary, or whatever
-- so when this is true, it makes it tough for even the motivated programmer
to do the work.

It's unfortunate that you have such pressing deadlines, and that I will be
gone for a month.  It may well be that your proposal is exactly what is
needed to kick Kermit protocol into the big leagues, but it might have been
possible to refine it in such a way that continuous full duplex transmission
would be possible for those systems capable of it, while provision was made
for those systems (CP/M-80 springs to mind) that have to turn their backs
on the communication port from time to time in order to write to the disk.

As you suggest, systems like CP/M along with the systems that really have
half duplex communication channels might be accommodated by the long-packet
extension, especially if modified to allow segmented long packets (this
reminds me of SMTP vs BSMTP...).  But it would be a lot cleaner if a single
Kermit extension could take care of everyone.

A final misgiving is that allocation of a CAPAS bit and Send-Init field is
irrevocable.  Once Kermit programs are out in the world that use them, they
can never be used for anything else.  Therefore, I'd like to emphasize that
the full duplex sliding window feature specified in Info-Kermit V3 #7 should
still be considered EXPERIMENTAL.  The group at The SOURCE will be tuning it
as they work on their new implementations, and I'm sure that some of the
comments and suggestions from Info-Kermit will be in the back of their
minds.  I expect that all this activity will settle down in a month or two,
and a "final" copy of the sliding window specification will be available
then.  Until then, no one should attempt to work from the current
specification without first contacting the people at The SOURCE (mail to
OC.SOURCE@CU20B).  Since the CAPAS bit and the window size field will be
allocated to their windowing method, it is essential that the protocol
invoked by them is clearly, completely, and unambiguously specified before
any programs using them are distributed to the public.

- Frank

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

End of Info-Kermit Digest
*************************
-------
 2-Aug-85 17:40:38-EDT,9111;000000000000
Mail-From: SY.FDC created at  2-Aug-85 17:40:04
Date: Fri 2 Aug 85 17:40:04-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #12
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri,  2 Aug 1985       Volume 3 : Number 12

Departments:

  ANNOUNCEMENTS -
        C-Kermit 4C(057) Hurriedly Replaced

  PROPOSALS -
        Attribute Packets, Windows
        A Vote FOR Long Packets
        Sliding Windows vs. Long Packets vs. Segmentation

  MISCELLANY -
        VMS Kermit and VMS V4
        Problem with Stevens' Kermit for Apple //
        Bugs in Version 2.28 of MS-DOS Kermit

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

Date: Wed 31 Jul 85 18:07:00-EDT
From: Frank da Cruz <[e-mail]>
Subject: C-Kermit 4C(057) Hurriedly Replaced
To: [e-mail]
Keywords: C-Kermit

One of the edits in 4C(057) apparently broke C-Kermit on 68000's and
possibly other non-VAX, non-PDP-11 machines -- the old int/char pitfall.
Anyone who ftp'd C-Kermit from CU20B between 8:00pm-EDT July 29 and
6:00pm-EDT July 31 should pick up a new copy of K2:CKCFNS.C.  Too bad I
didn't have a 68000 to test this on -- apologies, and thanks to Philip Jeuck
<[e-mail]> for pointing out the problem.  You'll know if you have
the bad version if it announces itself with the date 29 Jul 85; the
(hopefully) fixed one is dated 31 Jul 85.

Also, there was a minor error in conditional compilation for 4.1BSD which
should also be fixed (K2:CKUTIO.C) and there was a minor change to the
makefile (K2:CKUKER.MAK), and a minor problem with subshell invocation
on systems with ints and pointers of different sizes (K2:CKUUSR.C).

This should REALLY be the last release of this program for at least a
month, so those who have not been getting new versions because they keep
changing so often should pick up this one.

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

Date: Fri 2 Aug 85 15:14:57-EDT
From: Frank da Cruz <[e-mail]>
Subject: Attribute Packets, Windows
To: [e-mail], [e-mail]
cc: Info-Kermit
Keywords: Sliding Windows Kermit, Attribute Packets

I was just looking at the protocol manual and realized that the current edition
does not contain something which might be useful to you, namely two new
attribute fields:  "1" specifies the exact byte count of the file, and "2"
specifies the byte size (e.g. "7" or "8").  This will be in the next edition.
Many people have asked for a somewhat finer-grained way to report the file
size than the number of K (e.g. some systems need to preallocate space, but in
some unit other than K).  - Frank

P.S. Bye till September.

P.P.S. I was waiting for a message to this effect from someone who called,
but it hasn't arrived, and I'm leaving now, so here it is in a nutshell:

If you have tested your sliding window algorithm with a slow (1200b or less)
line and a fast (hard or RAM) disk and it works as expected, please verify
that it ALSO works with a FAST (9600b or more) line and a SLOW (floppy) disk
before finalizing the protocol and releasing any programs that implement it
to the public.

P.P.P.S. To everyone -- please keep sending comments on the new proposals to
Info-Kermit@CU20B, even while I'm gone -- they'll appear in the digest on
a weekly basis, approximately.

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

Date: Thu, 1 Aug 85 14:04:13 pdt
From: hpl-opus![e-mail]
Subject: A Vote FOR Long Packets
Keywords: Long Packets, Sliding Windows Kermit

I'd like to cast a vote FOR the long-packet proposal.

It seems to me to be a simple enough extension that it can be implemented
and debugged quite quickly, without massive program changes.  There are a
number of situations where it will definately help; I have one user of
ST-Kermit who has already "rolled his own" long packets, and another
champing at the bit.

I see long packets as complementary to (and even compatible with) sliding
windows; there is no reason to have to choose only one.

If someone would specify the extra bits and bytes in the send-init packet
(very clever to have left those out of the proposal), we could get some
implementations going soon.  (Anyone want to volunteer for C-Kermit?)

Ken Poulton
hplabs!poulton

[Ed. - Let's leave the proposal open for discussion, but if you want to play
with an experimental implementation, let's say that the long packets bit is
bit #5 and the length fields are the 2nd and 3rd bytes after the CAPAS
field.]

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

Date: Fri, 2 Aug 85 09:42:58 cdt
From: [e-mail] (Jim Knutson)
Subject: Sliding Windows vs. Long Packets vs. Segmentation
Keywords: Sliding Windows Kermit, Long Packets

Something that hasn't been addressed in this, is the protocol negotiation.
In the past, both sides have not needed to negotiate because it was not
necessary.  Each side always transmitted what the other wanted.  If there
was disagreement over an option, the lowest common denominator was used.
Now we have several transmission schemes.  There is the normal packets
transmission with packet lengths up to 96 characters, extended packet
lengths, extended packet lengths with segmentation and sliding windows with
all the above options.  How will the correct scheme to use be decided
between the two Kermits.  Will a disagreement always bring you back to 96
character packets?  For example, if a user selects sliding windows on a
kermit that can have either sliding windows and/or extended packets and the
remote kermit can only do extended packets, will they both revert to 96
character packets?  Will extended packets be used?  What if both could have
done extended packets with segmentation but not sliding windows?  Are we
going to have a build in a priority CAPAS to prioritize the decision between
transfer schemes?

Jim Knutson

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

Date: Thu, 1 Aug 85 14:04:13
From: LCG.KERMIT
Subject: VMS Kermit and VMS V4
Keywords: VMS Kermit

Some of the folks at RCA have been using the new VMS Kermit on VMS V4.x and
noticed odd echoing which was traced to differences in the V4 terminal
driver's echo from V3. Characters like control-O were getting screwed up and
leaving local terminals in graphics mode, as a symptom.

It turned out there was a workaround. The procedure to use is as follows:

        Set line <whatever>
        local host set term <whatever> /PASTHRU
        connect

The result is that things then work OK. VMS V4 users may want to take note.
Charles Garman reported this to me.

        Glenn Everhart

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

Date:     Wed, 31 Jul 85 20:26:19 PDT
From:     [e-mail]
Subject:  Problem with Steven's Kermit for Apple //
Keywords: Apple II DOS Kermit

When sending a file (specifically, a text file in 7 bit mode) from either an
Apple ][+ or //e, to a Vax/Vms machine running V4 [with the V4 version of
Kermit], the Apple kermit gets a "WRITE PROTECTED" error AFTER the transfer
of the file (and the Vax deletes the file if the appropriate option is left
as the default) if the disk is write-protected.

It seems silly that write-protecting a disk should prevent the proper
reading of a file. Anyone have a fix for this before I delve into the file
manager?

                                                -Ken
Adelman, Caltech
                                                 [e-mail]
                                                 [e-mail]

[Ed. - Anybody out there who can help?]

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

Date: 2 Aug 1985 0653-PST
From: Pawka <PAWKA@NOSC-TECR>
Subject: Bugs in Version 2.28 of MS-DOS Kermit
To: [e-mail]
Keywords: MS-DOS Kermit

I found a couple of minor bugs in the Z-100 version of MS-Kermit,
Version 2.28, here are the fixes:

1) The STATUS command causes the program to wander off into never-
   never land, module MSSET.ASM had 2 instuctions missing, in routine
   BAUDPRT a push and a pop of di were missing:

        Was:
                BAUDPRT   PROC   NEAR
                call getbaud        ; read baud rate first

        Should be:
                BAUDPRT   PROC   NEAR
                push di             ; preserve this
                call getbaud        ; read baud rate first
                pop di

 2) The delete, backspace or Ctrl/H keys were not erasing characters
    in the command line. The routine that gets characters from the
    keyboard now, for some reason, puts out a space when it reads one
    of these characters. I fixed this by changing a string in
    MSXZ100.ASM:

        Was:
                delstr  db  BS,' ',BS,'$'

        Now:
                delstr  db  BS,BS,' ',BS,'$'

I hope this doesn't foul up something else, it seems o.k. for the stuff I do.

                                Mike Pawka
                                [e-mail]

[Ed. - Provided only for information to H/Z-100 folks; we'll check it out and
include in the forthcoming release if ok.]

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

End of Info-Kermit Digest
*************************
-------
 9-Aug-85 13:37:30-EDT,16925;000000000001
Date: Fri 9 Aug 85 13:34:34-EDT
From: The Mailer Daemon <[e-mail]>
To: [e-mail]
Subject: Message of 9-Aug-85 13:21:37

Message failed for the following:
*<KERMIT>[e-mail]: No such mailbox
        ------------
Date: Fri 9 Aug 85 13:21:37-EDT
From: Jeff Damens <[e-mail]>
Subject: Info-Kermit Digest V3 #13
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-to: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri, 09 Aug 1985       Volume 3 : Number 13

Departments:

  ANNOUNCEMENTS -
    Kermit directories/files have moved

  KERMIT ENHANCEMENTS DISCUSSION -
    Sliding windows on micros should work
    ANY-duplex Windows
    Half-duplex windowing and large packets

  UNIX KERMIT -
    CKermit Statistics

  MS-DOS KERMIT -
    Warning: Unrecognized Baud Rate

  MISCELLANY -
    How do you edit pc-ix sources?
    RT-11/TSX+ Kermit
    Wanted: Kermit for the Burroughs B-20s,B-25s,B-26s running BTOS.


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


Date: Sat 3 Aug 85 09:02:08-PDT
From: Douglas Edwards <[e-mail]>
Subject: "Warning: Unrecognized Baud Rate"
Keywords: MS-DOS Kermit

I use MS-DOS Kermit for the IBM PC (actually I have a Compaq, but they
seem interchangeable).  I have one minor problem.  When I start up
Kermit I always get the message "?Warning: Unrecognized Baud Rate"
even though my init file clearly specifies 1200 bps.  (It works
fine--the message seems to have no significance, it's just annoying.)
What causes this?

    Douglas Edwards
    (edwards@su-csli)

[Ed. - When it starts up, MS-DOS Kermit looks at the baud rate the
  serial port is set to and tries to identify it (so that the status
  command will print the correct value if the baud rate isn't
  explicitly set).  If it can't figure out the baud rate, the message
  is printed.  This has nothing to do with what's in your init file -
  it is printed even before the init file is read.  The message won't
  affect anything else; it should probably be removed. ]

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

Date: Sun, 4 Aug 85 15:08:17 pdt
From: "Corwin Nichols; Community Data Processing; 415-322-9069" <cdp!corwin@Glacier>
Subject:  sliding windows on micros should work
Keywords: Sliding Windows Kermit

In a July 27 note, B.Eiben writes:

>As is probably known, none of our current 'Van Neuman' machines can handle
>more than one task at any given instant of time.  The illusion of
>'time-sharing' and 'multi-tasking' or even 'multi-processing' are only
>possible with the existence of a sophisticated interrupt-structure
>[typically combined with 'hardware assisted' context-switching] and software
>delivering the book-keeping services.

>The currently most 'popular' micro-systems [CP/M and MSDOS or derivatives]
>are SINGLE-tasking systems.  Although the used micro-processors typically
>support a basic interrupt-structure, the lack of buffered and hardware
>assisted I/O devices limits the interrupt-structure basically to ERROR
>intercepts and clock-service.  -- Or in laymans terms, "A typical micro
>CANNOT accept characters on the Input-port, as long as its reading or
>writing to the floppy".

It is true that the current crop of popular micros run MSDOS, CP/M, or
AppleDos, and that these are singletasking operating systems.  However
it is NOT necessary to have a "sophisticated interrupt-structure" or
fancy hardware in order to process a single stream of incoming characters
while performing other tasks such as monitoring the incoming stream,
calculating checksums, transmitting ACKs, etc.  All that is required is
a simple interrupt routine which captures the incoming stream in a buffer,
and which is enabled throughout disk i/o operations.

All machines which claim to be close to IBM PC compatibility meet this
simple criteria.  Many CP/M machines also meet these requirements, ei
Radio Shack models 2, 4, 12, and 16; all Compupros, Altos's, Cromemcos and
any other machine which uses a dma chip for disk i/o and has a serial
chip that is on an interrupt line.

Since most of the CP/M and MSDOS implementations are already machine dependent,
I don't foresee any major problems implementing the sliding window code
on most of the popular micros.

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

Date: Fri, 2 Aug 85 20:18:22 pdt
From: hpl-opus![e-mail]
    hplabs![e-mail], hplabs![e-mail]
Subject: ANY-duplex Windows
Keywords: Sliding Windows Kermit, Long Packets

I agree with Leslie et al, that they have a viable, apparently
well thought-out proposal for full-duplex sliding windows.

Where we differ is in whether half-duplex windows
belong to Sliding Windows or to Long Packets.  They argue that
the various half-duplex proposals all filter down to long,
segmented packets.  At the link level (what passes down the
wires, and how to synchronize it) this is true.

But NOT AT THE PACKET LEVEL, where most of the programming
is involved.  The major part of the implementation of full-duplex
windows is in the handling of a window of "active" packets
(except when the opsys doesn't support multi-processing).
At the packet level, the handling of half-duplex windows is
nearly the same, as Leslie agrees:

    1. Ken Poulton's suggestion of a way to do "super-packet" half-duplex
    (message dated July 27).  This is a effectively a super-packet with
    segmentation.  ********************************************
    ************* Hugh agrees with Ken Poulton that the coding on this
    suggestion would parallel well with the full-duplex coding.
    ***********************************************************


PROPOSAL: Have the full-duplex windows allow for half-duplex
operation.  All implementations with full-duplex
windows should be able to run in half-duplex mode also, so that
we don't end up with two (probably incompatible) versions of
windows/long-packets running around.

I don't think this requires adding much to a full-duplex window scheme.
To repeat from my earlier proposal:

     All the full-duplex version needs to do is:
    1) negotiate half-duplex status and super-packet size along
        with window size
    2) bunch outgoing packets together (without end-of-lines)
        to form a super-packet
    3) wait for the replying super-packet before sending the next.

My immediate concern is with point (1): unless this negotiation
is added to the full-duplex windows NOW, it never will.
But once that part is defined, the implementation is easy.

In fact, it might be a positive benefit for future full-duplex
implementations: one could bring up half-duplex windows
first to debug the window algorithm and worry about the low-level
interrupt/process handling stuff later.  (Half-duplex windows
have got to be easier to debug than full-duplex...)

Adding a half-duplex option to sliding windows also makes them
more portable: half-duplex windows might still work across
operating system revs or different hardware (e.g., PC-almost-clones)
when a full-duplex implementation (that munged the interrupt
vector, or whatever) broke.

To argue by the numbers:

    1) half-duplex windows are a SIMPLE extension of
    the proposed full-duplex window proposal

    2) half-duplex windows ADD portability and robustness,
    even for full-duplex machines

    3) The only critical need *right now* is to *define* the
    bits and bytes for negotiating half-duplex windows
    and add that part of the negotiation to the
    full-duplex window specification.  In the interests of
    allowing Leslie, et al to move along, implementation
    can wait.

If full-duplex windows go ahead without a half-duplex provision,
it seems likely that we will eventually agree to a separate segmented
long packet proposal, which may go the way of File Attribute Packets.
(Almost no one has implemented these because there is almost no
one else to exchange them with.)  Momentum is key here!


Leslie & co have made a large contribution here, and I thank
them for that.  I agree that this window proposal is indeed a
critical moment for Kermit.  We *all* benefit by making it
useful to more machines.

After all, isn't that what Kermit is all about?

Ken Poulton
hplabs!poulton

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

Date: Wed 7 Aug 85 03:20:06-EDT
From: Ken Rossman <[e-mail]>
Subject: Kermit directories/files have moved
Keywords: Kermit DIR

Due to space shortages on our PS structure, all Kermit directories and
files have been moved to the PX/PB structure.  All system-wide logical
names have been correspondingly redirected, so if you use the system-wide
logicals for all file references, you should not notice any difference.

Mail questions and/or problems to info-kermit@CU20B.

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

Date: 7 Aug 85 18:11:49 EDT
From: BL02@CMU-CC-TC
Subject: how do you edit pc-ix sources?
Keywords: Editor

Help!
    I have a pc-xt running pc-ix.  I can't live with INed (the editor)
anymore.  Since ckermit is a rather large program, and it has been
made to run under pc-ix, I gather someone out there has a nice editor
that runs under same.  Can someone give me a pointer to where I can
get one?  I really am looking for an emacs clone (thief, fine, jove, etc.)
or even real emacs, etc., etc., etc.  I do have some sources to thief
and jove, but not for pc-ix, and I just don't have the time right now
to fix them up.

Can anyone help me??  or am I just stuck with INed?  Thanks SO MUCH for
any replies or comments.

        Bryan Lally
        bl02@cmcctc
------------------------------

Date: Tue, 6 Aug 85 11:59:46 PDT
From: [e-mail]
    [e-mail]
Subject: Half-duplex windowing and large packets
Keywords: Long Packets, Sliding Windows Kermit

I'd like to make a proposal which essentially adds some details
to Ken Poulton's proposal for half-duplex sliding windows with
super-packets (Info-Kermit #11).  Extend the protocol to
negotiate both the maximum window size and the super-packet size,
using the byte following the window size for the super-packet
size.  Now, if the super-packet size is 0 or 1 (treat 0 as
equivalent to 1), then we have full-duplex windowing as in the
Source's proposal.  If the super-packet size is the same as the
window size, then we have half-duplex windowing.  If somewhere in
between, then we have full-duplex windowing using super-packets.
Note that if window size is super-packet size times 2, then
although we strictly have full-duplex windowing, we can consider
it to be half-duplex with type-ahead.  I believe that will work
on a few half-duplex systems.  It will certainly work on my MTS
system.  In this proposal the window size in terms of number of
super-packets outstanding at once is (window size)/(super-packet
size).

Keep the rule in the original windowing proposal that explicit
ACKs and NAKs are required for each packet.  Note that implicit
ACKing must be disabled if the environment is full-duplex,
because you really don't know if the missing packet is an ACK or
a NAK (you could change it to implicit NAKing).  The other rule
that differs between half- and full-duplex environments is that
in a half-duplex environment one should do something with a
packet with a bad checksum - sender treats it as a NAK and
receiver sends a NAK.  That prevents having to wait for a timeout
every time a packet gets mangled.  As the windowing proposal
correctly states, in a full-duplex envorinment one must simply
ignore packets with a bad checksum.  That is because one cannot
guess the correct packet number as one can in the half-duplex
environment.

I'd also like to propose one more extension to save money on
public data networks.  Many of those networks charge by the
packet and packet sizes are typically up to 128 or 256 bytes.
I'd like to extend the packet length field to 2 bytes when the
first length byte (decoded) is 1 or 2.  That will allow packet
sizes from the current minimum up to 284 with no loss of
efficiency on short packets.  It will allow a super-packet of
26696 (284*94) bytes which seems more than long enough.  Two more
bytes are needed in the Init packet to negotiate the maximum
packet size just as in the original long packet proposal.

Note that I haven't used packet size 0 so this doesn't conflict
with the large packet proposal.  However, I'd like to see this
proposal supercede that one because it is superior in several
respects.  It allows ACKing and NAKing parts of large packets and
it fits in with the windowing proposal.

Now, this idea complicates the negotiation process a bit, because
if one side wants to be half-duplex and the other side doesn't
care, the negotiation must be sure to end up in a half-duplex
state.  I believe the following rules will work: 1.  Use the
minimum value of window size (or smaller, see 3).  2.  Be
half-duplex (super-packet size equal to window size) if either
side requests that.  3.  Make super-packet size divide (no
remainder) window size and make super- packet size be such that
the resulting quotient is the minimum of the two quotients
requested, by adjusting the window size downward if necessary.

The biggest drawback to this proposal is that it doesn't allow
very large packets when one really wants a window size of 31
(since in that case one cannot use super-packets).  Nonetheless,
the 284 byte maximum packet size in that case seems sufficient.

I'm a bit out of touch for the next week and have been for a few
days so this proposal may not take into account everything it
should and I won't be able to respond until next week.

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

Date: Mon, 5 Aug 85 14:19:56 pdt
From: seismo!decvax!ucbvax!ucdavis!deneb![e-mail] (Michael Shulman)
Subject: RT-11/TSX+ Kermit
Keywords: RT-11 Kermit

We understand that there is a version of Kermit available
for the TSX+ system.  It is far easier for us to obtain a
copy of this system on 8" disk than it would be to bootstrap
it ourselves.  Are there any sites that have such a system
running and would be willing to make us a copy on 8" disk?

Thank you,

Michael Shulman
Computer Center
UCDavis ... ucbvax!ucdavis!deneb!ccrms


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

Date: Thu, 8 Aug 85 03:29:24 pdt
From: Neal Holtz <[e-mail]>
Subject: CKermit Statistics
Keywords: C-Kermit

A statistic regarding performance of C-Kermit:

       source:  Vax 11/750 4.2 BSD
       dest:    Apollo DN320, Aegis SR8
       line:    9600 baud
       type:    text
       # files: 53
       # chars: 684206
       time:    29 min. (+/- 1 min.)
       effective rate:  393 chars/sec

Notes:
1) Apollo versions:
    C-Kermit 4.2(030) PRERELEASE # 2, 5 March 85
    C-Kermit Protocol Module 4.2(015), 5 Mar 85
    C-Kermit functions, 4.2(026) 5 Mar 85
    Unix cmd package V1.0(015) 27 Feb 85
    User Interface V4.2(038), 5 Mar 85
    Apollo Aegis tty I/O, 4C(023), 20 May 85 for Apollo Aegis SR8
    Aegis file support, 4C(024) 20 May 85 for Apollo Aegis SR8
    Connect Command for Unix, V4.2(006) 5 March 85
2) Vax versions:
    C-Kermit 4.2(030) PRERELEASE # 2, 5 March 85
    C-Kermit Protocol Module 4.2(015), 5 Mar 85
    C-Kermit functions, 4.2(026) 5 Mar 85
    Unix cmd package V1.0(015) 27 Feb 85
    User Interface V4.2(038), 5 Mar 85
    Unix tty I/O, 4.2(016), 5 Mar 85 for 4.2 BSD
    Unix file support, 4.1(015) 28 Feb 85 for 4.x BSD
    Connect Command for Unix, V4.2(006) 5 March 85
3) All compiler optimizing turned off on Apollo
4) Used about 25% of CPU on Vax
5) Used about 70% of CPU on Apollo

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

Date:     Fri, 9 Aug 85 9:46:06 EDT
From:     David Roth (Ft. Benj. Harrison) <[e-mail]>
Subject:  Wanted: Kermit for the Burroughs B-20s,B-25s,B-26s running BTOS.
Keywords: Burroughs B2x, BTOS

This Sept.15 we are expecting shipment to arrive of dozens of Burroughs B-20s,
B-25s & B-26s. The operating system they run is called BTOS. We are in need
of a version of KERMIT for these systems. Anyone have a version or enough
experience in using BTOS to suggest what existing version of KERMIT we
should start with.
The Army refers to these systems as: TACCS.
Thanks in advance.
                                David A. Roth
                                droth@brl-bmd
                        US Mail:
                                COMMANDER
                                USA Soldier Support Center
                                ATSG-DTU-S
                                Attn: Mr. David A. Roth
                                Fort Benjamin Harrison, IN
                                                46216-5590
                        AUTOVON:699-4298
                        FTS:335-4298
                        COMMERCIAL:[phone]
------------------------------

End of Info-Kermit Digest
*************************
-------
-------
30-Aug-85 18:31:41-EDT,21691;000000000001
Mail-From: US.JD created at 30-Aug-85 18:31:00
Date: Fri 30 Aug 85 18:31:00-EDT
From: Jeff Damens <[e-mail]>
Subject: Info-Kermit Digest V3 #14
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri, 30 Aug 1985       Volume 3 : Number 14

Departments:

  UNIX KERMIT -
    Bug (?) in C-Kermit 4C


  MS-DOS KERMIT -
    Concurrent DOS KERMIT


  CMS/TSO KERMIT -
    CMS Kermit Improvements?
    KERMIT-TSO and 7171 (2 messages)
    CMS KERMIT and Yale 2.0 (2 messages)


  MISCELLANY -
    More on sliding windows
    Kermit for the PRO
    Getting K11 on floppies
    6809 Kermit
    BTOS Kermit
    Kermit for TI 99/4A
    CompuPro KERMIT version wanted to work with Hayes Micromodem.
    CROSS and other queries
    Prime Kermit
    Plea for help
    Kermit/milnet
    Kermit over TELENET: Help Needed
    Kermit for Fortune 32:16
    Kermit on VMS


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

Date: 9 Aug 1985 1612-EDT
From: B.Eiben LCG Ext 617-467-4431 <EIBEN at DEC-MARLBORO.ARPA>
Subject: More "sliding WINDOWS"
Keywords: Sliding Windows Kermit, Long Packets

The gist for micro's lays NOT in the fact, that they have [or haven't] an
interrupt-structure [infact having none is cleaner then having "something"].

The PROBLEM typically is the "floppy-controler" i.e FD17xx , which delivers
data "fast" enough , so that one has to TURN OFF interrupts during READ/WRITE
but SLOW enough to lead easily to character-loss during floppy-processing.

The typical coding sequence [very innocent] looks like
    DI
    Call Write/Read Sector
    EI
... that alone makes "sliding WINDOWS" impossible - since one eventually HAS
to write the stuff to the disk - and there's NO TRICK to stop the SENDER from
sending - except for "holding back ACKs" - and that takes away most of the
advertised speed-improvements.

Obviously the "sector-time" window is dependant on the media-speed [floppies
will be LOOSERs compared to winnies] and the amount of 'character lossage'
depends on the channel-speed [ at 1200 baud one might loose NOTHING , since
the window is about one char-time, and thats hanging around in the USART ...
at higher speeds it'll be one or more lost char's - i.e. a full NAK/resend
packet cycle ] - so as seen from the "innocent bystander" we now have
introduced a feature , which might "work for me" but "not for You" - i.e.
the same MICRO connected to the same Mainframe will "win" or "fail" depending
on storage medium and/or channel-speed == in my mind NOT A GOOD IDEA .

Rgds,
Bernie.
------------------------------

Date: Wed 7 Aug 85 17:58:06-PDT
From: Wing Lee <WingLee%ECLD@ECLA>
Subject: KERMIT-TSO and 7171
Keywords: TSO Kermit, 7171 Protocol Converters

I hate to keep on bugging you about KERMIT-TSO and the 7171, but
my boss keeps on asking me if there is any news.

This is our situation.  We installed the Series/1 version of KERMIT-TSO
on our 3081, in March of 1985.  Everything worked fine, and everybody
was happy.  In May, we replaced our Series/1 with an IBM 7171, so
that we could have more lines going into TSO.  That's when our
problems started.  Going through the 7171, we were able to
download but not upload.  When we tried to upload, the file transfer would
hang at random places.  When I used DEBUG mode to look at the packets,
I saw that the tranfer would always stop right after a file transfer.
As soon as I discovered this, I sent a message to Columbia asking for
help.

In the meantime, we have put together a makeshift way to get KERMIT-TSO
to work.  On our 3081, we run both MVS/TSO and VM/CMS.  Our ascii interface
to TSO is an IBM 7171, our ascii interface to CMS is a SERIES/1.  We
have been able to have users who wish to do file transfer to TSO, to
use the CMS Series/1.  Then they would DIAL MVSA and connect to
our MVS system.

That works. But now our Systems people are thinking of replacing the CMS
Series/1 with another 7171.  When we told them that this would disable
are ability to use KERMIT altogether, they said that our TSO KERMIT is
not supported by Columbia, and we should not be using TSO Kermit on our
TSO system until Columbia has a supported version.  Thus we should not
even have the package on our system.

My question is, does Columbia support the Series/1 version of KERMIT-TSO?

[Ed. - No.  We don't run TSO.]

wing
------------------------------

Date: Wed 7 Aug 85 19:10:07-PDT
From: Wing Lee <WingLee%ECLD@ECLA>
Subject: kermit-tso and 7171
Keywords: TSO Kermit, 7171 Protocol Converters

in my last message i said, that when uploading, the transfer stops
right after a file transfer.  i meant that the transfer stops right after
a bad packet.  i should have reread my message more carefully before
i sent it out.

wing

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

From: Gary Mills <[e-mail]>
Subject: 6809 Kermit
Keywords: 6809 Kermit

Does anyone have a version of Kermit for the 6809 CPU, with Flex-9 or OS/9
operating systems?  C or assembler languages would be suitable.


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

Date:     Sat, 10 Aug 85 13:04 EST
From:     Larry Afrin <[e-mail]>
Subject:  Bug (?) in C-Kermit 4C
Keywords: C-Kermit

Hi,

    I just got the latest version of 4C a few days ago (the one
the Digest swore would be the "absolute last" release of 4C).  I compiled
it for a System V system, and the problem I noticed occurred when I
was "get"ting some stuff from SIMTEL20.  The files on SIMTEL that I was
transferring had names like ABCDEF. and GHIJKLMN.  (the point here being
that they're all upper-case, as you would expect from a TOPS-20 system).
I wanted to transfer them to my UNIX system and give them the same,
upper-case filenames, just without the dot.  I knew that if I told my
local Kermit "get ABCDEF." or "get ABCDEF", it was going to do some
funky translation of the name (for what reasons, I don't know; I just
remember seeing somewhere that Kermit adjusts filenames for the
"conventions" of your system, which in UNIX usually means all lower-case),
which isn't what I wanted.  So I figured I would just type in "get" and
let it prompt me for the remote filespec and the local filespec.  For
the remote filespec I entered "ABCDEF.", and for the local filespec I
entered "ABCDEF".  The transfer then started up ... "IRSF" and wham! my
local Kermit told me "ABCDEF. => abcdef", which wasn't what I wanted.

    My whole point here is, if Kermit goes to the trouble of asking
you exactly what you want your local filespec to be, shouldn't it
refrain from translating that name (in this case from uppercase to
lowercase)?  In fact, why can't the "get" command be set up so that
(1) if you don't give a command line filespec and it goes ahead and prompts
you, it shouldn't translate either the remote or local filespecs; and (2)
if you do give a command line filespec, it should be interpreted as the
*exact* filespec for the local system, but it should be "appropriately"
translated to make the remote Kermit happy.

    I'm not 100% sure that (2) is "right", but I do feel that (1) is
right.

    Oh, yeah, one more thing:  Also during this transfer operation with
SIMTEL20, I tried this command: "get *.c".  Assuming my SIMTEL filenames
matching this spec were ABC.C, DEF.C, GHI.C, and JKL.C, this is what my
local Kermit reported to me during the transfer:

        ABC.C => *.c
        DEF.C => def.c
        GHI.C => ghi.c
        JKL.C => jkl.c

and yes, sure enough, my local Kermit really did create a filename called
"*.c".  Now, is this a bug, or did I just specify my "get" command
incorrectly?

    Thanks for any info, advice, etc., you can provide.

                    -- Larry Afrin
                       Dept. of Computer Science
                       Clemson University

Please send replies, if any, to:
lbafrin@clemson                         if you're on CSNet
lbafrin.clemson@csnet-Relay             if you're on ARPANet

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

Date: Mon 12 Aug 85 09:15:36-EDT
From: Bill Catchings <[e-mail]>
Subject: BTOS Kermit
Keywords: Burroughs B2x Kermit, BTOS

The best version of Kermit to work with for the Burroughs BTOS is probably
C Kermit.  I do not know for a fact that Burroughs supplies C for BTOS, but
Convergent Technologies (the maker of the B-20 series) supplies a C for CTOS
(The "parent" of BTOS).  My knowledge of BTOS is limited, but I believe that
CTOS and BTOS are pretty close.  The C for CTOS is pretty poor, based on
Mark Williams C, and the terminal/file transfer product that CT supplies is
terrible.  After 40 screens it starts over at the first screen.  Very annoying.
I plan to be working on a CTOS version of C Kermit in the next few weeks.  If
I succeed in getting one working it will be announced on Info-Kermit.  If not
you'll have to try yourself.

                    -Bill Catchings

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


Date: Tue, 06 Aug 85 19:58:34 EDT
From: Peter DiCamillo  <[e-mail]>
Subject: CMS Kermit Improvements?

The latest version of CMS Kermit includes features which make it very
attractive to users at Brown. These include support for Series/1
connections, binary data transfer, and server mode. As a result,
the Computer Center plans to recommend Kermit as the standard file
transfer program between CMS and  IBM PCs, Macintoshes, and other micros.
In evaluating CMS Kermit, we noticed that, as documented, server mode
only supports GET, SEND, FINISH, and BYE. This is very obvious to
the Macintosh user who has a menu of server commands, most of which
are not supported by CMS Kermit. Also, it would be useful to us if
CMS Kermit could preserve the date and time of files whenever possible.
Is any work planned or in progress to add these features? If not, I
may attempt to add them myself.

[Ed. - Kermit allows you to create the file on the destination
       computer with the same write date and time as on the source
       computer.  This requires however supporting attribute packet.
       At this time, CMS Kermit does not support attribute packets
       although it may do so in the future.  If you'd like to add the
       support, let us know so there won't be a duplication of effort
       on the part of some other ambitious soul. ]


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

Date: 14 Aug 1985 23:45-EST
From: Sanjay Kapur <[e-mail]>
Subject: kermit for the pro
Keywords: DEC PRO300 Kermit

Is there a version of kermit available for the DEC PRO350 running
the Professional Operating System? Where can I get a copy of it?


[Ed. - yes.  It's the k11 version, available on the distribution tape
       or in numerous other ways (see following message).]

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

Date: 10 AUG 85 12:04-EST
From:  [e-mail]
Subject: GETTING K11 ON FLOPPIES
Keywords: Kermit-11

In Response to Kermit Digest re RX0x dist.


Getting K11 on various media

K11AAA.AAA     Updated 14-JUN-1985 09:22  Brian Nelson


Kermit-11 Edit history:  K11CMD.MAC
Kermit-11 Installation:  K11INS.DOC
Kermit-11 Documentation: K11HLP.HLP  (no separate user manual)
Kermit-11 Files:         K11FIL.DOC



Please note that while Kermit-11 uses RMS11 for all versions (RT11 excluded)
you do not need RMS on your system unless you opt to use the versions linked
to RMSRES (K11.TSK for RSTS/E and K11POS.TSK for M/M+ and P/OS).
For further information, please read K11INS.DOC



To get Kermit-11 and all the other Kermits:

  KERMIT Distribution
  Columbia University Center for Computing Activities
  7th Floor, Watson Laboratory
  612 West 115th Street
  New York, N.Y.  10025


There is also a fairly current copy of Kermit-11 available  from  DECUS,
order  number  11-731.  As  of June 1985 the DECUS library has Kermit-11
available on RX01's and RX50's (in RT and  P/OS  format).  Additionally,
the SIG tapes almost always have a current version on them.


To get Kermit-11 from the author:


Mail:

800bpi          DOS-11 format
1600 bpi tape   DOS-11, ANSI or VMS Backup
RX01            RT format, binaries only
RX50            RT or P/OS (readable on Micro/RSX), delays are possible
                since I have only one PRO/350 and one hard disk.

For tapes,  VMS Backup format is preferred (default if not specified).
For RSTS/E, V9 Backup format is preferred. V9 backup is NOT compatible
with previous releases of RSTS/E, but IS compatible with VMS backup.

You must supply the media (extras are nice to offset the cost).


Brian Nelson
Computer Services
University of Toledo
2801 West Bancroft
Toledo, Oh 43606
[phone]   or   [e-mail]


Bitnet:

from VM/CMS:    CP SMSG RSCS MSG UOFT02 KERMSRV DIR
                CP SMSG RSCS MSG UOFT02 KERMSRV SEND K11*.*

from VMS Jnet:  $ SEN/REM UOFT02 KERMSRV SEND K11*.*


 Columbia University maintains a BITNET Kermit server also,
username KERMSRV node CUVMA.  Command format is similiar to
the VMS KERMSRV on node UOFT01.

Dialup:

        [phone]
        Service class  VX785A
        User: KERMIT
        Password: KERMIT

Source and hex files are in KER:, binaries are in KERBIN:

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

Date: Mon 19 Aug 85 05:33:45-PDT
From: [e-mail]
Subject: Kermit for TI 99/4A
Keywords: TI 99/4A Kermit

Gentlemen

    I  am  trying  to  locate  a  version  of  Kermit  for  the  Texas
Instruments 99/4A Home Computer.  I have been informed that one exists
or  is  currently  under  implementation.   I  would  appreciate   any
information that you may have regarding Kermit for the TI 99/4A.

Anthony Gargaro.

------------------------------
Date: Mon, 19 Aug 85 12:23:44 EDT
From: David Roth (Ft. Benj. Harrison) <[e-mail]>
Subject: CompuPro KERMIT version wanted to work with Hayes Micromodem.
Keywords: CompuPro Kermit, Hayes Modem

We need help on getting a version of KERMIT for the CompuPro running
CP/M 2.2LD to work with a Hayes Micromodem 100 using the microcoupler.
We have the source to KER:CPMPRO.M80 from Columbia University but it is
for use with Compupro Interfacer 3/4.
Thanks in advance.
                                David A. Roth
                                droth@brl-bmd
                        US Mail:
                                COMMANDER
                                USA Soldier Support Center
                                ATSG-DTU-S
                                Attn: Mr. David A. Roth
                                Fort Benjamin Harrison, IN
                                                46216-5590
                        AUTOVON:699-4298
                        FTS:335-4298
                        COMMERCIAL:[phone]

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

Date: Mon, 19 Aug 85 13:44:28 edt
From: jax-lab!jng (John N Guidi)
Subject: Concurrent DOS KERMIT
Keywords: MS-DOS Kermit, Concurrent Kermit

I would like to run KERMIT on a Concurrent DOS, IBM PC/AT system.
Is there a separate Concurrent DOS distribution? If not, can one
use the PC-DOS KERMIT while running Concurrent DOS? If this is the
case, are there any caveates to keep in mind?
Thanks.

John Guidi
The Computing Service
The Jackson Laboratory
Bar Harbor, ME  04609
phone: [phone]
uucp:  ...!decvax!unh!jaxlab!jng
bitnet: jaxlab@maine

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

Date: Friday, 16 August 1985  15:51-MDT
From: [e-mail]
Subject: CROSS and other queries
Keywords: CROSS Assembler

NetLandians,

Could someone please point me to the documentation/instructions for
CROSS - the cross assembler available on some TOPS-20 hosts, and used
extensively for KERMIT applications.

[Ed. - Take a look in psb:<micros>cross.* on Cu20B.]

Second:  Is CROSS proprietary or public domain?

[Ed. -  I think it's public domain.]

Third:  What happened to CU20B as a host?  The KERMIT archives are out there
(Columbia University), and I saw the msg they were moving the archives to
another disk... but when trying to FTP to CU20B, I get an unknown host error.
Can anyone point me right?

[Ed. - Cu20b underwent some disk reshuffling, but it should be back online
       now. ]

Thanks in advance,
David Kirschbaum
Toad Hall

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

Date: Tue, 20 Aug 85 07:53 PDT
From: "Chase Lila"@LLL-MFE.ARPA
Subject: Prime Kermit
Keywords: Prime Kermit

Can the Prime Kermit transfer binary files?       [e-mail]

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

From: [e-mail] (Larry Bierma)
Date: 20 August 1985 0953-PDT (Tuesday)
Subject: CMS KERMIT and Yale 2.0
Keywords: VM/CMS Kermit, Yale ASCII Communications Program

Is CMS KERMIT supposed to work through a Series/1 running version 2.0
of the Yale software?  Whenever we start the server it hangs up the
line.  Everything works fine in line mode through a 3704, and in page
mode through a 7171, it's just the series/1 that hangs up.

[Ed. - We use CMS Kermit through a Series/1 running the version 2.0 of
       the Yale Ascii code and version 3.2 of EDX all the time without
       any problems.  The way this works is Kermit puts the S/1 into
       transparent mode.  It sounds like you don't have the most
       up-to-date software for the S/1. ]


--Larry        ARPA: [e-mail]
        UUCP: {decvax,ucbvax,ihnp4}!sdcsvax!sdcsla!nprdc!bierma
        PSTN: [phone]

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

Date: Tue 20 Aug 85 15:34:52-CDT
From: [e-mail]
Subject: plea for help
Keywords: VAX/VMS Kermit, HP1000 Kermit

Hi

I am trying to find a way to connect my Vax (VMS 4.1) to our HP
1000 running the RTE-A operating system.  Is there a Kermit out
there for this OS.  I looked and found the one for a previous
HP1000 operating system (RT6/vm or some such moniker)

Please respond to [e-mail], as I am not on the
INFO-KERMIT discussion.

Steve Kneuper
Lockheed Austin Division
[phone]

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

Date: 14 Aug 1985 1541-PST
From: Contr36 <CONTR36 at NOSC-TECR>
Subject: kermit/milnet
Keywords: C-Kermit, MILNET

from: Paul Attermeier
      Sandia National Labs
      Albuquerque, NM
      [phone]

I am trying to transfer some files from a VAX at the Naval Ocean
Systems Center back to my machine using Kermit. I have had no success
so far and the problem seems to lie somewhere in the MILNET
connection.

I'm running Kermit on a VAX/780 under Ultrix.  (The header reads
'C-Kermit 4.2 (030) Prerelease #2, 5 March 85, 4.2 BSD).  I've been
able to transfer files from another local 780 running VMS and a
version of Kermit (VMS Kermit-32 version 3.0.052) that appears to be
older than the one on the NOSC machine, (VMS Kermit-32 version
3.1.062) so I don't think there is a Kermit version incompatibility
problem.

Whenever I try a Kermit file transfer across MILNET, it just tries
for a minute or two and then times out. Do you know of any Kermit
or MILNET parameters which need to be changed from their defaults?

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

Date:     Fri, 23 Aug 85 09:57 EST
From:     Larry Afrin <[e-mail]>
Subject:  Kermit over TELENET: Help Needed
Keywords: TELENET

Fellow Frog Lovers,

    I would like to use Kermit for file transfer between my IBM PC and an
NCR Tower running System V UNIX.  Both machines are running the latest
versions of Kermit available for them.  The only problem is that GTE TELENET
is in the middle.  (From the PC's Kermit I dial TELENET's local number and
then give the connect code (host address) by which TELENET knows the Tower.)
Something with TELENET is preventing file transfer from working (the
initialization packets don't even make it through).  Does anyone out there
have either (1) a proven method for using Kermit over TELENET or (2) an
explanation of why such may be impossible?  Any help, advice, pointers, etc.
would be greatly appreciated.  Thanks in advance...

                    -- Larry Afrin
                       Dept. of Computer Science
                       Clemson University

Please send replies, if any, to:
lbafrin@clemson                         if you're on CSNet
lbafrin.clemson@csnet-Relay             if you're on ARPANet

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

Date: Wednesday, 21 August 1985  08:59-MDT
From: Steve Westfall <ihnp4!gargoyle!sphinx![e-mail]>
Subject:   Kermit for Fortune 32:16
Keywords: Fortune 32:16 Kermit

The Bulletin of the Atomic Scientists at the University of Chicago has
a Fortune 32:16 computer.  The system administrator has had problems
getting kermit to work with his Fortune and would like to get in touch
with anyone who has helpful information about this.  Please get in
touch with the following person, not me:

            Barry Bowen
            Bulletin of the Atomic Scientists
            5801 S. Kenwood
            Chicago, Illinois 60637
            312-363-5225
            UUCP:  ...ihnp4!gargoyle!xeno

Thanks.


Steve Westfall                Uucp:  ihnp4!gargoyle!sphinx!west
Senior Staff Analyst          Bitnet:  [e-mail]
U. of Chicago Computation Center  Mailnet: [e-mail]

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

Date: 22 Aug 1985 12:32-EDT
Subject: kermit on vms
From: [e-mail]
Keywords: VAX/VMS Kermit, C-Kermit

     I am trying to connect a VAX/VMS system to a VAX/UNIX 4.2 system
using KERMIT.  The UNIX side is running version 4C (CK*) and the VMS
side is running the MACRO version (VMS*.MAR).  The link is made up of
ports of DMF32s on both machines.  If someone else has tried this before,
I need to talk to them because I may not have set up the VMS environment
correctly.  From the UNIX side I can CONNECT to VMS just like a terminal
with no problems.  On the VMS side though, when I CONNECT to UNIX,
I have a problem with data overrunning buffers, as though there were no
flow control.  Any help would be appreciated.

  Joe Zakar
Zakar at USC-ISI

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

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

-------
 5-Sep-85 18:44:47-EDT,21422;000000000001
Mail-From: SY.FDC created at  5-Sep-85 18:44:24
Date: Thu 5 Sep 85 18:44:24-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #15
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Thu,  5 Sep 1985       Volume 3 : Number 15

Departments:

  SLIDING WINDOWS -
    Sliding Windows Work on Fast Line with Slow Disk
    Re: ANY-duplex Windows (2 messages)

  MS-DOS KERMIT -
    POPDOS2 and Kermit Problem
    Problem with MS kermit on DEC Rainbow 100+
    Leading Edge & Corona Portable -- Kermit Fit?
    Kermit for the Hyperion?

  IBM MAINFRAME KERMIT -
    Solution to TSO Kermit vs 7171 Problem
    Kermit with Yale ASCII?

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

Date: Thu 22 Aug 85 15:42:46-EDT
From: John Mulligan <[e-mail]>
Subject: Sliding Windows Work on Fast Line with Slow Disk
Keywords: Sliding Windows Kermit

Frank - I tried the windowing direct connect at 9600 baud with a standard
IBM PC (Floppies) and had no problems.

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

Date: Thu 22 Aug 85 15:46:43-EDT
From: John Mulligan <[e-mail]>
Subject: Re: ANY-duplex Windows
Keywords: Sliding Windows Kermit, Long Packets

Dear Ken,

   I would like to thank you for your messages on the windowing proposal.
They were well thought out and written, and helped us a great deal in
refining the proposal.  I have been meaning to reply before, but I was
still learning the mail system on Columbia.  Frank was the only one I
knew how to send messages to!

   Anyway, we have been thinking about the half-duplex situation.  I'm
sending our current thoughts to you before we go public with them.

   First, the Send-Init packet.  Define an additional bit in the capabilities
mask indicating half-duplex windowing:

   Bit        1     2     3     4     5
             reserved  ATTRIB  FULL  HALF

  Do a bitwise "AND" of the sender pair with the receiver pair.

  Full  Half
  0     0       Kermit Classic
  1     0       Full-duplex as defined now
  0     1       Half-duplex extension to be elaborated
  1     1       Either full or half *
                 *If both, default to half; shouldn't happen because
                  second send-init should pick one.

Second, half-duplex itself:

   Create a new data packet type that says "this data packet is not the
   last in this group; don't answer yet".  Thus the current standard
   DATA packet can be answered right away, and our current full-duplex
   definition is consistent.

   I'm suggesting the new packet type be called the WATA packet, and it
   would be just like a DATA packet except that it would mean
   "WAiT A minute, I'm not done sending this group, don't reply yet".

   A DATA packet (as in "DAT's All for this group, go ahead and reply")
   would signal the end of a particular group of packets.

   The above definition is consistent with both classic KERMIT and with
   the full-duplex windowing.

   As the receiver processed WATA packets, it would compose the ACKs and
   NAKs in the same manner as for full-duplex windowing, but buffer
   them for sending when the half-duplex line was turned around (indicated by
   receipt of a DATA packet).

   This system should use almost identical code for both full and half
   duplex windowing, and would (as you mentioned) make it very
   easy to debug in half-duplex and then move to full-duplex.

   Error handling, window rotation, etc. appear to remain the same,
   at least at first glance.

   We think the maximum half-duplex window size could be 63, instead
   of 32, but we aren't totally sure.

Thanks again for your very helpful thoughts.  Let me know what you think of
the above.
                     -John Mulligan

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

Date: Mon, 26 Aug 85 23:19:52 pdt
From: hpl-opus![e-mail]
Subject: ANY-Duplex Windows
Keywords: Sliding Windows Kermit, Long Packets

Glad to hear from you, John!

Here are my thoughts:

Repeated for the benfit of others:
>
>    First, the Send-Init packet.  Define an additional bit in the capabilities
>     mask indicating half-duplex windowing:
>
>    Bit        1     2     3     4     5
>              reserved  ATTRIB  FULL  HALF
>
>
>   Do a bitwise "AND" of the sender pair with the receiver pair.
>
>   Full  Half
>   0     0       Kermit Classic
>   1     0       Full-duplex as defined now
>   0     1       Half-duplex extension to be elaborated
>   1     1       Either full or half *
>                  *If both, default to half; shouldn't happen because
>                   second send-init should pick one.

Yes, but I think that "1 1" should default to full duplex.
Both sides are capable, so why not use full-duplex?
(If you want to choose half-duplex with a pair of Kermits
capable of either, "SET WINDOW HALF-DUPLEX" or some such command
should cause only the half-duplex bit to be sent.)


Both sides should also send a super-packet size (S) in the
next byte following the window-size (W) byte.
If half-duplex windows are selected, then the super-packet size
used is the lower of the two super-packet sizes.

Super-packet size must be less than or equal to half the window size
(S <= W/2) :
    1) We must have window size (W) >= 2x super-packet size (S) in case
    the first packet of a super-packet is lost (then the next super packet
    contains packet 1 plus packets S+1 through 2S-1).
    2) We can only make use of W > 2*S in the case of multple retries
    for a particular packet.  (This could be useful in very noisy
    environments...)
The normal case (the program default) should probably be for S = W/2.
Note that S may be more limited by a machine's input buffer size
than by W (=~ memory size).   It might be less than W/2 even for full
duplex machines (i.e., how *long* can a full-duplex machine sustain
a full speed input without any pauses?).

Note that super-packet size is a maximum only.

More repeated stuff:
>
>
> Second, half-duplex itself:
>
>    Create a new data packet type that says "this data packet is not the
>    last in this group; don't answer yet".  Thus the current standard
>    DATA packet can be answered right away, and our current full-duplex
>    definition is consistent.
>
>    I'm suggesting the new packet type be called the WATA packet, and it
>    would be just like a DATA packet except that it would mean
>    "WAiT A minute, I'm not done sending this group, don't reply yet".
>
>    A DATA packet (as in "DAT's All for this group, go ahead and reply")
>    would signal the end of a particular group of packets.
>
>    The above definition is consistent with both classic KERMIT and with
>    the full-duplex windowing.
>
>    As the receiver processed WATA packets, it would compose the ACKs and
>    NAKs in the same manner as for full-duplex windowing, but buffer
>    them for sending when the half-duplex line was turned around (indicated by
>    receipt of a DATA packet).

I'm not convinced that we gain by adding a new packet type.

Note that we cannot send an EOL character to the half-duplex host
between packets, because this causes the host to finish the read
and probably miss the start of the next packet.  On my system,
at least, the system not only can't send while it's receiving,
but, after completing a read, it doesn't buffer until a new
read is issued for the line.
System call overhead ensures that the next read will not be issued
until well after several characters of the next packet have gone
by, even if no processing is done on the packet in the meantime.

(The alternative is XON handshaking between packets, which
will defeat the whole pupose of super-packets.
Note also, that we have not gotten away from XON handshaking
between super-packets.)

This means that when the kermit program on a half-duplex host
gets the packet, an EOL has been received.  EOL is a de-facto
super-packet delimiter.
As soon as the end of the super-packet (the EOL) is processed,
the program knows it can proceed to reply.

If one side is full-duplex, it can queue up ACKs and NAKs as it reads
packets, but it must wait for the EOL (and probably XON) before
sending them.  I suppose that for a full-duplex host,
WATA/DATA is a way of providing the higher-level protocol
with the end of super-packet data which the half-duplex host
gets implicity by the nature of its i/o system.

It seems to me that making the send-packet routine wait for
receiving routine to get an XON is sufficent, although this
hides the super-packets from the packet-level protocol.
Is there a reason to tell it?
If so, perhaps the full-duplex kermit can implement a WATA
packet internally: a DATA packet received without an EOL gets
reported internally as a WATA,
but only DATA packets are actually sent over the wires.

I'm not real strong on this one way or the other;
I'm just wary of adding packet types.

As Bruce Cowan points out, a half-duplex receiver can NAK
bad-checksum packets since it *knows* which packets were supposed
to be sent (including which ones resent).
I'm not sure whether this helps or not, since the absence of an ACK
is just as sure an indication to the sender.  *Something* (at least one
ACK/NAK) does have to be sent, however, to let the sender know
to retransmit.
The best policy is probably to send only ACK's unless no good packets
are received, in which case a NAK for the lowest-numbered outstanding
packet may be sent.
This has the advantage of agreeing with the full-duplex case,
for best commonality of coding.

It seems to me that where super-packets are most vulnerable is if
the EOL (or the XON) is lost.  In that case, my system, at least,
will time out and throw away the whole super-packet!
Some simple kluges will help here: send some padding followed by a
second EOL character *after* each super packet if the padding
parameter is non-zero.

As long as we don't get into a situation where the end of the super-packet
(and the EOL) is lost on every transmission, though, we still gain:
the critical EOL characters are a lower percentage of the
total characters sent.

>    This system should use almost identical code for both full and half
>    duplex windowing, and would (as you mentioned) make it very
>    easy to debug in half-duplex and then move to full-duplex.
>
>    Error handling, window rotation, etc. appear to remain the same,
>    at least at first glance.

I believe so, too.

>    We think the maximum half-duplex window size could be 63, instead
>    of 32, but we aren't totally sure.

I'm not sure that the gain would be worth making it different
from the full-duplex case.  Ease of coding and all...

One thing I have not thought about yet is how to integrate long packets
with windows.  Bruce makes a good case for allowing packets to be
close to 128 or 256 characters to take advantage of public data network
packet sizes.  I lean towards using the published long-packet
extension rather than his proposed special case for up to triple-size
packets, though.
It seems that the easy solution is to state that window and super-packet
negotiations are really for windows of 94*W *characters*;
when using longer packets, you must scale W and S down accordingly.
This is not as flexible as one might wish for, though.

Your turn!

Ken Poulton

Bit by bit, byte by byte, we'll figure it out...

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

Date: Tue 13 Aug 85 13:45:37-EDT
From: Fuat C. Baran <[e-mail]>
Subject: POPDOS2 and Kermit Problem
Keywords: MS-DOS Kermit, popdos2

I have been testing some of the popups (Bellsoft) recently and I have
found one problem.  The problem occurs when I use Kermit (v2.28) and
popdos2.  Here is what happens:

I install the popup and go into kermit.  Until I use popdos2 (calling
it up with ALT-U) I have no problems.  Then I call popdos2 and do the
following: I cd to a subdirectory and a dir *.* of the subdirectory.
I then exit from popdos2 and continue with Kermit.  I try transferring
more files but later when I look at the files I see that they are all
filled with garbage.  The garbage looks like random characters and,
here and there, file names of the subdirectory that I had done the dir
on.  I tried this several times and with different files and got the
same results.  Kermit works fine until I do the cd and dir sequence in
popdos2.  Any files transferred after that point come out as garbage.

So far that is the only major problem I have encountered with popups.
I minor irritation is the alarm clock feature in continuous display
mode.  Every time the screen scrolls up a line it moves the clock (I
keep the display in the top right hand corner of the screen) up with
it and then it redisplays it where it should be.  (If you put the
clock in some other place, on the bottom for example, then it scrolls
up with the page and you get multiple displays on your screen.)

Note: I have an IBM-PC with 256K and two disk drives.  I use a TAXAN
monochrome display with a Paradise Color Card (yuk!  [The Paradise
card has been giving me problems like substituting characters on my
screen ("S." -> "S*" with the "*" flickering, etc...)])

                                        --Fuat Baran
                                          [e-mail]

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

Date: Fri, 23 Aug 85 10:38:21 mdt
From: [e-mail] (Richard Thomsen)
Subject: Problem with MS kermit on DEC Rainbow 100+
Keywords: MS-DOS Kermit, DEC Rainbow

I have (am currently) using MSKERMIT on my Rainbow 100+, connecting to a
Berkley 4.2 UNIX system on a VAX.  When I run the Rand Editor under Kermit,
the cursor arrow keys do not work.  When I run the Rand Editor using the
Rainbow built-in terminal emulator, then the arrow keys work.  I suspect
that the Kermit program does not change the normal cursor keys to the
application cursor keys, but it does so with the keypad keys, which work
as expected.

I have not had a chance to look extensively at the code, but I guess I could
if that is desired.

                        Richard Thomsen
                        [e-mail]

[Ed. - In a pinch, you can always make a file that does "set key" commands
for the cursor keys, and "take" the file whenever you want to run the
editor.]

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

Date: 25 Aug 1985 0040-PDT
From: Rob-Kling <Kling%UCI-20B@UCI-ICSA>
Subject: Leading Edge & Corona Portable -- Kermit Fit?
Keywords: Leading Edge D PC, Corona Portable PC

For reasons explained below, the new Leading Edge D machine
might be an attractive PC compatable. As might also a Corona portable
at about $1250.

Has anybody had experience using recent MS-Kermits (2.27 or 2.28) with
either of these machines. [I would also appreciate any comments on the
compatability or ruggedness of these machines if anybody has relevant
experience.]

Some dealers in Southern California are pricing the Leading Edge D Machine
rather aggresively -- with 640K, parallel & seriel port, Hercules-like board,
hefty power supply, monitor & 2 DSDD drives ... about $1300-$1400.
About $700 more for a 20MB Seagate or Rodine hard disk w/WD controller.

They will also take off about 25% for universities...... making the
floppy machine about $1150 and the hard disk machine about $1700.

These are attractive prices..... if the machine works well, is
about as compatable as anything else on the market, etc. (And if Leading
Edge doesn't go under in its endless suits with Mitsubishi.)

BTW. The machine has a small footprint and also comes with a 1 year warranty.
Processor is an 8088 at 4.77 MHz. No speed demon, but the aim seems to
be to aim at the highest cmpatability possible (Phoenix BIOS, ...).

I would apprecaite any comments on the compatability, ruggedness of the Leading
Eedge D machine from people who can share some recent experience.

I am told that this machine is just coming to market and that it is better (?)
than the earlier M machine which Mitsubishi manufactured for Leading Edge.

I'll summarize key responses for the net.

Rob Kling
Department of Information and Computer Science
University of California, Irvine
kling@uci-ics-a

PS. Corona has also recently dropped prices. I would also appreciate
comments on the IBM compatability & general value of the Corona portables
manufactured in the last year (since the ROM BIOS was changed because of the
suit by IBM).

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

Date: Wed, 4 Sep 85 11:48:05 pdt
From: Peter Ludemann <[e-mail]>
Subject: Kermit for the Hyperion?
Keywords: Hyperion Kermit

Does there exist a version of Kermit for the Hyperion
(also sometimes known as Bytec Hyperion or Anderson-Jacobson
Ajile) running DOS2.11 (DOS1.x is acceptable)?

The generic MS-DOS Kermit gets a "write error while reading from
COM1" error - I suspect the problem is that the Hyperion uses
a Zilog SIO chip instead of whatever the IBM-PC uses.

Thanks in advance,

Peter Ludemann
    [e-mail] (ubc-vision!ubc-cs!ludemann)
    [e-mail]  ([e-mail]@ubc.mailnet)
    [e-mail]   ([e-mail])

[Ed. - Generic MS-DOS Kermit should be able to work on any DOS machine.
It uses only DOS calls for i/o, and has no knowledge of any chip.  Try
fooling with the SET PORT command, and maybe you'll stumble upon a device
designator that will work.]

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

Date: Wed 14 Aug 85 08:52:52-PDT
From: Wing Lee <WingLee%ECLD@ECLA>
Subject: Solution to TSO Kermit vs 7171 Problem
Keywords: TSO Kermit, 7171 Protocol Converters

Good News!  The problem we had with the Series/1 version of TSO-KERMIT
has been solved.  The problem we were having was that TSO-KERMIT would
hang at random places whenever you tried to upload to TSO.  One of
our Systems Programmers, Valaine Saito, discovered what we think
the problem is.  What follows is Valaine's message to me.

>    i looked at the kermit through the 7171 problem again since it appears
>that it really HAS to work if we're going to lose a s/1.  i stumbled through
>the assembler program, it looks like the logic is okay.  after determining
>that, i went to the s/1 and 7171 manuals to see what the difference was.  it
>turns out that there is NO logical difference, but there clearly is a
>functional difference.
>
>    both the s/1 and the 7171 have 64 char type ahead buffers.  the s/1 must
>handle it differently.  when i have both the host and micro kermits sending
>packet lengths of 60 (less than the 64 char buffer size), everything works
>fine.  when either of the kermits sends > 64 packet lengths, the familiar
>"failure to receive ackn from host" msg appears on the micro and the transfer
>stops.  (all this pertains to file transfer from micro to host, i assume the
>other way works since no one has said otherwise.)  at 9600 baud, i ran a
>largish file (60+ kb) through a number of times (10 or so) and it worked
>every time with BOTH kermits sending packet sizes of less than 64.
>
>    so the solution is to send packets of size X, where x is less than 64
>(i always tried sizes of < 64, i didn't try 64).  the practical options
>are:
>
>    tell users about the packet length problem and have them set both
>    lengths themselves.
>
>    re-code the host kermit to accept a max packet size of 63 or 64.
>    (this isn't too cool because only the receive section has the
>     problem.  changing the max packet size would affect all
>     sections.)
>
>    re-code the host kermit to utilize the RPSIZ variable correctly
>    and change the value to F'64' (or 63).  RPSIZ is the max receive
>    packet size.

I have tried sending packet sizes of 64 bytes and that works.  When I tried 65
byte packets, the upload failed, so it looks like 64 is the magic number.

wing lee

[Ed. - For CMS Kermit, we will look into the possibility that the program
can determine if it's a 7171 (it's not clear that it reports itself
differently from a Series/1) and in that case use the smaller packet size.]

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

Date: Wed, 28 Aug 85 17:12 EST
From: Jim Ennis  <[e-mail]>
Subject: Kermit with Yale ASCII?
Keywords: Yale ASCII Communications Program

What is the oldest version of the YALE ASCII communication package that
can be used with Kermit for upload download (i.e. transparency)?
We have an old turkey implementation using Yale ASCII V2.0 running
under EDX V3.2.....    It is my understanding that I need to go to a
more recent version of the Yale ASCII support in order to utilize the
transparency capabilities of that later version.  Furthermore, I need
to go to a more recent version of EDX before I can go to the more
recent version of the Yale package.  Information on this subject will
be greatly appreciated...... The only reason this is an issue is be-
cause we have only floppies on the box (no hard drive) and I want to
get it right the first try.  Sincerely.

[Ed. - We run version 2.0 of the Yale ASCII package, and version 3.2 at
update level P0A of the EDX Supervisor, and have experienced no problems.
There was, however, a complaint from Larry Bierma@NPRDC in the last Info-Kermit
digest, who claimed that file transfers through the Series/1 would "hang up"
even though they worked fine through the 7171 or 3704.]

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

End of Info-Kermit Digest
*************************
-------
 6-Sep-85 18:08:45-EDT,15713;000000000001
Mail-From: SY.FDC created at  6-Sep-85 18:08:13
Date: Fri 6 Sep 85 18:08:13-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #16
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri,  6 Sep 1985       Volume 3 : Number 16

Today's Topics:

             Downloading .EXE Files Which Destroy Monitor
                           CR/LF Processing
   How to Make Kermit Work over European Packet Switching Networks
                          Kermit on NEC 8001
                        Concurrent DOS Kermit
                  New BITNET KERMSRV Command Syntax
       Kermit for Japanese Microcomputers and NTT Lisp Machine
                     Kermit for Sharp PC 1500 A?

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

Date: Thu, 15 Aug 85 11:58:49 pdt
From: [e-mail] (Don Reynolds)
Subject: Downloading .EXE Files Which Destroy Monitor
Keywords: .EXE File Transfer

Welcome to a new user of Kermit on an IBM compatible!  We like the frog
a lot here, but he sometimes croaks!  This may not be your problem, but
the symptoms happened to me before.  By mistake I used the host command:

    kermit s filename.ext

which sends 7-bit ascii text files, but will not send 8-bit (image mode)
executable (.COM & .EXE) files, Wordstar format files, or other binary
files.  The command for image mode is

    kermit si filename.ext

If you try it without the "i" switch it really trashes the files, and gives
the results Brzozowski states a couple messages down from your message.
However, the file size still looks reasonable using the DOS DIR command.

Question for the net:

People have noted in this digest problems burning out the IBM monochrome
display trying to execute such a file.  I wonder if something like Norton's
Utilities, U-File, or some other utility that looks at disk sectors or one
that looks at memory can easily look at the header to see if the file has
been trashed?  Will DEBUG work?  What do you look for?  Note that I person-
ally have only academic interest since we have mostly color monitors here,
but someday I may have to download executables to a monochrome system.

Best,
Don

[Ed. - The Kermit protocol allows file transmission in both text and binary
mode.  Text mode means that any necessary conversions are done on the file
-- by both the sender and the receiver -- to make the file useful and
readable on the target system.  Binary mode means no conversions are done.
Unfortunately, most Kermit programs have to rely on the user to specify
whether a file is text or binary, because (a) the sending Kermit program
usually can't tell because most systems (e.g. MS-DOS) don't provide this
information in the file descriptor, and (b) the receiving Kermit certainly
doesn't know (unless the sender informs it using the almost universally
unimplemented Attribute packet).  Now, it might be observed that text files
tend to contain bytes whose high-order bits are all off, whereas binary
files tend to have many bytes with this bit on.  However, for the sending
Kermit program to determine whether a file is binary by this method would
require it to make a preliminary pass through the file (the WHOLE file if it
turns out to be text) which would be undesirable for many reasons (e.g.
timeouts when files are long).  Many operating systems require executable
programs to be in a certain format or to be tagged in a certain way, and
will therefore not attempt to execute text files.  But since not all OS's
guard themselves in this way, users should also take precautions.  On a
case-by-case basis, heuristics can be added to some of the Kermit programs
but they will never be foolproof.  For instance, PDP-11 Kermit allows the
use to specify a list of filetypes to determine the mode of the file -- but
how can it know whether a .COM file is a DCL command file (text) or, say, a
CP/M-80 program image (binary)?]

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

Date:     Fri, 23 Aug 85 15:06:18 BST
From:     Chris-on-Fridays <[e-mail]>
Subject:  CR/LF Processing.
Keywords: CR/LF

Info:

     Is there an accepted policy about when Kermit should and should not do
CR/LF (logical-end-of-record) processing?

     Obviously it is wanted in text-files and not in binaries.  By default
any 7-bit file is probably text, and any file sent as 8-bit image is
probably not; but what assumption do you make if 8th-bit-prefixing is
switched on?

     If the answer to the previous is "binary", shouldn't Kermits in general
make it rather difficult to accidentally switch on 8th-bit-prefixing?  And
if the answer to that one is "yes", then is it wise for a Kermit server, or
in fact any mainframe Kermit, to regularly offer 8th-bit-prefixing in its
I-exchange?  (This is suggested in the protocol manual.)

     Those of us who live on unix (with its LF as record-terminator) are
keenly aware of the problems of files which come in with CR instead.
Unsophisticated users tend to get absoultely floored; and it's they who are
most likely to get into trouble if the two Kermits they are using do not,
between them, pick sensible defaults.

     As an extension, what about the filing-systems which expect to find
carriage-control-characters either at the start of each line (as per
Fortran), or even at the end (older IBM formats)?

                                Chris Kennington (cjk@ucl-cs)

[Ed. - 8th-bit prefixing is totally unrelated to text vs binary mode.  The
prefixing mechanism is just a trick to squeeze 8-bit bytes through a 7-bit
link.  Most Kermit programs do (and should) enable 8th-bit prefixing
automatically if parity is not none (i.e. is even, odd, mark, or space); it
is a transmission technique akin to TELNET IAC doubling.  All Kermit
programs I know about run in text mode by default, and 8th bit prefixing is
off by default except in systems (like IBM mainframes, or Prime computers)
that always use parity.  In Unix, text mode means LF/CRLF conversion is
done, and it works Unix-to-anything, anything-to-Unix, so long as the
"anything" Kermit is also in text mode.  But see the discussion after the
previous message about the perils of automatic mode selection.  Systems that
have carriage control or other "structured text" formats bear the
responsibility for converting them to canonical (CRLF) format before
transmission; VAX/VMS Kermit (the Stevens Bliss version) does this.]

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

Date: Fri, 30 Aug 85 10:12 MET
From: Peter Bendall, DECUS VAX SIG Europe
  <[e-mail]>
Subject: How to Make Kermit Work over European Packet Switching Networks
Keywords: European Networks

Since I started distributing 6800 and 6809 FLEX Kermits I have received MANY
calls to say that Kermit is not able to work over the European packet
switching networks.

The following "work around" does however work for the German DATEX-P system
and will probably work for other systems also:

For Kermit-32 on VAX/VMS systems:

Call the VAX using CONNECT and start Kermit-32, and issue the commands:

SET RECEIVE START_OF_PACKET 7
SET SEND START_OF_PACKET 7

and then start the server if required.  Then escape to your own Kermit and
issue the equivalent commands:

SET REC SOP=7
SET SEN SOP=7

(or whatever they look like)

and then it works.

[Ed. - Apparently DATEX-P does not pass through Control-A's, which are
used by Kermit as the start-of-packet character.]

In the case of the VAX systems, we have checked that the control-As are
still in the packet when they reach our machine but we have found no
simple way to get them into the packets...  If anyone knows the proper
workaround please let me know!

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

Date: Wed 28 Aug 85 11:17:59-PDT
From: Ronald Blanford <[e-mail]>
Subject: Kermit on NEC 8001
Keywords: NEC 8001

Some time ago there was a complaint that the Generic version of Kermit
only partially worked on the NEC 8001.  I had reason to need it recently
and found the following fix which works quite well.

Generic Kermit uses the iobyte to switch to the BAT console (which takes
its input from the RDR device) so that it can check the serial port input
status using the Console Status BIOS call.  The BIOS therefore must check
the iobyte twice in this situation, once to determine that the BAT console
is in use, then again to decide which physical device RDR is set to.  The
NEC 8001 does this for the Console Input routine, but not for Console Status.
The default Console Status routine always returns No Input Available, so
that Kermit never tries to receive a character even though it can send them
just fine.

The solution is to patch the dispatch table for the Console Status routine
so that it proceeds to the serial status routine instead of the default.
It might be hard to determine the address of the status routine if RDR is
set to the PTR, UR1, or UR2 device, but for the TTY device the address is
just two entries earlier in the table to be patched.  Fortunately Kermit
uses the TTY device by default.

On the NEC 8001, the serial driver is loaded dynamically, and the address
of the status routine varies depending on which driver is used.  Therefore
this patch must be made each time the system is cold-booted, after installing
the serial device driver but before running Kermit.  It's easiest to make
the patch into a simple program using DDT as follows:

A>DDT
DDT VERS 2.2
-A100
0100 LHLD 1        ; get the address of the BIOS jump table
0103 INX  H        ; step forward to the Console Status entry
0104 INX  H
0105 INX  H
0106 INX  H
0107 MOV  A,M        ; get the address of the Console Status dispatcher
0108 INX  H
0109 MOV  H,M
010A MOV  L,A
010B INX  H        ; step past the dispatcher's initial JMP instruction
010C INX  H
010D INX  H
010E MOV  C,M        ; pick up the address for the TTY Status routine
010F INX  H
0110 MOV  B,M
0111 INX  H
0112 INX  H        ; step forward to the BAT entry
0113 INX  H
0114 MOV  M,C        ; save the TTY address in the BAT entry
0115 INX  H
0116 MOV  M,B
0117 RET        ; return to CP/M
0118 .
-^C            ; Now get out of DDT
A>SAVE 1 KPATCH.COM    ;  and save the patch as a COM file

With this patch program available, perform the following sequence of
actions after cold boot to bring up Kermit:

A>INSTALL8 IRS232A TTY: [,,,,O]        ; install the driver as device TTY
                    ; set up for Object files.  The driver
                    ; name may vary.
A>KPATCH                ; Patch the BAT status routine
A>KERMIT                ; Start Kermit

With the interrupt-driven serial driver in place, this has worked perfectly
for me at up to 9600 baud.  Good luck.

-- Ron

[Ed. - Thanks, Ron!  I've stored this message in the Kermit distribution as
CP4NEC.HLP.]

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

Date:  Wed, 4 Sep 85 03:14 EDT
From:  "John C. Klensin" <[e-mail]>
Subject:  Concurrent DOS Kermit
Keywords: Concurrent DOS, MS-DOS Kermit

PC-DOS Kermit seems to work fine under Concurrent DOS, with a few
qualifications, as you expect.  First, most of the 'internal' commands
that require PC-DOS interactions don't work, e.g., LOCAL DIR (wildcard
SENDs work fine).  This is, of course, less of a problem under
Concurrent than it would be under PCDOS, since, with Concurrent, you can
switch processes and do anything of these things (or even keep the
current directory or whatever in a handy window).  Second, you must use
SUSPEND=OFF if you expect to do transfers in background.  Third,
experience with the PC indicates that you may want to arrange a bit more
waiting time and/or retry count maximum with your mainframe kermit if
that is possible -- things sometimes get a little slow if there is a lot
of other stuff going on in the machine, especially if kermit is a
background, rather than foreground, process.  I would suspect that this
would be less of a problem on the AT, but haven't tried.

I keep fussing with a CDOS-specific version of Kermit, based on the
CP/M86 version when I manage to be around for more than a couple of
weeks (not frequent in the last year).  It is, of necessity, heavily
dependent on the operating system, and is quite slow when it works.  But
this message is coming to you from a Concurrent DOS 4.1 system, using
PC-DOS kermit, for whatever that is worth.  If someone else would like
to take that on, I would be happy to transfer everything I have done,
and try to transfer everything I know/have found out, otherwise I will
keep fussing as I have time.

The combination of MSDOS kermit and Concurrent also worked fine under
version 3.2 of the latter; versions before 3.2 are hopeless, since they
don't support PCDOS mode.

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

Date: Fri 16 Aug 85 11:03:59-EDT
From: Daphne Tzoar <[e-mail]>
Subject: New BITNET KERMSRV Command Syntax
Keywords: BITnet KERMSRV

 The syntax of Kermsrv commands has changed slightly so the file
 AANETW.HLP should be modified.  Here is the command format:

?
HELP
SEND { DIR | fn ft | ?}
PUNCH { DIR | fn ft | ?}

Send returns information in netdata format.  Punch uses punch format.
If PUNCH is used, files with LRECL 80 or under will be punched Class
A.  The others will be disk dumped Class N.  The DIR (directory
command) has been replaced by SEND DIR or PUNCH DIR.  File names may
contain wildcards.  Requests to Kermsrv can be either in the form of
messages or reader files, where the file contains a single line with a
valid Kermsrv command.

/daphne

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

From: ihnp4!kddlab!nttmecl!nttmecl!NTT-20![e-mail]
Date: 27 Aug 1985 2023
Subject: Kermit for Japanese Microcomputers and NTT Lisp Machine
Keywords: Japanese Micro Kermit, NTT Lisp

 Kermit for Japanese micro computers is supported.  Kermit for the
following computers is available:

   (1) NEC PC8800 on CP/M-80
   (2) NEC PC9800 on CP/M-86
   (3) FUJITSU FM-8 on CP/M-80
   (4) FUJITSU FM-11 on MS-DOS
   (5) IBM5550 on MS-DOS

In addition to these computers, Kermit for NTT Lisp Machine ELIS
was written by its language TAO. TAO is a dialect of Lisp which
unifies an object-oriented programming paradigm and a logic
programming paradigm with a procedural programming paradigm.
NTT Lisp Machine (interpreter) runs 1.3 times faster than SYMBOLICS
LISP MACHINE (compiler).

If you are interested in these Kermits, please send me mail to

           hplabs!kddlab!nttmecl!murakami@Berkeley

Is it useful for you to get Kermit sources for Japanese computers?
I hesitate to send these sources because of the following reasons.
 (1) These Kermits will not be widely used in your country.
 (2) Kermit on CP/M-80 is based on the old Kermit version.

We are translating an important part of the Kermit manuals into Japanese.
I would appreciate if you'd allow me to distribute these manuals in Japan.

                    Thank you for your attention

[Ed. - Does everyone agree that the programs listed above are not of general
interest outside of Japan?  If not, I'll try to get them into the Kermit
distribution.]

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

DATE: 26 Aug 85 1735 WEZ
FROM: [e-mail]  (Franklin A. Davis)
SUBJECT: Kermit for Sharp PC 1500 A?
Keywords: Sharp PC 1500 A Kermit

Anyone know of a Kermit for the Sharp PC 1500 A?  A colleague needs it, and
unfortunately isn't even sure if it uses CP/M, but our guess is that it may
be a close clone.  Please answer directly.

Thanks -- Franklin  <[e-mail]>
Institute for Informatics and Applied Mathematics
University of Bern
Laenggassstrasse 51
CH-3012  Bern
Switzerland

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

End of Info-Kermit Digest
*************************
-------
10-Sep-85 17:43:14-EDT,21796;000000000001
Mail-From: SY.FDC created at 10-Sep-85 17:42:02
Date: Tue 10 Sep 85 17:42:01-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #17
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Tue, 10 Sep 1985       Volume 3 : Number 17

Special C-Kermit Edition:

                        New C-Kermit Bug List
               C-Kermit on a 3B2 - Secure Line Locking
                Kermit/cu Incompatabilities on the 3B2
                     C-Kermit Speed on TRS-Xenix
                   C-Kermit Performance with Parity
                            C-Kermit Ideas
         C-Kermit Remote Server Commands Fail After an Abort
       Possible Missing Code in C-Kermit 4C(056)/ckutio 4C(032)
  Cancel File Forces Discard of Remaining Files in C-Kermit 4C(057)
                     Bug in C-Kermit Line Locking
                   Bug Report For C-Kermit 4C(057)
                      Problem Installing 4C(057)
         C-Kermit Take File Control and Background Operation
                   C-Kermit on UTS vs the IBM 7171?
                  Exiting "Protocol Mode" Gracefully

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

Date: 10 Sep 85 17:00:00 EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: New C-Kermit Bug List
Keywords: C-Kermit

Most of the messages in this issue report bugs and problems with C-Kermit
4C(057), the current (since July 31) release for Unix.  The problems are
not urgent, so a new release has not yet been prepared.  The problems have,
however, been noted in the "beware" file, KER:CKUKER.BWR, available via
anonymous FTP from Internet host CU20B.  Some of the messages below are
over a month old -- apologies; I'm still catching up from the backlog of
mail after a long vacation.

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

Date: 16 Aug 85 23:01:39 GMT
From: Robert Vidua <gatech!gitpyr![e-mail]>
Subject: C-Kermit on a 3B2 - Secure Line Locking
Keywords: C-Kermit, 3B2 Kermit

I just recently got C-Kermit 4C(055) and brought it up on a 3B2 running
System V Rel 2.  I'm trying to use it on a line that uucp also uses and
I'm not sure how to do this without making a potential security problem
and still giving ordinary users full access to the line.  I don't want
to modify the code.  That leaves me with a two other solutions: 1) make
kermit setuid to something (it doesn't handle this correctly (i.e. no
'setuid (getruid ())' or equivalent), so this isn't a valid solution)
and 2) make the tty line as well as /usr/spool/locks readable and writable
by everyone (nasty if someone decides to get malicious).  I'm not too
concerned about the 3B2, since I know/trust all the users on it (it's
a intra-departmental machine), but I'll soon be bringing up the same
kermit on a couple of 3B20s that's open to the whole campus and I'd like
to solve the security problem first.

About two or three months ago, there was a discussion on this very topic
in fa.info-kermit which I, silly me, neglected to pay attention to.  Now
I need the information.  Does anyone have an archive of those messages
and is willing to send me a copy?

Robert Viduya
Georgia Institute of Technology

UUCP:   {akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!robert
        {rlgvax,sb1,uf-cgrl,unmvax,ut-sally}!gatech!gitpyr!robert
BITNET:    CCOPRRV @ GITVM1

[Ed. - The discussions are in the Info-Kermit Digest V2 #11-12, #38-39, and V3
#2.  You should be able to pick up the archives over BITNET via KERMSRV at
host CUVMA -- V2 should be called "MAIL 85A" and V3 should be "MAIL TXT".]

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

Date: 3 Aug 85 16:00:12 EDT
From: Eliot Lear <[e-mail]>
Subject: Kermit/cu Incompatabilities on the 3B2
Keywords: 3B2 Kermit

I am running kermit on an At&T 3B2 running System V.2.  I don't know if I am
repeating what someone said but we have discovered that cu requires a line
be owned by uucp while Kermit requires that the line be owned by root.
Since the everyday average user is not allowed to root, this presents
problems.  I imagine that this has something to do with checking to see if
the line is active but I don't know.  I figured I'd mention it to you,
though.

                    eliot lear

[Ed. - See previous discussions of line locking.]

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

Date:  Mon, 26 Aug 85 14:46 MDT
From:  [e-mail]
Subject:  C-Kermit Speed on TRS-Xenix
Keywords: C-kermit, TRS-Xenix Kermit

After compiling the latest ckermit on TRS-80 Model 16b (v. 7 Xenix), I
timed a transfer from VAX/VMS:  16 chars/sec.  I then removed the
-DDEBUG and recompiled.  Now over 200 chars/sec at 4800 baud.

[Ed. - As predicted in V2 #35, building the program without the debugging
feature can result in a perceptible speed improvement -- but 1250% is more
than just perceptible!  I wonder if the difference is as great on other
systems.  In light of this report, it might make sense for every site to
build the program both ways -- use the non-debugging version for production
and the debugging version for tracking down & reporting problems.]

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

Date: 28-AUG-1985 12:17:47
From: [e-mail]
Subject: C-Kermit Performance with Parity
Keywords: C-Kermit, Parity

    Here's a relayed note on C-KERMIT from Tim Green, Computer Unit,
Warwick University UK. If you want to reply send it to me and I'll forward it.

          Alan Phillips
            Lancaster University

Forwarded message:

I've just put up C-Kermit 4C(057) and have some comments to make regarding
its performance. The performance of C-Kermit on a VAX is fine when you use
it with no parity.  Typically I can get 480ch/s on a 9600 baud line.
However due to the local net we have here we can't use it with no parity for
binary files.  As soon as you start to use parity the performance is greatly
degraded.  This is due to the way C-Kermit tries to detect whether parity is
correct.  If you do a profile of it while it is running you find that it is
spending most of its time setting and unsetting a timer.  There are two
posible solutions to this.  One: Do not test the parity, just assume that it
is correct (leaving error detection to the checksum).  Two: provide an
option to set 7bit data when using no parity.  We are using a VAX 780 with
4.2 Unix.

[Ed. - You're right about the poor performance when parity is "on".  It's
because the program is doing single-character reads rather than reading an
entire "line" (up to a carriage return).  It does this because the
terminating CR might have its parity bit on and therefore won't be
recognized as a CR.  A more clever scheme will used in a future release to
speed things up.  By the way, parity is not used by Kermit for error
checking; rather, Kermit (unlike some other protocols) "tolerates" parity
that is imposed upon it by the communication medium or one of the hosts
involved.]

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

Date: Sat, 3 Aug 85 00:18:04 pdt
From: "Scott Weikart; Community Data Processing; 415-322-9069"
 <cdp!scott@Glacier>
Subject:  C-Kermit Ideas
Keywords: C-Kermit

Here's are some comments on items in the recent ckuker.bwr file.

> - When connecting back to C-Kermit after a transaction, or after finishing
>   the server, it may be necessary to type a ^Q to clear up an XOFF deadlock.
>   There's not much the Kermit program can do about this...

If XON/XOFF is enabled, why couldn't Kermit send an extra ^Q before exitting?

[Ed. - The problem is in the other direction.  The local PC needs to send a
^Q to the remote end.  But you don't want the PC to do this automatically,
because it might mess things up -- e.g. suppose the remote Kermit was invoked
from within EMACS, which uses ^Q as a command, and has popped to EMACS upon
exit...]

> - ckufio 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.  (Find out how Unix FTP does it...)

How about forking a shell that's kept around, and communicating
with it through pipes.  This way you would only incur the fork and exec
overhead the first time a file name is specified.  Various EMACS's use this
technique.  In fact, it seems like this could also be used for the
"!" command.

[Ed. - Right, that's the idea.  Any volunteers to submit some code for this
that fits in the current framework and works for all versions of Unix?
Would this technique work on small systems, e.g. small-memory PDP-11's?]

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

Date: Tue, 6 Aug 85 10:46:07 PDT
From: [e-mail] (David Ragozin)
Subject: C-Kermit Remote Server Commands Fail After an Abort
Keywords: C-Kermit

Running C-Kermit, 4C(057) under 4.2BSD connected to MS-DOS 2.27 Kermit.
With the C-Kermit side in server mode it responds properly to remote and
remote host commands from the MS-DOS side.  However, if I interrupt a remote
command by typing a Control-C on the MS-DOS side, all further remote or
remote host commands fail, except for "remote help". For instance, "remote
dir" elicits the message "Can't list directory", "remote space" gives back
"can't check space", "remote host...." leads to "can't do system command".
Apparantly something on the C-kermit side has been left in a strange state
by the abort.

[Ed. - If you read the MS-DOS Kermit chapter of the Kermit User Guide,
you'll see the explanation.  ^C typed to MS-DOS Kermit during a file
transfer returns to MS-DOS Kermit command level "immediately without sending
any kind of notification to the remote system"; it's for use when, for
instance, you give a "send" command but then realize you forgot to start up
a Kermit on the other end.  This means that the remote Kermit blithely
continues with what it was doing, in this case sending data packets.  If you
waited for a couple minutes (after the other side timed out the maximum
number of times) the situation would have cleared up by itself.  If you have
a real transaction in progress that you want to interrupt, then you should
use ^X or ^Z, which most any Kermit server will honor.  MS-DOS Kermit also
provides a ^E interrupt, which sends an error packet to the remote side,
which is guaranteed to stop any transaction (assuming it arrives).]

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

Date: Mon, 12 Aug 85 23:30:16 BST
From: [e-mail]
Subject: Possible Missing Code in C-Kermit 4C(056)/ckutio 4C(032)
Keywords: C-Kermit

I had a friend of mine in the US snork a copy of C-Kermit and post it to me
on floppy disks.  He must have grabbed 4C(056) just before 4C(057) was
released and re-released (see Info-Kermit Digest v3 #10/12).  Unfortunately,
the ckctio file seems to lack rtime and gtime routines.  I managed to patch
together a working ckctio by including the appropriate lines of code from
ckvtio.c.  I hope that this oversight has been remedied in 4C(057).
Script Command, V2.0(006) 14 Jun 85

[Ed. - It has.]

As a footnote, the problem reported earler with wart on a Whitechapel
(Info-Kermit Digest v2 #38) seems to have disappeared.

                 Les J. Wu - [e-mail]

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

Date: Tue, 13 Aug 85 17:37:10 PDT
From: [e-mail] (David Ragozin)
Subject: Cancel File Forces Discard of Remaining Files in C-Kermit 4C(057)
Keywords: C-Kermit

Setting: C-Kermit 4C(057) BSD version on VAX-11/7xx's under BSD4.2.
Problem: When receiving multiple files a Ctrl-F discards the current file, and
   all subsequent files in the same batch. (The transfer of each subsequent
   file is started, and then aborted with a discarded message.)

(I seem to remember a report of a problem of this sort a long time ago, but
find no mention in the .bwr file.  I have also reproduced the same behavior
between 4C(056) versions.)

[Ed. - Sure enough, it's a bug.  Will note this in the .bwr file and fix in
the next release.]

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

Date: 20-AUG-1985 10:29:51
From: [e-mail]
Subject: Bug in C-Kermit Line Locking
Keywords: C-Kermit

Forwarded message from Dave Osborne, Cripps Computing Centre, Nottingham U, UK

There is a bug in the the Version 7 unix version of the program. The
ckutio.c module, when opening the line (such as /dev/tty), in its
"ttopen" routine, does an 'ioctl' call with parameter TIOCEXCL, to hold the
line for exclusive use.  Unfortunately, it doesn't bother to
unset this condition before closing the line.

[Ed. - This is fixed in the current release.]

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

Date: 28-AUG-1985 09:58:17
From: [e-mail]
Subject: Bug Report For C-Kermit 4C(057)
Keywords: C-Kermit

   I've had a bug report passed to me from Icarus Sparry, Electrical
Engineering Department, Bath University UK.

Bug in C-Kermit 4C(057) and previous releases:

File CKCFN2.C, routine SPACK

If padding is in operation then it is inserted at the start of the packet
before the ^A, as well as at the end of the packet before the EOL. However the
values at the start of the packet are counted for the checksum, (except for the
first) and the ^A is also included in the checksum.

The workaround is to remember where the ^A is or to start the checksum after
npad+1 characters.

[Ed. - Oops!  You're absolutely right.  This will be noted in the .bwr file,
and will be fixed in the next release.  By the way, padding should only be
sent before the packet, not after the end before the terminator -- I have no
idea how that line of code got in there...]

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

Date: Wed, 4 Sep 85 16:42:51 cdt
From: Dave Rasmussen <uwmacc!uwmcsd1![e-mail]>
Subject: Problem Installing 4C(057)
Keywords: C-Kermit

I have the version that supposedly corrects the 68000 architectural bugs
mentioned by Frank da Cruz on Usenet, the one marked as: C-Kermit, 4C(057)
31 Jul 85, 4.2 BSD

When I tell it to "set line /dev/t1570" where t1570 is owned by uucp and mode
666, kermit just hangs there.  The problem is on a 68000 based Integrated
Solutions box running 4.2bsd.  I tried running as the superuser in case there
were any file conflicts, but this doesn't change things.

I do have this version running on a Vax 750 with 4.1bsd and it talks to remote
lines with no problems or other modifications.

Any suggestions, or anyone else had these problems? It may well be our
environment, but I think I've looked it over thoroughly.

Dave Rasmussen, CSD University of WI - Milwaukee

[Ed. - Can anyone with a similar system offer any advicde?]

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

Date: Tue, 3 Sep 85 18:22:15 pdt
From: [e-mail] (Dave Tweten)
Subject: C-Kermit Take File Control and Background Operation
Keywords: C-Kermit

When I read the contents of the current ckuker.bwr file, with particular
attention to the two items I have previously commented on, I noticed
someone had added editorial comment to each item indicating that this
message is necessary.  Though my original message, which included code,
also covered my reasons for the suggestions, I'll repeat the reasons
here.

     Some users report that it would be more desirable to have an error
     during execution of a take file return directly to command level,
     rather than pop to the invoking take file (why?).

Kermit has no flow-of-control commands to be used in TAKE files.  It is
therefore impossible to write a TAKE file which does something
intelligent if a file IT TAKEs should die.  The result of that fact, and
of the way the unmodified Kermit works, is that multiply nested command
files with an error at the bottom level die a slow and painful death,
wasting the user's time until they work their way back up to the top
level.  In background, this is particularly wasteful, since there is
noone to hit ^C to end the nonsense.

My proposal, which I have implemented at our site, is simply a matter of
euthenasia for terminal TAKE files.  Where the Columbia-issue command
processor closes the current TAKE file and pops one level, I have put in
a while statement which makes it keep closing and popping until interactive
command level is reached.

[Ed. - Actually, what is needed is a "set" command to control whether this
is done, with which users can "declare" some errors fatal and others not.
The DEC-20 Kermit script facility has something like this.]

     Some users report that the program should make no internal
     distinction between running in foreground or background (why?).

Release C-Kermit attempts to determine if it is in background by
checking if its parent has set SIGINT to SIG_IGN.  That is not a
completely reliable indicator of being in background, and furthermore,
why would it want to know if it is in background?

[Ed. - So it would know whether or not to issue messages to the user's
screen.  If in background, attempting to print a message to the screen
freezes the the process.]

The release version changes its behavior in a couple of ways as a
function of whether it thinks it is in background.  It sets several
signals to be ignored (which are ignored by default for background
anyway), and it decides to abort immediately on any command failure from
standard input (which prevents graceful termination of a remote server).
Incidently, this is the only way release C-Kermit generates a return
value of BAD_EXIT.

Because C-Kermit's changed behavior in background made it difficult to
debug scripts intended to run in background, I changed ours so it
doesn't try to be different in background.

Ours ALWAYS returns a status value on exit.  The status value is always
GOOD_EXIT if no commands have failed, and BAD_EXIT, otherwise.  That
makes it easy to debug a shell script which uses a while loop to retry
Kermit a number of times.  When a command from standard input fails, our
C-Kermit sets the eventual returned status value to BAD_EXIT and keeps
going, so later commands can gracefully shut down a remote server, if
any.

Over all, I believe our two changes have made C-Kermit much more
civilized, particularly when run from a script.  If Columbia would like
diffs for our changes, I would be happy to send a more recent set.

[Ed. - Dave has sent the diffs; does anyone else have any opinions on these
issues?  Meanwhile, I'll add a little more in the way of rationale to the
comments in the .bwr file.]

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

From: ihnp4!inmet!ada-uts![e-mail]
Date: 9 Aug 85 17:08:39 CDT (Fri)
Subject: C-Kermit on UTS vs the IBM 7171?
Keywords: C-Kermit, UTS Kermit, 7171 Protocol Converters

I am under the impression that the CMS version of Kermit knows how to talk
through the IBM 7171 protocol converter.  The 7171 allows ascii devices
(terminals or pc's running terminal emulation programs) to look to the IBM
host like an IBM 3270 type terminal.

We (at Intermetrics Inc 733 Concord Ave Cambridge Mass 02138) are running
UTS on a 3083 IBM host with a 7171 attached.  We would love to run a Kermit
that knew about the 7171 and was able to send files back and forth through
it.  So:

    * Is it true that the CMS kermit knows how to do this ?

[Ed. - Yes.]

    * If so, how hard would it be to add this capability to UTS Kermit ?

[Ed. - I believe Philip Murton at the University of Toronto
([e-mail]) has done this, or knows someone who did.  The
UTS code uses a different technique (escape sequences) than CMS Kermit
(CCW programming).]

    * Are there any plans to do so?

[Ed. - Philip, do you have this code for the current, or a recent, release
of C-Kermit?]

    * Would you like us to take a shot at it (and where do we go for
      help when we need it) ?

[Ed. - Let's see if/how Philip responds.  If we don't hear from him, we'll
try to dig up the code he sent us long ago for the old Unix Kermit.]

Thanks,

        Fred Mueller   [phone]

PS Thanks in general for devoting so much energy on such a worthwhile
   cause.  I hope you get lots of kudos for it.

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

Date: Sat, 7 Sep 85 02:49:35 edt
From: ukma!sean@anl-mcs (Sean Casey)
Subject: Exiting "Protocol Mode" Gracefully
Keywords: C-Kermit

I think that C-kermit should have some provision for completely aborting
the protocol from the terminal.  When one is trying to figure out which
parity, flow control, handshaking, etc. settings to use with new computer,
a considerable amount of time may be spent waiting for the local kermit to
give up on the transfer.  CTRL/F and CTRL/B are provided to abort a
transfer in progress, but there is no way to abort the protocol without
also exiting kermit (and losing dtr on the line). I'd like to see another
control sequence, perhaps CTRL/X, that would cause the local kermit to
immediately exit the protocol and give the command prompt.  Then, when one
is debugging a kermit conversation, the protocol could be easily aborted
as soon as the debugger sees that the two kermits aren't talking
correctly.

-  Sean Casey                        UUCP:   [e-mail]   or
-  Department of Mathematics                 {cbosgd,anlams,hasmed}!ukma!sean
-  University of Kentucky            ARPA:   ukma![e-mail]

[Ed. - I agree, this has been noted in the .bwr file for some time.  MS-DOS
Kermit has a couple options for this which are missing from C-Kermit.  They
should be added in future releases.]

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

End of Info-Kermit Digest
*************************
-------
12-Sep-85 18:40:09-EDT,17249;000000000001
Mail-From: SY.FDC created at 12-Sep-85 18:39:42
Date: Thu 12 Sep 85 18:39:42-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #18
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Thu, 12 Sep 1985       Volume 3 : Number 18

Today's Topics:

        Announcing LM-KERMIT for Lispmachine Lisp Environments
                     Kermit Diskette Distribution
           HP110 Kermit Binaries & MSIBMP.BOO Name Problem
       NEC PC8800 (not 8001), APC III, & other Japanese Kermits
                       Kermit and the Far East
          Kermit and the European Packet Switching Services
                 Kermit on X.25 and Similar Networks
                         Kermit over Networks
                        CMS Kermit with 7171's
           Behaviour of MS-Kermit 2.28 on a COMPAQ Portable
                 Kermit for Exxon Office Systems 500?
                  Kermit for Cromix and the NCR DMV?
                  MS-DOS Kermit for the Gavilan PC?

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

Date: Wed, 11 Sep 85 19:04:27 EDT
From: George J. Carrette <[e-mail]>
Subject: Announcing LM-KERMIT for Lispmachine Lisp Environments
Keywords: LM-Kermit, Lisp

                              LM-KERMIT
               KERMIT and terminal emulation capability
                   for ZetaLisp based lispmachines.

LM-KERMIT was implemented by Mark David of LMI (Lisp Machines Inc).  The
use of KERMIT on a lispmachine can fill the gap between sophisticated (and
expensive) networking hardware and software available on lispmachines and
the other extreme, NO NETWORKING.  What we found is that many mainframe/
minicomputer installations take a long time to purchase and install
something like ethernet TCP-IP, but that KERMIT shows up almost everwhere,
already installed or in some users directory.

There are presently available two versions:

* bundled with the LMI-LAMBDA. It supports terminal emulation, KERMIT,
  and serial connections via RS-232, TCP-IP (TELNET), etc. Also
  provided is a HOST/MAINFRAME emulation capability so that PC's
  can log into the machine and use SERVER mode.

* A port to the Symbolics 36xx machines done by Mark Ahlstrom of Honeywell.
  It supports terminal emulation, KERMIT, and serial connections via
  RS-232.

The source is conditionalized in the usual manner, #+LMI, #+SYMBOLICS.
There are a few #+TI conditionalizations although they have not been
tested. A user of the TI (Texas Instruments) Explorer should be able to
bring LM-KERMIT up by changing most of the #+LMI conditionalizations to
#+(OR LMI TI).

A word about the programming style used.  Don't expect anything exemplary.
Parts of the code are a quick hack off of KERMIT.C, and much of the window
system code is a mix of "doing while learning" combined with later added
sophistication and hair. Compiling the source gives style warnings of
various severities on both the LMI and Symbolics machines. However, the
number of phone calls I've been getting on this has forced us to either
tell people to go away or provide what we have now. The port that Ahlstrom
did to Symbolics Release 6.0 was also of the "conditionalize into the
source the equivalent Symbolics function name or feature" rather than the
other more slow route of "rewrite things to use mainline Common-Lisp
functions."

However, now that it is out people will no doubt be improving things.

-gjc

[Ed. - The files are in KER:LM*.*, available via anonymous FTP from CU20B.]

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

Date: Thu 12 Sep 85 12:43:33-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Kermit Diskette Distribution
Keywords: Kermit Diskettes

As anyone who has received a Kermit tape knows, bootstrapping the
microcomputer versions from the tape is a tricky, frustrating business.
It's even trickier if you don't have a computer with a tape drive.  To ease
the pain, we are preparing to make it easier for people to get Kermit
programs on diskette; we expect to be able to distribute IBM PC and Apple
Macintosh diskettes ourselves, and we'd like to compile a list of other
sources for diskettes or other "native media".

If you know of a user group or other organization that distributes Kermit
on native media for a particular system (e.g. a Heath-89 user group, a
TRS-80 user group, etc), please send me the information that would be
needed to order Kermit from that organization -- Address, pricing, order
number, etc, plus phone number (so I can verify the information and their
willingness to act as distributor).  Also, if you belong to a user group
that could be distributing Kermit but isn't, maybe you could submit it.
Individuals are also welcome to volunteer to distribute diskettes -- as
some already have been doing for the Apple II and Commodore 64 -- but when
addresses and ordering information are published, the demand might exceed
the ability of a single individual to meet it.

Of course, any person or group that distributes Kermit should not be doing
it for profit; the cost should be designed only to recover expenses for
media, postage, packaging, etc, plus a little margin to allow for expansion
when demand outstrips capacity.

P.S. If you can't reply by netmail, send it to me at

    Columbia University
    Center for Computing Activities
    612 W. 115th Street
    New York, NY  10025

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

Date: Wed 31 Jul 85 19:25:38-PDT
From: Jim Lewinson <[e-mail]>
Subject: HP110 Kermit Binaries & MSIBMP.BOO Name Problem
Keywords: HP110 Kermit

According to the documentation, KER:MSIBMP.BOO is supposed to be
MSIBMPC.BOO.  I suppose it got truncated to make it 6 characters, but
AAFILES.HLP should be updated.

[Ed. - Thanks for pointing this out, will change AAFILES.HLP.]

Also, you find an (old) .EXE file for the HP-110 MS-DOS kermit on
[SU-GSB-WHY] WHY:<KERMIT>MSHP110.EXE.  It is based on an old version of the
source code, and I'm not sure how well tested it is, but maybe it will help
someone more than nothing.  Maybe when I get back to the west coast I can
get someone working on rebuilding it with the latest sources.

                    Jim

[Ed. - Thanks.  The 8-bit binary .EXE file is now available as
KB:MSHP11.EXE, and a hex encoding (straight two-hex-digits per 8-bit byte)
is in KER:MSHP11.HEX.  There is also source and documentation which may or
may not correspond to the binaries in KER:MSXHPX.*.]

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

Date: Fri 6 Sep 85 22:33:03-PDT
From: Ronald Blanford <[e-mail]>
Subject: NEC PC8800 (not 8001), APC III, & other Japanese Kermits
Keywords: Japanese Micro Kermits, NEX PC8800 Kermit, APC III Kermit

The NEC 8001 Generic Kermit-80 patch had a slight error, not in the patch,
but that the machine is in fact the NEC PC8800.  I got confused by the
multiplicity of models I deal with.  (I don't believe there is an 8001.)

As for the offer of source for Japanese computer Kermits, the NEC PC8800
has been extensively sold in this country so that source may be useful.
The PC9800 is sold here (with differences) as the APC III, which supports
only MS-DOS, making a CP/M-86 Kermit of no use.  I don't know about the
other models mentioned.

I received an MS-Kermit system module for the APC III (MSXAPC3.ASM) from
someone at Virginia Tech (VPI&SU).  I haven't seen it included in your
lists, so I wonder if you ever got a copy.  It seems to work acceptably
with version 2.28.  I can make it available if you wish.

-- Ron

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

Date: Sat, 07 Sep 85 16:50:22 cet
From:  [e-mail]
Subject: Kermit and the Far East
Keywords: Japanese Micro Kermits

There are some Fujitsus and NECs over here in Germany.  I would appreciate if
you could put at least the MS-DOS version on CUVMA.

I have requested Mr. Murakami to send it direct, but I don't know, really if it
will work. (usenet-BITNET)

Eberhard W. Lisse

[Ed. - I tried too, but got mailer replies back with messages like "Too
many hops"...]

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

Date: Sat, 07 Sep 85 16:21:39 cet
From:  [e-mail]
Subject: Kermit and the European Packet Switching Services
Keywords: European Networks

I have no problems at all with the European packet switching service.
I have had no trouble on the Datex-P after setting both Kermits to

         SET PARITY EVEN

I have used the following hardware:

    IBM-PC     DOS 2.11 KERMIT 2.28
    OSBORNE 1  CP/M 80  KERMIT 4.05
    RAINBOW    DOS 2.?? KERMIT 2.26
    VAX 11/780 VMS 3.7
                   4.1  KERMIT 3.0.055
                               3.0.066.
    CYBER 175   NOS     KERMIT ???

    IBM         VM/CMS  KERMIT 2.??

( If I dial my BITnet host [the IBM] through Datex-P I have to set
  my local parity to even. I don't set anything on the IBM.

  If I do it from any machine through at the Technical University
  or from the University Hospital I have to set the local parity to
  MARK.

  This indicates that Datex-P forces the parity to EVEN.

  I can't get our PDP-11/44 RMS-X11M with the new KERMIT to file
  transfer.  CONNECT works, but now way of getting one single packet
  over to the IBM or back.  Doesn't bother me though, as I'm doing
  the file transfer with the VAX anyway due to a faster line.)

[Ed. - I believe newer versions of PDP-11 Kermit handle IBM communications
a little better.]

Same thing works for Telenet I am told by [e-mail] who
had a mail the other day.

Eberhard W. Lisse <[e-mail]>

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

Date: Wed, 11 Sep 85 11:15:18 BST
From: "Chris.K.Now-and-Then" <[e-mail]>
Subject: Kermit on X.25 and Similar Networks
Keywords: European Networks

     Peter Bendall's suggestion (infodig 16) of substituting BEL (07) for
SOH (01) as Kermit start-of-packet is an interesting kludge, but not quite
the canonical way of dealing with the problem (of how to work Kermit across
text-line-oriented networks).  Admittedly almost any (terminal) network will
pass BEL, for obvious reasons; but bridges, PADs etc. often feel free to
add BELs if they see fit.  What about a PAD which stuck a BEL into any
"overlength" line?

     I regularly Kermit large files over UK JANET, which uses XXX (X.3,
X.28, X.29) above X.25.  In normal terminal (line) mode, SOH will be
stripped.  The easy answer is to switch to character (transparent) mode, in
which case all control characters are passed through "as sent".  For XXX
this is in fact overkill, since there are parameters to specify which
control chars are to be passed; but it is straighforward and always
supported on the user interfaces; it also switches off local echo, which is
desirable.  In principle character-mode could result in Kermit packets being
sent as several blocks each; this does not in fact happen when using a
standard JANET PAD, due to the forward-on-timeout strategy employed.

     I believe that every terminal network protocol includes a transparent
mode, so the solution is generally applicable.

                                        Chris Kennington.

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

Date: Sat, 7 Sep 85 13:52:05 edt
From: Mike Ciaraldi <[e-mail]>
Subject: Kermit over Networks
Keywords: MILNEY, TELENET

Two messages in Info-Kermit digest volume 3, number 14 asked about file
transfers over Milnet and Telenet.  I haven't used either of these, but the
symptoms sound like a problem I have run into before.

Sometimes you are able to log on, start up Kermit on the remote machine, and
give it commands like "DIR" with no trouble.  But when you try to do a file
transfer your local machine just sits there until it times out, as if no
packets are being received either way.

When this has happened to me, I can usually get it to work by EXPLICITLY
setting the parity of both Kermits, local and remote.  Naturally, if your
communications channel (e.g. Telenet) enforces a particular parity (e.g.
even), you have to set the Kermits to match each other and the comm channel.

Parity being slightly off doesn't seem to affect commands like DIR, but file
transfers and other things that use packets cannot handle it because the
checksums, 8th-bit prefixing, and so on are thrown off.  Thus no packets get
through.

Mike Ciaraldi
ciaraldi@rochester
seismo!rochester!ciaraldi

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

Date: Tue, 10 Sep 85 09:03:52 EDT
From: ostrove@umd5 (Steve Ostrove)
Subject: CMS-KERMIT with 7171's
Keywords: VM/CMS Kermit, 7171 Protocol Converters

We are in the process of testing out our 7171's with CMS.  Although I haven't
done extensive testing, yesterday I transfered a 65K file using KERMIT-MS
on one side and KERMIT-CMS on the other (versions 2.28 and 2.01 respectively).
The transfer was using a packet size of 94 (default).  I had no problems.
It would seem therefore that the problem with packet size and TSO, may be
a problem unique to TSO and the 7171's.  I will attempt to do more extensive
testing of them soon.

On a different note.  When we put KERMIT-CMS into server mode, it does not
seem to respond to any terminating command with the exception of FINISH.
Neither LOG or BYE works.  Is this normal??

Sincerely,
Steve Ostrove
User Services Staff
The University of Maryland Computer Science Center
[e-mail]

[Ed. - Thanks for the information.  No, CMS Kermit is supposed to log itself
out upon receipt of a BYE request, and it does so nicely on our CMS system.
No one here can think of a reason why it would fail to do so.  Can anyone
else?]

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

Date: Mon, 9 Sep 85 13:40:34 BST
From: [e-mail]
Subject: Behaviour of MS-Kermit 2.28 on a COMPAQ Portable
Keywords: MS-DOS Kermit, COMPAQ Portable

     I have encountered a slight bios incompatability between a real IBM
PC/XT and a "Compatable" Compaq Portable.  In short, MS-Kermit v2.28 with
bug fixes as advertised in .BWR file work fine on the XT.  The problem,
however, is that when sending or receiving files, the Compaq displays a
blank inverse video mode line with a single spurious character ('s') above
the transfer status displays.  The mode line displayed during connection
appears normally.

     The information normally contained in this mode line is rather
important in that it gives the user information on how to abort an active
file transfer.  After some digging, I traced the problem to the routine
'putmod' in MSXIBM.ASM.  As I don't have documentation on the bios
interfaces I did a simple backout to the putmod routine in version 2.27.
Below are the affected lines:

Original version 2.28 code:
             call    poscur
             pop     si              ; get message back
     putmo1: lodsb                   ; get a byte
             cmp     al,'$'          ; end of string?
             je      putmo2
             mov     ah,14           ; write to screen
             mov     bx,07000h       ; inverse video, page one
             int     bios
             jmp     putmo1
     putmo2: ret                     ; and return
     putmod  endp

Version 2.27 backout:
             call    poscur
             pop     dx              ; get message back
             mov     ah,prstr
             int     dos
             ret
     putmod  endp

        This fix works fine for the COMPAQ.  On a real PC, however, the
information line is displayed in normal video.  At least this backout
provides the user with the necessary information in all cases.  Has anybody
else experienced this anomolous behaviour with a Compaq or have an
explanation for the incompatability?

                        -- Les J. Wu <[e-mail]>

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

Date: Fri, 6 Sep 85 15:19:48 edt
From: Bob Sutterfield <[e-mail]>
Subject: Kermit for Exxon Office Systems 500?
Keywords: Exxon Office System 500 Kermit

The secretary across the hall has recently been blessed with an Exxon Office
Systems 500 Series word processor.  It apparently crunches words nicely
enough, but its facilities to talk to the outside world are severely
limited.  It has some sort of asynchronous communications software, but this
won't do the job for us.

I don't know what kind of processor it has, nor what operating system it
runs.  We really need to get several hundred pages of publications off this
beast, and onto a usable machine.  Does anybody know of pointers to a Kermit
for this beast?

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

Date: Mon, 09 Sep 85 03:37:14 cet
From:  [e-mail]
Subject: Kermit for Cromix and the NCR DMV?
Keywords: Cromix Kermit, NCR DMV Kermit

Any information regarding Kermit for Cromemco Cromixor the NCR
Decision MATE V ?

Eberhard W. Lisse  <zdv626%djukfa11.bitnet%wiscvm.arpa>

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

Date: Tue, 10 Sep 85 14:08:18 PDT
From: [e-mail]
Subject: MS-DOS Kermit for the Gavilan PC?
Keywords: MS-DOS Kermit, Gavilan PC

A professor here has the Gavilan PC with the 3" drives.  Has anyone
successfully run MS-DOS Kermit on one of these, and if so, can we possibily
get a copy of the disk?

Thanks is advance,

Rich Fagen
Caltech Computing Support
[e-mail]
[e-mail]
(818)-356-3896

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

End of Info-Kermit Digest
*************************
-------
13-Sep-85 18:16:56-EDT,17716;000000000001
Mail-From: SY.FDC created at 13-Sep-85 18:16:20
Date: Fri 13 Sep 85 18:16:20-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #19
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri, 13 Sep 1985       Volume 3 : Number 19

Departments:

  MACINTOSH KERMIT -
    New Macintosh Kermit Bug List
    Macintosh Kermit VT100 Emulation Bottom-of-Screen Bug
    Garbage in Upper Left Corner on MacKermit
    MacKermit Comments
    MacKermit/ScreenSaver Incompatibility
    MacKermit Transfer Command
    Macintosh Kermit Key Configurator Limitation
    Mac Kermit Show-Response Window Too Narrow
    Bug and Nit in Macintosh Kermit
    Terminal Emulation Bug In Mac Kermit
    Double Keying Option-Keys in Mac Kermit
    Mac Kermit vs Yale ASCII

  IBM MAINFRAME KERMIT -
    Kermit for UTS with Series/1
    CMS Kermit with 7171's (two messages)
    Kermit-11 vs IBM VM/CMS

  MISCELLANY -
    Kermit Distribution in the UK


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

Date: Fri 13 Sep 85 17:24:56 EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: New Macintosh Kermit Bug List
Keywords: MacKermit

The following messages report bugs in the current release of Macintosh
Kermit, or suggest improvements.  These have been noted in the new "beware"
file, KER:CKMKER.BWR, which is available via anonymous FTP from CU20B.  For
now, no changes are being made to the program, mainly because Mac Kermit is
still "between maintainers".

Although not mentioned specifically in conjunction with Mac Kermit, the
C-Kermit bug reported by Icarus Sperry (Bath Univ, UK) in Info-Kermit V3
#17, namely that checksums are computed incorrectly if padding is selected,
applies also to Macintosh Kermit.

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

Date: Thu 15 Aug 85 11:12:12-CDT
From: Don Nash <[e-mail]>
Subject: Macintosh Kermit VT100 Emulation Bottom-of-Screen Bug
Keywords: MacKermit, Terminal Emulation

I just found found this simply wonderful bug in Macintosh Kermit.  Here's how
to do it:

        1)  Set MacKermit 0.8(33) for 9600 baud, no parity, remote echo.

        2)  Connect to a VAX 11/780 running VMS 4.1 and Eunice and log in.

        3)  Set your terminal type by having the following lines in your
            LOGIN.COM file:

                $define TERM "vt100"
                $set term /dev = vt100 /line

        4)  Type out a file which is long enough to fill the screen more
            once using the following command:

                type /page filename.ext

        5)  When you are prompted to hit return, type ^C.  The word "Cancel"
            should appear, but it should be partially below the screen.

        6)  Type <CR> several times.  If you get the same results I did, then
            the screen of the Mac should go crazy.  It looks like snow on a
            TV set, except that it is black snow on a white background (which
            seems logical, since the Mac's screen is white).  The Mac is now
            completely wedged, the cursor does not respond to mouse movements.
            The only way out is to reset the Mac and restart MacKermit.

Also, the number zero and the capital letter oh were identical on MacKermit,
and the same applies to the capital letter "I" (the letter after "H"), and
the lowercase letter "l" (the letter after "k").  They are also *exactly*
the same.
                                        Don Nash

[Ed. - Thanks, noted in the beware file.]

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

Date: Thu 15 Aug 85 12:25:26-CDT
From: Don Nash <[e-mail]>
Subject: Garbage in Upper Left Corner on MacKermit
Keywords: MacKermit

I read the file CKMKER.BWR.8.  In the section UNDIGESTED, item #3 said that
Dan Tappan from BBN reported garbage in the upper left corner of the terminal
emulator window which eventually went away.  I have the same problem, but
it won't go away.  It is nothing serious, but it does seem to be permanent on
my copy of MacKermit 0.8(33).  It does not interfere with the display in any
way.  Hope this aids in digestion.

                    Don Nash

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

Date:     Mon, 19 Aug 85 11:45:56 PDT
From:     [e-mail]
Subject:  MacKermit Comments
Keywords: MacKermit

I'm very pleased with the new MacKermit release.  I use it now in
preference to MacTerminal.  I like the speed:  both initialization and
operation are much better than MacT.  I have set up the key map to send
the right characters for EDT.  File transfer with VMS is very smooth.

- Martin Ewing

Comments on 0.8(33) Kermit for Macintosh:

SERIOUS

1. The VMS TYPE/PAGE command types a page of output from a file and
types "Type enter to continue" (or some such) in reverse video on bottom
line of screen.  If you ^Y at that point to terminate, Kermit writes the
next line ("Interrupt" in reverse video) on what appears to be line 25.
Kermit often dies shortly thereafter.  I don't have the exact character
sequence that VMS is putting out.

[Ed. - Same as Don Nash's bug.  Temporary workaround: don't use VMS
(just kidding...)]

NUISANCE

2.  Screen is not thoroughly wiped by erase screen command.  Garbage
characters left at right of screen (sometimes).  This may have been
documented before.

3.  A blinking cursor, or, better, a blinking solid cursor would be a
great help.  It's nearly impossible to find the underscore in a page
full of text.  A user-selectable cursor format would be preferable.

[Ed. - Good idea.]

SUGGESTIONS

4.  It would be handy to distribute a standard VT100/numeric keypad
definitions file.  This is important for running the VMS EDT editor.
I'll donate such a file if requested.

[Ed. - Please do.]

5.  Apparently the VT10x graphics characters are not emulated.  At least
the MONITOR command on VMS does not produce the desired line and block
characters.  This would be a useful addition for those of us who like to
stare at these status displays.

6.  Emulate the VT102 printer port commands.

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

Date: Thu, 8 Aug 85 10:14:02 mdt
From: [e-mail] (John De Vries)
Subject: MacKermit/ScreenSaver Incompatibility
Keywords: MacKermit

I have received a report that while making long uploads from MacKermit while
ScreenSaver (a desk accessory) is active will cause the upload to bomb and
will indeed screw up the Mac's system, necessitating a reboot. It happens
when ScreenSaver goes and blanks the screen...

Zoz

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

Date: Fri 9 Aug 85 16:55:15-EDT
From: Don Lanini <Us.Dcl@CU20D>
Subject: MacKermit Transfer Command
Keywords: MacKermit

Whenever I try to use the transfer command under the transfer menu to launch
an application from another disk (a disk other than the one Kermit is on), it
blows up the machine with an ID = 26 error and hangs.

The version is 0.8(32)

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

Date: Wed 19 Jun 85 16:30:52-EDT
From: Bill Schilit <[e-mail]>
Subject: Macintosh Kermit Key Configurator Limitation
Keywords: MacKermit

I just read a message on the net... you might want to configure a system
disk with the Dutch or German, or French international resources and check
out the results of this on MacKey...

I think the result will be an incorrect keyboard (check this out in
relation to the KEYCAPS display).  Since the key names are hard
coded in an array in the program...

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

Date: Tue, 9 Jul 85 18:43:58 edt
From: Mike Ciaraldi  <[e-mail]>
Subject: Mac Kermit Show-Response Window Too Narrow
Keywords: MacKermit

When you give a remote command (e.g. Directory) to a server, the results
come up in a window.  You can scroll the window from side to side, but even
if you move it all the way to the left (i.e. the little box in the
horizontal scroll bar is all the way to the right), you still can't see the
right end of the line of text.  You have to stretch the window to see it.

[Ed. - I agree this might not be intuitively obvious to the user...]

When you do a "Get file from server", after the transfer is complete the box
that keeps you informed of the progress of the transfer still stays on the
middle of the screen until you click on it.  This is not really obvious as
the way to continue.  What makes it bad is that the mouse pointer still
shows as the little clock face indefinitely, implying that you ought to wait
before proceeding (maybe while it closes the file or something).

[Ed. - Right, this has been noted in the .BWR file all along.]

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


Date: 23 Jul 1985 02:04 PST
From: Charles Carvalho <CHARLES@ACC>
Subject: Bug and Nit in Macintosh Kermit
Keywords: MacKermit

A friend pointed out a bug and a nit in the Macintosh Kermit:

bug: if you call SFGetFile with the numTypes argument equal to zero,
it apparently doesn't find all files; numTypes should be -1 instead.

[Ed. - From one of the authors: "I haven't noticed any problems, and I
believe the code reflects the documentation."  Has anyone actually observed
files being skipped over?]

nit: the Close box at the left of the MacKermit window doesn't do anything;
it ought to be left out (define the window with the NoGoAway attribute).

                        /Charles

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

Date: Wed 31 Jul 85 15:18:44-EDT
From: Ben Fried <UI.Ben@CU20C>
Subject: Terminal Emulation Bug In Mac Kermit
Keywords: MacKermit, Terminal Emulation

I don't know if i can reproduce this, but i definitely found a bug in mac
kermit 0.8(33)

I was in emacs, typing a command into the echo area, when a send came in.  the
first few scan lines of the text showed up at the bottom of the screen, then
it froze--i had mouse control, but the event handler must have frozen,
because i got no response to any sort of update event -- keydowns, clicking
the mouse, whatever.

it looks like it didn't handle the scrolling of the text i was sent correctly,
and died somewhere in there.  but i'm not sure.

[Ed. - "Doubt it was the event handler, more likely it is a scroll problem with
the characters being drawn off the screen."  Noted in .BWR file.]

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

Date:  Sat, 7 Sep 85 19:10 MST
From: Barry Margolin <[e-mail]>
Subject: Double Keying Option-Keys in Mac Kermit

I think I've figured out why certain characters have to be doubled in
order to send them in MacKermit.  These characters are normally set to
nonspacing diacritical marks.  For instance, Option-e is normally a
nonspacing accent grave.  In the normal Macintosh text input
environment, nothing gets sent until you type the next character after a
diacritical, so that it can send the appropriate accented character.  If
you type the diacritical twice, it sends just the diacritial character.
If you type a character that cannot be used with that diacritical, it
sends the diacritical followed by the character.  This is all consistent
with the behavior I have seen when I use the Option key as a Control
key.  I suspect that the same problems would exist if I used the Option
key as a Meta key, which I believe is the default.

[Ed. - This was also noted in the .BWR file that originally went out with
0.8(33).]

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

Date: Thu, 22 Aug 85 19:47:45 edt
From: Mike Ciaraldi <[e-mail]>
Subject: Mac Kermit vs Yale ASCII

We just started using MacKermit to talk to our IBM 4381, which uses a Series
1 front end with the Yale Ascii package.  On the other end we installed the
version of TSO Kermit from U of Toronto.

File transfers work OK, it seems.

Big problem with terminal emulation.  The packages we use on MVS use lots of
boldface.  The CKMKER.BWR file says that boldface characters are the wrong
size, but for us it's worse than that.  The cursor proceeds along, putting
stuff on the screen, then skips back and erases several characters, leaving
a series of gaps in the line of text.  If you open up a window over the
affected area, then close it again, the text is OK.  It's not in boldface,
but it is perfectly readable and in the right place.

[Ed. - The problem is still probably due to the characters being a different
size from what they program thinks they are.  Some IBM/Yale-ASCII sites have
found the problem so annoying that they define a new terminal type for the
Macs, which is basically a VT100 without boldface.]

We tried opening up the SHOW RESPONSE window, stretching it to almost fill
the screen, then switching back and forth between it and the main window to
force refreshing of the screen image in the main window.  This works, but
the lower right corner of the SHOW RESPONSE window is "dead", i.e. clicking
on it will not bring the window to the front.  The dead area is the part
where the size-changing icon usually appears.  When the main window is in
the background, there doesn't seem to be this problem getting it back.

Mike Ciaraldi
ciaraldi@rochester

[Ed. - Mike mentioned in a subsequent message that they would try to come up
with a fix for the boldface problem.]

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

Date: 12 September 1985, 15:31:45 EDT
From: Philip Murton <[e-mail]>
Subject: Kermit for UTS with Series/1

We are no longer running UTS under VM here so that only version
of Kermit for UTS I have is based on the old UNIX Kermit.

[Ed. - This is the KERMIT.C from the Protocol Manual, with modifications
to support the Series/1, presumably it will also work with the 7171, 4994,
and other systems that run the Yale ASCII package.  I've put it in
K2:UTSS1.C on CU20B.]

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

Date: Fri, 13 Sep 85 02:07:01 EDT
From: Peter DiCamillo <CMSMAINT@BROWNVM>
Subject: CMS Kermit with 7171's

I can confirm Steve Ostrove's experience that CMS Kermit through the 7171
does not log itself out, and only responds to FINISH.  Even with FINISH, CMS
Kermit doesn't respond with "R;" until after I enter a carriage return back
in the terminal session.

From what I have heard, the packet size problem with 7171s is a performance
problem which only shows up when a 7171 is loaded.  If Steve was testing
with only one or two users on the 7171, then a larger packet size would
work.  I haven't had a chance to confirm this myself yet.

Kermit should be able to distinguish a Series/1 from a 7171 because a
Series/1 emulates a 3277 terminal, but a 7171 emulates a 3278 terminal. This
device type information is available to a program by using DIAG X'24' to
obtain information about the virtual console.

Peter DiCamillo

[Ed. - Can anyone provide a clue as to why CMS Kermit might refuse to log
itself out when run from a 7171, but log out OK when run from a 3705???]

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

Date: 13 September 85 14:35 EDT
From: [e-mail]
Subject: CMS Kermit and 7171s

The problem with Kermit (CMS at least, and I expect the same with TSO) and
7171s should only show up if the 7171 can not field the incoming characters
as fast as they are sent. This forces the 7171 to use a 64 character long
circular type ahead buffer. Once this buffer fills up the 7171 will not
accept further input until the buffer starts to empty.  As long as a set of
8 terminal ports is not 'over worked' it should be able to handle input from
a terminal at 9600 baud. It is only when more than one of the terminals on a
set of 8 ports is sending large data buffers at high data rates that there
will be overrun problems. I do not know at what data rates or how many
active terminals it takes to actually cause the problems, but 1 terminal at
9600 baud (plus the rest doing normal terminal type output traffic, not file
transfer) should not exhibit the problem. This problem has been discussed
with the IBM development team for the 7171. Personally I doubt that the
problem will be corrected in future versions of the device as it appears
that IBM does not intend to have the device support file transfer, but
rather to support attachment of dumb-terminals only.

":-)" Nick Gimbrone <[e-mail]> [phone]

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

Date: 13 SEP 85 07:39-EST
From:  [e-mail]
Subject: Kermit-11 vs IBM VM/CMS

The most recent Kermit digest had a comment regarding Kermit-11 and CMS.
Here is an explanation (?)

I should point out that Kermit-11 has never worked well with CMS  Kermit
(before  the  S/1  support) as the U of Toledo does not use standard IBM
half duplex lines, thus making testing impossible. The  controller  here
is  a  CCI  which  fakes  a FDX link. Kermit-11 does, however, work fine
with the S/1 support in the newest CMS kermit, as long as one  remembers
to set parity to anything other than the default, none.

brian nelson

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

Date: 10-SEP-1985 10:39:01
From: [e-mail]
Subject: Kermit Distribution in the UK

Lancaster University (UK) have just installed Columbia tapes written there
on August 3. The files are all online on a VAX 11/780 and can be accessed
freely by anyone who wishes using NIFTP or KERMIT. We can also send out
files on 9 track tape, and on floppy for some versions. The collection is
regularly updated with new tapes and files pulled from cu20b direct. For
details mail to Alan Phillips, SYSKERMIT @ LANCS.VAX1 (JANET address
000010404000.FTP.MAIL, or PSS address 23425240101.000010404000.FTP.MAIL), or
phone [phone] x 4881. Distribution is free to all educational
establishments: a small handling charge is made to commercial users.

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

End of Info-Kermit Digest
*************************
-------
20-Sep-85 17:58:08-EDT,14460;000000000001
Mail-From: SY.FDC created at 20-Sep-85 17:57:35
Date: Fri 20 Sep 85 17:57:35-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #20
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B

Info-Kermit Digest         Fri, 20 Sep 1985       Volume 3 : Number 20

Departments:

  ANNOUNCEMENTS -
    Kermit Available for Os9
    Commodore 64 Kermit V1.7 Available
    NEC APC III Kermit Available

  IBM MAINFRAME KERMIT -
    CMS Kermit Server Logout Problem Solved
    CMS Kermit 2.01 Init File Problem

  MISCELLANY -
    Kermit Diskette Distribution
    Kermit Diskette Distribution in UK
    Kermit-11, P/OS, and TMS
    Problem with C-Kermit on IS 68000 Q-Bus System with 4.2BSD
    C-Kermit on Xenix on PC/AT?
    C-Kermit for SUN on 1/4" Tape Cartridge?
    MacKermit Beware Addition
    Apple Kermit & CCS Card
    Kermit as Mail Server?
    Kermit for Victor 9000?
    Octopus / Flex Kermit?

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

Date: Wed 18 Sep 85 00:57:23-PDT
From: [e-mail]
Subject: Kermit Available for Os9

Os9 kermit is ready for distribution.  It is based on old Unix Kermit, and
also has limited server functions.  Read the .doc, .hlp, and .bwr files for
known limitations.  (It should work on all os9 versions, but connect mode
has a problem with the CoCo bit banger port.)

I am willing to make a "s" format (hexadecimal) file available, but due to
numerous compile time options, its usefulness would be limited.

Bob Larson <[e-mail]>
UUcp:  ihnp4!sdcrdcf!oberon!blarson

[Ed. - The files are available for anonymous FTP from CU20B as KER:OS9*.*.]

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

Date: 8 Aug 85 10:02:53 EDT
From: Eric <[e-mail]>
Subject: Commodore 64 Kermit V1.7 Available

C64 Kermit V1.7(52) is ready for release. The new edits are bug fixes to the
command parser that screwed up the disk commands, a fix to make 1200 baud
file transmission work at a full 1200 baud, and a fix to the ASCII/PETSCI
conversion tables. All fixes were done by Frank Prindle (Prindle@NADC).

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

Date: Thu 19 Sep 85 18:40:42-PDT
From: Ronald Blanford <[e-mail]>
Subject: NEC APC III Kermit Available

Here is the MSXAP3.ASM module for the NEC APC III.  I have only used this
briefly once, but as far as I can tell it does not implement keyboard
redefinition, does not implement any type of terminal emulation, and only
works with the standard serial port.  Terminal mode does not have backward
paging.

The author is RAL from Virginia Polytechnic Institute, more than that I
don't know.

-- Ron

[Ed. - Thanks, Ron.  The source file is in KER:MSXAP3.ASM on CU20B.]

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

Date: Tue, 17 Sep 85 00:19:12 EDT
From: Peter DiCamillo <CMSMAINT@BROWNVM>
Subject: CMS Kermit Server Logout Problem Solved

I think I've figured out why CMS Kermit doesn't log itself out correctly
through a Series/1 or 7171.  There are two problems.  First, when CMS
Kermit sends an ack to the logout or finish command, it uses transparent
write/read, as if it expected a response.  The micro doesn't send a
response, which I believe matches the Kermit protocol, so the user
has to complete the read.  The following update to CMS Kermit corrects
this problem by sending the final ack with just a transparent write:

./ R 00846000       $ 846290 290                   09/16/85 22:44:58
         DC     X'40',AL1(SBA),X'5D7F',AL1(SBA)             UPDATE1  00846290
S1ORDAD  DC     X'0001'             addr. -> 0 for write    UPDATE1  00846580
./ I 01601000       $ 1601500 500                  09/16/85 22:44:58
         XC     S1ORDAD(2),S1ORDAD  just write when ending  UPDATE1  01601500
./ I 02869000       $ 2869300 300                  09/16/85 22:44:58
         CLC    S1ORDAD(2),=H'0'    was write/read done?    UPDATE1  02869300
         BE     SPRET               no: return now          UPDATE1  02869600

             ^
[Ed. - I've removed some spaces so this will fit on the screen.]

The second problem affects only the logout command.  Before issuing the CP
LOG command, CMS Kermit uses the sequence of WRTERM and WAITT to send an XON
to the micro and wait for the write to complete.  However, if the console is
a Series/1 or 7171, CMS Kermit's own console interrupt handler is still in
control, so CMS hangs when the WAITT is executed.  Also, to send an XON in
this case would require another transparent write, since WRTERM cannot send
control characters through a full-screen interface.  The following update
solves this problem by bypassing the calls to WRTERM and WAITT for Series/1
and 7171 connections.  It seemed safe to skip them since they weren't
working in this case anyway.

./ I 01607000       $ 1607300 300                  09/16/85 22:44:58
         TM     S1FLAGS,ISS1        Is console a S/1?       UPDATE2  01607300
         BO     SERVLOG             Yes: skip line mode I/O UPDATE2  01607600
./ R 01611000       $ 1611490 490                  09/16/85 22:44:58
SERVLOG  LA     1,=C'LOG'                                   UPDATE2  01611490

These updates are for CMS Kermit Version 2.01, and assume serialization
starting at 1000 with an increment of 1000.  I've tested them with success
on both a Series/1 and a 7171.

Peter

[Ed. - Thanks, Peter -- I've included your message in CMSMIT.BWR until the
next release comes out.]

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

Date: Wed, 18 Sep 85 9:11:17 BST
From: Andrew J Cole <[e-mail]>
Subject: CMS Kermit 2.01 Init File Problem

CMS Kermit 2.01 works very well with one small exception (non-feature?).
If server mode is entered directly from the CMS command line Kermit seems
to fail to read the KERMINI files.

Many thanks for such a useful system for a real pig of a system!

[Ed. - Thanks for the report; it's been added to the .BWR file.]

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

Date: Tue, 17 Sep 85 11:47:16 EDT
From: [e-mail]
Subject: Kermit Diskette Distribution

I'd be willing to distribute Macintosh Kermit at RPI if you send me a copy
on diskette. There aren't many Macs at RPI, but there are a few. We support
Kermit on several mainframes on campus, and distribute it for IBM PCs and
some compatibles.

  Don Porter
  Assoc. Dir., Information Technology Services

[Ed. - I got a lot of responses like this to my query about Kermit diskette
distribution.  I guess I wasn't clear enough...  What I'm looking for are
organizations or individuals willing to distribute Kermit on diskette in some
particular format to the general public, e.g. by mail order, not just within
their own organizations.  I haven't received reports of any of these.  Can
anyone tell me about, say, Heath or Atari or Apple or ... user groups that
provide this kind of service, like PC SIG does for the IBM PC?]

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

Date: 19-SEP-1985 11:17:29
From: [e-mail]
Subject: Kermit Diskette Distribution in UK

  Lancaster University is able to distribute some KERMITs on native media. We
can currently handle Aculab Z80B, Sirius 1 (CP/M-86 and MS-DOS), BBC micro,
DEC Rainbow (CP/M-86) and IBM PC. We also maintain a freely accessible
contact list of other UK native media suppliers for machines we don't have,
and can broadcast enquiries to the UK Kermit community at large.
  Distribution is free in the UK to educational users, but there's a small
handling charge for others: we don't supply the discs ourselves. Interested
users should contact me BEFORE sending discs, to check availability.
  The service is one person, so response might be a few weeks, especially if I
have to pass discs on to others who actually own the machines.
  We are willing to co-ordinate supply in the UK : anyone who wishes can be put
onto our contact list if they let me have details.

              Alan Phillips
                Department of Computing
                  Lancaster University UK

E-mail to     SYSKERMIT @ LANCS.VAX1
JANET address 000010404000.FTP.MAIL
PSS   address 234252400101.000010404000.FTP.MAIL
Telephone  to 0524-65201x4881

(I cannot reply over UUCP and only unreliably over ARPA)

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

Date: 18 SEP 85 12:11-EST
From: [e-mail]
Subject: Kermit-11, P/OS, and TMS

I may interest you to know that someone is adding to Kermit-11 for P/OS
to support TMS.  I, as is often the case, will be unable to test such as
I do not hav TMS on the PRO but it does sound like the mods to Kermit-11
should be quite minimal.

brian

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

Date: 18 Sep 1985 1046-PDT (Wednesday)
From: Paul Graham <unr70!unrvax![e-mail]>
Subject: Problem with C-Kermit on IS 68000 Q-Bus System with 4.2BSD

A nearby site using an Integrated Solutions (IS) q-bus 68000 board under
4.2bsd has been unable to get Kermit to open the phone line.  Monitoring the
line shows behavior similar to cu and tip when the the line is first opened
(some lines are pulsed briefly) but after that kermit hangs.  It works in
remote mode just fine.  Anybody out there using an IS system successfuly?

Thanks for your time.

Paul Graham 702/784-6007
University of Nevada Reno
ucbvax!decvax!seismo!unr70!unrvax!pjg
unr70!unrvax!pjg@seismo[.CSS.GOV|.ARPA]

[Ed. - There seems to be a lot of this going around, see below...]

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

Date: Fri, 20 Sep 85 15:15:11 edt
From: [e-mail] (Young Etheridge)
Subject: C-Kermit on Xenix on PC/AT?

Am encountering problem with "connect".  After connecting /dev/tty00
to a null-modem line, then "set line /dev/tty00" followed with
"set baud 4800" then "connect", results in a deadly silence thereafter.

The communications channel is okay since "cu" works as advertised.

[Ed. - Can anyone who has this working offer some tips?]

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

Date: Mon 16 Sep 85 13:41:12-EDT
From: Frank da Cruz <[e-mail]>
Subject: C-Kermit for SUN on 1/4" Tape Cartridge?

Anyone willing to provide a working C-Kermit program for the SUN with 4.2BSD
on quarter-inch tape cartridge, please contact

    Peter Hiscocks
    416-979-5000 x6109
    Center for Advanced Technology (Ryerson Polytech), Toronto

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

Date: 19 Sep 85 20:05:07 CDT (Thu)
From: ihnp4!islenet![e-mail]
Subject: MacKermit Beware Addition

Minor addition to your Mackermit BWR file: when a Settings file is saved,
it does not store the Command-Shift-1...Command-Shift-9 flag, so we have
to set it every session if we want it active.

[Ed. - Thanks, I've added it.]

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

Date: Fri, 20 Sep 85 11:19:17 BST
From: Chris_K_Now-and-Then <[e-mail]>
Subject: Apple Kermit & CCS Card

     This note has circulated in UK.  It's obviously of general interest,
so I send if on to you.
                        Chris Kennington.
  Date: Wed 18 Sep 85 19:40:36-GDT
  From: Alan Greig <[e-mail]>
  Snail-Mail: Computer Centre / Dundee College of Tech / Dundee / Scotland

On the subject of Kermit for various Apple serial cards, the most notable
ommision (to my mind anyway) is the lack of support for the California
Computer Systems Card (CCS) which seems to be almost universely used in the
UK. At DCT we added support for this card to the sources and as we have
CROSS can provide hex files with this change. The original changes were made
by Colin Bruce ([e-mail]) who has now left to work with Data
General and involve only a few additions to some tables. The only known bug
is that the the card needs to be specifically reset by sticking some value
in its command register before running Kermit. (PR#n,IN#n RESET will do
this). This initialisation could/should really be inside apple kermit but
I've never got round to recompiling it.

Anyway it works and if anybody wants it let me know or I can send down
the changes to Lancaster.

            Alan Greig
             ([e-mail])

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

Date: Thursday, 19 September 1985  10:05-MDT
From: <crash![e-mail]>
Subject: Kermit as Mail Server?

I've seen several messages lately about people allegedly using Kermit as a
mail gateway to Unix systems.  Do you know how that is being done?  Seems
like there would have to be a lot more Kermit than I've ever seen to
accomplish it.  The implications are that of an almost uucp-like server.

Enlighten me, please?

--Bill

[Ed. - It is possible to run a Unix Kermit server as a login shell; OK
State is doing this.  Presumably, you can then have other systems dial it
up, transfer queued mail to it, and then issue the appropriate "remote
host" command to it to deliver the mail.  I don't know if anyone is actually
doing this -- is anyone???  However, I have heard of Kermit servers being
used as print spoolers, etc.]

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

Date: Friday, 13 September 1985  14:40-MDT
From: hao!nbires!isis!galon![e-mail]
Subject: Kermit for Victor 9000?

A friend has a Victor 9000 and is trying to talk with some IBM PC's.

I've been trying to get him a suite of Kermit Programs but todate have
been unsuccessful.  A tape won't do him any good and I haven't found
it on floppies.  I did locate it at Okstate, but was unable to pull it
using their uucp instructions either in kermit-a or kermit-b
directories.

Anyone knowing of or having a copy please contact me via email.

Thanks.

Pat Gallivan @                   UUCP: ..!seismo!hao!nbires!isis!galon!fmg
Galon Exploration, Inc.
7122 S. Fillmore,                       [phone]
Littleton, CO  80122             Data:  [phone]

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

Date: Tue, 17 Sep 85 17:26:34 BST
From: Chris_K_Now-and-Then <[e-mail]>
To: [e-mail]
cc: [e-mail]
Subject: Octopus / Flex Kermit?

Kermiteers:
     Anyone working on Kermits for either Octopus or Flex
machines?  Both wanted in the UK.
     Reply to "cjk@ucl-cs", a valid arpanet address.
                                        Chris Kennington

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

End of Info-Kermit Digest
*************************
-------
24-Sep-85 17:48:54-EDT,18487;000000000000
Mail-From: SY.FDC created at 24-Sep-85 17:48:17
Date: Tue 24 Sep 85 17:48:17-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #21
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Tue, 24 Sep 1985       Volume 3 : Number 21

Departments:

  ANNOUNCEMENTS -
    Kermit for QNX
    Kermit for Intel System 86/380 with iRMX-86
    Kermit for HP-1000 A-Series with RTE-A
    Kermit for Zilog System 8000 Zeus (Sys V)
    Kermit for the HP Integral PC
    Update of Fujitsu Micro-16s CP/M-86 Kermit

  UNIX KERMIT -
    Kermit for UUCP Mail
    Changes to C-Kermit 4C(057)
    Bug Fix for C-Kermit User Interface
    C-Kermit on Masscomp Systems?

  MS-DOS KERMIT -
    Problem with Sanyo 555 Kermit
    MsKermit Linking Idea

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

Date: Mon, 23 Sep 85 13:14:33 edt
From: Frank da Cruz <fdc@cucca>
Subject: Kermit for QNX

A version of Kermit for the Quantum Software QNX operating system has been
contributed by Anthony J. Starks, Merrell Dow Research Institute,
Indianapolis IN; although he doesn't mention what system it's supposed to
run on in his transmittal letter, I believe it's for 8088-based systems like
the IBM XT or AT and/or the DEC Rainbow.

The program based on the "old" Unix Kermit, but the QNX-specific support is
sufficiently different from any other Unix code I've seen that I've
installed it as a separate set of files, rather than attempting to merge it
with C-Kermit.  The files are in KER:QNX*.* on CU20B, available via
anonymous FTP.

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

Date: 23 Sep 85 13:44:04-EDT
From: Frank da Cruz
Subject: Kermit for Intel System 86/380 with iRMX-86

This is to announce Kermit for the Intel System 86/380 running iRMX-86,
written by Albert J. Goodman, Grinnell College, Grinnell, Iowa.  The program
is written in PL/M-86.  The source files (including built-in help) are
concatenated together into the file KER:I86KER.PLM, and a short external
help file is included as KER:I86KER.HLP, available from CU20B via anonymous
FTP.

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

Date: Mon 23 Sep 85 13:46:33-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Kermit for HP-1000 A-Series with RTE-A

Announcing Kermit for the HP-1000 A-Series with RTE-A, written in
Pascal/1000, contributed by Tor Lillqvist, Technical Research Centre of
Finland.  Here is his cover letter:

This is a Kermit implementation for the HP1000 A-series machines running the
RTE-A operating system (HPAKermit). It will probably also work on the older
E-series machines running RTE-6/VM.

The file HPAKERMIT.SRC is a large text file into which is merged all the
source files needed to build HPAKermit (just to keep the number of files
down).

HPAKermit is written in the Pascal/1000 dialect. (A note to Pascal purists:
this has many "useful extensions" which makes it more suitable to "Real
Programming", but of course removes any chance of an easy port to some other
Pascal system.) I would certainly prefer 'C', but the 'C' compiler for
HP1000 seems rather oldfashioned, and in any case, we don't have it.
HPAKermit must be compiled with the Pascal/1000 compiler of revision 2410
(or later).

HPAKermit is based on the (old) Unix Kermit, and has only basic features
(Send, Receive and Get). Connect mode is missing, as it is very hard, maybe
impossible, to implement successfully on a HP1000. Server mode is also
missing, but that is only a "Not-Yet-Implemented" issue.

HPAKermit has been tested extensively with MSDOS-Kermit version 2.27 and
HP3000 Kermit.  Using 9600 bps and an IBM PC/XT a transfer rate of 470
chars/s is achieved.

Best regards,

Tor Lillqvist
Technical Research Centre of Finland
Lehtisaarentie 2 A,
SF-00340  HELSINKI, FINLAND

Phone:  [phone]
Telex:  122972 vttha sf

I have no net address, but you can reach me through a friend of mine:
mcvax!hut!jtv

[Ed. - The files are in K2:HPA*.*, available via anonymous FTP.]

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

Date: Mon, 23 Sep 85 12:43:29 edt
From: Frank da Cruz <fdc@cucca>
Subject: Kermit for Zilog System 8000 Zeus (Sys V)

I received a tape from Mark E. Sunderlin, Internal Revenue Service,
containing C-Kermit 4C(057) revised to include support for the Zilog System
8000 with Zeus 3.20 and later.  This will appear in the next release.
Meanwhile, if anyone can't wait, the trick seems to be to build it for
System III/V ("make sys3") in the normal way, but first change all
occurrences of "setjmp" to "setret" and "longjmp" to "longret".  This might
be accomplished in the makefile without changing the program source by doing
something like...

zilog:
    make wermit "CFLAGS = -DUXIII -Dsetjmp=setret -Dlongjmp=longret -i" \
    "LNKFLAGS = -i -w"

(and also including -DDEBUG, -DTLOG, -O if desired); no one has tested doing
it this way, but the same trick works for some of the other systems.

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

Date: Mon, 23 Sep 85 12:43:29 edt
From: Frank da Cruz <fdc@cucca>
Subject: Kermit for the HP Integral PC

I received a tape from Robert Raymond of TransEra Corp, Provo Utah, with a
version of Kermit for HP Integral PC.  It's based on the old Unix Kermit,
but a cursory inspection of the code suggests that he's simply added System
V support to it.  Can anyone verify that the present C-Kermit runs on the HP
Integral via "make sys3"?  If so, I'll simply include that system on the
list of those supported by C-Kermit; if not, I'll be glad to make Robert's
code available to anyone with an HP Integral who would like to adapt it to
the current C-Kermit.

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

Date: Mon, 23 Sep 85 12:43:29 edt
From: Frank da Cruz <fdc@cucca>
Subject: Update of Fujitsu Micro-16s CP/M-86 Kermit

This fixes an error in baud rate setting/selection.  Submitted by the
original contributor, Chris Barker, WRIST Inc, Long Island City, NY.  The
source file is in KER:C86XFJ.A86.  Would anyone on the net would care to
build and test the result and supply a hex (.H86) file?

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

Date: Sat 21 Sep 85 14:35:52-EDT
From: Bdale Garbee <[e-mail]>
Subject: Kermit for UUCP Mail

I haven't finished doing it yet, but I am one of the people using/planning
to user Kermit on a UUCP host to move mail to other places.

The system in question is an Intel 86/330 running Xenix V2.2N, currently
working on getting implementation-specific bugs out of the latest C-Kermit.
More details when I'm done.

The idea is very simple.  Just create a user on the Unix/Xenix system named
something like 'kserver'.  Then build a .login or .profile for that user in
that user's home directory that fires up kermit in server mode, and then
terminates the process and hangs up when kermit exits.  A remote machine
that wants to do file transfer, either of UUCP mail or anything else, just
dials in, logs in as user kserver, and issues the appropriate kermit server
commands.  When done, he issues a server terminate command, which causes
Kermit on the Unix box to exit and kill the process... which should also
hang up the phone.

Using cron and shell scripts makes for easy packing and unpacking of bundles
of mail to/from the UUCP mail directory.  The remote system just has to have
a similar sort of batch facility to use to do the dialup.

Bob Hartman of ...!vaxine!spark!bob fame is using this technique to
implement a UUCP/Fidonet bridge.  I'm working on duplicating and then
expanding his work.  Will pass along details when it works, and would
be most interested in talking to other people who have this sort of
thing working, or want help on making it work...

Bdale Garbee
arpa: [e-mail], soon to be [e-mail]
uucp: ...allegra!pitt!rensys!bdale

[Ed. - Thanks for the news.  You may be interested in a customized Unix
Kermit server that they run at OK State as a login shell if you dial a
certain number -- have you been in touch with them...
vasoll%okstate.csnet@csnet-relay?  Of course, none of this addresses the
real questions of mail since (I assume) you're just sending mail in batch
mode and not control information in interactive messages, like SMTP would
do.  How do you handle the various situations that SMTP or UUCP would
handle, like bad routing information, can't connect to host, no such user,
etc etc?]

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

Date: Mon, 23 Sep 85 14:06:51 pdt
From: Ken Poulton <hpl-opus![e-mail]>
Subject: Changes to C-Kermit 4C(057)

[Ed. - Ken Poulton has submitted code for the following changes to C-Kermit.
Some of them are obviously desirable, some are in "sensitive" areas (where
opinions are divided); I'd like to solicit a concensus in these areas, if
possible.]

Fixes for HP 9000:
    added "make s500" which does the things formerly listed in the make file
    added code to disable HP's enq-ack handshaking (#ifdef IENQAK) in connect

Connect:
    changed use of XON/XOFF slightly (now it works like BSD, and better
    with HP terminals)

Set Handshake:
    now turns off XON/XOFF (-t already does this)

!
    merged ! and other uses of fork to call new routine zexecl in ckufio
    zexecl does an exec, using 1) the shell defined by environment variable
    SHELL, if any, or else 2) the user's login shell from /etc/passwd, or
    failing that, 3) /bin/sh.

[Ed. - I guess this is better than the current method, which ignores the
SHELL variable because some Unix systems do not set it automatically.]

control chars
    added conchr to ckutio and changes in ckucmd to support using the
    user's predefined control characters as he expects
[Ed. - Seems like a good idea, assuming the method used works for the
systems the program tries to support.  For Sys III/V, it does
ioctl(0,TCGETA,&x), and then sets the interrupt, character delete, and
line delete characters to x.c_cc[0], x.c_cc[2], and x.c_cc[3] respectively;
for all others it does gtty(0,&x) and ioctl(0,TIOCGETC,&y), and sets
interrupt, chardel, linedel to y.t_intrc, x.sg_erase, and x.sg_kill.  In
the first case, x is a struct termio; in the second, x is a struct sgttyb
and y is a struct tchars.  How many systems will this break?]

    added code for VENIX11 to turn off driver's recognition of these
    characters.  Most Unices (BSD, SysIII, etc) do this anyway in raw mode.

[Ed. - I've heard reports about this before, but never saw this behavior
in Pro/Venix, which I thought was the same.]

prompt
    settable with -DPROMPT=

startup files
    1) ./.kermrc   2) ~/.kermrc   3) /usr/local/lib/kermrc
    settable with -DKERMRC (as before) and -DSYS_KERMRC
    Note that order of first two is intentionally changed

[Ed. - This looks like a touchy one.  First, it might be argued that most
people would like the program to behave consistently, no matter what
directory you're connected to.  Second, if there is to be a "system-wide"
startup file, does everyone agree that it should be in /usr/local/lib?
Third, the program searches for the startup file as above, and executes the
first one it finds.  Maybe it should execute all of them?  If there is to
be a system startup file, should the program ALWAYS execute it?  Should
there be user-selectable options to specify the order in which startup files
are executed, and how many???  How to explain all this to users?]

eXIT command
    added eXIT command - allows leaving Kermit w/o unlocking or dropping line
    added ttnohu to close the tty w/o hangup
    creates ~/UNLOCKttyxx to remind user
    EXIT deleted to avoid confusion
    (maybe this should be disabled on BSD systems as not needed)

[Ed. - This is the most controversial area of all.  First of all, case-
sensitive commands are not in the spirit of Kermit.  Second, giving the
user the power to lock a line permanently might be fine on a small friendly
system, but not on a big one with many users.  The risk of a user leaving
a line locked (intentionally or not) is much higher with this method, and
the inconvenience to other users must be weighed against the advantages
of doing this.  Opinions?  (Here we go again...) ]

scripts
    commented out most of the messages
    user can use echo to write messages if he *wants* to

[Ed. - Opinions from script command users?]

#
    added comment command
    for documenting scripts
    (done with % by 4C(057))

[Ed. - I used "%" for this to avoid confusion with shell scripts.]

locking
    now accepts existing lock files owned by the user (to support eXIT)

[Ed. - This is probably not a bad idea, when it works...  But some sites
keep the locks directory write-protected (or even read-protected), and
other sites want to run Kermit, UUCP, CU, TIP, etc, set[ug]id'd, so there's
no good way to tell for sure whose lock file it is.  I truly believe that
"lock files" are the WORST thing about Unix...  It continues to amaze me
that the system was designed NOT to give exclusive access by default to
serial devices automatically upon open().]

VOID
    defined to null for V7, "(void)" for all others to avoid all the
    V7 ifdefs

[Ed. - I thought I had removed all those (void)s; they were just there for
lint's benefit, but I guess a couple are still there (in ckutio.c and
ckuus3.c); they should go too.]

-g rfn -a name
    changed ckcfns.c to try treating "-a name" as a directory name
    bug: zopeno gives an err msg if the name is a directory
[Ed. - This is a little tricky, not sure it's worth it...]

logging
    added better debug and transaction messages to clsif and clsof in ckcfns.c
[Ed. - Good messages are always nice.]

get
    fixed to strip newline off of -a name in take script
[Ed. - Obviously desirable.]

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

Date: Sat, 21 Sep 85 21:28:25 PST
From: !![e-mail]
Subject: Bug Fix for C-Kermit User Interface

We just got a new giant Amdahl machine, running the System V flavor of UTS.
So far, its only connection to the world is through 9600 baud lines.
Needless to say, my first order of business was building C-Kermit on it,
followed by Compress, followed by most of my files (it also has mucho disk).
It went mostly OK, though the lintish feature of the UTS C compiler fussed a
bit.  That's not the story for today, though.  While sending files to UTS, I
got fed up with Kermit's habit of double-spaceing between lines of dots.

I decided to fix it while waiting for the transfer.  The context diff below,
for ckuus3.c, is the result.  The problem arose from some confusion over
whether "p" was the position of the last character or of the next character
to go into the buffer.  I tried to make everything consistant.  My rules
were as follows: 1) "p" is the zero-based position of the next character to
be put on the line, 2) It is each message type's responsibility to determine
if there is enough space for it, and to leave "p" pointed at the next
available space when it is done.  I also parameterized the line length, and
set it to 79 for our C-Kermit, so terminals with linewrap won't.

[Ed. - diffs omitted, but will be included in next release.  Kermit was
also brought up recently on our own UTSV system, and worked ok, except for
some cosmetic problems with command echoing, which I think we can fix.]

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

Date: 23 Sep 85 16:34:00 EDT
From: STEVE KABERLINE <kaberline@ford-vax>
Subject: C-Kermit on Masscomp Systems?

Can you tell me, please, who is/has been working on the Masscomp specific
implementation of Unix Kermit?  I have a few comments/suggestions I would
like to forward (A network address, if available, would be nice) to them.  I
recall, at one time, seeing a list on CU20B of who-is-doing-what as far as
Kermit work goes, is there still such a file I can ftp over and look at?

[Ed. - I've lost the specific reference, but have had reports that Masscomp
systems can run the current release of C-Kermit just fine, when built with
"make sys3".  Anyone know otherwise?]

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

Date: Fri 20 Sep 85 21:39:02-EDT
From: Andy R Raffman <EN4.AR-RAFFMAN@CU20A>
Subject: Problem with Sanyo 555 Kermit

I thought that I should tell you that I have tried the new Kermit 2.28 for
the Sanyo 555, and it has a bug: the backspace key does not move the cursor
back or erase the previous character in command mode.  Given that many of
the other improvements in Kermit haven't helped the Sanyo version much (no
H-19 or VT-100 emulation, no set key, no mode line), unless you have fixed
some larger bugs in v.2.26 (I know that the log function doesn't work right),
you might consider going back to it until the backspace bug is fixed.

[Ed. - If any Sanyo users out there have a fix for this, please let us know.]

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

Date: Mon, 23 Sep 85 23:48:58 PDT
From: [e-mail]
Subject: MsKermit Linking Idea

The following is the relevant part of a response in our local electronic
conference (*Forum) which I think may be of interest to part of the Kermit
community.

2723. MTS Kermit Now Available
      Bruce Jolliffe          16:23 Mon Aug 13/84

2723/60. CORRIE KOST          21:16 Mon Sep 23/85      12 lines

   I would like to suggest that all versions of KERMIT be linked
   with Microsoft's LINK version 3.XX, so that they can be packed
   with Microsoft's EXEPACK utility.  This procedure can cut the
   size of the .EXE file by up to 50 %, and the .EXE file is still
   directly runnable from MS-DOS (...and it loads faster, too)
   Note that EXEPACK will produce garbage (no warning !) if you
   try to pack a file linked with LINK version 2.XX, or the
   default IBM-PC linker supplied with PC-DOS 3.0 and PS-DOS 3.1

                                  - Ya'akov

[Ed. - Does anyone know if a thus-packed file can be run transparently
under earlier versions of DOS?  Also what would the expected savings be
on a program like MS-Kermit 2.28, which has got rid of most of its static
buffers and does memory allocation at runtime?  Any other pitfalls to be
wary of?]

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

End of Info-Kermit Digest
*************************
-------
 7-Oct-85 18:50:21-EDT,20104;000000000000
Mail-From: SY.FDC created at  7-Oct-85 18:49:38
Date: Mon 7 Oct 85 18:49:38-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #22
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Mon, 7 Oct 1985       Volume 3 : Number 22

Departments:

  MISCELLANY -
    Half-Duplex Windowing vs Long Buffers
    Use of Kermit by the Blind (Several Messages)
    Hint for VMS Binary File Transfer using Kermit

  UNIX KERMIT -
    Ken Poulton's C-Kermit Changes (Several Messages)
    C-Kermit Works on HP Integral Kermit
    C-Kermit EOF Bug
    C-Kermit Does Not Compile on AT&T 3B20 SysVR2 - And the Fix
    Masscomp Kermit
    TI NU Machine Kermit
    Bug in C-Kermit Remote Commands under VAX/VMS

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

Date: Thu, 3 Oct 85 19:35 EDT
From: [e-mail]
Subject: Half-Duplex Windowing vs Long Buffers

Is everyone agreed that in half-duplex windowing, the EOL character should
not be sent until the end of a group of packets?  If an EOL character is
sent after each packet, my 370 TSO and WYLBUR systems will require some
delay before the next packet is sent.  Otherwise following packets will be
lost.  Also, if a packet received in error results in a parity error (likely,
but not certain), the resulting error message from the system will cause
the following packet to be obliterated also.  For my systems, I think it is
best not to send an EOL until the end of a group of packets.

However, if the EOL is not sent until the end of a group, there is another
problem which may be common to systems that check incoming parity.  Since
the whole group of packets is considered to be one "line" by the system,
an error in any packet that also results in a parity error (highly likely,
although not guaranteed), will cause the entire line (group of packets)
to be discarded.  Thus the half duplex windowing scheme results in extra
overhead for multiple packets per "line" with little corresponding benefit
in reduced retransmission when compared to the big packet proposal.

Therefore I prefer big buffers to half-duplex windowing.


                                 Roger Fajman <[e-mail]>
                                 Computer Center
                                 National Institutes of Health

[Ed. - Last chance to get your comments in...  The tide of opinion seems to
be favoring long packets, distinct from sliding windows.]

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

Date: Tue 1 Oct 85 14:17:51-EDT
From: Frank da Cruz <[e-mail]>
Subject: Use of Kermit by the Blind
To: [e-mail]
cc: [e-mail], [e-mail]

I've had a call from Kenneth Reed at NASA in Greenbelt, MD (phone [phone])
asking how Kermit can be used effectively by blind people.  Back in the days
when computers had terminals, you could put a device like a Votrax or DECtalk
or whatever between the terminal and the computer, and it could try to speak
the letters and numbers, or words, as they went by.  But microcomputers don't
generally have a place to attach such a device.  Kenneth says his Apple II
has a special card that somehow gets characters just before they're about to
be put on the screen and presumably can transmit them to a speaking device,
but that's just for the Apple.

I'm sure there has been a lot of discussion about this elsewhere, but I must
have missed it.  How can blind people use microcomputer applications in
general?  Obviously, graphics-oriented stuff is mostly out (and therefore,
presumably, also the Macintosh).  In MS-DOS, maybe there are console drivers
that can intercept characters, strip out (or interpret) formatting information,
and send the text out the serial port to, say, a Votrax, or maybe there are IBM
PC boards that "speak the screen" directly.  Anyhow, Kenneth's department is
selecting microcomputers and he'd like to see them pick one that text oriented
applications (like Kermit) can be adapted to give comprehensible audible
output.  If you have any information, please post it and also give Kenneth a
call at the number listed.

By the way, the way the Kermit file transfer display is done is important here.
On MS-DOS systems, a "form" is put up on the screen at the beginning of the
file transfer, and then numbers and messages are filled in and updated
randomly throughout.  If one were to read this stuff in sequence as it appeared
on the screen, it would be a pretty confusing jumble.  Also, you'd need a
pretty fast talker at high baud rates...  The serial output of local-mode Unix
Kermit or DEC-20 Kermit would be a lot more comprehensible when interpreted
by a voice device.

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

Date: Wed, 2 Oct 85 06:21:51 MDT
From: [e-mail] (Henry M. Halff)
Subject: Re: Use of Kermit by the Blind
References: <[e-mail]>

Let me suggest that your friend contact the following firm.

    Talking Computers, Inc.
    6931 North 27th Road
    Arlington, VA 22213
    703-241-8224

The fellow that runs the firm is Doug Wakefield.  His business is putting
speech synthesizers on computers for blind people.  He pretty much specializes
in IBM PC's, but he might be able to help with Apples.  The software that he
uses should have no problem with a screen display like Kermit's since the
user can, at any time, get a readout of the entire screen or any line
on the screen.

Hope this helps.

Henry M. Halff
Halff Resources, Inc.
[e-mail]

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

Date: Sat, 5 Oct 85 10:28:24 mst
From: Kelvin Nilsen <[e-mail]>
Subject: Kermit for the Blind

[Ed. - This is from the author & proprietor of VersaCom, a communication
program that includes Kermit.]

versacom does not run windows!  all i/o to the terminal is serialized through
the bios, write tty (except of course when it comes to terminal emulation).
this makes it possible to run versacom on a pc from a terminal and connect
to another system to transfer files.  for example:


      vt100                   dumb tty emulation
    +-------------+             +---------+            +----------+
    |home terminal|- 1200 baud -|office pc|-19200 baud-|office vax|
    +-------------+             +---------+            +----------+

xon/xoff handshaking is supported on both ports, in both directions and works
independently.  the amount of information reported by file transfers can be
each packet, or each file transfered.

anyway, this capability makes possible two solutions to the problem you
mentioned.  first, attach a votrax-type terminal to one of the com ports
of the pc.  second, modify versacom to send bios tty output to an internal
voice synthesizer instead of or in addition to the bios tty output.

kelvin nilsen

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

DATE: October 07, 1985 11:29:44 EDT
FROM: [e-mail]
SUBJECT: TERMINAL FOR THE BLIND

WE ARE TRYING SEVERAL DIFFERENT PRODUCTS FOR THE BLIND HERE AT VA. TECH
ONE IS A PACKAGE ON THE IBM PC CALL ED FREEDOM. VERY NICE PACKAGE.
WORKS OUTSIDE OF ALMOST ANY OTHER PACKAGE ON THE PC. WE USE THE TERM
EMULATOR YTERM WITH IT NO PROBLEMS.
WE ALSO USE THE AUDIOTRONICS TALKING KEYBOARD FOR THE PC. HAVING SOME
SPEED INTERFACE PROBLEMS. QUESTIONS CALL 703-961 5961.

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

Date:  5 Oct 1985 1454-PDT (Saturday)
From: [e-mail] (William Randy Day)
Subject: Re: Use of Kermit by the Blind

I am part of a research project here at the University of Washington aimed
at developing software for deaf-blind (both deaf and blind) users.  The
presentation problem is severe. As you say, graphics-oriented software is
out.  As you describe in you posting, even ``non-graphics'' programs like
kermit can prove incomprehensible if a straight screen output to speech
translation is made. We have come to the conclusion that a simple
hardware/software translation unit sitting on top of normal software is
inadequate, particularly for our severely handicapped target group. We have
taken the custom software approach.

Randy Day.
UUCP: {decvax|ihnp4}!uw-beaver!uw-june!randy
ARPA: randy@washington
CSNET: randy%washington@csnet-relay

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

Date: 3 Oct 85 17:20:20 GMT
From: [e-mail]
Subject: Hint for VMS Binary File Transfer using Kermit

If one has two VMS Vaxes connected together with RS-232 ports, binary files
will transfer OK, using 8-bit data.  The catch is that Kermit cannot possibly
be taught about all of the wild and wonderful RMS file formats (how many are
there?  1.0e10?), so making a BACKUP set (which contains the RMS formats) and
transferring it via Kermit will work fine.  Do a SET FILE TYPE FIXED in the
Kermits at both ends.  This allows .EXE files to be transferred directly, and
BACKUP save sets to be transferred and read from after fixing up the block
size.

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

Date: Wed, 25 Sep 85 11:38:25 pdt
From: hpl-opus![e-mail]
Subject: More Kermit Changes Comments

> -g rfn -a name
>     changed ckcfns.c to try treating "-a name" as a directory name
>         bug: zopeno gives an err msg if the name is a directory,
>                  even though it works.
> [Ed. - This is a little tricky, not sure it's worth it...]

It is consistent with other file transfer facilities such as uucp (and I
*needed* it for that reason).  The code *is* a bit messy because I didn't dare
change the machine-dependent primitives like zopeno (I can't write or test new
VMS or Mac versions).  I think adding an argument to zopeno will allow having
it do this operation (if appropriate for that opsys).

> eXIT command
>
> [Ed. - This is the most controversial area of all.  First of all, case-
> sensitive commands are not in the spirit of Kermit.  Second, giving the

The typed command is 'x' or 'xit'.

This is sometimes an essential feature, but not always desirable.  How about
making this feature depend on a compile-time ifdef?  Then the system manager
can control the use of this as appropriate.

Ken Poulton

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

Date: Tue, 24 Sep 85 18:43:32 pdt
From: "Scott Weikart; Community Data Processing" <cdp!scott@glacier>
Subject: Info-Kermit Digest V3 #21: Ken Poulton reactions

Here's my reactions to Ken Poulton's changes.

> !
>    merged ! and other uses of fork to call new routine zexecl in ckufio
>    zexecl does an exec, using 1) the shell defined by environment variable
>    SHELL, if any, or else 2) the user's login shell from /etc/passwd, or
>    failing that, 3) /bin/sh.

I like it.

> control chars
>     added conchr to ckutio and changes in ckucmd to support using the
>     user's predefined control characters as he expects

I like it, for those systems that support it (and leave ^W as backward
delete word on SYSIII, etc).

> startup files
>     1) ./.kermrc   2) ~/.kermrc   3) /usr/local/lib/kermrc
>     settable with -DKERMRC (as before) and -DSYS_KERMRC
>     Note that order of first two is intentionally changed

I would like to have two system files, kermrc.1st and kermrc.lst.
.1st would be done first, then a user's (if any) would be done (i.e. either
1) or 2) above), then .lst.  Basically, I want both defaults and mandatory
values, and this seems to be the only way to do it.

I think /etc might be a better place for the system-wide files, like
/etc/profile and /etc/cshprofile.

I'm not sure I like 1); it seems like a take file in the appropriate
directory would be safer.

> eXIT command
>     added eXIT command - allows leaving Kermit w/o unlocking or dropping line
>     added ttnohu to close the tty w/o hangup
>     creates ~/UNLOCKttyxx to remind user
>     EXIT deleted to avoid confusion
>     (maybe this should be disabled on BSD systems as not needed)

I don't like it.  I still think that pushing a subshell is the only reasonable
way to do it, with /usr/spool/uucp group accessible and kermit setgid (as I
described at length a while back).  Of course, I can't bitch too much since
I'm not offering to implement it.

> #
>     added comment command
>     for documenting scripts
>     (done with % by 4C(057))
>
> [Ed. - I used "%" for this to avoid confusion with shell scripts.]

But I'd *rather* have it be like shell scripts; my Emacs already assumes
that files with no or unknown extionsions use # as comment, and most
UNIX types will recognize # as comment.  And I doubt that a kermit
script will often look like a shell script.

> locking
>     now accepts existing lock files owned by the user (to support eXIT)

This seems good as long as it doesn't break when files or directories
or unreadable.  At least some people could have it right.

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

Date: Thu Sep 26 1985 17:55:58
From: Marco Papa <[e-mail]>
Subject: Comments on C-Kermit new features

These are my comments about the possible additional features or chhanges to
current features of C-Kermit.

1. SHELL stuff.  OK.

2. Control chars. OK.

3. Startup files. BAD!!! Much better like it is now.

3. Exit command.  BAD too!! I do not like case sensitivity, but much more
important I do not want users to leave locked lines around. There is really
no real advantage, and the risks are enormous.

4. Scripts with no echo. OK. In fact I hate to have my login script to show
right on the monitor the password I am using to login on another system.
Logging transactions is enough.  After one has found the correct login
sequence there is absolutely no need to show it everytime.

5. comment command for shell scripts.  OK together with 4.

6. locking. It won't work in most systems.  System managers are becoming
more restrictive in letting users create locks owned by them.


Marco Papa
USC - Computer Science Dept.

UUCP:  ...!{{decvax,ucbvax}!sdcsvax,hplabs,allegra,trwrb}!sdcrdcf!uscvax!papa
CSNET: [e-mail]
ARPA:  [e-mail]

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

Date: Wed, 25 Sep 85 10:43:58 pdt
From: hpl-opus![e-mail]
Subject: Use of '%' and '#' in Scripts

On the use of '%' or '#' for comments in scripts:

*Many* Unix programs allow '#' to introduce comments, not just shells.

In addition, some Unix systems allow "#! program" at the beginning of a file
to indicate that that file is a script for 'program' and should be executed
as such.  This is usually used for csh scripts ("#! /bin/csh") but would
allow one to write executable kermit scripts by writing

    #!/usr/local/bin/kermit

at the head of the file.  Then (on systems which support this) one need only
type the script's filename to execute it with kermit.

Ken

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

Date: 25 Sep 85 09:22:11 EDT
From: GH0N@CMU-CC-TC
Subject: C-Kermit Works on HP Integral Kermit

This is in regard to whether C-Kermit 4C runs on the HP Integral.  I have
gotten C-Kermit to run on the Integral with very little trouble.  Make sys3
does get the job done, but you need to either remove the code that sets up
lock files, or have the lock files put in a directory that is guaranteed
to be there (such as /tmp).  Another thing that crops up is that the C
compiler for the Integral has a bug in it (at least the version I have does)
that will cause it to report the sizeof() an array as being 0.  Sizeof() on
lone variables and structures (including structures containing arrays) work
fine.  The biggest hassle with making C-Kermit for the Integral is the fact
that you can't use make if you don't have either LOTS of memory or a hard
disk.  To compile and link all the code takes about an hour.

    Hope this helps.

Gordon Haverland
GH0N % CMU-CC-TC @ Carnegie    Mailnet }
GH0N @ CMU-CC-TC        BITnet  } soon to be GH0N.TC.CC.CMU.EDU ?
...!cmu-cs-pt!cmu-cc-tc!gh0n    uucp?

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

Date: Tue, 1 Oct 85 11:31:06 -0100
From: mcvax!philmds!duvel![e-mail]
Subject: C-Kermit EOF Bug

I've encountered a bug in C-Kermit v57.

The bug is that in ckcpro.c (and .w) a test is done on the return value of
reof.  However reof() does *never* return a value.  This makes ckcpro.c barf
sometimes that a file cannot be closed, but evidently there is no problem at
all.  By the way reof() is declared in ckcfns.c. I could not find other
calls except for the one in ckcpro.c

    Frans Meulenbroeks, Philips Microprocessor Development Systems
           ...!{seismo|philabs|decvax}!mcvax!philmds!frans

[Ed. - Right you are -- reof() should return the value that was returned to
it by clsof(), indicating whether the file was closed successfully or not.
Will be fixed in next release; noted in "beware file" till then.]

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

Date: Thu, 3 Oct 85 11:07:42 PDT
From: [e-mail] (Brian Kantor)
Subject: C-Kermit Does Not Compile on AT&T 3B20 SysVR2 - And the Fix

The routine 'unchar' in ckcker.h has a name conflict with the unsigned
character typedef included from sys/types.h.  Changing it to 'myunchar'
permits Kermit to compile.

    Brian Kantor    UC San Diego

    decvax\     [e-mail]
    akgua  >---  sdcsvax  --- brian
    ucbvax/        Kantor@Nosc

[Ed. - Thanks, will change this in the next release, and note it in the beware
file until then.]

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

Date: Sat, 5 Oct 85 02:19:30 CDT
From: Stan Barber <neuro1![e-mail]>
Subject: Masscomp Kermit

I submitted an version of 4.2 C-Kermit to the Masscomp Users Group that had
line-locking that would work (I hope) for most environments.  I have not had a
chance to get the most recent release of 4C to add those features to it that
deal with the line-locking problem effectively.

make sys3 does just fine, if line-locking is not an issue. If it is, then my
mods would probably satisfy most.  It is fortunate that the new version of UUCP
(BSD 4.3) supports a read/write by the world LCK directory to remove the need
for setuid programs.

I will be making the 4C version work on masscomp sometime soon, but 4.2 seems
to work for most people even with the bugs it has.

I will be happy to field any comments on the masscomp users group version.

Stan Barber
Baylor College of Medicine
[e-mail]
ihnp4!shell!neuro1!sob

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

Date: 20-Sep-85 14:33:10EDT
From: "KENNETH POOLE" <poole@nusc-ada>
Subject: NU-Machine Unix Kermit

I have done a simple mod of 4c(57) of the unix kermit for the NU-machine
unix from TI.  This Unix is the one on the LMI Lambda-Plus machines.
Please indicate how you would like me to send you the mods for adding
to the main source.  I modified ckutio,ckufio and ckuker.mak.  Also,
please add my name to the list for the info-kermit digest.  I was on
before, but we lost our arpanet software fo a while and i think i was
taken off the list.  Thanks,
            Ken Poole  849-6270

[Ed. - I tried to respond to this message, but couldn't seem to push a
message through.  Ken, please send me context diffs...]

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

Date: Thu, 26 Sep 85 15:21:32 GMT
From: John Rainbow Messenger <[e-mail]>
Via: [e-mail]
Subject: Bug in C-Kermit Remote Commands under VAX/VMS

We have found a bug in the remote command execution code for the VMS version
of C-Kermit.  The symptom was a complete failure to execute remote commands,
with a message of the form %F - Can't delete file (for instance).
The enclosed fix enables remote commands to be executed.

The patch is a context diff, and can be installed with the patch command.

[Ed. - Patch omitted, but listed in KER:CKVKER.BWR on CU20B.]

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

End of Info-Kermit Digest
*************************
-------
 8-Oct-85 13:03:52-EDT,20102;000000000000
Mail-From: SY.FDC created at  8-Oct-85 13:03:14
Date: Tue 8 Oct 85 13:03:14-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #23
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Tue,  8 Oct 1985       Volume 3 : Number 23

Departments:
                    New BOO-file Maker for MS-DOS
          Further Problem with MS-DOS Kermit 2.28 GET Command
                    About MS Kermit and EXEPACK...
   Communication Problems with MS-DOC Kermit 2.28 on Leading Edge PC
               MS-DOS Kermit vs "Desk Accessory" Clocks
             How to Build Z100 MS-DOS Kermit from Source?
                       Terminals for the Blind
                   The Claimed C-Kermit Bug for VMS
          Four-Table ASCII/EBCDIC System for EBCDIC Kermits
           Request for Osborne and Kaypro Kermit Diskettes
                        MacKermit TAC Problem
                  Re: Kermit 1.7 Loses at 1200 Baud
                        Kermit for Wang 2200?
                       Kermit for DG Machines?
                         Kermit for CDS 4000?

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

Date: Thu 26 Sep 85 11:39:58-EDT
From: Frank da Cruz <[e-mail]>
Subject: New BOO-file Maker for MS-DOS

Alan Phillips at Lancaster University (UK) added Lattice C support to
MSMKBO.C, so that now MS-DOS Kermit .BOO files can be made directly on the
PC.  The new version replaces the old one, as KER:MSMKBOO.C on CU20B.

If you don't know what a .BOO file is, it's yet-another-printable-encoding
for binary files, the format that we distribute MS-DOS Kermit binaries in.
It features 4-for-3 encoding and 0-compression so that the resulting .BOO
file is often shorter than the original .EXE.

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

Date: 24 Sep 1985 2221-EDT
From: Stephen H. Owades, c/o EIBEN@DEC-MARLBORO
Subject: Further Problem with MS-DOS Kermit 2.28 GET Command

I have had some problems with MS-DOS Kermit 2.28 on my IBM PC/AT, as I
described in a mail message some weeks ago.  I downloaded the MSKERM.BWR
file, which offered a solution to the faulty file-name truncation (in
multi-file GETs) problem.  I made the suggested changes, reassembled and
relinked, and tested the resulting program.  Apparently no truncation
whatever is performed on a GET; DOS truncates the file name passed to it by
KERMIT.  This does eliminate the problem of badly truncated file names
(wherein KERMIT was doing something bizarre to the name of the first
incoming file), but it has created a new, perhaps worse, fault.  Now
collisions (incoming file name the same as a file name already presen are
only detected when the incoming file name is valid under DOS; if the
incoming file name is longer than XXXXXXXX.XXX, KERMIT doesn't know there is
a conflict and the system hangs.  I had to reboot my AT!  Collisions are
detected and avoided with the "0-1-2-..." naming method described in
MSKERM.DOC if the incoming file name is valid under DOS--evidently KERMIT
doesn't realize that there is a collision when the incoming file name was
truncated by DOS.

Stephen H. Owades

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

Date: 27 Sep 1985 0912-EDT
From: LCG.KERMIT
Subject: About MS Kermit and EXEPACK...

I have used EXEPACK on MS Kermit 2.26 through 2.28 and it produces workable
code (note I relink from source). In the 2.27 and older versions the .EXE
file went from 80+ K to around 36K.  In V2.28 however the savings was minimal
(10% if I recall right).  Thus EXEPACK is of marginal use with V2.28.  Can't
say much about backward compatibility; it looks OK on PCDOS V2.0 on, but
could break some compatibles.  Since MSDOS Link V3.XX is not commonly
available I believe its a mistake to use it in distribution; people should
be able to recreate the distributed .EXE via source with more common tools...

Glenn Everhart

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

Date:  2 Oct 1985 1152-PDT
From: Rob-Kling <Kling%UCI-20B@UCI-ICSA>
Subject: Communication Problems with MS-DOC Kermit 2.28 on Leading Edge PC

I normally use Kermit through COMM1 on my IBM-PC. I was trying it on a
Leading Edge PC last night which was configured to communicate through COM2.
It wouldn't send commands to the modem.

The Status command indicated that 1200 baud was illegal [even though we could
use PC-TalkIII to dial out on COM2].

I could not get Kermit to accept any baud rate (e.g., 110, 300, 1200) as
legal for COM2.  That is, the Status command indicated an error at any baud
rate when I set the port to COM2, but it would accept 1200 baud on COM1.

When I came home, I tried setting Kermit to use COM2 on my IBMPC at home.
I have only one serial port on this machine, but tried to set COM2 as the
active port. I received the same error messages re inappropriate baud rate
["Baud rate not recognized" or equivalent message].

I couldn't find any information in the Kermit 2.28 manual to help me decide
where the problem might lie.

1. What may be the problem?

2. Do you know if anyone has tried to use MSKermit on one of the new leading
Edge D machines?

Thanks

Rob Kling
UC-Irvine

[Ed. - I'm pretty sure you can set the baud rate on COM2, as many people at
Columbia have two serial ports and use both.  If the second serial board isn't
there, the status command would not be able to figure out the baud rate, since
reading the (non-existent) baud rate status port would return something
meaningless.  I don't know anything about the Leading Edge machines, but it
sounds like they're another 'almost' compatible, at least in terms of the
second serial port.  Does anyone out there know something about Leading Edge?]

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

Date: Mon, 7 Oct 85 10:21:49 PDT
From: [e-mail]
Subject: MS-DOS Kermit vs "Desk Accessory" Clocks

Any program which accesses the IBM PC timer interrupt to place a real-time
clock on the screen seems to put a real strain on Kermit.  Continuous-update
programs basically trash Kermit.  I have a shareware program called Deskmate
on my PC right now, which updates the time on the screen every 10 seconds or
so.  It still badly interferes with Kermit.  I don't want to have to reboot
my system in order to use Kermit effectively.

Does anyone have a solution to this problem, or is it inherent in the IBM PC
architecture?

                    Steve Walton
                    Caltech Solar Astronomy
                    [e-mail]
                    [e-mail]
                    ...!psuvax1![e-mail]

[Ed. - Thanks for the report; I've noted it in the "beware" file.  There may
be a way to get two or more programs that use timers to coexist, we'll have
to look into it.]

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

Date: Mon 7 Oct 85 13:20:34-MDT
From: Dick Dysart <[e-mail]>
Subject: How to Build Z100 MS-DOS Kermit from Source?

I have downloaded the MS*.ASM files for Kermit for the Z-100, 13 of them..
I have run them thru MASM , each with no errors from MASM..(not sure if or
what I should modify for MY machine)..

Then when I LINK them, the linker responds -> I/O run error in EXE, and
aborts without creating the .EXE file...

I thought that I should try from the beginning as my Besterm still won't work
properly, and MAYBE a version of Kermit compiled on MY machine would work..

With the LINKER aborting this way, and I cant find that error message in the
MS-DOS manual as yet, I don't know what's wrong, nore do I have any idea
what to fix..

Any help would be appreciated......................Dick

[Ed. - Can anybody who has experience with MS-DOS Kermit on the Z100 offer
any help?]

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

Date: Mon, 7 Oct 85 20:31:19 EDT
From: Doug Gwyn (VLD/VMB) <[e-mail]>
Subject: Terminals for the Blind

I don't know why nobody seems to be mentioning the VersaBraille (another
company makes a similar device).  I used to have a blind programmer working
for me, and we tried various talking terminals, optical scanners, and so
forth.  Her conclusion was that the VersaBraille (with communications
software cassette) was much easier and faster, although for graphics (yes!)
she resorted to an optical scanner (sorry, I forget the trade name).

This topic really seems orthogonal to KERMIT, other than to the extent to
which it points out the silliness of fancy user interfaces in what was
supposed to be a file transfer program.

[Ed. - So true.  By the way, I can't find any other forum for discussion
of these issues in the "list of lists", so I don't mind if the topic
continues in Info-Kermit for a while.]

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

Date: Mon 7 Oct 85 21:47:01-EDT
From: Jin Au Kong <[e-mail]>
Subject: The Claimed C-Kermit Bug for VMS

The problem with "! XXX" in VMS is related to the BYTLM in user authorization
file, as we discovered soon after we installed C-kermit on our system.   For
VMS to create a subprocess, the BYTLM must exceed 4096 (which is our previous
setting), and of course, PRCLM must be at least 1.  I don't know the exact
minimum for BYTLM, but after we set it to 6144, it worked.

But note that the created subprocess will not be stopped after you get out
from Kermit.  Hope somebody can fix the problem.

[Ed. - Thanks, noted in the CKVKER.BWR file.  Does this mean that the
previous report is wrong and that no change needs to be made to the code,
or that both are necessary?  Anybody want to contribute "installation
instructions" for C-Kermit under VMS, and/or a review of its usefulness?]

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

Date: Sat, 27 Jul 85 15:55 PDT
From: [e-mail]
Subject: Four-Table ASCII/EBCDIC System for EBCDIC Kermits

[Ed. - This message was recently excavated and is now belatedly published.
It was apparently provoked by the new ASCII/EBCDIC translation feature of
VM/CMS Kermit v2.]

The two ATOE's and two ETOA's would differ in the following way.

First let us denote the system tables ATOE0 and ETOA0.  We will construct
ETOA1 to be the left inverse of ATOE0, i.e. for every printable ASCII
character x, ETOA1(ATOE0(x)) = x.  Similarly, we will construct ATOE1 to be
the right inverse of ETOA0, i.e. for every printable ASCII character x,
ETOA0(ATOE1(x)) = x.  The -1 tables are used to postmap incoming packets
back to ASCII and to premap outgoing packets out of ASCII.  They form an
outer layer to Kermit so it can analyze and build packets in ASCII.  If the
-0 system tables are nonstandard, then the -1 will be too.  Note that the
right inverse may not be unique and that either inverse may fail to exist.

The other function of translation tables is to map text messages back and
forth between ASCII and EBCDIC as packets are analyzed and synthesized.
Call these ETOA2 and ATOE2.  Ideally these should be based on the "standard"
in the IBM System 370 Reference Summary or the Appendix of the Kermit User's
Manual, and thus would differ from the -1 tables in the nonstandard
situation.  Currently, -1 tables do double duty as they perform the text
message translation function as well.  The result is various distortions in
text as it is transmitted to and from EBCDIC systems, including undesirable
substitutions and swallowing of characters.  In a four-table system as I
have outlined, these distortions would not occur.

What is left is to state mathematically the conditions under which the
-1 tables can be constucted, and to present the appropriate algorithms.

. ETOA1 exists iff ATOE0 is 1-1 (unambiguous) on the printable set.

. ATOE1 exists iff the range of ETOA contains the printable set.

With standard tables, these questions do not arise since in this case
the system tables are both left and right inverses of each other.

This is all I have time for now.  Hopefully, I can sketch the algorithms
later.  I ran into the problem of distorted characters at UCLA where TSO
Kermit has recently been installed with modified translation tables.  I
wanted to download Kermit-MS in the .BOO format as well as the Basic program
to decode it.  I noticed that the tilde (or degree sign) was getting
swallowed and that the backslash was being blanked out.  It would have been
easy enough to hand patch the Basic, but hardly the .BOO file.  I hope I
have convinced you that there is a problem.

Ciao -

Glenn Thobe
iva3get@uclamvs and vss7853@uclavm (bitnet)

[Ed. - Given the number of calls I get every day from IBM mainframe sites
who have "customized" their translate tables, I don't need convincing that
there's a problem.  But I'm not sure I understand how a 4-table system will
necessarily solve it.  Your level 1 tables that invert the system's tables
will only work if the system's tables are already unique and invertible --
in many cases they are not.  If 2 different printable ASCII characters are
mapped by the system to the same EBCDIC character, then the even the low
level stuff won't work -- some packets will be perceived has having wrong
checksums.  In such cases, the only solution is to fix the system's tables.]

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

Date: Wed, 25 Sep 85 13:10:12 PDT
From: [e-mail]
Subject: Request for Osborne and Kaypro Kermit Diskettes
To: [e-mail]

I have been in touch with Frank da Cruz regarding our local (Los Angeles
area) Osborne club acting as a distribution house for Osborne and Kaypro
Kermit diskettes and documentation. the details are all worked out, but
I do require copies on disk of latest versions and doc or library files
for these programs.  I would also like to obtain a copy of the Kermit
User Guide.

Anyone who can assist in this matter may reply directly to this message or
contact me also via:

                       1) [e-mail]

                       2) BOB DANTAS
                          % JET PROPULSION LAB
                          4800 OAK GROVE DRIVE
                          MAIL SLOT T-LL
                          MAIL SLOT T-1180 (CORRECT ONE)
                          PASADENA, CALIF.  91109

                       3) [phone]

[Ed. - I'll send a User Guide.  Could someone who has Kermit on Kaypro or
Osborne diskette please send in a copy?  Thanks!]

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

Date: Tue 1 Oct 85 09:07:52-PDT
From: Steve Dennett <[e-mail]>
Subject: MacKermit TAC Problem

The NIC has gotten several calls lately from users having trouble getting
Macintosh Kermit to work through a TAC.  I've tried doing file transfers
and have been equally unsuccessful.  The odd thing is that it's a one-way
problem.

Going through a TAC, files can be downloaded from host to Mac without
difficulty.  But when uploading, MacKermit sends three packets then
starts re-trying until it finally times out.

I've read the general information about using Kermit through a TAC and
have successfully moved files in both directions through a TAC using the
IBM PC version of Kermit, so the problem is something specific to MacKermit.
Also, I've tried all the different TAC twiddles (BIS/BOS, flow control,
varying packet sizes, etc.) but no combination seems to make a difference.

The version of MacKermit I'm using is .8(33) July 1985.  Since you're listed
as one of the authors, I hope you can help.  With the growing number of net
users and the popularity of the Mac, this question is certain to come up
with increasing frequency.

Thanks for your help.

Steve Dennett  (  [e-mail]  )
DDN Network Information Center

[Ed. - Well...  You've got the latest version of Mac Kermit, so that's not
the problem.  I've never used a TAC personally, so all my information is
second hand.  @B I S/@B O S makes the TAC transparent, so once you've done
that, you should be able to rule out any interference by XON/XOFF (which the
Mac doesn't do anyway), atsigns, etc.  The fact that you can download files
to the Mac seems to confirm this.  Therefore, I'd look again at the TAC's
buffers.  If there's a way to make them bigger, do that.  If not, you've got
to get the Mac to send shorter packets; to do this, tell BOTH Kermits to
reduce their packet sizes.  What may be happening is that the effect of
commands like "set send packet-length" might be the opposite of what you
expect -- some Kermits take this to mean that you want to override whatever
the other Kermit asks for, and while others do the opposite.  Let me know
how it works.  If you still have problems, find out as much as you can from
the two Kermits involved -- note all the current communications and protocol
settings, get debug and/or packet logs if possible.]

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

Date: Wed 2 Oct 85 21:30:17-EDT
From: Robert S. Lenoil <[e-mail]>
To: [e-mail]
cc: [e-mail], [e-mail]
Subject: Re: Kermit 1.7 Loses at 1200 Baud

I tried your suggested fix of setting the RS-232 registers to 8 so that my
modem could autobaud correctly, and then resetting them to zero.  This worked
in that my modem did autobaud correctly and go into high-speed mode.  However,
when I reset the rs-232 regs to zero, the host could no longer understand me.
Of course, if I left the registers at 8, I dropped characters.  The symptoms
are this: my transmit data light goes on, but the host does not return any
character (I am in full duplex).  After restarting with Kermit 1.5 (what I'm
using now), I saw that the DEC-20 was receiving nothing but back-quotes ("`").
I've rejected the possibility that my download went poorly, since I used
Kermit, and because the hex file has its own checksums.  Again, my modem is a
ProModem 1200, by Prometheus.  Has anyone else seen this behavior exhibited?

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

Date: Wednesday, 18 September 1985  17:43-MDT
From: [e-mail] (Paul Johnson)
Subject: Kermit for Wang 2200?

Does anybody have the source for Kermit on a Wang 2200?

paul johnson
{akgua,allegra,dcdwest,decvax,ihnp4,helios,ucbvax}!sdcsvax!pjohnson

[Ed. - To my knowledge, no Kermit program exists for any Wang systems other
than the PC, and no one is working on any.  Does anybody know something to
the contrary?]

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

Date: 26 Sep 1985 1331-EDT
From: LSM.DUNCAN at DEC-MARLBORO.ARPA
Subject: Kermit for DG Machines?

Is there ayone who could provide a copy of a Data General Kermit for an
MV4000 system in binary form?  We have a system with no compilers and a
cartridge tape.  Alternatively, is there a way to get a binary version
from a system so it could be downloaded with a 'crude' transfer program?

  Thanks,
     Jeff Duncan (lsm.duncan@dec-marlboro)

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

Date: 2 Oct 85 22:13:21 EDT
From: Steven Christensen <SC1K@CMU-CC-TE>
Subject: Kermit for CDS 4000?

Is anyone working on a Kermit for ComputerVision's CDS-4000 computer?  It's
basically a FORTRAN generic machine, with some strange idiosyncronicities.

    Steven Christensen
    Phone: [phone]
    Address: 728 Stuart Lane  Cincinnati, Oh  45245

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

End of Info-Kermit Digest
*************************
-------
17-Oct-85 17:51:15-EDT,21893;000000000000
Mail-From: SY.FDC created at 17-Oct-85 17:50:28
Date: Thu 17 Oct 85 17:50:28-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #24
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Thu, 17 Oct 1985       Volume 3 : Number 24

Today's Topics:

               MS-DOS Kermit for the DECmate II and III
               Crosstalk XVI 3.6 Kermit Implementation
         Kermit Throughput Problems with "Smart" Multiplexer
                          MacKermit and TACs
                        VMS Kermit 3.1.066 Bug
                     Re: VMS C Kermit problem...
                Commodore-64 Kermit 1.7 1200 Baud Fix
                   CP/M Kermit on a Remote Machine
     File Transfer Between VAX (Unix 4.2) and IBM 3081 (VM/370) ?
          File Transfer Between VAX And IBM PC Through LAN ?
         Victor 9000 CP/M-86 Kermit Binary Wanted (On Floppy)
                         MS DOS Kermit vs DTR
                  Kermit for 1750A, MOS, or Jovial?

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

Date: Thu, 17 Oct 85 10:02:47 EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: MS-DOS Kermit for the DECmate II and III

An implementation of MS-DOS Kermit 2.28 (the current release) is now
available for the DECmate-II and III with the XPU (MS-DOS) option, from an
anonymous donor at DEC.  The files are in KER:MSDM2.BOO (printably encoded
.EXE file, use KER:MSPCTRAN.BAS or KER:MSPCBOO.BAS to decode it, if indeed
DECmate MS-DOS has a Microsoft-like Basic), KER:MSDMII.BAT (for building from
source), KER:MSXDM2.ASM (system-dependent source module), and KB:MSDM2.EXE
(8-bit binary).  No documentation is available, but it is said to work, and
to use the DM-II/III's built-in VT100/200 firmware for terminal emulation.

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

Date: Wed, 9 Oct 85 08:57:06 cdt
From: [e-mail] (R. Blake Farenthold)
Kermit: Kermit on The Source

The Source (a commercial time sharing service) has just set up their
SIGS (Special interest groups) containing discussions & downloads for
people with various interests.  Aside from straight ASCII up and down
loads they offer Kermit transfers.

A couple of days ago I sent a 110K file to the Source using Kermit. At
1200 baud this should have taken about 15 minutes. IT TOOK OVER AN
HOUR!  Is Kermit that inefficent, is it horribly hampered when using
a packet switching network (I used Telenet), or has The Source slowed
things way down so they can collect more per-minute connect time!

In otherwords who do I yell at?

Blake Farenthold      |    CIS: 70070,521   |  UUCP: {ut-sally,ut-ngp,noao}
P.O. Box 3027         | Source: TCX023      |        !utastro!blake
Austin, TX 78764-3027 | Delphi: blake       |  Intr: [e-mail]
BBS: 512-442-1116     |    MCI: BFARENTHOLD |   ESL: 62806548

[Ed. - The people at The Source are well aware of the problem, which is
twofold: (a) TELENET, and the Prime computer itself (which is what you are
talking to) provide only 7-bit channels, so you incur the overhead of
8th-bit prefixing for binary files, and (b) any packet-switched wide-area
public network like TELENET has its own built-in delays, which, due to the
stop-and-wait nature of the Kermit protocol in its present form, will tend
to dominate any file transfer over TELENET.  To cope with these problems,
The Source has proposed (in Info-Kermit v3 #7, with discussion in following
issues) a sliding window protocol to allow multiple packets to be sent back
to back, which can result in a dramatic performance improvement under these
conditions.  Prototype programs are running now, and should be announced
before the end of the year.  By the way, don't complain too much -- most
other protocols don't work in this environment at all!]

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

Date: Wed, 16 Oct 85 20:02:47 EDT
From: RAF@UMDC
Subject:  Crosstalk XVI 3.6 Kermit Implementation

I just received a copy of Crosstalk XVI 3.6, which includes KERMIT support.
I gave it a quick try and encountered two problems.  One is that when I send
a text file from the PC to my TSO KERMIT, Crosstalk does not stop at the
Control-Z.  Thus I get a Control-Z plus some additional garbage at the end
of the file.  Microstuf customer support confirms that there is no way to
get Crosstalk to stop at the Control-Z.  Since Control-Z for end of file is
a PC convention, it seems to me that Crosstalk should support it.  Customer
support said they would pass the suggestion on for consideration.

The other problem is much more minor: after a Crosstalk KERMIT LIST command
is done to list KERMIT protocol options, everything put on the screen after
that is in high intensity.

Roger Fajman  <RAF@UMDC>
National Institutes of Health

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

DATE: 16-OCT-1985
FROM: [e-mail]
SUBJECT: Kermit Throughput Problems with "Smart" Multiplexer

A note to those of you who support a Kermit implementation on odd modems and
muxes:

I recently had a call from a Kermit-11 user who found that a download from
the host to the RT11 system for a given file took 2 minutes, whereas the
upload of the same file to the host took 14 minutes.  Solution: the mux they
were using severely downgrades the uplink bandwidth in an ill conceived
attempt to improve the host to local link bandwidth.  From what I have seen
recently in the various trade rags, this seems to be an approach that some
vendors are trying out.  Beware...

brian

[Ed. - One of the hardest problems Kermit or any similar protocol has to
cope with is that so much communication equipment is designed under the
assumption that input from a "terminal" will only be human keystrokes.
Another example follows...]

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

Date: Thu, 10 Oct 85 21:35:27 EDT
From: Dave Swindell <[e-mail]>
Subject: MacKermit and TACs

I've found that you have to explicitly set the send-packet length to
something less than 64 when uploading data from ANY PC over a TAC.  The TAC
input buffer just isn't big enough to handle the 90 (or is it 94?) character
default send-packet size used by MacKermit.  As was mentioned in the digest,
you also have to use the TAC commands @ B O S and @ B I S (in that order) to
allow the Kermit protocol to function correctly over a TAC.

Dave Swindell
BBN Laboratories

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

Date: Tue 8 Oct 85 16:15:54-EDT
From: Michael Fuchs <[e-mail]>
Subject: VMS Kermit 3.1.066 Bug

I don't know if 3.1.066 is state-of-the-art, but it can't handle CRCs and
8bit data simultaneously in server mode.  One can't set the micro to CRC and
send a binary file to the VAX unless one explicitly makes the micro
*request* 8-bit-prefixing.  CRC works fine with non-8bit-files, and 8bit
files can be sent micro to VAX with Checksum error detection.

The VAX puts a "3" in the appropriate place in the init packet.  Then, if
the data packet has bytes with the eighth bit high, it sends NAK packets
back to the micro.  (Indeed, the NAK packets correctly have CRCs.)  The only
way to use CRC error detection is to also have the micro request
8-bit-quoting (if one is sending 8bit data to the VAX).

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

From: Ivan Auger <[e-mail]>
To: info-kermit <@csnet-relay.arpa:[e-mail]>
Subject: Re: VMS C Kermit problem...

There is a default mailbox buffer size on any VMS system (mailboxes are used
for process communication).  You can have kermit set the size of mailboxes,
change the defaulf mailbox size, or you can indeed increase BYTLM quotas.
(By theway on our system you can do a SET HOST with a BYTLMC quota of 4096).
Ivan Auger, NYS Dept. of Health.

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

Date: Tue 8 Oct 85 17:20:07-EDT
From: Robert Lenoil <[e-mail]>
Subject: Commodore-64 Kermit 1.7 1200 Baud Fix

You must download the .INI file as a SEQ file. The proper parameters for the
kludge baud rates are contained in that file. 1200 baud will not work without
it.  That was the problem.  There is no way (from within Kermit) to set the
optional baud rate parameters in the .INI file, so you better download
KERMIT.INI properly, or 1200 baud won't work.  As as alternative, you might
wish to create KERMIT.INI with this small program:

10 open 8,8,8,"0:kermit.ini,s,w"
20 for i=1 to 45 : read b : print#1,chr$(b); : next
30 close 8
40 data 25,1,0,0,0,0,1,0,5,0,1,0,1,1,0,0,0,60,1,56,0,38,38,0,0,0,0,13,10,8,10
50 data 93,93,4,0,35,0,0,0,0,0,0,0,0,0

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

Date: Thu, 10 Oct 85 17:37:27 edt
From: Mike Ciaraldi  <[e-mail]>
Subject: CP/M Kermit on a Remote Machine

I sent this before, but I think it got lost:

Is there any way to run CP/M Kermit as the "remote" kermit rather than the
"local" kermit?  e.g. Suppose you had a computer bulletin board system
running under CP/M, and you wanted to use Kermit to upload and download
files.  You would use the Kermit on your own micro to call the BBS, and
could then run Kermit on the remote machine.  But when you told the remote
Kermit to, say, SEND, it would try to send the data out some communication
port, and would send only the status reports about the transfer to the
console (which is REALLY the modem ultimately connected to your local
machine).  Even if you use Generic Kermit and have it communicate with the
TTY or CRT device, it will still be sending both file data and the status
reports to the same device.  I know the IBM PC version has a flag you can
set to disable displaying the status, and the mainframe versions of Kermit
must be able to tell when to send status reports to the console and when not
to (by looking at the SET LINE perhaps?), but I couldn't find anything like
this in the CP/M Kermit 4.05 manual.

Thanks for your help.

Mike Ciaraldi
ciaraldi@rochester
seismo!rochester!ciaraldi

[Ed. - For now, there's no way to do this.  I've been forwarding messages
regarding CP/M-80 Kermit to the current maintainer, Charles Carvalho
(CHARLES@ACC), but haven't had a response in months.  Charles, are you
there???]

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

Date: 11 Oct 85 02:14:56 GMT
From: [e-mail] (P Wei)
Subject: File Transfer Between VAX (Unix 4.2) and IBM 3081 (VM/370) ?

We have vax running UNIX 4.2BSD , ckermit program, modem (/dev/tty18), vcu
(to use modem).  The ibm3081 also has cmskermit program.  the question is:
is it possible to transfer ascii file between this two system via that
modem?  I tried to use vcu to connect to ibm3081, but when I type 'kermit'
in CMS , I got 'an ascii terminal must be used' error message.  Even if i
didn't get that message, I couldn't get (escape) back to vax to invoke
ckermit because vcu doesn't allow me to 'escape'.  Then I tried to use
'kermit -l /dev/tty18 -b 1200'. The phone line was connected. However, when
ibm ask my terminal type, whatever I answer it warned me to check parity
etc...  I don't have time to go through further. I would like to ask if any
one knows my intention (file transfer) is possible.  If anyone has
experience, would you please mail me some sample session (as detail as
possible)? (e.g. the parameter settings...)  thanks a lot !

HP Wei

[Ed. - It is entirely possible to use Kermit to transfer ASCII text as well as
binary files between a 4.2BSD VAX and an IBM 370-Series mainframe running
VM/CMS.  Very briefly, here's how:

If you have a Series/1 style front end (7171, 4994, etc) running the Yale
ASCII package, you must also have version 2.00 or later of CMS Kermit on the
IBM mainframe (if you don't, you'll get the "An ASCII terminal must be used"
message.  If you're going through some other kind of 3270 protocol emulator,
then you can't use Kermit.  If you're going through a 3705-style front end
as an ordinary line mode TTY, you can use any version of CMS Kermit.

You should have version 4C(057) of C-Kermit on the Unix system -- certain
earlier versions had bugs that might have prevented them from working with
IBM mainframes.  To C-Kermit you should give the following commands if you're
coming in as a line-mode TTY:

set duplex half    (half duplex = local echo)
set flow none      (no full duplex xon/xoff flow control)
set handshake xon  (use half duplex line turnaround handshake)
set parity mark    (use whatever parity your IBM system expects)

or else the following commands if you're coming in through a Series/1 style
front end:

set parity even    (or whatever)

And of course you must also include whatever "set" commands are necessary
to set up the communication line ("set line", "set modem", "set baud", etc).

If all this seems a little strange, you can blame the IBM style of data
communications, which is different from everyone else's. ]

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

Date: 11 Oct 85 04:49:02 GMT
From: [e-mail] (P Wei)
Subject: File Transfer Between VAX And IBM PC Through LAN ?

We have several ibmpc's connected to ETHERNET LAN with the communication
program 'yterm'. I can connect the ibmpc to the vax (running UNIX 4.2) using
yterm. Therefore , the ibmpc serve as a terminal for the vax.  Now , I escape
the yterm program to DOS and invoke MSKERMIT and then type 'connect'. I get
back to the unix shell. CKERMIT is then invoked.  Then type 'send filename
<CR>'; escape (^]C) back to MSKERMIT ; type 'receive <CR>'. However, there is
no packet coming in. The screen just display 'transfer in progress......'
message forever!

(1) Am I totally wrong ? The kermit doesn't work on LAN ??? (only on tel
    line ? )
(2) Or I forgot to set some parameters ??? Can someone mail me sample session
    if same attempt has been done?

Thanks in advance.
HP Wei

[Ed. - Kermit can indeed be used over LANs, so long as the PC's connection to
the LAN looks like a serial communication port to the PC.  This would seem to
the case in HP Wei's query, since a terminal connection can be made.

In general, when the Kermit CONNECT command works but file transfer does not,
the culprit is usually (a) parity, (b) flow control, (c) packet size, or
(d) interference:

(a) Check to see if your LAN terminal interfaces are using some kind of parity
and if so, tell BOTH Kermit programs about it, using the SET PARITY command.

(b) It is command for LAN terminal interfaces to want to do xon/xoff flow
control with the PC.  Make sure you PC is set up for this (MS-DOS Kermit
does this by default in most cases).  If some other kind of flow control is
required (like RTS/CTS) you could be in for trouble.

(c) Some LAN terminal interfaces have small buffers and can't accept a normal
Kermit packet (90-95 characters) at 9600 baud.  Try using SET SEND/RECEIVE
PACKET-LENGTH for smaller packets, or else reducing the baud rate.

(c) Some LAN terminal interfaces intercept a certain character for control
purposes.  If this is a printable character, a Control-A, or a carriage return,
then this will prevent Kermit file transfers from taking place.  In this case,
try to find out how to change the box's intercept character to a control
character other than ^A or CR.  If the ^A or the CR are at fault, you can use
Kermit's SET START and/or SET END to change these.  If it's a printable
character, and it can't be changed in the LAN box, you're out of luck.]

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

Date: Sunday, 13 October 1985  06:56-MDT
From: Gijs Mos <[e-mail]>
Subject: Victor 9000 CP/M-86 Kermit Binary Wanted (On Floppy)

I want to get some files from our Victor 9000 computers to various other
machines. The best program to use seems to be kermit. The problem is how to get
Kermit running on the Victor.  I have a recent kermit distribution with a
V9000-CP/M 86 kermit on it. But I don't have an assembler, nor a way to get the
sources on the Victor 9000's disks.  So I guess I'm looking for a kermit CP/M
86 executable in Victor 9000 format.  Can somebody provide such a beasty at
media/handling costs?

Gijs Mos
Dept. of Biology
Free University
De Boelelaan 1087
1081 HV  Amsterdam
The Netherlands
{seismo,philabs,decvax}!mcvax!vu44!gijs

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

Date: 14-OCT-1985 11:41
From: Heather Holmback <[e-mail]>
To: Problems with MS-DOS Victor Kermit

We have been unsuccessful in using Kermit for a connection between a VICTOR
PC with operating system MS-DOS and the VAX, at the Max-Planck-Institut for
Psycholinguistics in Nijmegen, The Netherlands.  We are using Sirius version
1.20 by Barry Devlin, University College Dublin, April 1984, translated by
SIREXE.BAS (by Daphne Tzoar, CUCCA).  Could you please send information on
any later versions of Kermit or any recent solutions to problems.  Our main
problem is that only one file can be successfully uploaded without exiting
and reloading Kermit.  Also MSKERMIT.INI does not work as indicated in the
documentation.  Thanks.

[Ed. - Unfortunately, this is still the latest version of MS-DOS Victor/Sirius
Kermit.  No one has ever taken the trouble to write an MSXSIR.ASM module so
that Victor support would be included automatically in new MS-DOS Kermit
releases.  Any volunteers?]

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

Date: Wed, 16 Oct 85 19:11:05 CDT
From: <uwmacc!uwmcsd1!u1100u!os1100!Mark=[e-mail]>
Subject: MS DOS Kermit vs DTR

MS DOS Kermit leaves the modem signal DTR high upon exit.  This is useful
if a person wishes to exit kermit and then resume an online session, however
there are times when it is useful to drop DTR when running Kermit or when
finished with Kermit.  For instance some modems will answer the phone only
when DTR is high, so you might want to drop DTR after a Kermit session so
that YOU can answer the phone rather than your modem.

On our campus a great many of our computers are linked together by a Gandalf
PACX communications switch.  Our switch polls all ports not in use that have
DTR high.  Since we have hundreds of micro's hard-wired to the switch, if
they keep DTR high when the switch has no active connection on that port to
a given system, they bog down the polling and after a short period produce
copious timeout error messages on the switch console.  For this reason it is
important that our users drop DTR when finished with a session.
Furthermore, on some lines it is impossible to reconect or change systems
without dropping DTR first.

Ideally, it would be nice to have another SET parameter called DTR or DTR-
EXIT or DTR-QUIT or DROP-DTR that could be set ON or OFF so that when Kermit
is terminated it would dictate what state DTR would be left in.  It would
also be nice to just have a command like RESET COMx or DROP-DTR COMx.

In lieu of this facility in Kermit I have written a short COM program
which I call OFFCOM1.COM or OFF.COM for short.  The commands to create this
8 byte COM file follow.  I suggest typing them in without the comments
(things beggining with a semicolon).

DEBUG OFFCOM1.COM
A
; PROGRAM OFFCOM1
;       by Mark Zinzow
;
; Provides an external DOS command to clear
; the serial port.
; This has been tested on a Zenith Z150 running MS Dos 2.11 and an
; IBM PC AT running PC Dos 3.1.
; Note that this program is hardcoded for the address of the RS232 port.
; A better way would be to use an offset on the base address normally
; found in memory at location 40H:0.
;
    MOV DX,3FC   ; Port address for serial modem register.
                 ; (Use 2FC for com2 rather than com1)
    MOV AL,0     ; Store a zero as the value to output.
    OUT DX,AL    ; SEND the zero to the port.
                 ;
    INT 20       ;return to DOS

RCX
8
W
Q

After typing the Q you should get the DOS prompt back.  A DIR should
show the 8 byte com file OFFCOM1.COM.  This program can be run after
exiting kermit or from kermit using the run command.  I use a macro to
drop DTR with the command do off.  The macro definition looks like this:
DEFINE OFF RUN A:OFF.COM

The first program of this kind at our site was written by Mitch Blank for
the Zenith Z100.  Here's the MASM source:

[Ed. - Source omitted, stored in KER:MSXZ100.DTR.  Adding DTR control for
every system that MS-DOS Kermit runs on (not to mention all the different
internal modems in use on them) would be a very big job, so little programs
like this are probably the best approach.]

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

Date:  Thu, 10 Oct 85 13:47 CDT
From:  "David S. Cargo" <[e-mail]>
Subject: Kermit for 1750A, MOS, or Jovial?

Has anybody seen or heard of a version of Kermit written in Jovial, or
the assembly language of the 1750A for MOS (the MATE Operating System)?
We have some parts of the company that want such a thing.

[From "Burton J. Ewing" <[e-mail]>: By the way, MOS is a
derivative of Unix (by way of IDRIS?). This might be more useful info to the
Kermit community than MOS. Our people who have been peering about in MOS's
innards tell me that it is largely identical to Unix in most respects. Same
structure, same subroutine names, arguments, etc. Therefore, if we could
find another Unix hosted Kermit that was written in something we can compile
to 1750A code we are in business. The last time I checked, that meant JOVIAL
- but, who knows what will happen in the future?]

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

End of Info-Kermit Digest
*************************
-------
18-Oct-85 18:06:14-EDT,13892;000000000000
Mail-From: SY.FDC created at 18-Oct-85 18:05:42
Date: Fri 18 Oct 85 18:05:42-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #25
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Fri, 18 Oct 1985       Volume 3 : Number 25

Departments:

  KERMIT (ETC) FOR THE BLIND -
    Equipment for the Blind
    Use of Kermit by the Blind

  VM/CMS KERMIT -
    CMS Kermit V2.01
    CMS KERMIT bugs
    Kermit-CMS Fixes
    Bug Fixes for CMS-Kermit 2.01

  MISCELLANY -
    Dropping DTR on VMS
    Victor/Sirus Support on the Way for MS-Kermit 2.28

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

Date: Wednesday, 9 Oct 85 07:59:43 PDT
From: Robert Jaquiss <[e-mail]>
Subject: Equipment for the Blind

[Ed. - Some people have complained that this discussion is inappropriate
to Info-Kermit (and/or Info-IBMPC, Info-Micro, etc), but there's no
mailing list specifically for this topic.  And a lot of useful information
is coming in.  So please tolerate this digression for a while.  I'll also be
archiving all of these messages into a special file, KER:AABLIND.HLP.]

     I am a blind programmer at Tektronix Inc.  I have used Kermit on
several occations.  For my work I use a Thiel braille printer from Maryland
Computer Services.  To the computer it looks like a teletype that can send
and receive upper and lowercase.  Of course graphics are useless cursor
movement is impossible.  It is possible to deal with numbered or lettered
menus where you select the item you want by entering some character.  I have
a Versabraille as a backup terminal on which I have also used kermit it
worked fine.  The micro I am using runs CP/M so I don't have to contend with
menus.

     Here are some equipment sources that have reliable hardware.  Maryland
Computer Services sells a very good braille printer.  They have a specially
modified HP150 that talks and a accessory for a PC that will allow users to
use screen oriened software.  Telesensory Systems Inc. sells the
Versabraille (a refreshable braille display) and the Optacon (a hand held
scanner that will show you the shape of letters).  Vtek sells a tactile
display device for use on a ibm PC or Apple.

        Maryland Computer Services Inc.
        2010 rock Springs Road
        Forest Hills, Md. 21050
        Phone [phone]

        Telesensory Systems Inc.
        455 N. Bernardo
        Mountainview, Ca. 94039
        Phone [phone]

        Vtek
        1610 26th
        Santa Monica, Ca. 90404
        Phone [phone]

     If you need moe help call me at (503)  627-6346  (work).

        Robert S. Jaquiss

ucbvax!tektronix!robertj (uucp)
robert jaquiss@tektronix (csnet)
robert jaquiss.tektronix@rand-relay (arpanet)

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

Date: Fri, 11 Oct 85 9:34:53 EDT
From: Robert I. Isakower (IMD-SEAD) <[e-mail]>
Subject: Use of Kermit by the Blind

The following letter was sent to Kennith Reed 10/10/85 at your request.
9 October 1985

Dear Mr. Reed,

Recently  a request was forwarded to me from Frank da Cruz asking if I
had any information on the use of Kermit or the MS-DOS system by the Blind.

Perhaps this request was directed to me because I have tunnel vision (Retinitis
Pigmentosa).  I also have a degenerative hearing problem which places very
demanding requirements on any voice synthesizers used with visual aids for my
eyesight problems.  I have found SMOOTHTALKER on the Mac difficult to
understand.  DECTALK provides, for my personal use, the best voice output.
Please realize that I am not a judge of what constitutes good speech because
everything sounds to me as if it were coming from a distorted radio receiver.

The following information that I am including in my letter are my notes and
results of my own findings of a computer show that I attended in Ewing, New
Jersey this past September.  I have no corporate nor financial interest in any
of the company products and the information and comments that I am offering is
my personal opinion.

I sincerely hope that my enclosure will be of some assistance to you in your
research.  If I can be of any further assistance, please feel free to contact
me.
        Robert I. Isakower
        C,  Technical Systems Division

Four vendors featuring "talking computers" were at the show for aids for the
blind and the visually impaired.  I was unable to get prices for all the
equipment.

VTEK (formerly VISUALTEK)
1625 Olympic Boulevard
Santa Monica, CA   90404
1-800-345-2256

     VOYAGER Electronic Magnifiers:  $2,395 to $2,895

     Large Print Display Processor  (*) :  $2,695
(This device magnifies, up to 16X, whatever is on the screen, with
character enhancement.  It recognizes the ASCII code and redraws it as
a solid line vector, instead of an enlarged matrix of dots and spaces.)

     MBOSS-1 Braille Printer:  $3,225

     Braille Display Processor (*):  $3,495
This is a neat paperless braille output with a 20 cell tactile refreshable
braille readout.  It will provide the braille equivalent of 20 contiguous
character spaces on the computer display.  Audio signals indicate the
"position" of the 20 cell braille window on the video display.

     (*) for APPLE II, II+, IIe and IBM PC, PC-XT, PC-AT

COMPUTER CONVERSATIONS
2350 N. Fourth St.
Columbus, Ohio   43202
[phone] (after 6 PM)

     ENHANCED PC TALKING PROGRAM:  $500

     Written by a blind programmer, (Ronald Hutchinson), this is interfacing
software only, and requires the user's own computer, voice synthesizer, and
application progams.  Application programs are the programs that you wish to
use in a speaking mode and would be an additional expense with all talking
computers.  This company's program interfaces with the most used computers,
speech synthesizers and application software in the marketplace.  The company
will offer to recommend the configuration best suited to your needs and budget.

MARYLAND COMPUTER SERVICES
2010 Rock Spring Rd
Forest Hill, Maryland    21050
[phone]

     TOTAL TALK PC (microcomputer, display, speech synthesizer, keyboard)

AUDIODATA/IBM PC KEYBOARD (2 slider keys, speech synthesizer, speaker, and
display magnification with optional low cost monitor)-provides audio output
from your IBM PC.  The vertical slider key locates the desired line and the
horizontal key locates the character on the line. In this manner, the user can
hear the screen, one line at a time, character by character.

     THIEL BRAILLE (high speed-120 cps) EMBOSSER

     CRANMER-PERKINS BRAILLER (4000 character memory typewriter, braille
printer, plotter, smart terminal, portable):  $2,350.

     READY READER optical character reader (typewritten material to braille
or voice):  $11,500.

     MCS computer systems are based upon Hewlett-Packard computers which are
very well constructed.  Unfortunately, none of the above equipment was
demonstrated to me, for one reason or another.

A fourth vendor was demonstrating a speech synthesizer that works with
the APPLE II.  I wasn't stirred by it and left early, not being offerred
any literature.

COMMENTS: VTEK and MCS have been around a long time, know the business of
electronic visual aids, have the most varied product line and are probably
my best bet for the future.  They have equipment for both the visually
impaired and the totally blind.  MCS's AUDIODATA/IBM KEYBOARD promises the
simplest, cheapest and quickest fix for IBM PC users. Although it is a very
competitive computer marketplace, a small software manufacturer and system
iterfacing company such as Computer Conversations, probably with lower
production costs and more self-motivating talent, cannot be discounted.
Another company that should be investigated is the one that manufactures a
portable tactile (pins) readout device called the OPTICON.  I've watched
this used with great success and speed on printouts and teletypewriters (on
line), and I heard of some sort of adaptation to a computer display.  Note
that the OPTICON is difficult to learn to use.

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

Date: 9 October 1985, 13:36:52 EDT
From: Philip Murton             [phone]       MURTON   at UTORONTO
Subject: CMS Kermit V2.01

I think I found a small bug that is related to your edit [25],
if you have FILE set to BINARY and have compression ON.  Here's the fix:

[Ed. - Thanks!  Code omitted, but included in KER:CMSMIT.BWR.]

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

Date: Wed, 9 Oct 85 23:04 CDT
From: Brick Verser <BAV@KSUVM>
Subject: CMS KERMIT bugs

Here is another small CMS KERMIT problem.  If running on the 7171 (or
Series/1, I think), CMS KERMIT 2.x doesn't work if the virtual machine
console is not at address 9.  While all of the diagnoses know to use
the dynamically determined console address, the HNDINT SET has address
9 hard coded.  The fix is simple and obvious, except that HNDINT doesn't
allow a register for the console address field, so the HNDINT macro
has to be replaced by the hand coded equivalent.

[Ed. - See below.]

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

Date:         Tue, 15 Oct 85 09:13 EST
From:         Dave Elbon  <[e-mail]>
Subject:      Kermit-CMS Fixes

I have some fixes for Kermit-CMS 2.01.

1) Kermit-CMS is confused when TERMINAL LINESIZE is set to OFF.

2) The actual virtual console address is not used in a call to HNDINT,
   which prevents Kermit-CMS from working if the address is not 009.
   (Many, many thanks to Brick Verser of KSU for this.)

3) CP SET ACNT should be turned OFF along with MSG, WNG, and IMSG.

When Series/1 mode is on it might be possible to set TERMINAL BREAKIN to
GUESTCTL rather than changing all of the message settings.
Acknowledge-To: Dave Elbon <SYSDAVE@UKCC>

[Ed. - Thanks, the code that was included with this message has been added
to KER:CMSMIT.BWR.]

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

Date: Wed, 16 Oct 85 14:25:24 pdt
From: [e-mail]
Subject: Bug Fixes for CMS-Kermit 2.01

[Ed. - Each of these paragraphs came with code to correct the reported
problem.  The code has been omitted here, but has been added to
KER:CMSMIT.BWR.]

Fix bug at RPACK4. Calculation of crck (block=3) must begin at the first
actual packet character not at RECPKT+1. Leading pad or junk characters move
it further down.  Use pointer RECPKTP.

Fix confusion and conflicts in use of MAXOUT and LRECL.  MAXOUT controls the
amount of data collected for a write and LRECL is used only during padding
of recfm F records.  During SET FILE BIN, MAXOUT was set to LRECL and during
SET FILE TEXT it was set to MAXTXT!  This is clearly wrong.  Also, MAXOUT
was set to LRECL during SET LRECL which causes recfm V writes to be blocked
to LRECL.

This fix removes the MAXOUT change during SET FILE. SET LRECL is changed to
set MAXOUT to MAXTXT for recfm V or to LRECL for recfm F.  SET RECFM is
changed to do the same.

Fix maximum LRECL to 65535 not 65536.  CMS allows only 65535 (64k-1). CMS
aborts the write if lrecl 65536 for recfm V.  And although CMS allows the
write if lrecl 65536 for recfm F, most products cannot handle such records.

Fix MAXTXT to be 65535 not 64536 (typo)!  Remove unused MAXBIN.

Change receive to expand tabs each 8 spaces (unix,cp/m,pcdos) for text file
receives.

Redisplay the send or receive command at completion, followed by the status
message, then the completed or failed message.  This gives the user
everything they need to know at one glance.  Initial status is "No send /
receive done yet".

Fix recfm f to pad lines with spaces not nulls.

Change DECODE to interpret CR and LF from the EBCDIC after translation with
ATOE instead of from the seven bit ASCII. This allows receive of text files
that contain characters with the eight bit set with the normal ATOE table,
or by altering the the ATOE table allows receipt of text in any eight-bit
code.  Also CR LF LF gives two lines based on CR LF then LF.

Fix receive to discard the trailing control-Z for text files This catches
all cases except where the control-Z has already been written to disk, e.g.
the 65535th character of the last recfm V record or the lreclth character of
the last recfm F.

Greg Small                                    [phone]
Microcomputer Networking & Communications     [e-mail]
214 Evans Hall CFC                            ucbvax!ucbjade!ucbopal!gts
University of California                      [e-mail]
Berkeley, Ca 94720

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

Date: Thu, 17 Oct 85 21:53:16 edt
From: faron![e-mail]
Subject: Dropping DTR on VMS

We have the latest VMS Kermit running under VMS 4.whatever, talking to
an autodial modem through a DMF-32 mux. The only way the VAX can get
the modem to hang up the phone is by dopping DTR. Can anyone help with
a way to do that, perhaps with a little program like the one that was
in the last info-kermit digest for MSDOS? Are there any VMS SET TERM
parameters that are involved?

                    Sidney Markowitz

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

Date: 18-OCT-1985 13:58:48
From:[e-mail]
Subject: Victor/Sirus Support on the Way for MS-Kermit 2.28

Brian Steel of Logic Programming Associates (UK) is doing an MSXSIR.ASM at the
moment - no idea when it will be ready though.  Will let you know as soon as I
hear from him.

        Alan

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

End of Info-Kermit Digest
*************************
-------
24-Oct-85 16:16:36-EDT,18062;000000000000
Mail-From: SY.FDC created at 24-Oct-85 16:14:36
Date: Thu 24 Oct 85 16:14:36-EDT
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #26
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Thu, 24 Oct 1985       Volume 3 : Number 26

Departments:

  ANNOUNCEMENTS -
    CU20B Internet Address Changed

  MS-DOS KERMIT -
    MS-DOS Kermit Files Reorganized
    Request for Kaypro 2000 Information
    Revised HP 110, Portable Support for MS-DOS Kermit 2.28
    New TI Pro Support for MS-DOS Kermit 2.28
    Fix for Z100 MS-DOS Kermit
    MS-DOS Kermit Key Definitions for EDT
    MS-DOS Kermit and DTR

  MISCELLANY -
    C-Kermit 4C(056/057) and MacKermit 0.8(33)
    2400 Baud Modems with MNP "Protocol"
    Update on Crosstalk Problems
    CMS Kermit "Enhancements"
    Kermit for the Blind
    Kermit for the Texas Instruments 99/4A??
    Kermit on Diskette for Terak?

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

Date: Thu, 24 Oct 85 15:33:59 edt
From: Frank da Cruz <SY.FDC@CU20B>
Subject: CU20B Internet Address Changed

Because Columbia is splitting its overburdened campus network into several
discrete but interconnected chunks, the Internet host address for CU20B
has changed, effective yesterday (23 Oct 85, 7:00PM EDT), from
[192.5.43.128] to [128.59.32.128].

The change has been reported to the NIC in hopes that they will get out a
revised host table in a day or so.  Until CU20B's new address is in your
host table, you can refer to it numerically (but then you don't get the
automatic recognition of what type of host it is; e.g. people coming in
from other DEC-20s will have to explicitly tell FTP "STRUCTURE PAGE",
"TENEX", or something to that effect.)

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

Date: Wed 23 Oct 85 14:13:21-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: MS-DOS Kermit Files Reorganized

Several recent submissions of MS-DOS Kermit material (see below) have
prompted me to reorganize the MS-DOS Kermit files a bit, so now they have
more consistent names.  The names are now in the following form:

    MScxxx.typ

The file name is no longer than six characters, the file type is 3 or less.
MS is the common prefix for all the file names.

"c" is a single-letter code that categorizes the file:

  A - General information, "read me" files, etc. (like this file)
  B - Files related to Bootstrapping
  I - Initialization or command files to be read by Kermit
  K - General program documentation (Kermit User Guide chapter, etc)
  R - Release notes
  S - System-independent Source code
  V - Binaries, .BOO files, documentation for a particular Version
  X - System-dependent source code & related documentation
  Y - System-dependent terminal emulation code
  Z - System-and-modem-dependent modem control code

"xxx" is a 3 letter code to designate which system an MSV, MSX, MSY, or MSZ
file applies to:

  AP3 - NEC APC-3
  APC - NEC APC
  APR - ACT Apricot
  DM2 - DECmate II or III with MS-DOS Option
  GEN - "Generic" MS-DOS (DOS calls only)
  HP1 - HP-150
  HPX - HP-110 and HP Portable Plus
  IBM - IBM PC, XT, AT, and PCjr (note, only works on RS-232 port of PCjr)
  MBC - Sanyo MBC-550
  RB1 - DEC Rainbow-100 series
  TIP - Texas Instruments Professional
  WNG - Wang PC
  Z10 - Heath/Zenith 100

"typ" is the file type, e.g.

  ASM - Assembler source (for Microsoft or IBM Assembler)
  H   - An assembler header file (included at assembly time)
  C   - A C language source file (e.g. Lattice C)
  BAS - A Basic language source (e.g. Microsoft Basic)
  BOO - An .EXE file encoded into printable characters for bootstrapping
  BWR - A "beware" file - list of known bugs or limitations
  HLP - A help file
  DOC - A longer documentation file
  MSS - Scribe text formatter source for a HLP or DOC file
  INI - An initialization or command file to be read by Kermit
  BAT - An MS-DOS Batch file (e.g. for building from source)
  UPD - A program update history file

KER:MSAAAA.HLP has been updated to reflect the changes, as well as the new
releases.  No changes were made to the programs themselves (except as
reported below), but I expect a new release of MS-DOS Kermit to be ready in
about a month.

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

Date: Tue, 22 Oct 85 16:30:24 pdt
From: Harvey A. Iwamoto <[e-mail]>
Subject: Request for Kaypro 2000 Information

I have been patching the Generic Kermit for the built-in modem in the HP 110
with minor success.  I was able to get the modem port in the Grid Compass
working with yet another patched Generic Kermit but the file transfer would
not work.  There is some problem with either parity, number of stop or data
bits.  It seems that each one of these built-in modems behave differently
and are located in differently addresses.  I am currently trying to get a
version of Kermit working for the Kaypro 2000 but I lack address information
about the modem port.  I called Kaypro directly but they would like users to
ask their dealers.  The only Kaypro rep got fired so there is no direct line
to information.  I need to know where the modem is located (memory or
ioport) and what the busy bits are.  Also, if it must be initialized.  In
short, the type of modem if any does it emulate.  If and when I get the
patched version working, I will make it available to any or all interested
parties.

Harvey Iwamoto

[Ed. - Internal modems are poison, but if you're stuck with one I guess this
is what you have to do.  Meanwhile, see below about HP-110 modem port.]

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

Date: Tue, 22 Oct 85 21:17:23 mdt
From: [e-mail] (Dave Forslund)
Subject: Revised HP 110, Portable Support for MS-DOS Kermit 2.28

Attached is the assembler source for the HP110 Kermit (MSHPX.ASM).  It works
both on the HP110 and the new HP Portable Plus.  Port 1 is the serial port
and Port 2 is the internal modem.  Defaults are even parity and 9600 baud on
the serial port and 1200 baud on the internal modem.  We should have a
version shortly which will also drive the HP-IL RS-232 interface as Port 3.
This new code correctly handles different parity settings and works without
modification on both the HP110 and the Portable Plus.  All of the work on
this code was done by Chuck Aldrich here at Los Alamos.  The separate
assembler source is assembled with MicroSoft MASM and linked with LINK just
has described in the MSKERMIT documentation.  This executable has also been
compressed with MicroSoft's EXEPACK utility before being processed with
MSBMKB.C into a .BOO file.

[Ed. - Thanks Dave!  The files are in KER:MS*HPX.*, available via anonymous
FTP from CU20B (by those who have fixed their host tables as shown above).]

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

Date: Sun 20 Oct 85 22:13:21-EDT
From: Joe Smith [phone] <[e-mail]>
Subject: New TI Pro Support for MS-DOS Kermit 2.28

About 6 months ago, my colleague Dan Smith tried sending you the updated
versions of the sources for MS-DOS Kermit 2.28 running on the Texas
Instruments Professional.  Apparently they did not get there.  The version
in question has H19 and Tektronix emulation and works at 9600 baud.  I have
uploaded them again. Please delete KER[MIT]:MSXTEK.ASM on both MARKET and
COLUMBIA - that file has been replaced by MSYTIP.ASM.  Please update
MSAAAA.HLP and MSBUILD.HLP to reflect the new name.

                Joe Smith

[Ed. - Thanks, Joe!  The files are available on CU20B as KER:MS*TIP.*.]

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

From: John Voigt, Tulane Univ. Systems Group <[e-mail]>
Date: 10/20/85 13:02:43 CDT
Subject: Fix for Z100 MS-DOS Kermit

August Treubig of Middle South Services discovered a bug in the Z100
version of KERMIT.  It caused MS-DOS to crash.  The fix is in the GETBAUD
routine; the call to bios_auxfunc should be surrounded by "push di" and
"pop di".

[Ed. - Thanks; the change has been made in the source file, MSXZ10.ASM, and
added to the Z100 Kermit beware file.  The .BOO file is still based on the
original source until the next release of MS-DOS Kermit.]

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

Date: 11 Oct 1985 0118-EDT
From: (Carl Houseman, GENICOM Corp., via) EIBEN@DEC-MARLBORO
Subject: MS-DOS Kermit Key Definitions for EDT

I've uploaded two files which make life for the IBM-PC/Kermit user
who also uses EDT a little easier.  Together they provide all the keypad
editing functions of EDT to the PC user.  They are:

MSIVT1.EDT    - An EDT initialization file which defines the numeric
                keypad functions to match a VT-100 layout.  Use of this
                file when editing on a VT-100/VT-220 is harmless, but
                those using "real" VT-52's should not invoke it.

MSIVT1.INI    - Defines the numeric keypad and function keys as to
                match VT-100 function keys as closely as possible, as
                follows:

                F1=PF1  F2=FP2  F3=PF3  F4=PF4  F5=backspace  F6=linefeed
                F7=up-arrow  F8=down-arrow  F9=left-arrow  F10=right-arrow

                The numeric keypad is the same as a VT-100 where the keys
                are the same, with the PRTSC key acting for the VT-100
                keypad comma, and the "+" key acting for ENTER.  The
                8, 4, 6 and 2 keys become cursor keys when SHIFT is held.

If the 5 key fails to work correctly (can't effect BACKUP while in EDT),
press the NUM-LOCK key.  Also note that an "=" will appear at the top left
of the screen after starting EDT; this is a problem with Kermit's VT-52
(Heath-19) emulation, and the "=" is not really in the file.  It does
not re-appear after scrolling off the screen.

Carl Houseman
GENICOM Corp.
703-949-1323

[Ed. - These files available in KER:MSIVT1.* on CU20B.]

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

Date: Sun 20 Oct 85 13:08:20-PDT
From: Carl Fussell <[e-mail]>
Address: Santa Clara University
Subject: MS-DOS Kermit and DTR

If anyone is interested, we have added a SET DTR ON/OFF command to the IBM
PC version of Kermit...  we also found that it was needed for some of the
communication we do.  We did not submit it back to Columbia since it was
only added to this one version.  If you would like a copy, contact me.  If
anyone is interested, I will upload it to my guest account at Score where it
can be ftp'd.  As I recall, the changes were only in a couple modules.

Carl

[Ed. - Again, the problem here is that in inordinate amount of research and
effort would be required to add DTR control to all the different versions of
MS-DOS Kermit; the MSX*.ASM system-dependent modules would have to be
redesigned, possibly resulting in damage to systems that the new design
could not be readily tested on, etc.  Far better to supply a trivial little
program for toggling DTR, and define macros in Kermit for running it with
Kermit's RUN command.]

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

Date: Mon, 21 Oct 85 20:06:40 est
From: George Wyncott <[e-mail]>
Subject: C-Kermit 4C(056/057) and MacKermit 0.8(33)

Two of our staff members with Macintoshes reported the following problem:

C-Kermit 4C(056/057) seems to fail when used with MacKermit 0.8(33).
C-Kermit version 4.2(030) PRERELEASE #2 works correctly under normal
conditions.  Here's what happens with versions (056) and (057):

1. C-Kermit is executed interactively and given the "r <file>" command.

2. MacKermit is directed to send the file.

3. C-Kermit receives the file completely.

4. MacKermit continues to resend the end-of-file packet (B) continuously.

It appears that C-Kermit is not acknowledging the B packet correctly,
causing MacKermit to cycle endlessly and preventing the end-of-transmission
(Z) packet from being exchanged.

HERE'S THE STRANGE PART: If you give C-Kermit the "log debug" command
before the "r <file>", the exchange takes place without error - C-Kermit
gets the Z packet.

NOW HERE'S ANOTHER STRANGENESS: C-Kermit 4.2(030) works the opposite.
You get a correct transfer UNLESS "log debug" is commanded.  Then it
hangs up just like versions (056) and (057).

     George Wyncott
     [e-mail]

[Ed. - The problem can probably be traced to how C-Kermit sends out the ACK
to the B packet, and then closes the line.  Unfortunately, Unix tends to
close the line while sending out the packet is still on its list-of-things-
to-do-when-it-gets-around-to-them...  Solution: flush the output queue
before closing the line.  Or if that adds too much system-dependent hair,
sleep(n) before the close.  The program currently does a sleep(1), but it
may be that more than a second is needed for busy systems and/or low baud
rates, so maybe n should be some function of these.]

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

Date: Mon Oct 21 21:55:09 1985
From: Herm Fischer <hermix![e-mail]>
Reply-To: HFischer@USC-ECLB
Subject: 2400 Baud Modems with MNP "Protocol"

I looked (briefly) into the new 2400 baud modems for use with my Xenix
system.  The dealers all push versions with a built-in protocol called
MNP.  This protocol handles retries of bad characters, BUT (e.g., beware)
it is not really suitable for use on communications where the underlying
software already has a protocol.

With uucp, the MNP flow control will be incompatible, and thus one will
have to disable MNP.

With Kermit, MNP is likely to play havoc particularly where the end-to-end
flow control needs to be preserved (likely at 2400 baud on systems which
might become busy), because MNP only appears to support modem to computer
flow control.

For interactive computer access, if you need control-s or control-q, e.g.,
if you use an editor like emacs ever, then again you might have difficulties.

The people who produced the MNP protocol, and whose marketing has caused the
modem suppliers to energetically advertise its features (without being
knowledgable of its operation), ended up recommending that I buy some other
modem without the feature.

Finally, be aware that MNP is only a retry on error protocol; it is not a
forward error correction device with Hamming codes (as I expected from its
sales literature).

[Ed. - Thanks for the comments, Herm.  Any further discussion of MNP and/or
X.PC in relation to Kermit would be most welcome here.]

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

Date: Fri, 18 Oct 85 19:42:31 EDT
From: RAF@UMDC
Subject: Update on Crosstalk Problems

The latest word from Microstuf customer support is that both problems
that I encountered with Crosstalk XVI 3.6 Kermit support will be fixed
"soon".  The two problems are not stopping at the Control-Z in a text
file and setting the wrong screen intensity in the KERMIT LIST command.

Roger Fajman  <RAF@UMDC>
National Institutes of Health

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

Date: Sat, 19 Oct 85  23:07 EDT
Subject: CMS Kermit "Enhancements"
From: ("Bob Shields <VBOB@UMDB>") <@UMD2.UMD.EDU:[e-mail]>

In one of the latest "info-kermit" digests I read that someone had modified
CMS Kermit to "automatically" expand tab characters to 8 column boundaries.
If this is being considered as a standard operation, I would like to cast my
vote against it.  I have found that XEDIT will expand tabs just fine (see
the "EXPAND" and "COMPRESS" commands), and will do it to whatever columns
*I* specify, not just every *8*.  I more often use a tab setting of every 4
columns, and sometimes use ones that are not at fixed intervals (like 10,
16, 30,...  for CMS ASSEMBLE files).  Maybe this can be resolved with "yet
another SET command" in CMS Kermit.

[Ed. - You're right, it shouldn't be hardwired into the program.]

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

From: Sheldon Talmy <[e-mail]>
Date: 19 Oct 85 18:36:58 PDT (Sat)
Subject: Kermit for the Blind

In response to your msg about "Kermit for the blind", there is a great deal
being done for the visually handicapped in conjunction with computers.

One company I suggest is IRTI:

Innovative Rehabilitation Technologies Inc.
26699 Snell Lane, Los Altos Hills,Ca, 94022
415-948-8588

They have a huge catalog of products for the visually impaired, including
synths & entire turn-key systems.  If nothing else, the man who owns
the company is an excellent resource for info on the latest products.

I've been writing articles on computers for the handicapped for the last couple
of years, & have gathered several sources for products, that are ready to go
now.  If I can be of any help, send me a msg, & I'll be happy to assist you.

I note from other messages on the subject, that some research is going on that
could conceivably come under the heading of "re-inventing the wheel".
As i'm involved in the field, I might possibly be able to save time & effort,
so contact me if you like.

Shel Talmy<>Talmy@Rand-Unix

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

Date: Sat, 19 Oct 85 09:07:59 EST
From: pur-ee![e-mail] (Mike Spitzer)
Subject: Kermit for the Texas Instruments 99/4A??

I've heard someone mention this... does Kermit exist for the 99?  If not,
why not?

          Mike

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

Date: Wed 23 Oct 85 16:01:10-EDT
From: [e-mail]
Subject: Kermit on Diskette for Terak?

     I have a Terak which I am trying to use as terminal for the flourscence
center vax.  I would like to be able to transfer Kermit to the Terak.  If you
know of anyone who has(had) a Terak and has Kermit on 8 inch single density
floppies, please send me mail.

                     Thank you,
                          Miriam Gulotta  ( MG1k@cmcctc)

[Ed. - Can anyone help?]

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

End of Info-Kermit Digest
*************************
-------
28-Oct-85 15:45:11-EST,8780;000000000000
Mail-From: SY.FDC created at 28-Oct-85 15:43:16
Date: Mon 28 Oct 85 15:43:16-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #27
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Mon, 29 Oct 1985       Volume 3 : Number 27

Departments:

  ANNOUNCEMENTS -
    CU20B Address, Info-Kermit-Request Mail Trouble
    New Release of BBC Acorn Kermit
    Kermit for GEC-4000 Minicomputers
    New ACT Apricot Support for MS-DOS Kermit 2.28
    Kermit for RMX86

  MISCELLANY -
    MacKermit vs Cray
    C-Kermit 4.2(030) Source Wanted
    VMS Kermit-32 bug fix
    CMS-Kermit Expanding Tabs on Receive
    C-Kermit on Diskette for Chromatics 7900?

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

Date: Mon 28 Oct 85 12:42:42-EST
From: Frank da Cruz <[e-mail]>
Subject: CU20B Address, Info-Kermit-Request Mail Trouble

Apologies to all who have had trouble with the host address change for CU20B.
It was announced correctly in the last issue of Info-Kermit, but unfortunately
it was reported incorrectly to the NIC, which had CU20B listed as [128.59.32.1]
rather than [128.59.32.128] for several days.  Apologies also to those who
had trouble mailing to Info-Kermit or Info-Kermit-Request at CU20B, even when
the host address was right -- it all started when a disk filled up...
Everything should be back to normal now.

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

Date: Mon 28 Oct 85 12:42:30-EST
From: Frank da Cruz <[e-mail]>
Subject: New Release of BBC Acorn Kermit

This is to announce Version 1.02 of BBC Acorn Kermit from Alan Phillips of
Lancaster University, UK.  It includes significant improvements and bug
fixes over the current release, and is in extensive use in the UK.  The files
are in KER:BBC*.* on CU20B, available via anonymous FTP.

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

Date: Mon 28 Oct 85 12:45:02-EST
From: Frank da Cruz <[e-mail]>
Subject: Kermit for GEC-4000 Minicomputers

This is to announce Kermit for the British GEC 4000 Series minicomputers with
OS4000/RAL from Martin Loach of Rutherford-Appleton Laboratories.  The files
are in KER:GEC*.* on CU20B.

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

Date: Mon 28 Oct 85 12:50:08-EST
From: Frank da Cruz <[e-mail]>
Subject: New ACT Apricot Support for MS-DOS Kermit 2.28

This is to announce a new release of the ACT Apricot support for MS-DOS
Kermit 2.28 from Ralph Mitchell of Brunel University, Uxbridge, Middlesex,
UK.  The files are in KER:MS*APR.* on CU20B.

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

Date: Mon 28 Oct 85 12:52:52-EST
From: Frank da Cruz <[e-mail]>
Subject: Kermit for RMX86

This is to announce a second Kermit program for Intel x86/xx systems with
the RMX86 operating system.  This one is written in PL/M by Robert Schamberger,
Wilson Lab, Cornell University, Ithaca NY 14583.  It is available on CU20B as
KER:RMX*.* (the other one is in KER:I86*.*; they are completely different
programs -- reviews or comparisons would be appreciated).

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

Date: Tue, 22 Oct 85 12:18 pst
From: "pugh jon%b.mfenet"@LLL-MFE.ARPA
Subject: MacKermit vs Cray

I have been trying to use the MacKermit version 0.8(33) with our Cray
supercomputers and it has failed to go.  I have an earlier version of
Kermit from Stanford that does work.  The PC Kermit also works, but only
version 2.27 which is because it ignores an echoed packet, or so I am told.

I have tried using Kermit-PC version 2.26 with our Crays and it exhibits
the same symptoms MacKermit does.  I was wondering if MacKermit could be
modified by the creator there at Columbia to ignore the echoed packet that
gets returned.  Perhaps an investigation into the changes between the two
versions of Kermit-PC would be helpful.  I am willing to help in any way
that I can, including lots of testing.

For information purposes, I am a consultant at the National Magnetic Fusion
Energy Computer Center in Livermore, California, and we have users all over
the country using our four Crays.  It would be beneficial if we could have
Kermit working for all the physicists trying to use their Macs with our
Crays.  I would personally hate to see people forced to use a PC.  Yuck!

                                                Yours Truly,
                                                  Jon Pugh

[Ed. - MacKermit suffers from a bug endemic to all the current releases of
C-Kermit, having to do with padding.  The problem is that whenever padding
is being used, and the padding character is not null (0), the checksum is
calculated incorrectly, and seems to only effect the Crays, since they are
the only ones that need non-null padding on Kermit packets.  The problem
will be fixed in the next release.]

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

Date: Wed, 23 Oct 85 10:34:39 CDT
From: Gregg Wonderly <[e-mail]>
Subject: C-Kermit 4.2(030) Source Wanted

We want to update our Kermit server to the current release level, but have
misplaced the original source we worked from, preventing us from getting
diffs to show the changes we have to install to the current release.  Does
anyone out there have vanilla source for the C-Kermit which announces itself
as "C-Kermit 4.2(030) PRERELEASE # 2, 5 March 85"?

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

Date: Fri, 25 Oct 85 16:35:33 edt
From: [e-mail] (John Owens)
Subject: VMS Kermit-32 bug fix

Here is code for two changes to VMS Kermit 3.1.066.  In the diffs I changed
the version number to 3.1.067, but you should do whatever is appropriate with
that.  The first change is to the VMSMSG module to correct a bug with CRC mode.
Previously, if you sent 8 bit data without 8 bit quoting, the CRC would be
computed incorrectly, since the code stripped the high bit if parity was none.
The fix is just to reverse the condition and strip the high bit if the parity
is NOT none.  Diffs to the .MAR file are enclosed, but you should rebuild it
from the .BLI file instead - my changes are just hacks by hand, since I don't
have a BLISS compiler.

[Ed. - Code omitted, but added to KER:VMSMIT.BWR.]

The second change is optional, and is just my preference.  This change, to
the VMSMIT module, makes FINISH not cause the program to exit, but just to
return to the Kermit-32 prompt, so that, for example, statistics could
be printed.  This agrees with what C-Kermit does, but I believe Kermit-20
exits the program on a FINISH....  Remember not to even bother with the diffs
to the .MAR file if you have access to a Bliss-32 compiler - my changes are
definitely not what the compiler would do.

[Ed. - Code also omitted, but added to KER:VMSMIT.BWR.]

John Owens                UUCP:
General Electric Company          ...!decvax!mcnc!ncsu!uvacs!edison!jso
Factory Automated Products Division    Compuserve: 76317,2354
Charlotesville, VA            Phone:    [phone]

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

Date: Sun, 27 Oct 85 21:44:59 pst
From: [e-mail]
Subject: CMS-Kermit Expanding Tabs on Receive

I struggled over whether to expand tabs during receive or not.  Clearly
leaving the file alone is more flexible for the experienced CMS user.
However, most of our users do not want to bring up XEDIT and EXPAND tabs on
every file they upload.  Most of the systems that use Kermit to send to CMS
use the tab8 convention and use it freely without the users direct knowledge
of it (msdos,cpm,unix).  I have decided to make tab expansion on receive the
default and use a modeless prefix to disable it.

Also, that mod I submitted (UCB09) is flawed because it depends on being
able to overflow the ARBUF by 8 characters which is only OK because
CMS-Kermit 2.01 misallocates the buffer in the first place.  Please remove
UCB09 until I fix it.

Greg Small                                    [phone]
Microcomputer Networking & Communications     [e-mail]
214 Evans Hall CFC                            ucbvax!ucbjade!ucbopal!gts
University of California                      [e-mail]
Berkeley, Ca 94720

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

Date: Fri 25 Oct 85 13:14:50-EDT
From: Frank da Cruz <[e-mail]>
Subject: C-Kermit on Diskette for Chromatics 7900?

Gina Morinaka of Hercules Aerospace in Utah needs to get C-Kermit on an
8" diskette for the Chromatics 7900 workstation.  If you can help her,
please call 801-250-3776.

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

End of Info-Kermit Digest
*************************
-------
 1-Nov-85 17:11:24-EST,12809;000000000000
Mail-From: SY.FDC created at  1-Nov-85 17:10:48
Date: Fri 1 Nov 85 17:10:48-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit-Digest V3 #28
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Fri,  1 Nov 1985       Volume 3 : Number 28

Departments:

  ANNOUNCEMENTS -
    Pascal/VS Kermit/CMS
    7171 Support for IBM Mainframe MUSIC Kermit
    Another Kermit for Intel Micro Development Systems

  MISCELLANY -
    We Are Working on a Robust Kermit for IBM MVS/XA TSO
    7171/Series 1 and Kermit-MS interaction
    Problems with New HP-110 MS-DOS Kermit Support
    Commodore-64 Kermit V1.7

  QUERIES -
    Need Kermit Diskette for IBM PC with Xenix
    Need Kermit 3.5" Diskette for HP-9816
    Need Kermit Diskette for HP-9000/S500 HP-UX System

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

Date:    Thu, 31 Oct 85 10:06 EST
From:    [e-mail]
Subject: Pascal/VS Kermit/CMS

I am sending you an updated source for my Pascal KERMIT/CMS along with an
updated FULLSERV ASSEMBLE file.  The new source will handle some additional
server commands and fixes some minor bugs.  A major bug shows up when using
the old KERMIT source with the newer version of the PASCALVS compiler which
does a more careful checking of strings.  The updated source will correct
this fault.

[Ed. - The files are in KER:CM2*.* on CU20B, available as usual via
anonymous FTP.]

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

Date: 24 October 1985, 16:58:52 EST
From: [e-mail]
Subject: 7171 Support for IBM Mainframe MUSIC Kermit

Here is a new version of KERMIT for MUSIC (IMUSIC), based on the
Indiana/Purdue original, but with support for the 7171 front end added,
approved by the original author Marie Schriefer at INDYVM.
                                                    J.V.

[Ed. - The files are on CU20B as KER:IMUSIC.*.]

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

Date: Fri 1 Nov 85 4:21pm EST
From: Frank da Cruz <[e-mail]>
Subject: Another Kermit for Intel Micro Development Systems

This is to announce yet another version of Intel Microcomputer Development
System (MDS) Kermit, for the ISIS operating system, written in PL/M.  It's
an upgrade to the original version, and adds the ability to talk to a Kermit
server (GET, FINISH, BYE, (remote) CWD) and a way to send multiple files
using a special command LSEND that reads the list of files to send from the
specified file.  It was submitted by

  Hanh Tuan Truong
  Leigh Instruments ltd.
  2680 Queensview Dr.
  Ottawa, Ontario
  K2B-8J9 CANADA

The files are in KER:MD2*.* on CU20B.  The MDS*.* files are still there too.
It seems that this new version is based on the original release of MDS
Kermit, which in the interim was updated & fixed at Intel's DSSO department.
If anyone who cares about these systems would care to do a comparitive
review for Info-Kermit, it would be most welcome.  Better still would be an
integration of the two programs into a single one.

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

Date: 29 Oct 85 1500 WEZ
From: [e-mail]  (Franklin A. Davis)
Subject: We Are Working on a Robust Kermit for IBM MVS/XA TSO

We have a robust version of Kermit for TSO systems that is adapted from the
CMS Pascal Kermit.

It includes server mode with most of the possible remote commands.  In local
mode you can execute TSO commands from within Kermit.  Coming soon will be
wildcards, though that is tough on an IBM...

MVS and CMS are so different that it will not be possible to have a single
version for both systems.  However, Fritz will be maintaining it for at
least the next couple of years.

Anyone interested in 'Beta test' of TSO kermit, please contact us directly.

-- Fritz & Franklin <[e-mail]>
Institut fuer Informatik und angewandte Mathematik
Universitaet Bern
Laenggassstrasse 51
CH-3012  Bern
Switzerland

[Ed. - How about Series/1 (4994, 7171, ...) front-end support?  We're
getting such a proliferation of MVS/TSO IBM mainframe Kermits -- versions in
assembler, Pascal, and PL/I, with and/or without Series/1 support, ...

1. U of Chicago's, based on Columbia's original (primitive) CMS Kermit, only
   for use on line-mode TTYs.

2. U of Toronto's, based on Chicago's but only for use thru Series/1 or 7171.

3. Rice University's, supposedly fancy, in PL/I, but you have to buy their
   support functions from them.

4. University of Maryland is working on yet another completely different,
   fancy TSO Kermit (in assembler?).

5. And now this one.  Not to mention the two versions for VM/CMS; when it
   rains...]

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


Date: Fri, 01 Nov 85 11:05:31 cet
From: [e-mail]
Subject: 7171/Series 1 and Kermit-MS interaction

We have found that our new 7171 protocol converters work much less well for
us than the Series 1 boxes for Kermit file uploading with the newer
generation of IBM-like PCs.  The symptoms are a 7171 hang up when uploading
files from the PC AT or Zenith 158s over 9600 bps direct connect lines.  We
have been using Kermit heavily for about a year, and normally these devices
upload fine, but if the Kermit-MS 2.28 they are running is YAKing faster
than normal due to (1) use of a mono screen (2) use of a faster crystal (3)
use of FANSI-CONSOLE to speed screen writing, then the 7171 hangs in a
pretty big way.  Multiple master resets must be sent to the 7171 to get
session control back again.  If one SETs DEBUG ON in Kermit-MS, then the
time spent writing the packets to a color screen slows things down enough
to work unless FANSI-CONSOLE is in there speeding things up again.  The
evidence is as follows:

Connected through 7171 to Kermit-CMS 2.01:
IBM PC AT, 8mhz, EGA & ECD, with DEBUG OFF --> failure
IBM PC AT, 8mhz, EGA & ECD, with DEBUG ON  --> success
As above w/ FCONSOLE, DEBUG ON or OFF      --> failure
Zenith 158, 8mhz, monochrome, DEBUG ON|OFF --> failure
Zenith 158, 8mhz, color, DEBUG OFF         --> failure
Zenith 158, 8mhz, color, DEBUG ON          --> success

Connected through a Series 1 all of the above succeed.  The SEND PACKET in
all cases was 64 since the 7171's won't work from my AT under any
conditions with a larger size.  The only conclusion I have been able to
draw is that the slow screen writing routines of the color BIOS slow
Kermit-MS down enough such that when DEBUG is ON the YAK packet from
Kermit-MS does not go back until the 7171 is ready.  I assume this is
because the incoming packet is being written to the screen before the YAK
is sent (though I have not checked the Kermit code to verify this).  I am
inferring that the problem is due to the 7171 because (1) it works through
the Series 1 (2) many Master Resets are required to wrest control back, but
conceivably the issue is one of CMS Kermit's control of the 7171 rather
than the box's internals.

Any suggestions or relevant experiences would be appreciated.
Michael Palmer
Washington University Computing Facilites
Bitnet address:  PCSC@WUVMD

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

Date: 26 Oct 1985 2242-EDT
From: LCG.KERMIT@DEC-MARLBORO
Subject: Problems with New HP-110 MS-DOS Kermit Support

Took the new version of MSXHPX.ASM last night.  Unfortunately, in being
compatible with both the 110 and the PLUS, it develops several problems on
the plus.  In particular:

1. PORT 2 is set to AUX.  On the plus, this is not the INTERNAL MODEM
necessarily, but is the default modem set in the system configurator.  To
insure that the internal modem is used, the PORT selection logic should
select COM3, not AUX.

2. All character output is being sent to the punch via MSDOS PUNOUT call.
This is slow, and, worse, will direct output to AUX even if the serial port
is in use.

3. Minor points: the program starts with even parity and 7 bit words.  This
causes chaos in every situation we tried.

Changes are shown below by giving at least one line before and after each
change.  Would appreciate your forwarding to appropriate authority.

Also, leaving DTR on on the PLUS is not just a nuisance, it is deadly, since
you also leave on the MODEM or SERIAL interface, which eats the battery at
incredible rates.  I have attached to the end of this a short program to
turn those off.  I run KERMIT on the plus from a command file KERMIT.BAT
which contains the following:

    MSXHPX 1%
    MODEMOFF

This guarantees modem/serial port doesn't run down battery.

Mike Mellinger  800-325-0888

Modified MSXHPX follows:

[Ed. - Code omitted, included in KER:MSXHPX.BWR for now; see next message.]

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

Date: Mon, 28 Oct 85 23:08:28 mst
From: [e-mail] (Dave Forslund)
Subject: Re: Problems with New HP-110 MS-DOS Kermit Support

In response to the problems with MSXHPX on the Portable Plus:

1. We felt the choice of the AUX port was an advantage because one could
also choose the HP-IL loop RS-232 interface from the PAM without having to
add an additional port in kermit itself.  It is true to use the modem with
Kermit one must have selected it in the PAM.  However, if it is selected
then port 1 is the serial port and port 2 is the modem (or HP-IL RS-232).
Choosing COM3 for the Portable makes the code incompatible with the HP-110.

2. We used this call as it was in the generic Kermit.  We will try this
suggested fix.

3. Our choice of even parity and 7 bit words is what works on our network
here at Los Alamos and avoided us having to have a .ini file to modify the
defaults.  If others like other defaults, so be it.

4. Thanks for the modemoff file.  It will be a big help.

By the way, for this code to work properly on the internal modem in the
HP110 still requires some work, as the modem does not respond
conversationally but requires special ioctl commands to dial, etc.  We have
not pursued this any further.

Dave ([e-mail])

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

Date: Sat 26 Oct 85 13:05:13-EDT
From: [e-mail]
Subject: Commodore-64 Kermit V1.7
To: [e-mail]

Kermit 1.7 for the Commodore 64 is completely non-functional.  There is a
bug in the VT52 emulation routines which crashes the program every time I
attempt to use Emacs.  This same bug crashes the program whenever I try to
send or receive a file, since the current packet, number of packets sent,
etc, are displayed on the screen using the same routines.  Does a quick fix
exist for this problem, or do I have to wait for the next version of Kermit
for the problem to be fixed.  As it stands, Kermit 1.7 is completely useless
for file transfer.  HELP!!!!

                Roger Preisendefer
                RP0Q @ CMU-CC-TD


[From Eric <[e-mail]> - C64 Kermit-65 V1.7 works fine at
300 baud or 1200 baud.  There are no bugs in the VT52 emulation, and no
'serious' (or well known) bugs in the file transfer routines.  Chances are
this person did not download the files correctly to his C64 - I use Kermit
with Emacs extensively and send files all the time with much sucess.  I
suggest that this person send away to Robert Lenoil for a C64 Kermit
diskette -- 229 Commonwealth Ave, Boston MA 02116 -- $7.00 incl postage.]

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

Date: Tuesday, 29 October 1985 07:30:30 EST
From: [e-mail]
Subject: Need Kermit Diskette for IBM PC with Xenix

I would like to have a kermit on my IBM PC running under Xenix (and
talk to the MS-DOS PC).  Where can I get a copy of one?

Sriram

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

Date: Tue 29 Oct 85 14:28:43-EST
From: Frank da Cruz <[e-mail]>
Subject: Need Kermit 3.5" Diskette for HP-9816

Marilyn Evans, Polaroid Corp, Cambridge MA, 617-577-3662 or -2262, needs
Kermit for the HP-9816.  She thinks the HP-Pascal version that was written
for the 9836 a while back might work.  Could anyone send it to her on a
3.5" diskette so she can try it out?  Thanks!

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

Date: Tue 29 Oct 85 11:39:33-PST
From: David Liu <[e-mail]>
Subject: Need Kermit Diskette for HP-9000/S500 HP-UX System

Is there anyone ever installed and run Kermit on HP-9000/500 computer (which
runs HP-UX)?  This is what I am trying to do and may save me some of the
efforts if I can get some advise.

Dave Liu@SIERRA-SU

[Ed. - Again, the best thing would be for someone to send him a diskette.
Any volunteers?  (Contact Dave directly)]

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

End of Info-Kermit Digest
*************************
-------
13-Nov-85 17:53:13-EST,16634;000000000000
Mail-From: SY.FDC created at 13-Nov-85 17:52:28
Date: Wed 13 Nov 85 17:52:27-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #29
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed, 13 Nov 1985       Volume 3 : Number 29

Today's Topics:
                           Kermit the Frog
                           Kermit the Book
                         New Kermit-11 Coming
                         Kermit for NEC APC-3
           C-Kermit 4C(057), Mackermit 0.8(33), and 2.9BSD
                 Okstate's Kermit Server Active Again
       Binary File Transfer Between C-Kermit and VMS Kermit-32
                  Kermit Problems, Notes and Praises
                      Osborne Executive Kermit?
                          Kermit & MUSIC SP

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

Date: Tue 12 Nov 85 15:26:44-EST
From: Frank da Cruz <[e-mail]>
Subject: Kermit the Frog

The new (December 1985) MACWORLD Magazine features a cover story on Kermit
-- no, not Kermit the file transfer protocol, but Kermit the Frog, the
proprietor of a whole new line of Muppet-based educational software.
"Kermit" is a trade mark for some of this software, like "Kermit's
Electronic Story Maker."  This is one among the many good reasons why "our"
Kermit should (and can) not become a commercial product.

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

Date: Wed 13 Nov 85 17:02:22-EST
From: Frank da Cruz <[e-mail]>
Subject: Kermit the Book

I'm writing a Kermit book for Digital Press.  I hope it will be out in
Spring or Summer 1986, and I hope the price will be relatively low (it
can't be set yet, because the manuscript isn't done, but there is general
agreement that it should not be a high-priced item).  I hope the book will
be a big improvement over the Kermit User Guide and Protocol Manual; it
will contain all the information from these manuals, plus a lot more --
background in data communications, file organization, etc; more cohernet
organization, lots of illustrations, tables, code fragments, etc etc.  But
it will lack the detailed descriptions of the various Kermit programs found
in the User Guide; that information will continue to be supplied along with
each program.  Anyhow, the idea is for the book to "work" for everyone from
the utter novice to the Kermit programmer, pehaps in conjunction with a
program-specific handout, and to promote Kermit a little more as a serious
protocol and maybe encourage future Kermit program contributors to stick to
the "standard" command syntax a little better and provide code examples to
make it easy for them to include server mode, 8th-bit quoting, etc etc.

Preparing the manuscript, plus doing my "real job," is keeping me pretty
busy, which partly explains the lag between Info-Kermits (the rest of the
explanation is that there hasn't been a lot of activity recently anyway).
Occasionally I might bother someone for a bit of specific information to
round out some table or other.  Here's one tidbit I haven't been able to
dig up anywhere -- what multiplexing technique is used by VA-3400 1200bps
modems (frequency division?) and at what baud rate does it transmit (some
1200bps modems actually transmit at 600 baud).  Here's another one -- does
anyone know the etymology of "D-Connector" or "DB-xx" (as in DB-25)?

Also, if anyone wants to fill in the following questionnaire and send it
back to me, I'd be most grateful.  This is just for purposes of filling in
some illustrative tables, contrasting the diverse communication and
file architectures of various machines and OS's.  I've already got info
for the common ones, like DEC-20, VAX/VMS, IBM VM/CMS, MS-DOS, etc etc, but
am looking more for the "strange" ones -- HP minis, DG minis, P-E minis,
Prime computers, mainframes of Burroughs, Honeywell, Sperry, CDC, etc.

Machine, Model(s):
Operating System:
Version of OS following info applies to, if it makes a difference:
Machine Word Size:

Text Byte Size, and how many bits within byte are used for a character, and
what happens to any leftover bits:

Directory structure (flat file system, 1 level of directory, hierarchical):

Filespec format (indicate punctuation and max length of each field, e.g.
DEV:[DIR]NAME.EXT;n with DEV=6, DIR=12, NAME=8, EXT=3, n=numeric generation.

Text code: (7-bit ASCII, 8-bit extended ASCII, 8-bit EBCDIC, etc):

Normal record separation technique for text files (CRLF, LF, CR, RCW, fixed
block, etc):

EOF indication (nearest character, word, block); what happens at EOF if
EOF not recorded exactly (e.g. CP/M ^Z trick):

Asynchronous Communications (But first please indicate if the system
normally prefers some other style, like IBM-style synchronous block mode
terminals):

Duplex (full, half):

Flow Control (half duplex line turnaround handshake char, XON/XOFF, ENQ/ACK,
ETX/ACK, etc):

Required or default parity:

Special or unusual characteristics worth noting about file system,
text representation, or communications:


Thanks to anyone who responds!  Also, any suggestions of a general (or
specific) nature would be most welcome, especially from people who have had
problems with some aspect of Kermit that could have been avoided by better
documentation.

- Frank

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

Date: 8 Nov 1985
From: [e-mail]
Subject: New Kermit-11 Coming

 There currently is a version 2.38 of Kermit-11 available.  The version will
only be available via Bitnet or dialup to UOFT02 until December 85 as I am
waiting for modifications from some other people regarding M+ v3 and also
PRO/TMS support. As always, the file K11CMD.MAC has the edit trail.

How to get it:

Bitnet:

from VM/CMS:    CP SMSG RSCS MSG UOFT02 KERMSRV DIR
                CP SMSG RSCS MSG UOFT02 KERMSRV SEND K11*.*

from VMS Jnet:  $ SEN/REM UOFT02 KERMSRV SEND K11*.*

Dialup:

        [phone]
        Service class  VX785A
        User: KERMIT
        Password: KERMIT

Source and hex files are in KER:, binaries are in KERBIN:

[Ed. - I imagine Brian will be sending the successor to 2.38 to Columbia
when it's ready; will announce it when it arrives.]

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

Date: Fri, 8 Nov 85 13:55:55 est
From: Phil Johnson <[e-mail]>
Subject: Kermit for NEC APC-3

Since you had the source but not the binary for NEC APC-3 Kermit,
I built the binary for you.

Phil Johnson

[Ed. - Thanks!  It's in KER:MSVAP3.BOO ("boo" file) and KB:MSVAP3.EXE
(8-bit binary).]

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

From: Vic Abell <[e-mail]>
Date:  8 Nov 1985 1438-EST (Friday)
Cc: [e-mail], [e-mail], [e-mail]
Subject: C-Kermit 4C(057), Mackermit 0.8(33), and 2.9BSD

C-kermit 4C(057) does not work properly with 2.9BSD, as distributed
by Berkeley.  It may work with the Harvard, Seismo distribution, but
I haven't tested that.

One problem is that the Berkeley 2.9BSD distrubution does not support
the 4.2BSD timeval and timezone structures and the functions that
surround them.  Thus, all of the #if tests in ckutio.c that assume
2.9 to 4.2 equivalence in that area must be undone.

A second problem is that the protocol rule for <rdata>Z in ckcpro.w
tests for a return value from the function reof() in ckcfns.c  Reof()
does not return a value.  The protocol rule works on 4.2BSD out of
happenstance - apparently the return value register happens to be
non-negative.  Under 2.9BSD it doesn't work - apparently because
the return value register happens to be negative.

I am enclosing diffs that show the changes necessary to eliminate
these two problems.  The diffs for ckcpro.w also include a fix to the
<rfile>B protocol rule that I reported earlier to this mailing group.
It prevents the EOT ack from being lost in interactive mode when the
terminal is switched from cbreak to cooked.  Note that the sleep time
was raised to five seconds on the slower 11/70s.

Vic Abell, [e-mail]

[Ed. - Thanks!  Diffs omitted, appended to KER:CKUKER.BWR, will be
included in the next release.]

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

Date: Sun, 10 Nov 85 17:42:19 CST
From: Gregg Wonderly <[e-mail]>
Subject: Okstate's Kermit Server Active Again

    Due to an obscure bug in some modifications made to the KERMIT SERVER at
OKSTATE, the server has not been able to service GET requests from users.
This problem has been located, and fixed.  We appologize for any headaches
caused (We had a few here in finding this one).  Thanks to those who pointed
the problems out initially.

Gregg Wonderly
Department of Computing and Information Sciences
Oklahoma State University

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

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

Date: Fri, 1 Nov 85 21:55:26 pst
From: [e-mail] (David Robinson)
Subject: Binary File Transfer Between C-Kermit and VMS Kermit-32

I am having troubles transfering files to and from a SUN-2/170 running
Ckermit 4C(57) and a VAX/VMS3.7 running Kermit-32(66).

Transfering both ways one side or the other is mapping ALL ^J's to ^M's
which reaks havic on my binary data.  I have set file type to binary on
both machines with no success.  When I set file type fixed on the VAX (A
suggestion from a friend) The file makes it thru the data transfer part but
dies on the final handshaking with an error "unimplemented server command".

We are constrained to use only the VAX as a server, our connection allows
logins only on the VAX side.

Any and all help on this problem would be appreciated.

"How to get raw binary files from Ckermit to kermit-32?"

                David Robinson
                [e-mail]

[Ed. - I've heard complaints like this before, but don't have a VMS system
to track them down with, and the folks at Stevens Inst of Tech are badly
bogged down in other work for the time being.  Anybody out there can help?]

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

Date: Wed 6 Nov 85 21:25:42-EST
From: Christopher Lent  ([e-mail])
Subject: Kermit Problems, Notes and Praises

PROBLEMS:
*****
MSRVRB1.BOO - MS-DOS Rainbow-100 boot file.
The first line of KER:MSVRB1.BOO contains:
    KER:MSRB10.EXE
rather than
    MSVRB1.EXE
A minor oops but it could give a first time user a problem.

[Ed. - Thanks, I fixed it.]

*****
MSSDEF.H - MS-DOS KERMIT macro assembler (MASM) source header file.
    Perhaps a stronger warning should be included that KER:MSSDEF.H
must be renamed to MSDEFS.H before compiling.

[Ed. - Thanks, I put warnings in appropriate places.]

*****
MSIBMP.EXE - Compiling your own:
I compiled MSIBMP.EXE on an IBM/PC-XT using V2.0 MASM with the suggested /S
option and have experienced no problems with the resultant V2.28 IBM-PC KERMIT.
*****

notes:
+++++
MSIBMP.EXE - IBM/PC KERMIT through a DECServer 100:
    I have been using KERMIT V2.27 and now V2.28 through DEC's new
DECServer 100 terminal server.  All I can say is WOW!!  The configuration
consists of a VAX-11/780 with VMS 4.1 running KERMIT-32 V3.1.066 and IBM/PC's,
and XT's running PC-DOS 3.1 and KERMIT V2.27 and V2.28.

    Kermit works fine with the initial settings on the terminal server.
The server doesn't interfere with the KERMIT protocol.  KERMIT file transfers
exhibit no visible loading of either the terminal server or VMS, even at 19.2K
baud.  The local CWD command has greatly aided doing incremental PC/XT backups
to corresponding VMS directories.
+++++
Note - Converting "BINARY" Text files on VAX/VMS created by KERMIT-32.

    Most users doing backups of PC's to our VAX use the KERMIT-32 SET
FILE TYPE BINARY option so the .COM and .EXE files will transfer properly.
This results in a minor problem when text file transferred as "BINARY" files
are to be edited or revised on the VAX.  A workaround procedure for this
follows using the age-old editor TECO.  Since TECO's calling sequence has
changed in VMS 4.x two versions are given.

VMS 3.x:

$ ! Untested
$ TECO :== $SYS$SYSTEM:TECO.EXE
$TOP:
$if "''p1'" .eqs. "" then inquire p1 "Binary file to be converted to text"
$if "''p1'" .eqs. "" then goto TOP
$WRITE SYS$OUTPUT "Converting file ''p1' to text format."
$! the line after edit/teco 'p1' should contain EX<ESC><ESC>
$! where <ESC> is the escape character (decimal 27, octal 33, hex 1B)
$TECO 'p1'
EX$$
$write sys$output "File ''p1' converted to text format."
$exit

VMS 4.x

$! Works!
$TOP:
$if "''p1'" .eqs. "" then inquire p1 "Binary file to be converted to text"
$if "''p1'" .eqs. "" then goto TOP
$WRITE SYS$OUTPUT "Converting file ''p1' to text format."
$! the line after edit/teco 'p1' should contain EX<ESC><ESC>
$! where <ESC> is the escape character (decimal 27, octal 33, hex 1B)
$edit/teco 'p1'
EX$$
$write sys$output "File ''p1' converted to text format."
$exit

Usage:
    If the above file is called CVT.COM in the current directory
simply type type following to convert the "BINARY" text file FILE.BIN
    $ @CVT.COM FILE.BIN
and the new version of file.bin will be in VMS's default text file format.

Beware:
    If the "BINARY" text file has lines which exceed 255 characters,
VMS's EDIT/EDT editor will truncate these lines during editing.
+++++
Praises:
#####
Ckermit - general praises
    Nice Job!!!  I was previously using the version now relegated to the
to the documentation.  The new version work fabulously on our AT&T 3b5
computer.   I've even managed to get a version running on a V6 UNIX system.
The V6 version was compiled using a modified V7 compiler so I doubt it would
be of any use to others.  With quite a bit of emulating V7 system calls,
I produced a working version of Ckermit.  Just a warning, in split I/D spaces
on the PDP-11, some V6 system calls do NOT work.
#####
Final comments:
    Kermit is fabulous.  I now try to get it to friends as a matter of
course.  At first they're a little confused as to why they need Kermit, but
about a month after they come back and say "Wow, how can I get Kermit for
machine XYZ-123/X?" and we figure out how to load the initial copy.
    I must admit I'm a convert.  When I originally read about Kermit in
BYTE, I thought "Oh, yet another ASCII file transfer package".  Reading on I
thought, "Hmm, sounds pretty easy to implement".  Then I put these thoughts on
the back burner for a few years.
    In March of 1985, I found Kermit source on a FIDO BBS system and tried
it on the PC.  It worked wonderfully. They also had 'C' source for a Unix
Version of Kermit. I loaded it on our 3b5 and our V6 system and it worked with
only minor modifications. The BYTE articles made the debugging much more
simple.
                    Keep up the good work!
                    Chris Lent
                    [e-mail]
                    Care of:
                    oc.pedhem@cu20b

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

Date: Wed, 6 Nov 85 20:38:02 pst
From: George Cross <[e-mail]>
Subject: Osborne Executive Kermit?

Can someone inform me of the status of the Osborne Executive version
of Kermit?  Browsing through the mail archives (83/84 Epoch) one finds
a flurry of interest when the OE  was alive but it seems to have faded
out.  My questions are:

1. Does the Osborne 1 version work on the Osborne Executive?
2. Does the Generic CPM version work on the Executive? If so how?

I don't receive this list regularly, so a mail reply to me would be preferred.
Thanks,

 George R. Cross        [e-mail]
 Computer Science Department    [e-mail]
 Washington State University    [e-mail]
 Pullman, WA      99164-1210    Phone: [phone] or 509-335-6636

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

Date: Fri, 08 Nov 85 08:57:21 cet
From:  [e-mail]
Subject: Kermit & MUSIC SP

Does anyone know if Kermit-MUSIC 1.0 is compatible with the new
release of MUSIC (MUSIC SP)?  I realize that it contains its own
communications program PCWS, but sites with several operating systems
like ours would prefer to use one program (Kermit!) for all
micro to mainframe communication if possible.

Michael Palmer, Washington University Computing Facilities
BITNET address:  PCSC@WUVMD

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

End of Info-Kermit Digest
*************************
-------
20-Nov-85 19:26:06-EST,6349;000000000000
Mail-From: SY.FDC created at 20-Nov-85 19:25:31
Date: Wed 20 Nov 85 19:25:31-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #30
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed, 20 Nov 1985       Volume 3 : Number 30

                            BITNET Things
                     Kermit Over Public Networks?
                        Kermit for the HP-87?
                MVS/TSO Kermit with Protocol Converter?
                        Kermit for Tandy 6000?
                           Cromix Kermit???

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

Date: Wed 20 Nov 85 18:44:10-EST
From: Frank da Cruz <[e-mail]>
Subject: BITNET Things

Due to a change that was made in CU20B's host tables some time between Oct 24
and Oct 29, Info-Kermit mail destined for BITNET was lost.  The affected
issues were V3, Numbers 27, 28, and 29.  The problem is now fixed.  I will
remail these three issues to all the BITNET members after this issue goes out.
Sorry for the inconvenience.

Speaking of BITNET, those who access the Kermit file collection via the
BITNET Kermit file server, KERMSRV at CUVMA, may have noticed two things, one
good, one bad: (a) the KERMSRV server itself has been behaving a lot better
lately, and (b) the Kermit files have not been updated in several weeks to
reflect recent announcements.  (a) is because our IBM systems folks have
been working on KERMSRV, mostly in an effort to reduce network overhead by
queuing files according to length, discarding duplicated requests etc.  An
announcement about exactly what was done should appear shortly.  In the
meantime, send the HELP command to KERMSRV to learn about any changes or
new commands.  (b) is because the person who used to keep the BITNET area up
to date has changed jobs and has not been replaced yet; I hope the situation
will be remedied soon.

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

Date: Wed 20 Nov 85 18:44:10-EST
From: Frank da Cruz <[e-mail]>
Subject: Kermit Over Public Networks?

I know this has been hashed over before several times in the past, but I'd
like the gather all the relevent information together into one place
(the Kermit book)...  What experiences have people had using Kermit over
the public networks?  These include Tymnet, Telenet, Uninet, Datapac,
Transpac, Datex-P, and all the ones I don't even know about.  Here's a short
questionnaire:

Name of Network (spelled and capitalized as the vendor prefers):

Company or Organization that "owns" it:

Country or Area covered:

What are the characteristics and peculiarities of the network?  Sacred
characters, delay, transmission wakeup (does a Kermit packet correspond to
a network packet?), etc...

Could you make Kermit file transfer work at all?  If not, what was the fatal
impediment?  If so, what tricks were necessary?  These include SET commands
to Kermit itself (for parity, packet length, retry threshold, timeout, flow
control, handshake, etc; what particular parameters and values are necessary?),
and commands to the network (the local or remote node or PAD).

If anyone would like to answer the same questions as they apply to RS-232
connections through local area networks -- Sytek, DEC LAT, etc -- please do.

Thanks in advance!

P.S. And thanks to all those who responded to my previous questionnaire about
computer file systems and communications -- I learned about Honeywell/MULTICS;
Sperry 1100/OS 1100; HP-1000 (partly); PDP-11/RT/RSX/RSTS/POS; UCSD p-System;
Prime/Primos; Os9.  Any more out there?  HP-3000?  Data General?  CDC?  Cray?
Gould?  Perkin-Elmer?  PDP-8?  Burroughs?  Honeywell GCOS?  Lisp Machine?  Etc?

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

Date: Thu, 14 Nov 85 02:18:55 -0100
From: hans@oslo-vax (Hans A. ]lien)
Subject: Kermit for the HP-87?

Kermit for Hewlett Packard Series 80 is needed by a colleague.
A version working on the CP/M-extension card would also be of some help...

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

Date: Thu 14 Nov 85 11:39:37-EST
From: Michael Fuchs <[e-mail]>
Subject: MVS/TSO Kermit with Protocol Converter?

Does anyone have any experience using either the U of Chicago or the
U of Toronto MVS/TSO Kermit in the following enviroment (or similar):

    AMDAHL V8470
    MVS/SP3 (will have MVS/XA)
    using TSO
    through protocol converter (asynch to SNA) to COMTEN

Any tips, assurances, bewares, "no problem, pal"'s, or "won't work"'s
gratefully appreciated.

Michael Fuchs
Coefficient Systems Corp.

[Ed. - If the protocol converter is a Series/1 or equivalent running the
Yale ASCII Communication system or equivalent, then the Toronto version
should do the trick.  Other sites are reportedly adding support for additional
protocol converters to MVS/TSO or VM/CMS Kermit or both.  Again, recall that
this can only be done for those protocol converters that all the host to
put them in transparent (pass-through) mode and take them out again.]

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

Date: 12 Nov 85 01:52:34 GMT
From: Yosef Gold <ihnp4!aecom![e-mail]>
Subject: Kermit for Tandy 6000?

I am looking for the tandy 6000 version of Kermit.  The Tandy is running
Xenix.  I have no way to load it off tape.  The ideal would be either a
floppy or email.

      Yosef Gold
      ...{ihnp4,rocky2,philabs,esquire,cucard,pegasus,spike}!aecom!gold

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

Date: 20 November 1985, 17:08:08 MEZ
From: Eberhard W. Lisse <[e-mail]>
Subject: Cromix Kermit???

Has anybody got a net-adress for the

           Losinger, AG in Berne/Switzerland

who are according to a rumor ( AAWAIT HLP on CUVMA.BITNET ) working
on an implementation for CROMIX?

As I am based in Germany a surface mail adress would do as well.

Also does anybody know about an implementation for an ICL 2900 under TME ?

Thanks in advance,

el


Eberhard W. Lisse  <zdv626%djukfa11.bitnet%wiscvm.arpa>
                   <psuvax1.uucp!djukfa11.bitnet!zdv626>

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

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

-------
27-Nov-85 11:55:40-EST,18568;000000000001
Mail-From: SY.FDC created at 27-Nov-85 11:54:55
Date: Wed 27 Nov 85 11:54:55-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #31
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed, 27 Nov 1985       Volume 3 : Number 31

Departments:

  ANNOUNCEMENTS -
    PDP-11 Kermit Now Available for IAS 3.1
    Kermit in C for DG MV Series with MV/UX
    New Release of Burroughs B7900 Kermit
    Another Kermit for Intex RMX Systems
    VMS Hexify/Dehexify Fix
    IMUSIC - MUSIC Kermit w/7171 support

  UNIX KERMIT -
    More notes on C-Kermit 4C(057)
    More on Masscomp Running C-Kermit 4C(057)
    Zilog Zeus Kermit, Os9 Kermit Warning
    Problems with MacKermit for the Macintosh version 0.8(33)

  MS-DOS KERMIT -
    MS-DOS Kermit V2.28
    Hardware Upgrade for some Professional Graphics Controllers
    ROMing MS-DOS Kermit

  MISCELLANY -
    ETX/ACK Flow Control?
    Problem Downloading Files with Apple II Kermit

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

DATE: 25-NOV-1985
FROM: BRIAN@UOFT02
SUBJECT: PDP-11 Kermit Now Available for IAS 3.1

This is to announce that a version of Kermit-11 for IAS 3.1 is available.
Due to source incompatibility, only the task image and hexified task image
will be made generally available.  The complete sources will be archived at
UOFT02 in directory KERIAS: available from dialup access, and a copy of the
sources will be sent to Frank when I send the K11 update the first week of
December.  Doc and HEX files are in KER: as K11I31.* and KERBIN:K11I31.TSK.

Many thanks to Gene Costello and Bruce Wright of the EPA for this version of
Kermit-11.

Brian Nelson

[Ed. - This was the last current DEC operating system that did not have
a Kermit program -- now they all do.  The hex, odl, cmd, and doc files are
in KER:K11I31.* on CU20B.]

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

Date: Wed, 27 Nov 85 09:44:53 est
From: John Sambrook <uw-beaver!entropy!gandalf>
Subject: Kermit in C for DG MV Series with MV/UX

This is a Kermit for Data General MV Series computers.  In order to use this
Kermit you need the MV/UX product installed on top of your AOS/VS system.

If you don't have the MV/UX product but do have Data General's C compiler
you can modify the source to eliminate all calls to the UNIX emulator.
While this should not be too difficult, it will require some work.  I would
have done it for you but my schedule is just too tight.

If you don't have a C compiler feel free to translate this to another language.
Note that you will need to provide a multitasking environment.

This version of Kermit was created from an older version of Kermit.  It may or
may not be up to date.  It was tested at our site with a Kermit on a 4.2BSD
system and seemed to work fine.  As our site is moving to native UNIX (DG/UX)
we will not be using this Kermit for very long.  I will answer questions about
this version as my schedule permits.

John Sambrook
Department of Bioengineering WD-12
University of Washington
Seattle, Washington  98195
Work: [phone]
UUCP: uw-beaver!entropy!gandalf

[Ed. - Thanks!  The files are in KER:DGM*.* on CU20B, available via
anonymous FTP.  The program is based mostly on the old Unix Kermit.]

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

Date: 24 Nov 85 09:44:53 est
From: J.M.H. Smeets, Technische Hogeschool Eindhoven (THE), Netherlands
Subject: New Release of Burroughs B7900 Kermit

Enclosed is a tape containing our final implementation of Kermit for
the Burroughs B7900.  It includes file compression and binary transport.

[Ed. - The program, which is written in Burroughs Algol, is available on
CU20B as KER:B79*.*.]

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

DATE:    85/11/25
FROM:    [e-mail]
SUBJECT: Another Kermit for Intex RMX Systems

I'm releasing RMXKERMIT this week.  I'll get a tape off to you as soon as I can
get DP to do it.  Our campus bookstore will send out 5 1/4" DSDD RMX format
disks for $6/disk.  Disk 1 contains the executable program & documentation.
Disk 2 contains source code for those who want it.  Orders can be sent to:

     University Bookstore
     6049 E. 7th St.
     Long Beach, CA 90840

     Attn: Lyle Bartlett

[Ed. - This yet-another-RMX-Kermit will be announced again when it shows up
at Columbia.  This one differs from the others in being an adaptation of
MS-DOS Kermit, rather than a PL/M implementation.]

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

Date: 29 Oct 85
From: Andrew L. Burke, Tektronix MS 63/196, Wilsonville OR 97070
Subject: VMS Hexify/Dehexify Fix

Here are fixed versions of the VMS HEXIFY and DEHEXIFY programs.  While
these programs worked correctly on small files (files with less than 65535
lines, or thereabouts), failed on large files.  The problem was as follows:
the programs both used a longword (four bytes) internally to record the
current line number while reading/ writing the hexified file.  However, both
only read/wrote a word (two bytes) to/from the hexified file.  So, when it
came time for the VMSDEH program to read a line past the 65535th, it found
that the line number had wrapped back to line one.  This causes prolems
because the program uses the line index to decide whether to expand
compacted nulls or not, and when it found the next line index not equal to
the current plus the current line length, it starts writing out nulls
(counting from 65535 to 1, or therabouts...).  To make a long story short,
it didn't work.  The fix is simply to read and write a longword.  The other
modification is to VMSDEH is that it reports an end of file error when it
finished reading the hex file.

[Ed. - The fixed versions replace the old ones as KER:VMSHEX.MAR and
KER:VMSDEH.MAR on CU20B.  This came up because Tektronix is including Kermit
with its TekniCAD product on its 4100 series systems with CP/M-86.]

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

Date: Sat, 23 Nov 1985 18:06 CST
From: John Voigt - Systems Group Tulane <[e-mail]>
Subject: IMUSIC - MUSIC Kermit w/7171 support

We have discovered a bug in the new version of KERMIT for MUSIC which
supports the 7171 and Series/1 protocol converters.  This bug does not
always seem to cause a problem but it should be fixed in your code.  The
error is a result of a non-initialized control block field when sending
the first packet.  If you are trying to use this version of KERMIT with
the 7171 and you get a message FSIO ERROR - 0B1000 then this fix should
correct the problem.

In routine INTRINI find the following lines: (near line number 2565)
         LA    R1,RECPKT
         ST    R1,KERMFSRB
add the following lines after the above two:
         LA    R1,L'RECPK2     GET LENGTH OF INITIAL SEND PACKET
         ST    R1,KERMFSRL     SET RECORD LENGTH IN CONTROL BLOCK
This should correct the above error.

We have also found that if the terminal is defined to MUSIC as a "B" model
(with APL graphics characters) the 7171 will incorrectly translate data
causing KERMIT to fail altogether.  This is a permanant restiction and
should be noted in a BWR file.

[Ed. - Noted, along with above fix.]

Also, in answer to several questions from other MUSIC sites, I would like
to let everyone know that KERMIT is running on MUSIC/SP without any
modifications so if you are considering a software upgrade it should not
cause any proplems for your KERMIT users.

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

Date: Sun, 24 Nov 85 04:16:02 CST
From: Stan Barber <neuro1![e-mail]>
Subject: More Notes on C-Kermit 4C(057)

One more suggestion:

I would provide some mechanism to allow SYSIII compatible sites to
configure what signal that might like to use to allow the child and
parent to notify each other of problems. At my site, SIGUSR1 can not
be used by kermit, so I modify ckucon.c by replacing SIGUSR1 with
SIGUSR2. That fixes everything just fine.

At least a warning should be noted somewhere (in the .bwr file, I guess)
so that people will know to change it.

Alternatively, I would suggest a unique name (SIGKERMIT) that the
installer can define in the makefile (e.g. -DSIGKERMIT=SIGUSR2) to
keep people from mucking in the source file.

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

Date: Sun, 24 Nov 85 23:07:42 CST
From: Stan Barber <neuro1![e-mail]>
Subject: More on Masscomp Running C-Kermit 4C(057)

There is one more difference that masscomp users should check if they make
Ckermit. Using the masscomp FIONREAD (when in connect mode) my cause characters
to be dropped.  Using myread generally works better. This is certainly true if
the masscomp has the imux or jmux installed on it. It may not be true with the
new HPSMux installed. We don't have one yet, so I don't know.

In any case, I suggest a line for masscomp be added to the makefile of this
form:

rtu:
    make wermit "CFLAGS= -UFIONREAD -DUXIII -DDEBUG -DTLOG -O" "LNKFLAGS ="

[Ed. - Thanks Stan, both your messages have been added to the .BWR file, and
are on the list for the next release.]

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

Date: Tue Nov 26 11:45:41 EST 1985
From: dolqci!irsdcp!scsnet![e-mail]
Subject: Zilog Zeus Kermit, Os9 Kermit Warning

I am the contributer of the Zilog Zeus support for C-Kermit.  Kermit WILL NOT
WORK with the newest version of the Zeus operating system, i.e. 3.21.  We have
gotten C-Kermit to run under this new release but we had to rewrite ckutio.c.
Do you want us to submit this new mod?

[Ed. - Sure, especially if the new ckutio.c also works with the old release
of Zeus.  Or do we have to have two separate compile-time options for Zeus
systems?]

Also we think(!?) we have found two bugs in ckermit.  One is in ckcpro.c.  In
this module, C-Kermit sends an initial NAK to the other system rather than
waiting for the other side to make the first move.  We simply commented this
line out and now C-Kermit will talk to older Unix kermits.  Could this be made
public so that C-Kermit can be made a little more universal?  Some systems may
never be able to port C-Kermit (ala Os-9 Level I) and need to be able to talk
to C-Kermit.  Can this be done without losing any other comapatibility?

[Ed. - Are you talking about when C-Kermit is given the RECEIVE command,
or the SERVER command?  In the former case, I don't see how we can get
around sending NAKs -- if the expected first packet doesn't come, Kermit
has to NAK it, in case it was lost on the way and the sender of it doesn't
do timeouts.  If your local Kermit does timeouts, you can turn C-Kermit's
timer off all together with SET RECEIVE TIMEOUT 0.  In the latter case,
you're right, there should be a SET SERVER TIMEOUT command to turn off the
periodic NAKing function of the server, but still let it time out during
a protocol transaction.  Something like this should appear in a future
release.]

  The 2nd bug is in ckutio.c  In this mod, ckermit waits to get the other
side's eol char but then ignores it and expects its own: see the following

#ifdef ZILOG
    seol = (len-- > 0) ? unchar(data[4]) : '\r';      /* Terminator  */
    if ((seol < 2) || (seol > 037)) seol = '\r';
#else
    eol = (len-- > 0) ? unchar(data[4]) : '\r';            /* Terminator  */
    if ((eol < 2) || (eol > 037)) eol = '\r';
#endif

the ifdef ZILOG is our correction.  It was our experience that C-Kermit
would not work with any system that did not use <CR> as eol or would
convert eol to <CR>.  Hope this helps!

[Ed. - Thanks.]

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

Date: 26 November 1985, 08:43:52 CST
From: Tim Klosowski, Argonne National Laboratory <[e-mail]>
Subject: Problems with MacKermit for the Macintosh version 0.8(33)

I have been testing version 33 of the Kermit program for the Macintosh
computer prior to its release to our users.  I have encountered no problems
using the program on a 9600-baud X.25 line hookup to our IBM 3033 mainframe.
The problems surfaced when using a 1200-baud line.  I found three cases
during the course of my testing.

FIRST, normal execution and normal completion.
The file transferred sucessfully, the message stating this appeared and, after
a mouse-click, returned to the KERMIT-CMS prompt.

SECOND, normal execution and abnormal completion.  The file transfers
successfully and the message appears.  Instead of the KERMIT-CMS prompt
after a mouse-click, the program displays odd characters (such as %B..) and
necessitates several carriage returns to get action on the screen.  The
characters continue until a file transfer error message appears followed by
the KERMIT-CMS prompt.  The error message states that the transfer did not
complete, but closer examination indicates that the files did indeed
transfer successfully.

THIRD, abnormal execution and completion.  The program stalls after a few
packets are transferred.  The emergency exit is the only recourse.

The first case is what should ideally happen.  The third is a known problem
(occurring after an emergency exit is invoked).  The one that truly puzzles me
is the second.  If this is a known problem or if there is something I can do to
eliminate the problem, please let me know.

[Ed. - Thanks for your report.  I think that problem #2 has something to do
with closing down the line before the acknowledgement of the B (Break
Transmission) packet has been completely sent.  This would only occur during
uploading, and can be cured by using an even longer delay between sending
the ACK and closing the line.  It could also occur if this final ACK were
lost for some reason; again, a delay could cure this too.  The problem
should be fixed in the next release.]

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

Date: Monday, 25 November 1985  13:46-MST
From: Dick McGee (MMW) <[e-mail]>
Subject: MS-DOS Kermit V2.28

Has anyone successfully ported kermit v2.28 to a Z100?  I fixed the reported
bugs in the source code and assembled it.  I can upload and download with it
okay.  If I do a DIRECTORY, PUSH, SPACE or any command that temporarily exits
to DOS it goes into the twilight zone and I have to hard reset.  I'm running
MS-DOS 2.18.

I'm quite satisfied with the 2.26 version of Kermit, but since like
Mt. Everest, version 2.28 was there I thought I would try it.

s/Richard McGee    [e-mail]

[Ed. - Sounds like another casualty of version 2.28's new dynamic memory
allocation.  Did you use the /S switch on the assembler?]

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

Date: 17 November 85 15:46-PST
From: Don Pelton [phone] x2901 <[e-mail]>
Subject: Hardware Upgrade for some Professional Graphics Controllers

[Ed. - Excerpted from a posting on Info-IBMPC.]

If you have bought, or plan to buy, IBM's Professional Graphics Controller
and Display, you may be interested in this.  Several of us who bought this
board early this year discovered, through some painstaking research, that
there was a hardware bug on the board that caused it to interfere with ANY
terminal emulation program making use of the asynch port.

The old PGC cards have the numbers 6323697 and 6323698 on the top left of
the memory card. The new cards have these two numbers inked out and the
number 6448811 replaces them.  The two old numbers are not always inked out
and if your board has the 6448811 number, you have a new board.

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

Subject: ROMing MS-DOS Kermit
Date: 25 Nov 85 10:38:57 EST (Mon)
From: [e-mail]

[Ed. - This message picked up from Info-IBMPC in response to a query from
ad0r@cmu-cc-te about installing Kermit ROMs in IBM PCs...]

It's probably not worth it.  If you are willing to forgo the file upload/
download functions of KERMIT and use it to emulate a dumb terminal, it
shouldn't be too difficult to replace the screen and keyboard interfaces
with BIOS calls (I think that KERMIT uses DOS calls for these functions,
but I don't have the code at hand).

If you do this, why bother with KERMIT?  There are several other packages
around which provide X3.64 interfaces; the real advantage to KERMIT is the
popularity of its file transfer capabilities.

If you want the file transfer capabilities, on the other hand, you will
have to write your own file subsystem and burn it on the PROM.  For all
its faults, DOS does provide a mechanism for device-independent disk
access.  Unless you are going to dedicate significant staff time (spelled
with dollar signs) to the project, you will wind up with a package which
will support only a few device types.

I see occasional articles in the press which describe central-server systems
where the node PC's have no hard disk (or sometimes no DASD at all).  The
nodes, when booted, go to the central server for their copy of DOS; this
might be a better technique for you.

Ciao.

Joe Morris (jcmorris@mitre)

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

Date: Thu 21 Nov 85 11:11:21-EST
From: Frank da Cruz <[e-mail]>
Subject: ETX/ACK Flow Control?

Does anybody know what ETX/ACK flow control is, and what systems use it?
Is it like XON/XOFF, or ENQ/ACK, or is it something completely different?

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

Date: 24 Nov 85 00:07:26 GMT
From: Jeff Hollingsworth <[e-mail]>
Subject: Problem Downloading Files with Apple II Kermit

I am having trouble using kermit to transfer files between an Apple IIe, and
UNIX. When I try to send files from UNIX to my Apple, all occurences of the
"&" (ascii 38) character are removed.  This happens in both the image and
text mode.  However, all goes ok when I transfer a file from the Apple TO
UNIX.  Does anyone have an idea what is happening.  The Apple has a Super
Serial card if that helps.

Thanks in advance.

Jeff Hollingsworth    UUCP:   ucbvax!cory!hollings
            ARPA:   [e-mail]
            AT&T:   [phone]

[Ed. - Sounds like the two sides are not agreeing about 8th-bit prefixing.
The Apple thinks it's doing it, Unix doesn't.  You didn't say what versions
of Kermit you're running, so the problem may be fixed by now.  In any case,
you might be able to work around it by saying SET PARITY ODD on both sides
to force 8th-bit prefixing.]

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

End of Info-Kermit Digest
*************************
-------
 5-Dec-85 16:50:34-EST,20014;000000000000
Mail-From: SY.FDC created at  5-Dec-85 16:49:00
Date: Thu 5 Dec 85 16:48:55-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #32
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Thu,  5 Dec 1985       Volume 3 : Number 32

Departments:

  ANNOUNCEMENTS -
    New MS-DOS Kermit Available for Evaluation
    VT-220 .INI File for MS-DOS Kermit

  MISCELLANY -
    Forthcoming NIH TSO Kermit
    Apple Kermit Problem
    Fix for Apple Kermit Problem
    Os9 Kermit on Os9/68000
    Xenix Kermit Modem Control
    MULTICS Kermit?
    Professional 350 Kermit w/o Hard Disk?
    HP 9836 Kermit Diskette Needed
    Osborne 1 SD Kermit Diskette Needed
    Kermit Praises and Uses

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

Date: Thu 5 Dec 85 15:55:21-EST
From: Frank da Cruz <[e-mail]>
Subject: New MS-DOS Kermit Available for Evaluation

I have the following letter from Joe R. Doupnik, Professor, Center for
Atmospheric and Space Sciences, Utah State University:

The enclosed tape ... holds an updated version of Kermit for MS-DOS
microcomputers.  This version is based on your MS-DOS Kermit 2.28 [the
current version]... and is identified internally as "version 2.28 jrd".
The updates include full DOS 2.0 file support thoughout, a nearly complete
set of advanced server functions, much cleaned up displays (Help, Status,
Set, etc), a much better file renaming algorithm, and quite a few bug
fixes.  All of the problems known [in 2.28 as of August 85] have been fixed
and some unreported ones were as well.  Internally the code has been
strengthened and cleaned up generally.

Kermit 2.28 jrd was built for IBM PC clones (a Zenith 151 here) and for
generic machines (I have one like this using a terminal and it is not at
all close to an IBM PC).  However, my updates affect the modules common to
all versions, [and there are also minor changes to] MSXIBM and MSYIBM.
There is a READ.ME file as well.

[End of letter.]  I have put these files in a special place on CU20B,
PS:<KERMIT-MS>*.*, available on the Internet via anonymous FTP.  I only
received the source files, but I built a version on the Rainbow, which (so far)
seems to work just fine.  The file names are the old ones, not the new
consistent ones (see KER:MSAAAA.HLP).  Since the people who used to take care
of MS-DOS Kermit here have quit, I am inclined to make this the new base
version.  It seems to be better than July-vintage 2.28 in all respects, but I'd
appreciate it if people could check it on different machines to verify this,
including the IBM family (with various graphics adapters), the Wang PC, the
HP-150 and 110, TI Pro, NEC APC, etc, and report back as to whether it would
be a good idea to switch to this version (and point me at an .EXE and/or
.BOO file).  The PS:<KERMIT-MS> directory includes 8-bit binary .OBJ files
(assembled with MASM 1.10 on the Rainbow) and MSVRB1.EXE, the 8-bit binary
Kermit .EXE file for the Rainbow.  The binary files are *.OBJ, *.EXE; the
text files are *.ASM, *.H, *.ME.

I still have a version of MS-Kermit laying around that has built-in VT100
(102?) emulation, but it's based on 2.27, and the emulation only works on the
IBM PC family, but effects all the others.  I figure we'd better first get a
clean base to work from, and then worry about how to add new stuff to it.

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

Date: Mon, 2 Dec 85 18:17:58 pst
From: Joel West <[e-mail]>
Subject: VT-220 .INI File for MS-DOS Kermit

I'm not the original author, but I'm told that if this is made
the KERMIT.INI for MS-DOS kermit on the Rainbow, it will make the
keyboard act like that of a DEC VT-220.

You might wish to include it in the FTP directory at Columbia-20.

    Joel West    CACI, Inc. - Federal
    [e-mail]
    {decvax,ucbvax,ihnp4}!sdcsvax!noscvax!westjw

[Ed. - It's in KER:MSIVT2.INI, the author is listed as Ken Bass
<[e-mail]>]

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

Date: Mon, 2 Dec 85  19:46 EST
From: RAF@UMDC
Subject: Forthcoming NIH TSO Kermit

I would like to correct an error that appeared in a recent Info-Kermit.
It is not the University of Maryland that is doing a TSO KERMIT, but
rather the National Institutes of Health in Bethesda, Maryland.
The confusion most likely arose because my BITNET mailing address is at
the University of Maryland until we get our BITNET connection running.
A description of our TSO KERMIT follows:

I spoke to you about our KERMIT on the phone some time ago.  It is based
on the University of Chicago TSO KERMIT, but we have really ripped it
apart - so it wouldn't be recognizable.  I spoke to Ron Rusnak about it
before we started development.  He said that they had no plans to do any
further development and planned to go to the Rice TSO KERMIT.  I tried
to get a copy of that KERMIT, but they were unwilling to send me one at
that time (but did later for $75).  Since we were unwilling to wait some
unspecified period of time just to look at the Rice KERMIT, we went ahead
with our plans.  Our TSO KERMIT has server mode, CRC, wildcard send and
receive, ability to issue TSO commands, timeout (without polling),
compression, 8th bit quoting, optional tab removal on upload, optional tab
insertion on download, support for NIH WYLBUR edit format, a SET
VOLUME command, binary file support, handling of line errors that
generate a break signal, multiple records per packet, handling of lines
500 or more characters long.  We also plan support for PDS members
and are reworking the help info to make it more helpful.  Another item
is an interface to the TSO CLIST facility for KERMIT command lists.
I'm no expert on CMS, but I'm not sure that TSO and CMS aren't different
enough to make separate programs the most reasonable way to go.  An awful
lot of the program is concerned with the system interface rather than the
KERMIT protocol.  Anyway, ours is almost done.  We will make it available
to you when it is finished

Roger Fajman
National Institutes of Health
[phone]
[e-mail]

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

Date: Saturday, 23 November 1985  17:07-MST
From: Jeff Hollingsworth <[e-mail]>
Subject: Apple Kermit Problem

I am having trouble using kermit to transfer files between an Apple
IIe, and UNIX. When I try to send files from UNIX to my Apple, all
occurences of the "&" (ascii 38) character are removed.  This happens
in both the image and text mode.  However, all goes ok when I transfer
a file from the Apple TO UNIX.  Does anyone have an idea what is
happening?  The Apple has a Super Serial card if that helps.

Thanks in advance.

Jeff Hollingsworth    UUCP:   ucbvax!cory!hollings
            ARPA:   [e-mail]
            AT&T:   [phone]

[Ed. - See next message.]

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

Date: Wed, 27 Nov 85 15:18:06 PST
From: [e-mail]
Subject: Fix for Apple Kermit Problem

In this message I've enclosed an update to your Apple Kermit program.
Versions 2.0 and 2.1 of the program do not handle eighth bit quoting
correctly. A student, Sam Lam, who was working for me during the
summer found the error. Below is the correction.

In the procedure Rpar three operands have to be changed from "rparrt"
to "rpar8" as indicated by the arrows.

                        -- Bruce Jolliffe

[Ed. - Thanks!  Code omitted, added to KER:APPLE.BWR.]

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

Date: Wed 4 Dec 85 15:05:39-PST
From: Bob Larson <[e-mail]>
Subject: Os9 Kermit on Os9/68000

The current version of os9 kermit can't be compiled by the current version
of os9/68k C (1.3) because "remote" is a reserved word.  (What version of
os9/68k C introduced this "feature"?)  Even after this problem is solved,
kermit doesn't work properly.  I'll be fixing this asap.  (I now have a
QT+ 68000 system.)

Bob Larson
Arpa: [e-mail]
Uucp: ihnp4!sdcrdcf!oberon!blarson

[Ed. - This message added to KER:OS9KER.BWR.]

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

Date: Mon 25 Nov 85 17:10:21-EST
From: Yoram Eisenstadter <[e-mail]>
Subject: Xenix Kermit Modem Control?

I'm trying to bring up Unix Kermit on my PC/AT running XENIX, but
I'm having difficulties.

I got ahold of the source, and compiled everything successfully using
"make xenix".

First problem: the machine hung when I tried to do a "set line /dev/tty00".
I was able to do a set line only after saying "set modem-dialer hayes",
even though I have a direct connection and not a modem.

2nd problem: after set line, I did a "set speed 9600".  Then I did a connect.
Kermit immediately came back with the message "Communication Disconnect",
and returned me to the C-Kermit> prompt.

I know that the hardware is O.K.  I use the same communication port with
MSKERMIT under DOS, and it works just fine (I'm using it now...)
I was also able to use the port (/dev/tty00) from Unix with the "cu"
command, by saying "cu -s 9600 -l /dev/tty00 dir".

What am I doing wrong?

[Ed. - See next message...]

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

Date: Wed Nov 27 12:10:47 1985
From: Herm Fischer <hermix![e-mail]>
Subject: Re: Xenix kermit difficulties

Ahh, the saga of carrier detect, clear to send, and data set ready continues...

If you fire up kermit, when you do a set modem-dialer, you place kermit into
the "clocal" (ignore carrier detect absence) state.  If you fire up kermit on
a direct connection without a modem, then be sure carrier detect is present
on the pins of the cable before firing kermit up.

I suggest purchasing one of those widget connectors with the led's which
goes between the rs232 cable and the computer to see which signals are present.
Often on direct connections, it is common to hot-wire carrier detect to some
other signal to get it to come up.  If you're on a LAN, then there might
be a LAN option to raise the carrier signal...

Your communications disconnection message comes from the UNIX operating
system notifying kermit that the carrier signal has dropped!  Same problem.

cu may override the "clocal" flag; I haven't looked at its code.  kermit
cannot override that flag because it must know when a remote modem hangs
up, lest it tie up a system or hang it...

  Herm Fischer
  [e-mail]; {ihnp4, decvax, randvax}!hermix!fischer

[Ed. - Herm not only wrote the Xenix modem support in C-Kermit, but he
also uses it all the time -- an existence proof that it works.]

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

Date:  Fri, 29 Nov 85 12:24 EST
From:  [e-mail]
Subject:  MULTICS Kermit

I have recently moved to Maui and been out of touch with my usual
MULTICS machine for about two months.  In that time, a new release of
the operating system was installed.  This came with KERMIT.  The new
KERMIT does not respond to my PC KERMIT, even though I have successfully
used this repeatedly with the previous version of MULTICS KERMIT.  I
have made every effort to ensure that the file parameters match at both
ends.

Could the fact that I'm now using a TAC have something to do with it?
Transfer has failed both ways using either an ASCII or binary file.

Anyone have a systematic approach to a solution??  I'd appreciate the
help as Maui is a veritable computer "wasteland"!

Wolf Wiedemann RADC-MULTICS

[Ed. - TACs are always a pain.  But I also keep hearing about all these
different versions of MULTICS Kermit that are in use "out there" that I
have never seen personally, so it might just as likely be the culprit.
Anybody care to clear up the MULTICS Kermit confusion?  Which is the
"real" one, and where does it come from?]

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

Date: Mon, 2 Dec 85 17:20:32 EST
From: [e-mail]
Subject: Professional 350 Kermit w/o Hard Disk

  I presently use Kermit on my Digital Pro-350, however I don't have a
hard disk on this system thus it operates as a Pro-325.  While Kermit
functions just fine with the obvious exception on interfacing with the
other utilites which it expects on disk, I can not get kermit to retain
its communications settings so it ALWAYs uses the defaults.
  The problem seems to be that Kermit wants to store its settings in
a file somewhere, but I can't figure out what that file is named or
where it is supposed to be;  if I could, then I could create it and
suspect all would be fine!
  Any help with this would be greatly appreciated.
  --chris

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

Date: Thu 5 Dec 85 08:44:31-EST
From: Frank da Cruz <[e-mail]>
Subject: HP 9836 Kermit Diskette Needed

If anybody has HP9836 Kermit on a diskette and is willing to send a copy
to someone who can't get it any other way, please call Steve Masticola
at RCA, Somerville NJ, 201-685-6594, collect if desired.  And if you're
willing to send Steve a disk, how about also sending one to the HP98x6
user group (is there such a thing?) so they can handle these requests?

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

Date: Thu 5 Dec 85 11:27:12-EST
From: Frank da Cruz <[e-mail]>
Subject: Osborne 1 SD Kermit Diskette Needed

I got a letter from Norway that was addressed like this:

    Columbia University
    Columbia, USA

It actually, came to me...  Somebody in Norway figured out that CU was in
New York, and then somebody at Columbia opened it up and saw the word Kermit
in it...  Anyhow, this guy lost his only copy of Kermit because of a power
hit, and can't find a single-density copy of it anywhere in Norway.  If some
kind soul would send one to

    Einar
    Norway

I'm sure he'd appreciate it.  Just kidding, his full address is

    Einar Fredriksen
    Edvard Griegsvei 34
    N-5037 Solheimsvik
    NORWAY

Thanks!

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

Date: Thu 5 Dec 85 13:46:34-EST
From: Chris Lent <[e-mail]>
Subject: Kermit Praises and Uses

KERMIT in the trenches:
    We've been using KERMIT down at Cooper Union quite a bit.
(We're at 3rd Ave and East 8th Street).
After I bought a copy of the tapes,  I put it on our systems
down at Cooper.  These are:
    VAX 11/780 VMS 4.2
    ATT 3b5 System V UNIX R 2.0.211
    PDP-11/45 UNIX V6 (plus)    ! This took a good bit of work
    PDP-11/23 UNIX V6 (plus-more)    ! Same as 11/45
    IBM-PC's, and PC-Jr's PC-DOS 2.0,2.1,3.0,3.1
    ATT 6300 (Very IBM compatible AND FAST!!!)
    Apple Mac's ! The VT102 emultator comes in very handy.
    Intel Blue Boxes "MDS-80" (ISIS-II)(8" Floppy only)
        ! We transfered this via a block-by-block copy
        ! from our VAX RX01 Console Floppy
    Intel 310's    ! DON'T EVEN THINK ABOUT BUYING THESE TURKEYS!!!!
        ! The 310's run MS-DOS BADLY (We had to write drivers
            for the serial port and winchester that Intel put in!!)
        ! Intel also foists IRMX-86 on you (Everyone needs an
            archaric multi-user Operating System on a
            machine that one person uses?)
        ! Kermit is having a hard time here only because the
        ! port drivers still are bug-infested. We tend to
        ! transfer to an IBM-PC and take the MS-DOS floppy
        ! and read that instead.
    Intel 380's ! BIGGER Multi-User TURKEYS!!
        ! Intel hasn't managed to port MS-DOS to these yet!!!!

Now we do a multitude of daily and regular transfers like:
STUDENT USE:
        Student archiving of programs.  This works wonderfully as
    we don't have to hunt through age-old backups for their stuff.
    It also has the added benefit that if the programs are written
    portably in 'C', Fortran, Pascal or Basic, they can do development
    work on PC's and other micros around the school or at home.
    The archiving is done at local PC's. This is necessary as our
    money for dialin facilities is limited and our computers are
    brought down each night because the building is closed.

        Students talking to FIDO bulletin board systems from home.
    This way they can get the latest shareware utlities.

        Students talking to each other's systems.  One interesting
    case is a lab group where the guy with the MAC did the diagrams,
    and printed the final version of the paper while another
    member typed the paper on his IBM. The third member
    proof-read the text on his Commodore-64.  Let's hear it for
    two wonderful standards: ASCII and KERMIT!!!!

COURSE AND PROJECT USE:
        Sending GTSTRUDL plotting files from our VAX to the 11/45
    where our CALCOMP plotter is.  This lets our civil engineers
    make giant plots of their structures and how they will deform
    under load.

        Sending Digitized maps and data from the 11/45 to IBM-PC's and
    the VAX. There a lot of this.  The students in the CAD/CAM
    course have to design a simple packeage and many of them
    digitize their intial shape library on the 11/45 before moving
    them to the final machine.

        Sending sample bitmapped image data from RT-11 format tapes
    read in on our VAX to Intel 380's for work in developing medical
    imaging systems.

MORE STUDENT USE:
        Sending and receiving programs under development from grad and
    undergrad students machines out at Bell Labs (and AT&T clones) for
    course work (complier design, programming languages, data structures,
    and of course the infamous Master's thesis).  Bell Labs
    machines at Whippany, Homdel, and Parsippany get the new
    versions from us as we get them from you.  Once Kermit'ed
    to a Usenet machine, the programs flow over Usenet to the
    apporiate machines.  Most times they just type
        % make sys3
    or the make for Berkley 4.2 and the Kermit works perfectly
    right away.  Many times the user DOESN'T know what type of
    machine he's running on (VAX, 3bx or whatever) and it STILL
    works well even though the "RIGHT" version wasn't used.
        The first version when over via the UNIX 'cu'(CALL UNIX)
    utility which talked through the VAX's modem via KERMIT in CONNECT mode.
    After fixing up the transmission errors,  we compiled it and
    got a reliable version of KERMIT via our 'cu'ed version.

FACULTY USE:
    The faculty computer program.  Professor's develop programs
    at home that the students use in their classes on the main
    computers.  The number of these programs we support now is getting
    huge.

    Faculty work on remote machines in places like Texas and Califonia.
    Usually they have older versions of KERMIT, so we ship a new
    version to our faculty member's account via the old KERMIT
    and then tell the remote staff where to find it for system-wide
    installation.


    And even more every day.


It seems like every third word out of my mouth is KERMIT.
My policy is now whenever someone has a machine or an account on
a machine which doesn't have KERMIT, we find some way of moving
KERMIT to them.  I must admit I thought the demand would be large
but it just seems to be growing in leaps and bounds.


The thing is that I've learned about so many strange operating
systems while installing KERMIT, but I rarely (once a month)
have to examine individual KERMIT packets when porting a new
KERMIT version.

We just seems to be trashing more old file transfer programs
every day.  It doesn't matter if they we purchased or hacked
together,  KERMIT is in general better and makes MUCH more
sense to maintain.  We usually keep the old one around until
we figure out how to send strange file formats (VMS is famous
for these.)

Well, I'll keep KERMITing the rest of the Universe.

                Thanks,
                Chris Lent
                Care of:
                [e-mail]
                (VAXmail) CUPHOA::LENT
(I'm working on tailoring utilities and EUNICE for them up here)

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

End of Info-Kermit Digest
*************************
-------
11-Dec-85 11:00:48-EST,9532;000000000000
Mail-From: SY.FDC created at 11-Dec-85 10:59:58
Date: Wed 11 Dec 85 10:59:58-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #33
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Wed, 11 Dec 1985       Volume 3 : Number 33

Departments:

  MS-DOS KERMIT 2.28 JRD -
    MS-DOS Kermit 2.28 jrd Not on BITnet
    MS-DOS Kermit 2.28 jrd Bug with X Packets
    Bug Report on MS-DOS Kermit 2.28 jrd on 18MHz PC/AT
    Suggestion for MS-DOS 2.29
    Minor Mod to New MS-DOS Kermit

  MISCELLANY -
    Apple-II Kermit Bugs
    Multics Kermit

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

Date: Wed 11 Dec 85 10:13:20-EST
From: Frank da Cruz <[e-mail]>
Subject: MS-DOS Kermit 2.28 jrd Not on BITnet

In response to numerous requests from BITnet for Joe Doupnik's improved
version of MS-DOS Kermit 2.28, I'm sorry to say I can't put it on BITnet
just yet, for a variety of reasons which are too complicated to explain.
It looks as though this version will wind up replacing the current one --
one or two minor bugs need fixing, plus checkout is still required on the
Wangs, HP's, NECs, etc -- and at that time it will replace the current
version on BITnet.

I'm also sorry I mentioned the MS-DOS Kermit 2.27 that had VT100 support
added to it.  In response to numerous requests for it, let me just say that
in order to avert utter chaos, I would prefer to get the fixed 2.28
installed as the standard, base version, and then call for volunteers to
take the VT100 support and fit it into the new base version.  If we don't do
it that way, we'll have multiple proliferating divergent versions of the
program which will be impossible to support.  Those of you who whose phone
doesn't ring 500 times a day with MS-Kermit questions might not appreciate
why this is important, so you'll just have to take my word for it.

Once again, I apologize for the reduced level of support for MS-DOS Kermit
and the BITnet Kermit files.  Like I said before, it's because the people
who used to take care of these things have left Columbia.  They will be
replaced, but I can't say when.  Soon, I hope.

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

Date: Tue 10 Dec 85 18:02:07-EST
From: Frank da Cruz <[e-mail]>
Subject: MS-DOS Kermit 2.28 jrd Bug with X Packets

First real bug -- if you send a generic command to a server which the server
does not support, and it sends back an error packet (which is the proper
behavior for servers under the circumstances), then the next file sent by
MS-DOS Kermit has its name in an X packet rather than an F packet, which of
course the server is not prepared to handle.  MS-DOS Kermit is apparently
setting its "X flag" in anticipation that the generic command will elicit a
X packet or a data-bearing ACK from the server, and then not resetting it
when the transaction is terminated by an error.  In fact, it should not set
this flag until such a response actually occurs, and it should reset the
flag at the beginning of each transaction.  Reportedly, the same behavior
crops up randomly (not reproducibly) at other times.

Thanks also to others who reported this problem.  If anybody develops a fix
(it should be real simple, something like setting the X-Flag to 0 at the top
of the command loop), please send it in.

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

Date: 9 Dec 85 08:57:00 PST
From: ALEX WOO <wu@ames-aero>
Subject: Bug Report on MS-DOS Kermit 2.28 jrd on 18MHz PC/AT

The new MS-DOS kermit seems to work fine on a 4.77MHz PC but it coughs on a
18MHz PC AT with the error message
    "? Not enough memory to run kermit"
The PC AT has about 2MB of memory.

[Ed. - Beats me, anybody have any ideas?  Doesn't sound like anything that
would involve timing loops...  Do all your other programs work on your
souped up AT???  Does the old Kermit?]

Also, if there a Makefile for the MS-DOS version of Kermit, perhaps using
one of the Info-IBMPC makes.

[Ed. - There isn't, sorry.  Does anyone know if there is a "make" that will
support command line arguments, so you can say "make ibm", "make rainbow",
"make tipc", etc?  If so, which one is it, where is it?]

Alex.

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

Date: Mon 9 Dec 85 04:18:07-EST
From: Joe Smith [phone] <[e-mail]>
Subject: Suggestion for MS-DOS 2.29

If you do plan to use MSKERMIT 2.28 jrd as the basis of the next release of
MS-DOS KERMIT, please add "SET TERMINAL mumble" and "SET DTR mumble" to the
system independent code.  Define dummy entry points in all the system
dependent modules so they can parse "mumble" or say "not implemented".  Then
the developers could add system specific arguments to these commands, such
as:

    SET TERMINAL NO-WRAPAROUND
    SET TERMINAL WIDTH 132
    SET TERMINAL ID VT125
    SET DTR ON
    SET DTR OFF
    SET DTR HANGUP-ON-EXIT

We need a general way to get to system-specific functions thru KERMIT's
command scanner.

/JMS

[Ed. - These sound like useful hints for whoever is going to volunteer to
fit the VT100 support into 2.28 jrd.]

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

Date: Sun, 8 Dec 85 01:23 EST
From: Larry Afrin <[e-mail]>
Subject: Minor Mod to New MS-DOS Kermit

The new MS-DOS Kermit (jrd's rewrite/mod of 2.28) has a minor problem when
it invokes COMMAND.COM to do stuff like TYPEing out files, DELeting files,
running CHKDSK, and RUNning any other program: when you type in the command
line in response to the "Kermit>" prompt, and then hit Enter, only a
carriage return is echoed.  No line feed.  This means that the first line of
output (either from COMMAND.COM or from the program loaded in by
COMMAND.COM) overwrites the "Kermit>" prompt and the command you typed.
Trivial, I admit, but aesthetically displeasing.  I made the following mod
in the location of the "run3" label in the MSKERM.ASM module in
PS:<KERMIT-MS> to output the needed line feed.

[Ed. - I've appended your code to the MSKERM.BWR file, but I can't reproduce
the problem, either on a PC/AT or a Rainbow.]

Other than this minor problem, I haven't found anything wrong yet with
jrd's version.  I'm running PC-DOS 3.10 on a plain vanilla PC.

Still waiting for a VT100 emulator to replace the Heath-19, though... (hey,
we can dream, can't we?)

[Ed. - Yes, but can we volunteer?]

P.S.  I'm running MASM version 1.00 (from the Dark Ages of 1981), and in
order to get the segments in the right order for the linker, I had to change
all references to segment name STACK to segment CTACK.  These references are
in modules MSKERM.ASM (4 references) and MSXDMB.ASM (2 references).  If you
don't make this change, the machine winds up taking a long walk off a short
pier when you hit Control-] C to come back from on-line mode to command
mode.

[Ed. - Anyone else have this problem?  I assembled the files with Microsoft
MASM 1.10 (1981,82) using no switches, and not renaming any segments, and
the result worked fine.  Also, has anybody ever heard of the /DOS switch
that Joe mentioned in his letter?]

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

Date: Fri 6 Dec 85 01:25:39-EST
From: Peter G. Trei <[e-mail]>
Subject: Apple-II Kermit Bugs

In reference to Sam Lam and Bruce Jolliffe's fix for the Apple ][ Kermit's
8th bit quoting bug, here is a way to install it in version 2.1a without
doing another download. I have not yet had the opportunity to perform
thorough checking and testing of this fix, so be cautious!

[This patch only works for version 2.1a]
Make a copy of your kermit-65 disk.
Boot with the new disk.
Enter the following DOS commands:

] UNLOCK KERMIT
] BLOAD KERMIT
] POKE 17303,35
] POKE 17317,21
] POKE 17329,9
] POKE 17399,194
] DELETE KERMIT
] BSAVE KERMIT,A$801,L$4E9B

As soon as I have finished checking this fix, I will ask Frank to put the
updated source and hex files into the download area on CU20B for
distribution. This may be related to the bug that strips out '&' on
reception of files.

                            Peter Trei
                            oc.trei@cu20b

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

Date:  Fri, 6 Dec 85 17:20 EST
From:  "John C. Klensin" <[e-mail]>
Subject:  Multics Kermit

As of approximately now, the 'real' Multics kermit is the one with which
problems were reported in V3#32.  It is a version created at Calgary and
being distributed with the system and supported by Honeywell (it is,
consequently, unlikely to be released to the Columbia archives).

It supports many options that the various older versions and kludges do not,
incluing server mode, 8th-bit-quoting, etc., and is structured much more
like other Multics commands that do similar things, such as the Internet FTP
command.  Its default option settings, however, tend to be a little more
optimized for Multics<->Multics transfers over X.25 and dial circuits than
for PC->Multics or Internet TAC use.  Users with problems should probably
bug Honeywell over conventional channels, as this is a supported product.

Does that help?

[Ed. - I guess.  Columbia, by the way, has never received this version of
Multics Kermit.  I suppose if all Multics sites get it automatically, no
harm is done.]

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

End of Info-Kermit Digest
*************************
-------
19-Dec-85 12:28:31-EST,20252;000000000000
Mail-From: SY.FDC created at 19-Dec-85 12:27:49
Date: Thu 19 Dec 85 12:27:48-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #34
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Thu, 19 Dec 1985       Volume 3 : Number 34

Departments:

  ANNOUNCEMENTS -
    New Honeywell CP-6 Kermit
    New version of IMUSIC

  MS-DOS KERMIT -
    MS-DOS Kermit 2.28 jrd Problems and Fixes
    IBM-PC Kermit V2.28 jrd Display Problems
    TopView Support for MS-DOS Kermit
    More MS-DOS Kermit 2.28 jrd Problems
    MSBOOT.FOR for Unix f77

  MISCELLANY -
    DEC-20 File Naming Problem
    Os9 kermit warning!
    Bugs in the CP/M Turbo-Pascal Kermit V1.00
    Re: Apple-II Kermit Bugs

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

Date: Thu, 18 Dec 85  10:50 EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: New Honeywell CP-6 Kermit

This is to announce a new Kermit program for Honeywell CP-6 systems from Lee
Hallin at Honeywell (Lee-Hallin%LADC@CISL).  This one is written in PL/6, a
PL/I-like language, and includes text/binary file transfer, wildcards, all
the prefixing options, server and client operation, command files, etc, but
lacks CRC, file interrupt, attributes.  (The other CP-6 Kermit is written in
Pascal and comes from Bucknell University.)

Lee's new CP-6 Kermit is available from CU20B via anonymous FTP as KER:HC6*.*.
Again, apologies to everyone on BITNET for the hiatus in getting new files
on KERMSRV; we should be back in business on that end after the holidays.

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

Date: Mon, 16 Dec 85  20:14 EST
From: John Voigt - Systems Group Tulane <[e-mail]>
Subject: New version of IMUSIC

I have a new version (1.2) of IMUSIC KERMIT available.  This version
incorporates several fixes as well as enhancing the set ? function.  I have
sent you the complete source with all the new changes.

JV/

[Ed. - Thanks!  This replaces the previous version (1.1) on CU20B.  It's
in KER:IMUSIC.ASM.]

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

Date: 12 Dec 85 21:23:04 PST (Thu)
Subject: MS-DOS Kermit 2.28 jrd Problems and Fixes
From: donovan@aero

   I've attached a fix to MS-DOS Kermit v2.28 rjd for a problem in the send
protocol.  The problem occurs when a send command follows a Kermit generic
command which causes flags.xflg to be set.  This happens whenever a remote
server displays output on the local screen.  The GENRIC procedure in MSSSER
is the culprit, but the simplest fix is to reset xflg in the SEND command
processor just before the server entry point at SEND11.  Here are diffs for
MSSSEN.

..........mssend.old
;    Send command

..........msssen.asm
;    Send command - protocol handler to send a file
; Normal entry - SEND does file transfer preceded by "F" packet
;         resets xflg
; Server entry - SEND11 does file transfer preceded by "X" packet
;         set xflg = 1 before call

..........mssend.old
send11:    mov flags.nmoflg,0    ; Reset flags from fn parsing. [21a]
    mov ah,setdma        ; set dta address [jrd]

..........msssen.asm
    mov flags.xflg,0    ; Reset flag for normal file send [mtd]
SEND11:    mov flags.nmoflg,0    ; Reset flags from fn parsing. [21a]
    mov ah,setdma        ; set dta address [jrd]

[Ed. - Thanks!  This was the most glaring bug in this version.]

Also, the Z-100 version has had a bug in backspace processing since v2.27.
When entering Kermit commands at the prompt, backspace (^H) won't back up
over characters on the screen.  The problem is caused by a change made to
MSSCMD.ASM near the label "cmge11".  Backspace was removed from the set of
characters which are echoed.  The fix is to change MSXZ10.ASM to send an
extra backspace.  "diff"s below.

..........msxz10.old
delstr  db    BS,' ',BS,'$'     ; Delete string. [21d]
home    db    ESC,'H$'

..........msxz10.asm
delstr  db    BS,BS,' ',BS,'$'     ; Delete string. [21d]
home    db    ESC,'H$'

The MS-DOS version with Joe Doupnik's modifications works with both HP150
and, with this fix, Z-100 modules.  Joe's modifications are a major
improvement to MS-DOS Kermit.  I suggest that once the documentation catches
up with the programming, the revised Kermit should be accepted as MS-DOS
Kermit v2.29.

[Ed. - Well, a couple more problems remain, and the contributions keep
pouring in.  But you're right, we have to draw the line somewhere.
See below...]

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

Date: Sat 14 Dec 85 05:33:09-EST
From: Kathleen Connors <[e-mail]>
Subject: IBM-PC Kermit V2.28 jrd Display Problems

I tried the new 2.28 version of Kermit for the IBM PC tonight.  It still has
some of the same problems (2 out of 3) that the old 2.28 version had, which I
reported to you last June.

1) When you GET a file the file transfer screen puts an "s"
   in upper left hand corner of the screen.

2) The mode line under the same conditions displays nothing
   except a single "^" in the first position.

The truncation of the file name upon receiving a file has been fixed.  I am
using a IBM PC I (64k motherboard), 512k of memory, DOS 3.0 and a internal
Qubie (Hayes compatible) modem. Since these problems, albeit cosmetic, still
exist I will probably continue to version 2.27.

[Ed. - Has anyone else ever seen this?  I haven't, and I've been running
both 2.28 and 2.28 jrd on an IBM PC for a couple weeks.]

Suggestions for future Kermits:

1) A means of clearing the terminal screen buffer from the local Kermit.

2) The Kermit initialization file should be allowed to be
   called KERMIT.INI instead of MSKERMIT.INI.

[Ed. - The reason it's called MSKERMIT.INI is that if you accidentally
transfer your KERMIT.INI file from a mainframe, you'd be in for some nasty
surprises the next time you started Kermit up on your PC.]

3) The ability to send a file "raw" without the Kermit protocol just xon/xoff.

[Ed. - Everybody wants this, along with login scripts and a DIAL command.
Maybe someday someone will write the code.]

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

Date: 12/16/85  6:10:45 E.S.T.
From: [e-mail]
Subject: TopView Support for MS-DOS Kermit

Here is a new MSYIBM terminal emulation module; the following changes
were made:

. ANSI set graphics rendition support extended to handle color attributes
   in addition to monochrome

. Direct moves to and from the video buffer modified to use TOPVIEW
   interrupt codes, so that KERMIT can run in the background under
   TOPVIEW and take advantage of TOPVIEW windowing support.

The following parameters are used in a TOPVIEW Program Information File to run
KERMIT under TOPVIEW with the MSYIBM TOPVIEW support added.

Memory:  Variable.  Suggest min and max be set to 128K to allow 'run' support.
 Set system memory to about 20K

Screen type: D
 Pages: 4
 Window size: 25 by 80
 Offsets:     0     0

Writes directly to screen:   no
 Accesses system keyboard buffer:  no
 Runs only in the foreground:   no
 Uses math coprocessor:    no

[Ed. - Thanks!  I haven't had a chance to try this out, but if these are the
only changes, then it should be compatible with JRD's new stuff, except for
one minor change that JRD made about Heath line wrap.  If anybody wants to
try this out, the file is with JRD's Kermit, stored as
PS:<KERMIT-MS>MSYIBM.TOP on CU20B only -- If you take it, please report back
about how/if it works, and whether it's safe to distribute as the standard
version.]

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

Date: Thu 19 Dec 85 09:24:23-EST
From: Frank da Cruz <[e-mail]>
Subject: More MS-DOS Kermit 2.28 jrd Problems

Beyond the bugs reported already (like the X-Flag bug), there are at least
two subtle problems with the new MS-DOS Kermit.  First, even when assembled
correctly with the "right" assembler and switches, it will sometimes (very
rarely) start executing garbage after a CONNECT command.  This happened to
me exactly once in several weeks of constant use -- I had escaped back from
a connection to the DEC-20, gave the DO IBM command, switched my port
contention unit to the IBM mainframe, gave the CONNECT command, and poof --
system totally dead, had to be rebooted.  A few other people have reported
similar occurrences.  I can't reproduce it; can anybody else?

The second problem applies to earlier releases as well, but only shows up
on a PC/AT, and (for us at least) only when communicating with a half duplex
system at 9600 baud using handshake.  The sympton is that, after the end of a
file transfer session from the mainframe to the PC, after the mainframe sends
the B (Break transmission) packet, the AT responds with its ACK, but the ACK
shows up as garbage at the mainframe.  If on the AT you SET DEBUG ON, the
problem goes away.  When the connection is run through a line monitor,
everything appears normal; the AT responds to each packet from the mainframe
immediately as the XON handshake appears, and ACK is in correct format.

The speculation is that the AT is somehow ACKing the B packet "too fast".
Even though we haven't caught it sending the ACK prematurely on the line
monitor, the behavior is exactly what you'd expect if a transmission
occurred before the line was fully "turned around".  Why would this happen
after a B packet, but not after any other packet?  Several possible
explanations suggest themselves: (a) unlike most other packets, the B packet
requires no processing, and can be ACK'd immediately; (b) MS-DOS Kermit
somehow forgets about handshaking after the B packet; (c) MS-DOS Kermit is
handling the UART incorrectly.

I think (b) is unlikely; we never saw any supporting evidence on the line
monitor.  While (c) is a possibility, it would take a lot of digging through
the low-level code to show up a problem; a cursory inspection reveals
nothing obvious (the UART's output holding register is always tested for
emptiness before giving it the next character).

If (a) is true, it would imply that the host is sending its XON before it is
really and truly ready for input.  Unlikely as this may seem (it's a
lightly-loaded IBM 3083), the fact that the problem only happens with the AT
-- which is much faster than the PC or the Rainbow -- lends some credence to
this theory.  If this is the real explanation, then the thing to do would be
to insert a brief sleep in MS-DOS Kermit before ACKing the B packet.  But
there are also some other packets that don't require any processing, namely
those that arrive with bad checksums; thus we might have to sleep before
retransmitting or NAKing as well.

If anyone can offer any insight or evidence to support any of these
theories, it would be much appreciated.  But beyond that, we may have here a
presage of things to come.  As microcomputers get faster and faster, they
may begin to strain the assumptions underlying the design of our
communications equipment.

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

Date: 13 Dec 1985 1427-EST (Friday)
From: Tom Putnam <[e-mail]>
Subject: MSBOOT.FOR for Unix f77

The subject FORTRAN program is supposed to be run on a host machine in
conjunction with MSPCBOOT.BAS on a target MS-DOS machine to download
MSKERMIT.BOO and similar binary files.  The program requires several
modifications to operate under UNIX.  (We are running UNIX 4.2 BSD).
In particular:

 * The variable ACK is declared as a 4-element array, but only the
   first element is ever used.  The initial READ statement:
          READ (5,200) OK, SPACE, COMMA, ACK
    200   FORMAT(4A1)
   implies that the whole array ACK will be read.  Since the format does
   not allow enough elements, a second "line" or "record" of input is
   requested, so file transfer never gets off the ground.

 * The write statements include a blank for carriage control.  Although
   some systems strip this character on output to the terminal, UNIX terminal
   output includes the blank and thus fouls up the character count check.

I corrected these problems, converted the program to FORTRAN-77, and
cleaned-up the logic a little so that we could use it on our systems.
The modified version of the program is available via anonymous ftp from
ASC.PURDUE.EDU in the "kermit" subdirectory, file name "msboot.f".

[Ed. - It's also on CU20B as KER:MSBOOT.F.]

Tom Putnam, Manager of User Services
Purdue University Computing Center

ARPANET: [e-mail]
     or  [e-mail]
BITNET:  PUTNAMT@PURCCVM
CSNET:   ac4@purdue-asc-tn
USENET:  [e-mail]
USMAIL:  Mathematical Sciences Bldg.
     West Lafayette, IN 47907
PHONE:     [phone]

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

Date: Tue, 17 Dec 1985  13:34 EST
From: [e-mail]
Subject: DEC-20 File Naming Problem

I am using TOPS-20 Kermit version 4.1 and running into the following problem:

The filenames that I am using on my microcomputer are in the same format as
TOPS20 filenames, that is, "<name>.<type>.<version>".  The software system
maintains the version numbers in the usual way.  As we have quite a few of
these computers, which are not tied together with a network, we use Kermit
to transfer files to and from MIT-OZ, our DEC 20.  This gives us all a
shared file system to work from.

Now, my problem is that I want to transfer files from my local machine to the
20, retaining the version number (note that this works fine when transferring
from the 20 to the local machine).  This is so the version numbers on the 20
will match the version numbers on the local machine.

Unfortunately, TOPS20 Kermit doesn't have an option to do this.  As far as I
can tell, the only options I have are "set file naming unconverted" and "set
file naming normal-form".  In neither case is the version number I specify
used to write the output file on the 20.  Instead, the file is forced to be
a "newest" generation -- either "FOO.BAR.34.0" (where the <type> is
"BAR.34") or "FOO.BARX34.0", respectively.

Could this be changed?  It seems to me that if the version number is
explicitly specified, it does no harm to open the output file under that
name if one does not already exist.  Or, if that is not reasonable, could
you add an option, say, "set file naming literal", that does what I want?
It is really a pain for me to have to rename all my files after I transmit
them.

Thanks,
Chris Hanson

[Ed. - Thanks for the suggestion.  I'll try to add another file-naming
option to Kermit-20 in the next release.]

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

Date:  Mon Dec 16 10:58:59 EST 1985
From: dolqci!irsdcp!scsnet![e-mail]
Subject: Os9 kermit warning!

   A warning about using kermit under os9 on a tandy CoCo: If you use kermit
with the multi-pak and the delux rs-232 pak, that is you intend to use /t2
as your outgoing device you MUST have the rs-232 pak in slot 1 of the
multi-pak. In fact the device driver for /t2 requires that the rs-232 pak be
in slot 1. ANY program that uses /t2 will only run if the rs-232 is in slot
1. Also it appears that you must have the carrier forced on BEFORE you run
kermit if you are using sometype of smartmodem. (maybe some os9 wizard out
there can find a patch to the device driver to let /t2 look for the rs-232
pak in another slot).

  Kermit on the CoCo is still (as far as I know - maybe bob larson knows
more) untested using device /t1, the so called "bit banger" port.

~ Addresses:  USmail: IRS, 1111 Constitution Ave. NW    Washington, DC 20224 ~
~             Atten: M. Sunderlin PM:S:D:NO             Office Phone:        ~
~ UUCP:  ...seismo!dolqci!irsdcp!scsnet!sunder          [phone]       ~
~        ...decvax!philabs!ubbs!sund                    (FTS) 634-2529       ~
~ CIS:   74026,3235                                                          ~

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

Date: Wed, 18 Dec 85 13:32:59 cst
From: Jeff Woolsey <[e-mail]>
Subject: Bugs in the CP/M Turbo-Pascal Kermit V1.00

I have found and fixed a few bugs in the Turbo Pascal Kermit for CP/M-80,
and made some simple but useful enhancements.

Bug #1: Binary file transfers "worked" (everybody was happy with checksums)
but the file was missing the 8th bit sometimes.  &X would not get the 8th
bit set, but &#X would.  The code that checked for control characters in
this case forgot that this was an &-quoted character if it wasn't also
#-quoted.  The fix in the else clause should be obvious.  See procedure
expand_packet in file KREC1.PAS here:

[Ed. - Code omitted.]

Bug #2: This first showed up as filenames listed by the DIR command being
separated by linefeeds.  The solution eluded me until I realized that I was
in user area 10 (= ASCII linefeed) at the time.  Fix it by not writing the
first "character" of the file name.  See procedure writefilename in file
KDIR.PAS.

Bug #3: The scourge of all machines using 16-bit signed integers.  The
displays of bytes (remaining to be) transferred wrap to negative integers
above 32767.  Since this number is calculated by multiplying blocks by 128
(an integer), you really only get 9 bits of information there.  This can be
remedied by multiplying by 128.0 (a real) and formatting the result.  See
procedure update in file KDISPLAY.PAS.  See procedure open_file in file
KOPEN.PAS.

Enhancement #1: I got tired of having to tell the host explicitly the name
of each file I was downloading when I should have been able to use
wildcards.  The impediment here is that Turbo Kermit goes to receive_init
state when it gets the EOF packet, and expects a send_init packet from the
host. Instead, it gets a file_header packet, and aborts.  A two-line change
allows Kermit to receive multiple files in this case.  Find the
repeat/case/until block that processes the incoming packets.  Only one of
the cases ever sets the state variable (to receive_init). Change it to
receive_header, and add a clause to the until condition checking for state
<> receive.  See procedure rfile in file KREC1.PAS here

[Ed. - Code omitted.]

Enhancement #2: Especially in conjunction wtih Enchancement #1, I wanted to
be able to see the name of the file being transferred along with all the
other statistics being displayed.  I stuck "gotoxy(58,2); write(fileref);"
at the front of procedure open_file in file KOPEN.PAS.

The above should be of general interest.  What follows summarizes the other,
more machine-specific changes that I needed to make.

I undid the IOBYTE stuff so that I could support all 4 of the serial ports
on my system.  I have a 1200 bps autodialing modem and a dumb 2400 bps modem
and I wanted to be able to autodial 2400 bps systems.  I support searching
through the various PAMS/PDSE/et.al. BBS lists and extracting the phone
numbers.  I rewrote pieces of the command processor to make it easier to add
new commands while retaining the ability to abbreviate them to uniqueness,
and I implemented meaningful semantics for commands like CONNECT 1 or
RECEIVE FRED.PAS .  I have a text capture mode, and if I desire the terminal
handler converts ANSI escape sequences into H19 sequences for my console.
...
The aim of Nuclear Freeze is to prevent Nuclear Winter.

                Jeff Woolsey
                ...ihnp4{!stolaf}!umn-cs!woolsey
                [e-mail]

[Ed. - Thanks. I've put this message in full (with code) in KER:TURBO.BWR on
CU20B, and have also passed it along to the Turbo Pascal Kermit authors.]

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

Date: Wed, 11 Dec 85 16:55:16 PST
From: [e-mail]
Subject: Re: Apple-II Kermit Bugs

>This may be related to the bug that strips out '&' on reception of files.

This IS the bug that strips out '&' on reception regardless of the setting
of text/binary and 7/8 bit data path.  When it sees an '&' in the incoming
data stream, it just unconditionally strips it and turns on the 8th bit of
the next character.

Sam Lam

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

End of Info-Kermit Digest
*************************
-------
24-Dec-85 14:12:09-EST,12480;000000000000
Mail-From: SY.FDC created at 24-Dec-85 14:11:39
Date: Tue 24 Dec 85 14:11:39-EST
From: Frank da Cruz <[e-mail]>
Subject: Info-Kermit Digest V3 #35
To: [e-mail]
Reply-To: Info-Kermit@CU20B
Queries-To: Info-Kermit-Request@CU20B
Message-ID: <[e-mail]>

Info-Kermit Digest         Tue, 24 Dec 1985       Volume 3 : Number 35

Departments:

  MS-DOS KERMIT -
    Kermit 2.28 jrd Bug Report
    Fast Kermit for AT?
    IBM-PC Kermit v2.28 Display Problems
    Kermit for Victor

  MISCELLANY -
    Kermit for Apples with StarCard
    Request for KERMIT binary for Radio Shack 6000 Xenix
    Set File 8-Bit in Kermit-20

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

Date: 23 DEC 85 13:15-MST
From: [e-mail]
Subject: Kermit 2.28 jrd Bug Report

1. Thanks for the mail messages and nice words. Using Bitnet here is magic
of a rather dark hue, alas.  Given that you seem to have a shortage of
MS-DOS folks perhaps I can get the mail via Bitnet and help solve the sundry
bugs as they arrive and then send responses to you for editing.

2. Bugs of various kinds in "MS Kermit 2.28 jrd" are discussed below.

3. Rare computer hangups when engaging IBM mode and then entering the
Connect state. Peering at the interrupt level code in file MSXIBM shows
several places of difficulty if the mainframe were to have sent a char
before Kermit was ready to accept one. Some changes were made to hopefully
avoid problems; all involve completing work before interrupts can interfere.
The hangup problem seems to be like a corrupted segment register (ds?),
which could happen I suppose if a char arrived during serial port
initialization.  Actually, I or someone needs to have a hard look at the
code in SERINT to see if all UART conditions are properly serviced and if
the 8259 interrupt controller chip is attended to in an manner consistent
with both IBM PCs and ATs. ISRs are such fun! My quick changes are as
follows.

  Procedure SERINI:
   - flush UART received character BEFORE turning on interrupts,
   - change allowable UART interrupting conditions to avoid interrupts on
     TX Holding Buffer Empty (a nonsense interrupt for us) but allow them
     on Data Available, RX Line Change, and Modem Change,
   - move push/pop es to allow quicker procedure exit,
   - replace call to proc Clrbuf with separate code since Clrbuf turns on
     interrupts within the body of SERINI (a likely culprit).
  Procedure SERRST:
   - move push/pop es to allow quicker procedure exit.
  Procedure SERINT:
   - send 8259 chip End-of-Interrupt signal as almost last item in the proc,
   - remove strange Enable Interrupts (sti) instruction within proc body;
     after all, we got here via an interrupt.

4. Data overrun when turning around line between IBM mainframe and IBM
PC/AT.  An obvious thing to do here is insert a small wait interval before
sending a packet (sending filler chars could still upset the host during
line turn around); this is usually called pacing.  In terms of fast micros
and sluggish mainframe terminal handlers, pacing seems to be one of the
solutions.  I added a 3 millisecond wait routine at the very beginning of
procedure OUTPKT in file MSCOMM; it may not be enough, but the delay is
easily adjusted.  If it's too long then we will lose the time slice, if too
short then mainframe loses the first part of a packet.

5. Files sent while in server mode do not use repeat prefixing.  My goof due
to misunderstanding the non-standard protocol of setting the prefix char.  Two
lines of code were added in procedure SERVER (in file MSSERV) to force the
default prefix char into the active prefix after each server command.

6. Items not clearly explained in original read.me file for 2.28 jrd.
 -- GET allows both file names to be on the same line; ex. GET theirs mine.
 -- GET allows ? chars in filenames after the first char, but I forgot to
    invoke the # --> ? translation. I think earlier versions omitted this
    also. Similarly, I parse both file names on whitespace (can be fixed)
    which is probably painful for IBM users.

7. All these changes affect three files: MSXIBM, MSCOMM, and MSSERV. Below is
the output of MSDOS utility FC on the new and original "2.28 jrd" files. The
complete files, with extension of .NEW, are being sent as well.

8. Happy holidays.  Joe

[Ed. - Now that we have established network connection with Joe, we can send
files back and forth rather quickly.  There may well be a few more
contributions from him in the coming weeks.  I've put the new files in
PS:<KERMIT-MS> on CU20B, in case anybody wants to check them out -- feedback
solicited and appreciated!]

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

Date: Thu 19 Dec 85 16:51:47-PST
From: Ed Pattermann <[e-mail]>
Subject: Fast Kermit...

Does anyone have a patch for MS-KERMIT that allows it to work with IBM AT's
that have faster crystals installed, like a 18MHZ crystal? Kermit fails
to work after installing the new crystal.

[Ed. - Some of the changes mentioned in the previous message might go a long
way towards helping here.]

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

Date: 19 Dec 85 16:39:48 PST (Thu)
From: Mike Iglesias <[e-mail]>
Subject: IBM-PC Kermit v2.28 Display Problems

I've seen the display problems that Kathleen Connors has seen with the original
v2.28 Kermit on both a IBM PC-I and a Compaq.  It appears to only happen on the
old motherboard PCs (we have only one of those here) and the Compaq (which must
do something the same way that the PC-I does).  It does not happen on the newer
PCs (PC-II; 256k motherboard) or a Compaq 286, so I suspect it may have
something to do with the ROM BIOS.

Mike Iglesias
University of California, Irvine

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

Date: 20 Dec 85 02:13:23 +0100
From: [e-mail]  ([e-mail])
Subject: Kermit for Victor?

I'm using a Vicky with "BIOS Version 2.9 February 4,1984 for V9000" and
MSDOS 2.11. I've tried to run the SIRIUS ASM available from KERMSRV
at CUVMA but it doesn't work. The CONNECT corrupts a lot of keys
(I'm using a German keyboard) and the RECEIVE doesn't work at 2400 baud.
The generic MSDOS kermit is running up to 2400 baud.

Has anyone a special kermit version for the Vicky (Victor 9000) PC?

Thanks

Reinhard Goeth (Techn. Univ. of Darmstadt/Fed. Rep. of Germany)

P.S. I wish you a merry chrismas and a happy new year.

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

Date:     Fri, 20-DEC-1985 08:53 MST
From:     Eric Zurcher <[e-mail]>
Subject:  KERMIT for Apples with StarCard

        I thought I'd pass along a few things that I've learned while trying
to implement KERMIT on an Apple ][+ with a StarCard CP/M board.  All of this
may already be familiar to you, but I provide it to you on the chance that it
may keep someone else from having to reinvent the wheel.

        "Official" versions of KERMIT exist for Apples using the SoftCard CP/M
board, but I could not locate any for the StarCard.  The SoftCard versions do
not work, since the two CP/M boards use quite different approaches in gaining
access to the Apple's ports.  I have found that the "generic" CP/M KERMIT can
be made to work quite well with the StarCard, but only after making a minor
alteration in the BIOS of the operating system provided with the card.  In its
standard configuration, the BAT: device is identical to the CRT: device, both
refering to the Apple's monitor and keyboard.  However, changing a single byte
in the BIOS will cause the BAT: device to refer to a serial card in slot 2 of
the Apple, which is of course the sort of arrangement that generic KERMIT
needs.  The byte in question is located at an offset of 63H from the start of
the JMP tables of the BIOS (that is, it can be easily located by adding 60H to
the address pointed to by the JMP instruction at address 0).  This address
normally contains the value CC - changing it to C8 will result in the
definition of the BAT: device being changed to slot 2 of the Apple.  (I have
not seen this "feature" documented anywhere, though I have not requested
technical documentation from the manufacturers of the StarCard.)  Once this
change is made, generic KERMIT works quite well.

        I'm currently working (though not very hard) on the rather simple task
of developing a KERMIT that will handle the task of modifying this byte, if
necessary.  At present, I get around the problem by booting the system with a
disk that contains a version of the BIOS in which I have already modified the
byte.  I've also managed to combine a few features of the SoftCard KERMITs with
the generic KERMIT, to allow VT52 emulation to work and to "tidy up" the
display during file transfers.  It works reasonably well.  If you wish, I will
send a version to you once I get everything working the way I'd like.

        There are a few caveats (aren't there always?): (1) an 80-column
display enhancer is almost a necessity for reasonable terminal usage;  the
StarCard can try to produce a 70-column display using software, but this is too
slow to keep up at even 1200 baud.  (2) I have not thoroughly tested this, but
I suspect that a DC Hayes MicroModem II will not work with this arrangement -
the problem is that you can't dial a number.  It does appear to be possible to
first dial and establish the connection under Apple DOS, then reboot the
machine to run CP/M.  In any case, whatever serial interface is used must be in
slot 2 of the Apple.  (3) I have not tested this arrangement at speeds above
1200 baud, but I suspect that faster speeds will not work well.  (4) Most of
the VT52 emulation features work as they should, but the "home and clear
screen" operation is a bit slow - at 1200 baud I usually lose the next dozen or
so characters received after this operation.  (5) It appears that data is
restricted to 7-bit, and not 8-bit bytes.  For transfer of non-ASCII files,
parity should be set to space.

        I hope somebody, somewhere, finds some of this useful.  In the long
run, it would be preferable to have a KERMIT for this system which accesses
the serial port a bit more directly, rather than through twiddling the IObyte,
but I will leave that task to someone else.

                                        Regards, and Merry Christmas!
                                        Eric Zurcher
                                        Dept. of Biology
                                        Utah State University
                                        Logan, Utah 84322-5305
                                        REHABIV@USU

[Ed. - Thanks for the information; I've added your message to the APPLE.BWR
file for the time being.  USU seems to be a beehive of Kermit activity these
days...]

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

Date: Sun, 22 Dec 85 11:41:56 EST
From: Glenn Ricart <[e-mail]>
Subject: Request for KERMIT binary for Radio Shack 6000 Xenix

I'd like to run KERMIT under Xenix on a Radio Shack 6000 (previously
known as the 16B before some magic happened).  Unfortunately, this
system does not have a C compiler so I can't start from the sources.
Could someone contribute the binary?  . . . . Thanks!

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

Date: Sun, 22 Dec 1985  13:29 MST
From: Keith Petersen <[e-mail]>
Subject: Set File 8-Bit in Kermit-20

Request for change in next update of Kermit-20:  Because I do a lot of
uploading to Simtel20 and frequently use SEND *.* to do it, I have my
KERMIT.INI do SET FILE BINARY.  No problem so far, as I can use ASCIFY
later to fix the ascii files - meantime I can go away from the
computer and let things transfer automatically (of course my Kermit-80
is set to default to SET FILE BINARY).

Now the problem: When downloading from Simtel20, that INI is still in
effect and I get garbage on ascii files sent to me.  I need to be
able to tell Kermit-20 to use SET FILE 8-BIT for sends from me to
Simtel20, and SET FILE AUTO for sends from Simtel20 to me.

Suggest it might be added as SET FILE SEND AUTO and SET FILE RECEIVE
8-BIT.

--Keith

[Ed. - Good idea, will probably be added to the next release.]

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

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