info-kermit@ucbvax.ARPA (08/03/85)
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
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 <SY.FDC@CU20B.ARPA>
Subject: C-Kermit 4C(057) Hurriedly Replaced
To: Info-Kermit@CU20B.ARPA
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
<JEUCK@SRI-KL.ARPA> 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 <SY.FDC@CU20B.ARPA>
Subject: Attribute Packets, Windows
To: oc.source@CU20B.ARPA, oc.jordan@CU20B.ARPA
cc: Info-Kermit
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!poulton%hplabs.csnet@csnet-relay.arpa
Subject: A Vote FOR Long Packets
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: knutson@ut-ngp.ARPA (Jim Knutson)
Subject: Sliding Windows vs. Long Packets vs. Segmentation
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
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: ken@cit-hamlet.arpa
Subject: Problem with Steven's Kermit for Apple //
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
ken@cit-hamlet.arpa
ken@caltech.bitnet
[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: INFO-HZ100@RADC-TOPS20.ARPA
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
PAWKA@NOSC-TECR.ARPA
[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
*************************
-------