SY.FDC@CU20B.COLUMBIA.EDU (Frank da Cruz) (07/22/86)
Info-Kermit Digest Tue, 22 Jul 1986 Volume 5 : Number 3
Today's Topics:
New Kermit for the Commodore Amiga
HP1000 Kermit
Bug in MS-DOS Kermit 2.29
Sanyo Kermit
BOO File Problems
Extra-Long Packets Specification
Some Thoughts about Long Packets in Kermit
CMS Kermit Problem
----------------------------------------------------------------------
Date: Mon 21 Jul 86 17:31:29-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: New Kermit for the Commodore Amiga
Keywords: Amiga, Commodore Amiga, C-Kermit
This new version of Kermit for the Commodore Amiga is based on the current
C-Kermit release, 4D(060), and has been sent in by Jack Rouse of SAS
Institute (Cary, NC). It replaces (by mutual agreement) the Amiga Kermit
previously submitted by Davide Cervone of the University of Rochester. The
CKI*.* files have been replaced, except for the bootstrapping files, which
remain where they were. Also, several of the system-independent C-Kermit
modules have been restored to their original condition (the previous Amiga
Kermit release altered them to include "printf2" and "printf3" functions;
these are no longer needed). The new release includes help, documentation,
beware, and "boo" files, along with source. The files are in KER:CKI*.* on
CU20B, plus (if you want to build from source) the other C-Kermit source
files (CKU*.C, CKU*.H, CKC*.C, CKC*.H, CKWART.*, CKCPRO.W). The files are
also available on BITNET from KERMSRV at CUVMA. For those who cannot get at
these files over the networks, or who have trouble with the bootstrapping
procedure, Jack will send an Amiga diskette including source and executable
program if you send him a check for $6.00:
Jack Rouse
106 Rubin Ct., Apt. A-4
Cary, NC 27511
The CKI*.* files from the previous Amiga Kermit are still available on CU20B
as KO:CKI*.*. Jack is also working on an adaptation of C-Kermit to Apollo
Aegis. This will be announced when it is received.
------------------------------
Date: 17 Jul 86 17:20 +0200
From: W._Michael_Terenyi%QZCOM.MAILNET@MIT-MULTICS.ARPA
Subject: HP1000 Kermit
Keywords: HP1000 Kermit
For a long time I have tried to install Kermit on every machine in our
company's multivendor computer hardware environment.
The biggest problems arose with the HP1000 (RTE-6/VM) we still have, but
finally I could solve them mostly.
The Fortran-Kermit (HPM* files) you distribute contains some bugs, but we
could get it running with an HP150-Kermit, but not with VAX- or
DEC20-Kermit. For a long time we had to use the HP150-Kermit (with debug
mode enabled) as an intermediate for transfers to other hosts. Not good, but
better than nothing.
When the Pascal-Kermit (HPA* files) arrived, we hoped to get it working,
because the Pascal-Compiler is identical on RTE-6/VM and RTE-A. But we ran
into big troubles, and as a regular reader of Kermit Info Digest I wonder
that nobody has complained about this Kermit version. These were the main
problems:
1. Two source files are missing (PASCAL.PAS, VMAST.PEX).
2. A compiler directive (STANDARD_LEVEL HP1000) is missing in some modules,
causing lots of compilation errors.
3. The revision number of the Pascal compiler has to be 2440
(or later) and not 2401 as stated in the instructions.
We did a lot of investigations to find this, but after adding the correct
compiler directive and installing a new version of the Pascal compiler, we
gave up, because of the missing source files. They contain only procedure
headers, and backtracing from the compilation errors it is possible to write
them again. But we did not want to put so much work in it. I also tried to
phone the author of this Kermit, but he went off in his holidays for 4 weeks
just half an hour before I called him, and nobody else was there to help me.
But finally everything turned into happiness, when I received a new Fortran
version of Kermit distributed at an HP1000 conference in Washington (DC). I
could compile and link it without any problems and it worked instantly.
Later I discovered a bug concerning the time-out setting of the terminal
port, but this was obvious and easy to correct. This Kermit version supports
remote and local (very difficult on a half-duplex machine!) operation as
well as server mode. And, best of all, this Kermit runs on RTE-6/VM and
RTE-A as well, the type and revision(!) of the operating system is
selectable by parameters.
I suggest, that this Kermit version should replace both the HPM* and HPA*
files in the official Kermit distribution.
I am sure that the author will give you the most recent version of this
Kermit (which I do not have, yet) if you contact him:
Paul Schuman
E-Systems, Inc., Greenville Division
P.O. Box 1056 CBN 101
Greenville, Texas 75401
Phone (214) 457-5358
Telex 701511 mfogvl ud
In the meantime we got MS-Kermit 2.29 on our ATs, and we discovered that the
HP1000-Kermit does not like it (file transfer with version 2.27 works
perfectly). We have found out, that the 2.29-Kermit precedes every packet
with XON or binary zero depending on the setting of the flow control, and
the HP1000-Kermit seems to have a bug in its packet parsing routine. Maybe
this is already corrected in the next release, which I will receive in
October presumably, but is now available from Paul Schuman as said above.
Best regards, Michael.
Real Name: Wolfgang Michael Terenyi
MAILNET: W._Michael_Terenyi_(SANDOZ)@QZCOM.MAILNET
ARPA/CSNET: W._Michael_Terenyi_(SANDOZ)%QZCOM.MAILNET@MIT-MULTICS.ARPA
JANET: W._Michael_Terenyi_(SANDOZ)%QZCOM@UK.AC.YORK.KL
G3 Fax: +43 222 867018
Telex: 132287 sfi a
Real Address: SANDOZ Research Institute
Brunner Str. 59
A-1235 Vienna
Austria, Europe
[Ed. - Many thanks for the information. We have written to Paul Schuman and
asked him to send it in. It will be announced when (if?) it arrives. Also
thanks for describing the MS-DOS Kermit problem so succinctly (see below).]
------------------------------
Date: Fri 18 Jul 86 11:22:05-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Bug in MS-DOS Kermit 2.29
Keywords: MS-DOS Kermit, IBM Mainframe, HP1000, Harris
The new MS-DOS Kermit has a serious problem when used with certain kinds of
host computers, including IBM mainframes, HP-1000's, and Harris minis. The
symptom is that file transfer doesn't work -- either at all, or else rarely.
The cause is that when flow-control is set to NONE, then Kermit erroneously
precedes each packet with a NUL (ASCII 0) byte. Most hosts are immune to
NULs on the communication line, but an IBM mainframe with VM/CMS will
discard all following characters up to the break character (CR), in Kermit's
case the entire packet. On the Harris, a NUL reportedly kills the entire
Kermit process. See the previous message for what happens on the HP-1000.
A patch is available for those who are affected by this problem. Since it
is rather long, it has been added to the end of the "beware file". This
file is available as KER:MSKERM.BWR on CU20B (via anonymous FTP on the
Internet) or MSKERM BWR on CUVMA (via KERMSRV on BITNET).
An updated release of MS-DOS Kermit containing fixes for this and all the
other reported problems, plus a few surprises, should be available in late
summer or early autumn. In the meantime, source-level patches will continue
to be listed in the beware file.
------------------------------
Date: 1986 Jul 21 19:43 EST
From: Bob Babcock <PEPMNT@HARVARDA.BITNET>
Subject: Sanyo Kermit
Keywords: Sanyo MBC Kermit
The Sanyo release of kermit version 2.29 has a bug which locks it at 300
baud. I got a copy of the sources over KERMSRV and fixed the problem. I
will send you the revised MSXMBC.ASM shortly.
I also got copies of the IBM specific routines and created a Sanyo version
with essentially all of the IBM features. This version requires an optional
video board which only some machines have. (The board was produced by Sanyo
to make the MBC series sufficiently IBM compatible to run Lotus 123.) I
have a couple little things which I may work on before sending the sources
off. I have named the Sanyo specific routines MSX55X.ASM, MSY55X.ASM and
MSZ55X.ASM, but you can change that if you prefer. Because of the video
board requirement, these do not replace MSXMBC.
[Ed. - Thanks. The names are fine, though it would be preferable if the
two Sanyo versions could be combined into one, which could tell at runtime
whether the option board was present. The new stuff will be announced when
it arrives.]
------------------------------
Date: Mon, 21 Jul 86 21:07:57 EDT
From: "Roger Fajman" <RAF@NIHCU>
Subject: BOO File Problems
Keywords: BOO File, Bootstrapping, MS-DOS Kermit, KERMSRV, EBCDIC
I figured out some problems that I encountered with BOO files and the IBM
PC. There were two:
(1) If you use the PUNCH command of KERMSRV@CUVMA on BITNET, the file comes
with trailing blanks, which will cause the EXE file generated to be
incorrect. The BOO format doesn't use blanks, so trailing blanks can be
safely stripped before the file is processed. However, MSBPCT.BAS does not
do this, so you had better.
[Ed. - The MSBPCB and MSBPCT programs should indeed strip trailing blanks.]
(2) When getting BOO files through BITNET, take care with your EBCDIC-ASCII
translations. Ours is the same as Columbia's, except for curly braces.
Most BOO files don't have curly braces, but MSBPCT.BOO (the C version of the
IBM PC BOO file decoder) does have a curly brace in it that represents a
count of NULs.
BOO files don't contain any kind of internal consistency check, such as a
byte count and/or checksum, so problems such as these just give you EXE
files that don't work.
[Ed. - It would have been nice to include consistency checks in .BOO files,
but since checksums or CRCs are based on the numeric, internal
representation of the characters, you get into trouble when going between
ASCII and EBCDIC systems. Actually, when you use the MSBOOT.FOR/MSBPCB.BAS
pair, there is a minimal kind of consistency check -- the length of each
line is transmitted along with the line by MSBOOT and checked by MSBPCB.
But you're right, you don't even get this with the MSBPCT programs. That's
why the recommended technique is to use these bootstrapping programs to
get a Kermit program that SEEMS to work onto your PC, and then use that
Kermit program to get another copy of itself, with error checking, etc.]
------------------------------
Date: Sat, 19 Jul 86 23:44:48 edt
From: roy@phri.UUCP (Roy Smith)
Subject: Re: Extra-Long Packets Specification
Keywords: Long Packets
> The first question some people ask when they learn of these of these [sic]
[Ed. - oops]
> devices [error correcting modems] is whether their error-correcting
> capability has made Kermit obsolete. The answer is an emphatic no [...]
I know this list is for discussing Kermit, but I couldn't help noticing that
exactly the same question is asked about uucp. Time and time again I've
seen people suggest that all the overhead of computing checksums that uucp
does could be eliminated if only you had error correcting modems. Come to
think of it, I've seen it asserted more than once that you don't really need
TCP/IP on an ethernet, since you don't have to worry about mangled packets.
Will people never learn?
As it happens, while I was typing in the first paragraph of this message, a
bunch of "/usr: file system full" messages popped up on my screen. Kermit,
uucp, and ftp (and presumably Decnet, Appletalk, Xmodem, and so forth) all
deal with full file systems in some rational way. Error correcting modems
do not. It doesn't do you much good to move the bits from here to there if
they just get dropped on the floor at the other end without any warning.
Roy Smith, {allegra,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016
------------------------------
Date: Sat, 19 Jul 86 01:18:10 edt
From: zeeff%b-tech.uucp%umich.csnet@CSNET-RELAY.ARPA
Subject: Some Thoughts about Long Packets in Kermit
Keywords: Long Packets, Sliding Windows
I see a potential problem with long packets - just because two kermits have
the capability, it might not make sense to use it. They may be connected
together by a regular modem. You can have some user selectable option, but
the less the user has to know about the lower levels, the better (getting
all the options set correctly can be difficult now). One solution might to
use adaptive packet sizing. They could start small, and rapidly grow larger
as it is determined that the link is error free. Another nice feature
(which I'm sure has been mentioned before) would be packet stacking and
built in compression. It might soon become difficult to determine where to
do some of these things - in kermit or in the modem.
- Jon Zeeff ihnp4!umich!umix!b-tech!zeeff
Jon_Zeeff@UMich-MTS.MAILNET
[Ed. - Well... There is also a packet-stacking extension to Kermit (called
"sliding windows"), which is independent of, and not mutually exclusive
with, long packets. However, sliding windows (a) require full duplex
communication, and (b) are complex to program. Any particular
implementation will depend on peculariarities of the system -- interrupts,
multiprocessing, etc -- in order to achieve full duplex transmission. Long
packets are the best way to boost performance in a half duplex connection
(and many of these new modems are half duplex), but you're right: long
packets should not be sprung on the user by default. The user should know
the necessary preconditions -- a very clean connection, large input buffers
at the receiving end, and effective, reliable end-to-end flow control.]
------------------------------
Date: 1986 Jul 21 19:43 EST
From: Bob Babcock <PEPMNT@HARVARDA.BITNET>
Subject: CMS Kermit Problem
Keywords: CMS Kermit
I have always found it difficult to run Kermit talking to an IBM mainframe
running CMS over a straight ascii line. The problem is that line noise
during a file transfer tends to interrupt the Kermit process and pop you
into CP. To resume execution of Kermit, you need to send a BEGIN command (b
is enough). But you can't do this without aborting the transfer at the
local Kermit, assuming that it hasn't already timed out before you noticed
the problem. This problem does not arise if Kermit is run over a series/1
interface or equivalent, but the IBM mainframe which is our link to BITNET
does not have series/1 software which would allow Kermit to run. I have
thought about modifying Kermit at different levels, either allowing the user
to hit a key and transmit a B, or making Kermit smart enough to recognize
the problem and automatically send the begin command. Do you know if anyone
else has attacked this problem? I don't want to reinvent the wheel. I
should emphasize that this is not a problem with the CMS Kermit, but rather
is a characteristic of the environment it runs in.
[Ed. - This is only a specific instance of a common problem: what should the
local Kermit do when the remote Kermit "goes away" during file transfer?
When the remote Kermit goes away, you're confronted by some aspect of the
underlying system, or in some cases nothing at all. The possibilities are
simply too numerous to be accounted for in the Kermit protocol, or any
protocol that attempts to span a large number of systems. You shouldn't
have to embody specific knowledge about a particular remote system in
another system's Kermit program -- if you did, where would it end? The best
that can be done is what is currently done: if a packet does not elicit the
expected reply, try again, up to the retry limit, and then give up, but also
allow for manual intervention. In the case of MS-DOS Kermit, you can type
Ctrl-C at any time during the file transfer to get back to Kermit-MS>
command level instantly, so that you can CONNECT and do whatever you can to
clean up. Unfortunately, there's no way to tell the local Kermit to resume
the file transfer where it left off.
CMS is a special case. Luckily, there's a special solution. Version 3 of
CMS Kermit (due for release Any Day Now, will put the line into a special
mode so that any characters at all that appear to CP will continue the
program, that is, will do what "begin" would have done.]
------------------------------
End of Info-Kermit Digest
*************************
-------