info-kermit@ucbvax.ARPA (08/01/85)
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
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
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: VIC@QUCDN.BITNET
Subject: Update of Pascal/VS Kermit for IBM VM/CMS
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
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: Bakin@MIT-MULTICS.ARPA
Subject: Re: The New Proposals
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
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 <Blarson@Usc-Ecl.Arpa>
------------------------------
Date: Mon, 22 Jul 85 09:11:50 edt
From: Steve Archer <archer@rochester.arpa>
Subject: TTSynch in 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!schulz@Purdue.EDU>
Subject: VMS-Kermit and VMS 4.0
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
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
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
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
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: BRIAN%UOFT02.BITNET@WISCVM.ARPA
Subject: Kermit-11 and 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
brian@uoft02.bitnet
------------------------------
End of Info-Kermit Digest
*************************
-------