SY.FDC@CU20B.COLUMBIA.EDU (Frank da Cruz) (12/19/85)
Info-Kermit Digest Thu, 19 Dec 1985 Volume 3 : Number 34
Departments:
ANNOUNCEMENTS -
New Honeywell CP-6 Kermit
New version of IMUSIC
MS-DOS KERMIT -
MS-DOS Kermit 2.28 jrd Problems and Fixes
IBM-PC Kermit V2.28 jrd Display Problems
TopView Support for MS-DOS Kermit
More MS-DOS Kermit 2.28 jrd Problems
MSBOOT.FOR for Unix f77
MISCELLANY -
DEC-20 File Naming Problem
Os9 kermit warning!
Bugs in the CP/M Turbo-Pascal Kermit V1.00
Re: Apple-II Kermit Bugs
----------------------------------------------------------------------
Date: Thu, 18 Dec 85 10:50 EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: New Honeywell CP-6 Kermit
This is to announce a new Kermit program for Honeywell CP-6 systems from Lee
Hallin at Honeywell (Lee-Hallin%LADC@CISL). This one is written in PL/6, a
PL/I-like language, and includes text/binary file transfer, wildcards, all
the prefixing options, server and client operation, command files, etc, but
lacks CRC, file interrupt, attributes. (The other CP-6 Kermit is written in
Pascal and comes from Bucknell University.)
Lee's new CP-6 Kermit is available from CU20B via anonymous FTP as KER:HC6*.*.
Again, apologies to everyone on BITNET for the hiatus in getting new files
on KERMSRV; we should be back in business on that end after the holidays.
------------------------------
Date: Mon, 16 Dec 85 20:14 EST
From: John Voigt - Systems Group Tulane <SYSBJAV@TCSVM.BITNET>
Subject: New version of IMUSIC
I have a new version (1.2) of IMUSIC KERMIT available. This version
incorporates several fixes as well as enhancing the set ? function. I have
sent you the complete source with all the new changes.
JV/
[Ed. - Thanks! This replaces the previous version (1.1) on CU20B. It's
in KER:IMUSIC.ASM.]
------------------------------
Date: 12 Dec 85 21:23:04 PST (Thu)
Subject: MS-DOS Kermit 2.28 jrd Problems and Fixes
From: donovan@aero
I've attached a fix to MS-DOS Kermit v2.28 rjd for a problem in the send
protocol. The problem occurs when a send command follows a Kermit generic
command which causes flags.xflg to be set. This happens whenever a remote
server displays output on the local screen. The GENRIC procedure in MSSSER
is the culprit, but the simplest fix is to reset xflg in the SEND command
processor just before the server entry point at SEND11. Here are diffs for
MSSSEN.
..........mssend.old
; Send command
..........msssen.asm
; Send command - protocol handler to send a file
; Normal entry - SEND does file transfer preceded by "F" packet
; resets xflg
; Server entry - SEND11 does file transfer preceded by "X" packet
; set xflg = 1 before call
..........mssend.old
send11: mov flags.nmoflg,0 ; Reset flags from fn parsing. [21a]
mov ah,setdma ; set dta address [jrd]
..........msssen.asm
mov flags.xflg,0 ; Reset flag for normal file send [mtd]
SEND11: mov flags.nmoflg,0 ; Reset flags from fn parsing. [21a]
mov ah,setdma ; set dta address [jrd]
[Ed. - Thanks! This was the most glaring bug in this version.]
Also, the Z-100 version has had a bug in backspace processing since v2.27.
When entering Kermit commands at the prompt, backspace (^H) won't back up
over characters on the screen. The problem is caused by a change made to
MSSCMD.ASM near the label "cmge11". Backspace was removed from the set of
characters which are echoed. The fix is to change MSXZ10.ASM to send an
extra backspace. "diff"s below.
..........msxz10.old
delstr db BS,' ',BS,'$' ; Delete string. [21d]
home db ESC,'H$'
..........msxz10.asm
delstr db BS,BS,' ',BS,'$' ; Delete string. [21d]
home db ESC,'H$'
The MS-DOS version with Joe Doupnik's modifications works with both HP150
and, with this fix, Z-100 modules. Joe's modifications are a major
improvement to MS-DOS Kermit. I suggest that once the documentation catches
up with the programming, the revised Kermit should be accepted as MS-DOS
Kermit v2.29.
[Ed. - Well, a couple more problems remain, and the contributions keep
pouring in. But you're right, we have to draw the line somewhere.
See below...]
------------------------------
Date: Sat 14 Dec 85 05:33:09-EST
From: Kathleen Connors <GS4.K-CONNORS@CU20A.COLUMBIA.EDU>
Subject: IBM-PC Kermit V2.28 jrd Display Problems
I tried the new 2.28 version of Kermit for the IBM PC tonight. It still has
some of the same problems (2 out of 3) that the old 2.28 version had, which I
reported to you last June.
1) When you GET a file the file transfer screen puts an "s"
in upper left hand corner of the screen.
2) The mode line under the same conditions displays nothing
except a single "^" in the first position.
The truncation of the file name upon receiving a file has been fixed. I am
using a IBM PC I (64k motherboard), 512k of memory, DOS 3.0 and a internal
Qubie (Hayes compatible) modem. Since these problems, albeit cosmetic, still
exist I will probably continue to version 2.27.
[Ed. - Has anyone else ever seen this? I haven't, and I've been running
both 2.28 and 2.28 jrd on an IBM PC for a couple weeks.]
Suggestions for future Kermits:
1) A means of clearing the terminal screen buffer from the local Kermit.
2) The Kermit initialization file should be allowed to be
called KERMIT.INI instead of MSKERMIT.INI.
[Ed. - The reason it's called MSKERMIT.INI is that if you accidentally
transfer your KERMIT.INI file from a mainframe, you'd be in for some nasty
surprises the next time you started Kermit up on your PC.]
3) The ability to send a file "raw" without the Kermit protocol just xon/xoff.
[Ed. - Everybody wants this, along with login scripts and a DIAL command.
Maybe someday someone will write the code.]
------------------------------
Date: 12/16/85 6:10:45 E.S.T.
From: TUCBOB@TUCCVM.BITNET
Subject: TopView Support for MS-DOS Kermit
Here is a new MSYIBM terminal emulation module; the following changes
were made:
. ANSI set graphics rendition support extended to handle color attributes
in addition to monochrome
. Direct moves to and from the video buffer modified to use TOPVIEW
interrupt codes, so that KERMIT can run in the background under
TOPVIEW and take advantage of TOPVIEW windowing support.
The following parameters are used in a TOPVIEW Program Information File to run
KERMIT under TOPVIEW with the MSYIBM TOPVIEW support added.
Memory: Variable. Suggest min and max be set to 128K to allow 'run' support.
Set system memory to about 20K
Screen type: D
Pages: 4
Window size: 25 by 80
Offsets: 0 0
Writes directly to screen: no
Accesses system keyboard buffer: no
Runs only in the foreground: no
Uses math coprocessor: no
[Ed. - Thanks! I haven't had a chance to try this out, but if these are the
only changes, then it should be compatible with JRD's new stuff, except for
one minor change that JRD made about Heath line wrap. If anybody wants to
try this out, the file is with JRD's Kermit, stored as
PS:<KERMIT-MS>MSYIBM.TOP on CU20B only -- If you take it, please report back
about how/if it works, and whether it's safe to distribute as the standard
version.]
------------------------------
Date: Thu 19 Dec 85 09:24:23-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: More MS-DOS Kermit 2.28 jrd Problems
Beyond the bugs reported already (like the X-Flag bug), there are at least
two subtle problems with the new MS-DOS Kermit. First, even when assembled
correctly with the "right" assembler and switches, it will sometimes (very
rarely) start executing garbage after a CONNECT command. This happened to
me exactly once in several weeks of constant use -- I had escaped back from
a connection to the DEC-20, gave the DO IBM command, switched my port
contention unit to the IBM mainframe, gave the CONNECT command, and poof --
system totally dead, had to be rebooted. A few other people have reported
similar occurrences. I can't reproduce it; can anybody else?
The second problem applies to earlier releases as well, but only shows up
on a PC/AT, and (for us at least) only when communicating with a half duplex
system at 9600 baud using handshake. The sympton is that, after the end of a
file transfer session from the mainframe to the PC, after the mainframe sends
the B (Break transmission) packet, the AT responds with its ACK, but the ACK
shows up as garbage at the mainframe. If on the AT you SET DEBUG ON, the
problem goes away. When the connection is run through a line monitor,
everything appears normal; the AT responds to each packet from the mainframe
immediately as the XON handshake appears, and ACK is in correct format.
The speculation is that the AT is somehow ACKing the B packet "too fast".
Even though we haven't caught it sending the ACK prematurely on the line
monitor, the behavior is exactly what you'd expect if a transmission
occurred before the line was fully "turned around". Why would this happen
after a B packet, but not after any other packet? Several possible
explanations suggest themselves: (a) unlike most other packets, the B packet
requires no processing, and can be ACK'd immediately; (b) MS-DOS Kermit
somehow forgets about handshaking after the B packet; (c) MS-DOS Kermit is
handling the UART incorrectly.
I think (b) is unlikely; we never saw any supporting evidence on the line
monitor. While (c) is a possibility, it would take a lot of digging through
the low-level code to show up a problem; a cursory inspection reveals
nothing obvious (the UART's output holding register is always tested for
emptiness before giving it the next character).
If (a) is true, it would imply that the host is sending its XON before it is
really and truly ready for input. Unlikely as this may seem (it's a
lightly-loaded IBM 3083), the fact that the problem only happens with the AT
-- which is much faster than the PC or the Rainbow -- lends some credence to
this theory. If this is the real explanation, then the thing to do would be
to insert a brief sleep in MS-DOS Kermit before ACKing the B packet. But
there are also some other packets that don't require any processing, namely
those that arrive with bad checksums; thus we might have to sleep before
retransmitting or NAKing as well.
If anyone can offer any insight or evidence to support any of these
theories, it would be much appreciated. But beyond that, we may have here a
presage of things to come. As microcomputers get faster and faster, they
may begin to strain the assumptions underlying the design of our
communications equipment.
------------------------------
Date: 13 Dec 1985 1427-EST (Friday)
From: Tom Putnam <ac4@purdue-asc.ARPA>
Subject: MSBOOT.FOR for Unix f77
The subject FORTRAN program is supposed to be run on a host machine in
conjunction with MSPCBOOT.BAS on a target MS-DOS machine to download
MSKERMIT.BOO and similar binary files. The program requires several
modifications to operate under UNIX. (We are running UNIX 4.2 BSD).
In particular:
* The variable ACK is declared as a 4-element array, but only the
first element is ever used. The initial READ statement:
READ (5,200) OK, SPACE, COMMA, ACK
200 FORMAT(4A1)
implies that the whole array ACK will be read. Since the format does
not allow enough elements, a second "line" or "record" of input is
requested, so file transfer never gets off the ground.
* The write statements include a blank for carriage control. Although
some systems strip this character on output to the terminal, UNIX terminal
output includes the blank and thus fouls up the character count check.
I corrected these problems, converted the program to FORTRAN-77, and
cleaned-up the logic a little so that we could use it on our systems.
The modified version of the program is available via anonymous ftp from
ASC.PURDUE.EDU in the "kermit" subdirectory, file name "msboot.f".
[Ed. - It's also on CU20B as KER:MSBOOT.F.]
Tom Putnam, Manager of User Services
Purdue University Computing Center
ARPANET: ac4@asc.Purdue.EDU
or ac4@purdue-asc.ARPA
BITNET: PUTNAMT@PURCCVM
CSNET: ac4@purdue-asc-tn
USENET: ac4@pucc-j.UUCP
USMAIL: Mathematical Sciences Bldg.
West Lafayette, IN 47907
PHONE: 317/494-1787
------------------------------
Date: Tue, 17 Dec 1985 13:34 EST
From: CPH%MIT-OZ@MIT-MC.ARPA
Subject: DEC-20 File Naming Problem
I am using TOPS-20 Kermit version 4.1 and running into the following problem:
The filenames that I am using on my microcomputer are in the same format as
TOPS20 filenames, that is, "<name>.<type>.<version>". The software system
maintains the version numbers in the usual way. As we have quite a few of
these computers, which are not tied together with a network, we use Kermit
to transfer files to and from MIT-OZ, our DEC 20. This gives us all a
shared file system to work from.
Now, my problem is that I want to transfer files from my local machine to the
20, retaining the version number (note that this works fine when transferring
from the 20 to the local machine). This is so the version numbers on the 20
will match the version numbers on the local machine.
Unfortunately, TOPS20 Kermit doesn't have an option to do this. As far as I
can tell, the only options I have are "set file naming unconverted" and "set
file naming normal-form". In neither case is the version number I specify
used to write the output file on the 20. Instead, the file is forced to be
a "newest" generation -- either "FOO.BAR.34.0" (where the <type> is
"BAR.34") or "FOO.BARX34.0", respectively.
Could this be changed? It seems to me that if the version number is
explicitly specified, it does no harm to open the output file under that
name if one does not already exist. Or, if that is not reasonable, could
you add an option, say, "set file naming literal", that does what I want?
It is really a pain for me to have to rename all my files after I transmit
them.
Thanks,
Chris Hanson
[Ed. - Thanks for the suggestion. I'll try to add another file-naming
option to Kermit-20 in the next release.]
------------------------------
Date: Mon Dec 16 10:58:59 EST 1985
From: dolqci!irsdcp!scsnet!sunder@seismo.CSS.GOV
Subject: Os9 kermit warning!
A warning about using kermit under os9 on a tandy CoCo: If you use kermit
with the multi-pak and the delux rs-232 pak, that is you intend to use /t2
as your outgoing device you MUST have the rs-232 pak in slot 1 of the
multi-pak. In fact the device driver for /t2 requires that the rs-232 pak be
in slot 1. ANY program that uses /t2 will only run if the rs-232 is in slot
1. Also it appears that you must have the carrier forced on BEFORE you run
kermit if you are using sometype of smartmodem. (maybe some os9 wizard out
there can find a patch to the device driver to let /t2 look for the rs-232
pak in another slot).
Kermit on the CoCo is still (as far as I know - maybe bob larson knows
more) untested using device /t1, the so called "bit banger" port.
~ Addresses: USmail: IRS, 1111 Constitution Ave. NW Washington, DC 20224 ~
~ Atten: M. Sunderlin PM:S:D:NO Office Phone: ~
~ UUCP: ...seismo!dolqci!irsdcp!scsnet!sunder (202) 634-2529 ~
~ ...decvax!philabs!ubbs!sund (FTS) 634-2529 ~
~ CIS: 74026,3235 ~
------------------------------
Date: Wed, 18 Dec 85 13:32:59 cst
From: Jeff Woolsey <woolsey%umn.csnet@CSNET-RELAY.ARPA>
Subject: Bugs in the CP/M Turbo-Pascal Kermit V1.00
I have found and fixed a few bugs in the Turbo Pascal Kermit for CP/M-80,
and made some simple but useful enhancements.
Bug #1: Binary file transfers "worked" (everybody was happy with checksums)
but the file was missing the 8th bit sometimes. &X would not get the 8th
bit set, but &#X would. The code that checked for control characters in
this case forgot that this was an &-quoted character if it wasn't also
#-quoted. The fix in the else clause should be obvious. See procedure
expand_packet in file KREC1.PAS here:
[Ed. - Code omitted.]
Bug #2: This first showed up as filenames listed by the DIR command being
separated by linefeeds. The solution eluded me until I realized that I was
in user area 10 (= ASCII linefeed) at the time. Fix it by not writing the
first "character" of the file name. See procedure writefilename in file
KDIR.PAS.
Bug #3: The scourge of all machines using 16-bit signed integers. The
displays of bytes (remaining to be) transferred wrap to negative integers
above 32767. Since this number is calculated by multiplying blocks by 128
(an integer), you really only get 9 bits of information there. This can be
remedied by multiplying by 128.0 (a real) and formatting the result. See
procedure update in file KDISPLAY.PAS. See procedure open_file in file
KOPEN.PAS.
Enhancement #1: I got tired of having to tell the host explicitly the name
of each file I was downloading when I should have been able to use
wildcards. The impediment here is that Turbo Kermit goes to receive_init
state when it gets the EOF packet, and expects a send_init packet from the
host. Instead, it gets a file_header packet, and aborts. A two-line change
allows Kermit to receive multiple files in this case. Find the
repeat/case/until block that processes the incoming packets. Only one of
the cases ever sets the state variable (to receive_init). Change it to
receive_header, and add a clause to the until condition checking for state
<> receive. See procedure rfile in file KREC1.PAS here
[Ed. - Code omitted.]
Enhancement #2: Especially in conjunction wtih Enchancement #1, I wanted to
be able to see the name of the file being transferred along with all the
other statistics being displayed. I stuck "gotoxy(58,2); write(fileref);"
at the front of procedure open_file in file KOPEN.PAS.
The above should be of general interest. What follows summarizes the other,
more machine-specific changes that I needed to make.
I undid the IOBYTE stuff so that I could support all 4 of the serial ports
on my system. I have a 1200 bps autodialing modem and a dumb 2400 bps modem
and I wanted to be able to autodial 2400 bps systems. I support searching
through the various PAMS/PDSE/et.al. BBS lists and extracting the phone
numbers. I rewrote pieces of the command processor to make it easier to add
new commands while retaining the ability to abbreviate them to uniqueness,
and I implemented meaningful semantics for commands like CONNECT 1 or
RECEIVE FRED.PAS . I have a text capture mode, and if I desire the terminal
handler converts ANSI escape sequences into H19 sequences for my console.
...
The aim of Nuclear Freeze is to prevent Nuclear Winter.
Jeff Woolsey
...ihnp4{!stolaf}!umn-cs!woolsey
woolsey@umn-cs.csnet
[Ed. - Thanks. I've put this message in full (with code) in KER:TURBO.BWR on
CU20B, and have also passed it along to the Turbo Pascal Kermit authors.]
------------------------------
Date: Wed, 11 Dec 85 16:55:16 PST
From: Samuel_Lam%UBC.MAILNET@MIT-MULTICS.ARPA
Subject: Re: Apple-II Kermit Bugs
>This may be related to the bug that strips out '&' on reception of files.
This IS the bug that strips out '&' on reception regardless of the setting
of text/binary and 7/8 bit data path. When it sees an '&' in the incoming
data stream, it just unconditionally strips it and turns on the 8th bit of
the next character.
Sam Lam
------------------------------
End of Info-Kermit Digest
*************************
-------