[mod.protocols.kermit] Info-Kermit Digest V5 #15

SY.FDC@CU20B.COLUMBIA.EDU (Frank da Cruz) (11/04/86)

Info-Kermit Digest         Mon,  3 Nov 1986       Volume 5 : Number 15

Today's Topics:
                 Kermit Files Split into Three Groups
               New Release of Kermit for TRS-80 Model 4
                  Atari ST Kermit Diskette Volunteer
                       Re: CompuServe vs Kermit
           How to Display Connected Directory in MS-Kermit
                      Kermit vs Datakit Networks
                PROCOMM Kermit File Transfer Problems?
              KermitLANd: Suggestions to Improve Kermit
                Ideas for Kermit Distribution Overflow

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

Date: Thu 30 Oct 86 17:08:01-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Kermit Files Split into Three Groups
Keywords: Kermit Distribution, Distribution, Tapes, OK State, UUCP

The Kermits just keep rolling in.  In June 1985, the material became too big
to fit on a single 1600-bpi 2400-foot reel of labeled tape, so we had to
split the files into two groups: A (micros) and B (minis and mainframes).
In August 86, the collection grew too large for two tapes, and intallation
of some new versions was put on hold.  So now a third tape (C) has been
added.  Tape C is for "esoterica" (less popular versions of Kermit,
implementations infrequently requested from us, European and Japanese
versions, etc, and redundant versions) and for large documents -- the Scribe
source for the User Guide and Protocol Manual, the mail archives, etc.  The
AAVERS.HLP file tells exactly which group each implementation is assigned
to.  AAFILES.HLP explains in a bit more detail.

Apologies to anyone who feels slighted by having their favorite Kermit
version assigned to the "esoteric" tape.  The assignments were not totally
arbitrary and capricious, but were made mostly according to the frequency
with which people ask for (or about) these versions, with the goal of having
the three collections occupy about the same amount of disk/tape space (about
15MB each).  The most popular micro and mainframe Kermits remain on tapes A
and B, so that people who order these tapes in the "old way" will still most
likely get what they were expecting.

For network access, the procedures are pretty much unchanged.  FTP, NFT, and
KERMSRV will continue to work as before.  The file KER:AANETW.HLP has been
updated (along with all the other relevant files) to reflect the new layout.
Apologies for the disruption in KERMSRV service from Friday afternoon (Oct
31) to Monday afternoon (Nov 3) while the files were being reorganized.

As we announced a couple months ago, our major tape-making facility (a small
UNIX Vax) could not have its Kermit files updated until this reorganization
took place.  This has now been done.  Oklahoma State University, which keeps
a parallel Kermit collection for UUCP access, updates its files from this
VAX; hence OK State has not been getting new Kermit files since August.  We
will send them a new set of tapes this week, and the automatic updating
should kick in again after they have installed it.

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

Date: Fri, 31 Oct 86 13:01:26 -0600
Subject: New Release of Kermit for TRS-80 Model 4
From: Gregg Wonderly <gregg%a.cs.okstate.edu@CSNET-RELAY.ARPA>
Keywords: TRS-80 Model 4

This is to announce the newest version of the TRS80 Model 4 KERMIT.  This
version, 5.2, has many small bug fixes, as well as some major additions to
the program.  The changes are listed in detail in the file M4CHGS/ASM, but
the most important ones since the previous release (5.0) are bug fixes,
command restructuring (particularly SET FILE), transaction and debug
logging, and wildcards allowed in SEND and KILL.

Version 5.1 was never released.  There were also some changes in the
H19-filter that is now included in the distribution.  These changes include
the addition of a STRIP8 parameter to SETH19 that will allow the parity bit
to be stripped from characters before they are put on the display.

In this version of KERMIT, I have made some attempts to start reducing the
number of hardware manipulations that do not use the system SVC's.  However,
there are still many Model 4 specific operations.  I would like to begin
replacing the Model 1/3 version of KERMIT with this version, in the interest
of making more of the functionality of Model 4 KERMIT available to Model 1
and 3 owners.  If anybody is interested in taking on the task of doing this
for either machine, the help would be greatly appreciated.  Most of the work
will involve finding replacement code for routines that manipulate the Model
4 hardware (Display, Comm Line, etc...).

Any interested parties should send mail to me at the address below so that
there can be some sort of cordination of efforts.

Gregg Wonderly
Department of Computing and Information Sciences
Oklahoma State University

UUCP: {cbosgd, ea, ihnp4, isucs1, mcvax, uokvax}!okstate!gregg
ARPA:  gregg@A.CS.OKSTATE.EDU or gregg%okstate.CSNET@CSNET-RELAY

[Ed. - Thanks, Gregg!  The new version replaces the old one as KER:M4*.*.
In the spirit of consolidating the hundreds of Kermit versions, I'd heartily
encourage anyone who cares about the TRS-80 Model 1 and 3 Kermits to get
together with Gregg and try to hammer together a common version for the
models 1, 3, and 4.]

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

Date: Mon 3 Nov 86 12:05:59-EST
From: Il H Oh <SA.IL@CU20B.COLUMBIA.EDU>
Subject: Atari ST Kermit Diskette Volunteer

I finally got Kermit running on my Atari ST.  I'd be glad to mail ST Kermit
diskettes to other ST users, if they'll send me a preformatted diskette and
a self-addressed, stamped return mailer.  My address is:

  Il Oh
  362 Riverside Dr. Apt. 10B7
  New York, NY 10025.

il

[Ed. - Many thanks!  Diskette volunteers are always welcome, as are user
groups and diskette services that are willing to provide Kermit diskettes by
mail order at low cost (say, in the neighborhood of $10).  If anyone out
there has a Kermit program on a diskette that's not readily available from
Columbia or other sources, you are heartily encouraged to volunteer as Il
has done, or to submit it to an appropriate user group or diskette service.]

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

Date: Tue, 28 Oct 86 21:40:12 est
From: jpm@bnl.ARPA (John McNamee)
Subject: Re: CompuServe vs Kermit
Keywords: CompuServe

To answer the query from Dan Caldano in Info-Kermit V5 #14: no, CompuServe
does not support Kermit.  They support XMODEM and two of their own protocols
(CIS "A" and CIS "B"), and are working on something like X.PC for concurrent
file transfer and terminal sessions.  I doubt they are going to support
Kermit since it was a major fight to get them to support XMODEM, and a lot
more of their users have XMODEM than have KERMIT.

John McNamee	<jpm@BNL.ARPA>	   CompuServe: 70235,1345

[Ed. - Do the current protocols suffice?  Can everybody get at Compuserve
with an 8-bit transparent path, with buffers that never need to be shorter
than 132, etc?  Or do they all have CompuServe A & B on their micros?  If not,
then maybe those who need Kermit could start infiltrating and agitating...]

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

Date: Wed 29 Oct 86 15:05:29-EST
From: Peter Kanaitis <PK0P@TD.CC.CMU.EDU>
Subject: How to Display Connected Directory in MS-Kermit

In Info-Kermit Digest V5 #14, John C Klensin writes:

>2) There is apparently no convenient way to display the [path]name of the
>current local directory....
>
>[Ed. - Right, this should show up in a future release.]

Why not do a:

Kermit-MS>run cd
 or
Kermit-MS>run chdir

P. Kanaitis
Allegheny-Singer Research Institute
PK0P@TD.CC.CMU.EDU

[Ed. - Where there's a RUN, there's a way...]

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

Date: Wed, 29 Oct 86 08:02:46 est
From: ulysses!psk@ucbvax.berkeley.edu (Philip S. Kravitz)
Subject: Kermit vs Datakit Networks
Keywords: Datakit

Unlike Vern Bradner (Info-Kermit Digest V5 #14), I use Kermit all the time
over Datakit networks and have not experienced any problems.  (I primarily
use the Unix version of Kermit although I have had no problems with the
MS-DOS version either).

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

Date: Wed, 29 Oct 86 16:10:04 PST
From: Lawrence_Clarke%UBC.MAILNET@MIT-MULTICS.ARPA
Subject: PROCOMM Kermit File Transfer Problems?
Keywords: PROCOMM

I am having problems transfering files from an IBM-PC/XT using PROCOMM V2.42,
to a VAX/VMS V4.4 system running KERMIT-32> V3.1.066.  File transfers seem to
work fine with normal PCKERMIT/MSKERMIT V2.29, but will not work with PROCOMM.
Has anyone out there had any experiences with PROCOMM'S kermit file transfers
to a VAX ???

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

Date: Thu, 18 Sep 1986 15:28 PDT
From: "Jeffrey Sicherman"  <JAJZ801%CALSTATE.BITNET@WISCVM.WISC.EDU>
Subject: KermitLANd: Suggestions to Improve Kermit
Keywords: Kermit Protocol, Suggestions

My intention was to link several PCs with on onsite minicomputer.  Since
Kermit is already in the public domain and is implemented on numerous
machines, it seems to me that it could be suitable for this purpose if some
program changes were made to existing implementations and a very few
(perhaps even non-essential) packet/protocol changes were made for a
LAN-only environment.  Some of the considerations that have occurred to me
are indicated below, but I'm sure there are some features and complexities
that I have overlooked.

[Ed. - Jeffrey goes on to point out that a Kermit server is a lot like a
network file server, and then discusses problems of routing, station
identification, topology, media access & contention, file attributes, mail,
etc., at some length.  KERMIT IS NOT A NETWORK.  It's strictly for
point-to-point, user-initiated, temporary connections over serial
communication devices.  Furthermore, Kermit provides terminal emulation, NOT
virtual terminal service -- there's a big difference.  Kermit's design is
simply not amenable to layering of arbitrary kinds of network services --
especially interactive ones like virtual terminal service, SMTP dialogs,
etc.  All these problems have been solved already, and a lot of the software
-- particularly TCP/IP implementations -- is either in the public domain or
else relatively cheap.  Let's remember that the vast majority of Kermit
users are individuals with modems who couldn't care less about these issues,
let alone take the time to work on design and implementation problems that
take huge, PAID, programming teams years to solve.]

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

Date: Thu, 18 Sep 1986 00:19 PDT
From: "Jeffrey Sicherman"  <JAJZ801%CALSTATE.BITNET@WISCVM.WISC.EDU>
Subject: Ideas for Kermit Distribution Overflow
Keywords: Files

I noted the request for assistance in cleaning up the Kermit distribution
files in the recent digest (vol 5 no. 8) and the associated difficulties in
maintaining order in the system.  In response to this, I suggest the
following:

It would be useful to have a file that was a matrix of kermit
implementations.  The rows of this matrix would be the various
implementation; the columns would be features implemented.  This could be
restricted only to features defined within the Kermit protocol and standard
or could also include other esoterica but should at least include all the
defined features and such things as mode of operation.  The matrix entries
could be as simple as Y/N or X/- to indicate the compliance, or a level of
support (e.g.  checksum types) or could indicate parametric values (e.g.
maximum packet sizes) or the characters used for implementation (e.g.
prefixes).

     A couple of columns could also include annotations such as latest
version.  Multiple entries might be desirable where there are multiple
implementations or there is a new version in beta test; if so they should be
marked as such.  It would also be nice to have some figure of merit or
rating that indicates the reliability, quality of documentation, and ease of
use; this would probably be not scientific in nature but hell, one of the
advantages of development by controlled chaos is not having to adhere to a
lot of bureaucratic rules.

     Admittedly, a matrix of reasonable comprehensiveness would be rather
large and be difficult to present in printed form.  Therefore there should
be a native, master form of the matrix which is comprehensive.  This, I
expect, would take the form of a spreadsheet file (in native form and/or
some common convertible, importable standard one)...

[Ed. - Jeffrey goes on to describe how the matrix might be implemented, and
discusses some of the attendant problems.  It's a great idea, but one that
will probably never see the light of day.  If it's a spreadsheet, it's
necessarily dependent on some piece of software that not everybody has.  If
it's plain text, we've got a problem in organization and formatting; many
people want to see this information in printed form, which limits it to 80
or 132 columns in width -- our AAV*.* files are the best we've been able to
come up with to date; they fit on the screen, and can be printed 2-up on
landscape paper and/or double-sided for convenient mailing (when you mail 30
or 40 Kermit info packets per day, you have to think of these things).  They
show the most important information (file prefix, system, os, language,
version number, date, contributor) as compactly as possible in the space
that we have.  To reorganize these files all you need is a sorting program,
which every computer should have, and to search them a text editor suffices.
Still, the need for a master list of Kermit versions (available, on-the-way,
and possible) that includes more information than the AAV and AAW files is
real.  I expect we'll have to do something like this one day, and the form
it will take will be some kind of simply structured plain text.  It's just a
matter of finding the time to do it.]

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

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