info-kermit@ucbvax.ARPA (07/03/85)
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
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
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
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
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
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: lotto%lhasa@harvard.ARPA
Date: 30 Jun 85 14:19 EDT
Subject: MS DOS Memory Allocation in 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 lotto@harvard.ARPA 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
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: Frankston@MIT-MULTICS.ARPA
Subject: Kermit Versus 9600 Baud
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
*************************
-------