info-kermit@ucbvax.ARPA (02/09/85)
From: Frank da Cruz <SY.FDC%CU20B@COLUMBIA.ARPA>
Info-Kermit Digest Fri, 8 Feb 1985 Volume 2 : Number 3
Departments:
ANNOUNCEMENTS -
MS-DOS Kermit for Sanyo MBC-550
New Cray Kermit
Commodore-64 FORTH Kermit Source Available
Kermit in Pascal for DG AOS, AOS/VS Systems
UNIX KERMIT -
More Unix Kermit Volunteers
MISCELLANY -
New MVS/TSO Kermit in PL/I
Multics Kermit Fix
Polo Kermit??
Sacred Characters, a Protocol Issue
Kermit for PCjr
----------------------------------------------------------------------
Date: Fri 8 Feb 85 11:32:55-EST
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
Subject: MS-DOS Kermit for Sanyo MBC-550
To: Info-Kermit@CU20B.ARPA
This is to announce MS-DOS Kermit for the Sanyo MBC-550 from Joe Smiley,
Du Pont Co, Wilmington DE. It requires DOS 2.11 or above.
He has supplied the MSXMBC.ASM system-dependent module, plus an executable
program file built from the version 2.26 sources (any volunteers to try
building a 2.27 version?).
He says he's still working on it, and will submit another version with
full VT100 emulation at some future time. The files are on CU20B in:
KER:MSXMBC.ASM - System-dependent module source
KER:MSMBC.HLP - Help file
KER:MSMBC.BOO - "boo" file for downloading
KB:MSMBC.EXE - 8-bit binary program image
------------------------------
Date: Wed, 30 Jan 85 16:52:46 mst
From: lfm@LANL (Leah F. Miller)
To: sy.fdc@CU20B
Subject: Cray Kermit
... has, to my knowledge, a current grand total of 4 installations: Los
Alamos, Livermore Natl Lab, Sandia in Albuquerque, and Cray Research in
Chippewa Falls, Wisc. So, that makes it rather a curiosity compared to some
others which must have many hundreds of installations. But user acceptance has
been immediate. No further updates planned. It's been a pleasure being
associated with your activities. Leah Miller
[Ed. - This is by way of announcing a new release of Cray-1 Kermit, which
is now available on CU20B as KER:CRAY.*.]
------------------------------
Date: Fri 8 Feb 85 11:37:24-EST
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
Subject: Commodore-64 FORTH Kermit Source Available
To: Info-Kermit@CU20B.ARPA
Bob Detenbeck of the University of Vermont has sent in the FORTH source
screens for his Commodore-64 Kermit. They are in KER:C644TH.SCR on CU20B.
There is also a short help file, KER:C644TH.HLP.
------------------------------
Date: Fri 8 Feb 85 16:55:09-EST
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
Subject: Kermit in Pascal for DG AOS, AOS/VS Systems
To: Info-Kermit@CU20B.ARPA
This is to announce a version of Kermit for Data General machines running
AOS and AOS/VS, written in SP/Pascal, contributed by Duane Galbi of
Maine-Endwell High School, Endwell, NY. The files are in KER:AOSK2.*.
The same person also contributed DG Dasher terminal support for MS-DOS
Kermit, but this cannot be installed for distribution yet because changes
were made to several modules, and these must be reconciled with other
people's changes to the same modules.
------------------------------
Date: Fri 8 Feb 85 16:55:09-EST
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
Subject: More Unix Kermit Volunteers
To: Info-Kermit@CU20B.ARPA
Since yesterday, several more volunteers have come forth, and some errors
in the addresses of previous volunteers have been corrected. Below is the
list as it stands. It continues to reside in KER:CKWHO.TXT on CU20B...
Meanwhile, there seems to be agreement that the "UUCP line locking" business
can be included in the Kermit program without legal entanglement if the code
is original, and not lifted from a proprietary program like UUCP itself.
Such code has already been contributed by Tony Movshon (see below), but is
not installed for distribution yet.
Another issue that is reported frequently is the length of the character string
constants, particularly in ckuser.c. These will need to be shortened. What is
the minimum longest string constant that the smallest C compiler will allow?
Now I know why so many C programs print long messages using a printf for each
line...
DEC Pro-350/380, Venix SY.FDC@CU20B (Frank da Cruz)
IBM 370-series, Ahmdah UTS SY.FDC@CU20B (Frank da Cruz)
Apple Macintosh SY.WBC3@CU20B (Bill Catchings)
Masscomp RTU 2.2 sob@RICE (Stan Barber)
Coherent vortex!lauren@RAND-UNIX (Lauren Weinstein)
Callan UniStar 300 with
Unisoft 68000 System V Unix EBM@MIT-XX (Eliot Moss)
ATT 3Bx, System V Chris@COLUMBIA-20 (Chris Maio)
IBM PC, etc, PC/IX HFISCHER@USC-ECLB (Herm Fischer)
IBM PC, etc, Xenix HFISCHER@USC-ECLB (Herm Fischer)
Xenix HFISCHER@USC-ECLB (Herm Fischer)
Os9 BLARSON@USC-ECL (Bob Larson),
bdale@cmu-cs-g (Bdale Garbee)
Version 7 vasoll%okstate.csnet@CSNET-RELAY (Mark Vasoll)
2.9 BSD hipl!tony@NYU-CMCL2 (Tony Movshon)
4.2 UUCP Line Locking hipl!tony@NYU-CMCL2 (Tony Movshon)
Prime BLARSON@USC-ECL (Bob Larson)
HP9000 Series 200 (HP9836)
with HP-UX System III b-davis@utah-cs (Brad Davis)
CP/M (Small C or BDS C) bdale@cmu-cs-g (Bdale Garbee)
------------------------------
Date: Wed, 16 Jan 85 15:58:40 CST
From: FARRELL@RICE.BITNET
To: SY.FDC%CU20B@COLUMBIA.ARPA
Subject: New MVS/TSO Kermit in PL/I
Rice has now completed implementing KERMIT under IBM MVS/TSO. This is a new
implementation of KERMIT for the TSO environment rather than a rework of the
VM/CMS code. It was written in IBM PL/I and a locally developed TSO command
writing package (which is as of yet unreleased). Rice TSO KERMIT has been
tested in MVS/SP 1.1.1 environment at Rice and the MVS/SP 1.3 environment at
University of Chicago.
This KERMIT is based on the version 5 protocol manual. It has been tested
with PCKERMIT 1.20, MSKERMIT(IBM) 2.26, Rice MacKermit (in beta test), and
MSKERMIT (IBM) 2.27. Server mode is also supported.
We are ready to send an MVS load module, the source, and limited
documentation. Because we have not yet released the command writing package
used in the source, it is not possible for other users to compile the
source. (We may decide to submit the package to the SHARE Library which
would solve this issue.) Both Chicago and Notre Dame were able to install
without modifications to the code containing calls to the command writing
package.
Thanks,
Farrell Gerbode
Rice University Computer Center
[Ed. - Note, we've also received other MVS/TSO contributions, but these
are based on the Chicago assembler version. A recent arrival from the
University of Toronto has Series 1 support. This one will be announced
when it arrives, and of course any news about the Rice MacKermit will
also be passed along. Meanwhile, if somebody at the U. of Chicago (which
produced the original MVS/TSO Kermit) could comment on how this version
should be viewed -- a replacement for theirs, an alternate version that's
only useful for PL/I sites, etc...]
------------------------------
Date: Wed 23 Jan 85 09:13:18-EST
From: Paul Amaranth <OC.AMARANTH@CU20B.ARPA>
Subject: Multics Kermit Fix
To: sy.fdc@CU20B.ARPA
I think I got a fix for that strange problem that was reported in [V1 #44 of
Info-Kermit]. This should work:
The following code should be inserted into the procedure setup_terminal which
is just before the end of the kermit_ module. My best guess is that an attempt
was being made to change the fnp modes (which included half duplex) before the
current transmission of text was completed. This code prevents that from
happening. I talked to the fellow who experienced the problem and he said
that it sometimes happened when receiving, but never sending. It also depended
on system load. The only difference in the code is that on SEND, there is a
time delay before the modes are changed, which would let any transmission
complete.
Oh well. This code has no effect on normal operation.
[Ed. - For now, the patches are in the file KER:MUKMT.BWR.]
------------------------------
Date: Wed, 30 Jan 85 16:23:50 EST
From: Dave Swindell <dswindel@bbn-labs-b>
Subject: Polo Kermit??
To: info-kermit@cu20b.arpa
Does anyone know if a Kermit version exists for a Polo PC?? The Polo is
supposedly 'IBM compatable' (what isn't), however, V2.26 IBM Kermit doesn't
work on it. We haven't tried generic MS-DOS Kermit yet. I wanted to see if
anyone else had any 'Polo' experience before I dive in any deeper!
Dave Swindell
BBN Labs
[Ed. - Bill Catchings had a Polo for a evaluation. He says it is not in any
way IBM compatible. They claim to be IBM compatible at the data file level;
in other words they can both use the same 1-2-3 files. Let us know if generic
MS-DOS Kermit works -- by the way, 2.27 generic Kermit has better support for
fooling around with the port designators and file handles than 2.26 did.]
------------------------------
Date: Fri, 1 Feb 85 13:23 CST
From: "David S. Cargo" <Cargo@HI-MULTICS.ARPA>
Subject: Sacred Characters, a Protocol Issue
To: INFO-KERMIT@CU20B.ARPA
Here at Honeywell we are running into an issue that I'm sure others have
encountered. I'll explain what we see happening and then ask for some
discussion about what can be done.
We have a number of systems which, for what ever reason, preempt certain
printing characters. Sometimes these are the computer systems, and
sometimes it is the network control hardware. Some of the typical
characters that cause problems are the backslash (hex 5C, "\"), the
pound sign (hex 23, "#"), the at sign (hex 40, "@"), and the tilde (hex
7E, "~"). These symbols are either escape characters (in which case
they can make it through the network if they are doubled), hardwired
editing characters, or network hardware command prefix characters. Some
of the networks over which we want to use Kermit get very convoluted.
There isn't any way we can see that would allow the problem characters
to be doubled, or escaped in an adequate way. The only way we can see
that avoids collision with "sacred" characters is to avoid using these
characters at all, in much the same way that avoiding use of the control
characters avoids problems.
The questions that I see this presenting are: how to specify the
characters that must be avoided, how to communicate the set of
characters to be avoided from one Kermit to another, how to agree on the
set, and how to handle the presense of such characters in the file (or
data) being transmitted.
The last question relates to another problem we have encountered, where
the transmitted file contains characters used by the protocol ("#" for
example). We can't always pick the protocol characters to match
characters which are not used in the source file. What is a workable
way to avoid that problem?
Ideally, agreeing on the set of characters would be straight forward.
Each side would be told what characters won't make it through if they
are transmitted to the other end, so it won't transmit that set.
Another alternative would be to not transmit any character in either
set.
The problems I see are in specifying the packet length (which is a
number encoded into a character) and the checksum (which is a number of
various size encoded into one or more characters). If some characters
must be avoided some values become unrepresentable. That clearly isn't
satisfactory.
One possibility would be to add a character encoding mechanism which
would take a packet, encode any of the forbidden characters before
transmission, and reconstitute them upon receipt. This has the
disadvantage of adding another layer to the protocol, requiring the
negotiation of another character, and complicating the packet structure
further (since its length on transmission would grow depending on the
number of characters which had to be encoded).
I am not sure that cure isn't worse than the disease. Still, it would
provide a way for Kermits to communicate through even more hostile
territory than they can now. We (at Honeywell) have pragmatic reasons
for wanting some way of setting the characters that must be avoided.
Others probably face the same problem. I want to open the issue up so
it can be discussed, and ideally a solution agreed upon. It isn't an
easy issue, but it is an important one.
[Ed. - Kermit was designed on the usually correct assumption that any
printable ascii character can make it from one end to the other unscathed.
In the rare cases when a certain printable is sacred, like the '@' that is
normally used as the TAC escape character, one can either change the Kermit
programs involved to double the character (the normal method for passing
escape characters through a device that looks for an escape character), or
change the escape character to a nonprintable character that differs from
Kermit's packet start, packet end, turnaround, and padding characters (if
any), or put the device in "transparent mode". Beyond that, I'm afraid that
the cure is indeed worse than the disease -- the likelihood that the
required extra layers of protocol could be added to scores of existing
Kermit programs (3 or 4 scores at last count) is pretty small. What's worse,
the poor user would have to know to tell Kermit to do this!]
------------------------------
Date: Wed 6 Feb 85 18:08:05-EST
From: Bdale Garbee <AG0B%CMCCTE@CMU-CC-TE>
Subject: kermit for pc jr.
To: sy.fdc%CU20B@CMU-CC-TE
Frank -- what is the status of kermit on the PC jr.? I keep getting
asked about it, and it's getting harder to turn people away. I haven't
done anything with the MSDOS version before.... reading back issues of
info-kermit pointed me to msibmjr.*, which don't exist. Does v2.26 work,
and if so, does it work only on the rs232 port? I think the guy who's
really griping is using some sort of internal modem?
Bdale
[Ed. - The PCjr comes with a built-in modem and an RS232 port. Kermit 1.20
and later work on the PCjr's RS232 port but not on the modem. To use the
RS232 port, you have to say 'set port 2', because it's COM2. We have no
plans to make it work on the modem -- we don't have a PC to play with any
more. Any volunteers?]
------------------------------
End of Info-Kermit Digest
*************************
-------