SY.FDC@CU20B.CC.COLUMBIA.EDU (Frank da Cruz) (09/07/85)
Info-Kermit Digest Fri, 6 Sep 1985 Volume 3 : Number 16
Today's Topics:
Downloading .EXE Files Which Destroy Monitor
CR/LF Processing
How to Make Kermit Work over European Packet Switching Networks
Kermit on NEC 8001
Concurrent DOS Kermit
New BITNET KERMSRV Command Syntax
Kermit for Japanese Microcomputers and NTT Lisp Machine
Kermit for Sharp PC 1500 A?
----------------------------------------------------------------------
Date: Thu, 15 Aug 85 11:58:49 pdt
From: reynolds@AMES-NAS.ARPA (Don Reynolds)
Subject: Downloading .EXE Files Which Destroy Monitor
Welcome to a new user of Kermit on an IBM compatible! We like the frog
a lot here, but he sometimes croaks! This may not be your problem, but
the symptoms happened to me before. By mistake I used the host command:
kermit s filename.ext
which sends 7-bit ascii text files, but will not send 8-bit (image mode)
executable (.COM & .EXE) files, Wordstar format files, or other binary
files. The command for image mode is
kermit si filename.ext
If you try it without the "i" switch it really trashes the files, and gives
the results Brzozowski states a couple messages down from your message.
However, the file size still looks reasonable using the DOS DIR command.
Question for the net:
People have noted in this digest problems burning out the IBM monochrome
display trying to execute such a file. I wonder if something like Norton's
Utilities, U-File, or some other utility that looks at disk sectors or one
that looks at memory can easily look at the header to see if the file has
been trashed? Will DEBUG work? What do you look for? Note that I person-
ally have only academic interest since we have mostly color monitors here,
but someday I may have to download executables to a monochrome system.
Best,
Don
[Ed. - The Kermit protocol allows file transmission in both text and binary
mode. Text mode means that any necessary conversions are done on the file
-- by both the sender and the receiver -- to make the file useful and
readable on the target system. Binary mode means no conversions are done.
Unfortunately, most Kermit programs have to rely on the user to specify
whether a file is text or binary, because (a) the sending Kermit program
usually can't tell because most systems (e.g. MS-DOS) don't provide this
information in the file descriptor, and (b) the receiving Kermit certainly
doesn't know (unless the sender informs it using the almost universally
unimplemented Attribute packet). Now, it might be observed that text files
tend to contain bytes whose high-order bits are all off, whereas binary
files tend to have many bytes with this bit on. However, for the sending
Kermit program to determine whether a file is binary by this method would
require it to make a preliminary pass through the file (the WHOLE file if it
turns out to be text) which would be undesirable for many reasons (e.g.
timeouts when files are long). Many operating systems require executable
programs to be in a certain format or to be tagged in a certain way, and
will therefore not attempt to execute text files. But since not all OS's
guard themselves in this way, users should also take precautions. On a
case-by-case basis, heuristics can be added to some of the Kermit programs
but they will never be foolproof. For instance, PDP-11 Kermit allows the
use to specify a list of filetypes to determine the mode of the file -- but
how can it know whether a .COM file is a DCL command file (text) or, say, a
CP/M-80 program image (binary)?]
------------------------------
Date: Fri, 23 Aug 85 15:06:18 BST
From: Chris-on-Fridays <cjk@ucl-cs.arpa>
Subject: CR/LF Processing.
Info:
Is there an accepted policy about when Kermit should and should not do
CR/LF (logical-end-of-record) processing?
Obviously it is wanted in text-files and not in binaries. By default
any 7-bit file is probably text, and any file sent as 8-bit image is
probably not; but what assumption do you make if 8th-bit-prefixing is
switched on?
If the answer to the previous is "binary", shouldn't Kermits in general
make it rather difficult to accidentally switch on 8th-bit-prefixing? And
if the answer to that one is "yes", then is it wise for a Kermit server, or
in fact any mainframe Kermit, to regularly offer 8th-bit-prefixing in its
I-exchange? (This is suggested in the protocol manual.)
Those of us who live on unix (with its LF as record-terminator) are
keenly aware of the problems of files which come in with CR instead.
Unsophisticated users tend to get absoultely floored; and it's they who are
most likely to get into trouble if the two Kermits they are using do not,
between them, pick sensible defaults.
As an extension, what about the filing-systems which expect to find
carriage-control-characters either at the start of each line (as per
Fortran), or even at the end (older IBM formats)?
Chris Kennington (cjk@ucl-cs)
[Ed. - 8th-bit prefixing is totally unrelated to text vs binary mode. The
prefixing mechanism is just a trick to squeeze 8-bit bytes through a 7-bit
link. Most Kermit programs do (and should) enable 8th-bit prefixing
automatically if parity is not none (i.e. is even, odd, mark, or space); it
is a transmission technique akin to TELNET IAC doubling. All Kermit
programs I know about run in text mode by default, and 8th bit prefixing is
off by default except in systems (like IBM mainframes, or Prime computers)
that always use parity. In Unix, text mode means LF/CRLF conversion is
done, and it works Unix-to-anything, anything-to-Unix, so long as the
"anything" Kermit is also in text mode. But see the discussion after the
previous message about the perils of automatic mode selection. Systems that
have carriage control or other "structured text" formats bear the
responsibility for converting them to canonical (CRLF) format before
transmission; VAX/VMS Kermit (the Stevens Bliss version) does this.]
------------------------------
Date: Fri, 30 Aug 85 10:12 MET
From: Peter Bendall, DECUS VAX SIG Europe
<decus%v750.ira%germany.csnet@csnet-relay.arpa>
Subject: How to Make Kermit Work over European Packet Switching Networks
Since I started distributing 6800 and 6809 FLEX Kermits I have received MANY
calls to say that Kermit is not able to work over the European packet
switching networks.
The following "work around" does however work for the German DATEX-P system
and will probably work for other systems also:
For Kermit-32 on VAX/VMS systems:
Call the VAX using CONNECT and start Kermit-32, and issue the commands:
SET RECEIVE START_OF_PACKET 7
SET SEND START_OF_PACKET 7
and then start the server if required. Then escape to your own Kermit and
issue the equivalent commands:
SET REC SOP=7
SET SEN SOP=7
(or whatever they look like)
and then it works.
[Ed. - Apparently DATEX-P does not pass through Control-A's, which are
used by Kermit as the start-of-packet character.]
In the case of the VAX systems, we have checked that the control-As are
still in the packet when they reach our machine but we have found no
simple way to get them into the packets... If anyone knows the proper
workaround please let me know!
------------------------------
Date: Wed 28 Aug 85 11:17:59-PDT
From: Ronald Blanford <CONTEXT@WASHINGTON.ARPA>
Subject: Kermit on NEC 8001
Some time ago there was a complaint that the Generic version of Kermit
only partially worked on the NEC 8001. I had reason to need it recently
and found the following fix which works quite well.
Generic Kermit uses the iobyte to switch to the BAT console (which takes
its input from the RDR device) so that it can check the serial port input
status using the Console Status BIOS call. The BIOS therefore must check
the iobyte twice in this situation, once to determine that the BAT console
is in use, then again to decide which physical device RDR is set to. The
NEC 8001 does this for the Console Input routine, but not for Console Status.
The default Console Status routine always returns No Input Available, so
that Kermit never tries to receive a character even though it can send them
just fine.
The solution is to patch the dispatch table for the Console Status routine
so that it proceeds to the serial status routine instead of the default.
It might be hard to determine the address of the status routine if RDR is
set to the PTR, UR1, or UR2 device, but for the TTY device the address is
just two entries earlier in the table to be patched. Fortunately Kermit
uses the TTY device by default.
On the NEC 8001, the serial driver is loaded dynamically, and the address
of the status routine varies depending on which driver is used. Therefore
this patch must be made each time the system is cold-booted, after installing
the serial device driver but before running Kermit. It's easiest to make
the patch into a simple program using DDT as follows:
A>DDT
DDT VERS 2.2
-A100
0100 LHLD 1 ; get the address of the BIOS jump table
0103 INX H ; step forward to the Console Status entry
0104 INX H
0105 INX H
0106 INX H
0107 MOV A,M ; get the address of the Console Status dispatcher
0108 INX H
0109 MOV H,M
010A MOV L,A
010B INX H ; step past the dispatcher's initial JMP instruction
010C INX H
010D INX H
010E MOV C,M ; pick up the address for the TTY Status routine
010F INX H
0110 MOV B,M
0111 INX H
0112 INX H ; step forward to the BAT entry
0113 INX H
0114 MOV M,C ; save the TTY address in the BAT entry
0115 INX H
0116 MOV M,B
0117 RET ; return to CP/M
0118 .
-^C ; Now get out of DDT
A>SAVE 1 KPATCH.COM ; and save the patch as a COM file
With this patch program available, perform the following sequence of
actions after cold boot to bring up Kermit:
A>INSTALL8 IRS232A TTY: [,,,,O] ; install the driver as device TTY
; set up for Object files. The driver
; name may vary.
A>KPATCH ; Patch the BAT status routine
A>KERMIT ; Start Kermit
With the interrupt-driven serial driver in place, this has worked perfectly
for me at up to 9600 baud. Good luck.
-- Ron
[Ed. - Thanks, Ron! I've stored this message in the Kermit distribution as
CP4NEC.HLP.]
------------------------------
Date: Wed, 4 Sep 85 03:14 EDT
From: "John C. Klensin" <Klensin@MIT-MULTICS.ARPA>
Subject: Concurrent DOS Kermit
PC-DOS Kermit seems to work fine under Concurrent DOS, with a few
qualifications, as you expect. First, most of the 'internal' commands
that require PC-DOS interactions don't work, e.g., LOCAL DIR (wildcard
SENDs work fine). This is, of course, less of a problem under
Concurrent than it would be under PCDOS, since, with Concurrent, you can
switch processes and do anything of these things (or even keep the
current directory or whatever in a handy window). Second, you must use
SUSPEND=OFF if you expect to do transfers in background. Third,
experience with the PC indicates that you may want to arrange a bit more
waiting time and/or retry count maximum with your mainframe kermit if
that is possible -- things sometimes get a little slow if there is a lot
of other stuff going on in the machine, especially if kermit is a
background, rather than foreground, process. I would suspect that this
would be less of a problem on the AT, but haven't tried.
I keep fussing with a CDOS-specific version of Kermit, based on the
CP/M86 version when I manage to be around for more than a couple of
weeks (not frequent in the last year). It is, of necessity, heavily
dependent on the operating system, and is quite slow when it works. But
this message is coming to you from a Concurrent DOS 4.1 system, using
PC-DOS kermit, for whatever that is worth. If someone else would like
to take that on, I would be happy to transfer everything I have done,
and try to transfer everything I know/have found out, otherwise I will
keep fussing as I have time.
The combination of MSDOS kermit and Concurrent also worked fine under
version 3.2 of the latter; versions before 3.2 are hopeless, since they
don't support PCDOS mode.
------------------------------
Date: Fri 16 Aug 85 11:03:59-EDT
From: Daphne Tzoar <Sy.Daphne@CU20B.ARPA>
Subject: New BITNET KERMSRV Command Syntax
The syntax of Kermsrv commands has changed slightly so the file
AANETW.HLP should be modified. Here is the command format:
?
HELP
SEND { DIR | fn ft | ?}
PUNCH { DIR | fn ft | ?}
Send returns information in netdata format. Punch uses punch format.
If PUNCH is used, files with LRECL 80 or under will be punched Class
A. The others will be disk dumped Class N. The DIR (directory
command) has been replaced by SEND DIR or PUNCH DIR. File names may
contain wildcards. Requests to Kermsrv can be either in the form of
messages or reader files, where the file contains a single line with a
valid Kermsrv command.
/daphne
------------------------------
From: ihnp4!kddlab!nttmecl!nttmecl!NTT-20!MURAKAMI@seismo.CSS.GOV
Date: 27 Aug 1985 2023
Subject: Kermit for Japanese Microcomputers and NTT Lisp Machine
Kermit for Japanese micro computers is supported. Kermit for the
following computers is available:
(1) NEC PC8800 on CP/M-80
(2) NEC PC9800 on CP/M-86
(3) FUJITSU FM-8 on CP/M-80
(4) FUJITSU FM-11 on MS-DOS
(5) IBM5550 on MS-DOS
In addition to these computers, Kermit for NTT Lisp Machine ELIS
was written by its language TAO. TAO is a dialect of Lisp which
unifies an object-oriented programming paradigm and a logic
programming paradigm with a procedural programming paradigm.
NTT Lisp Machine (interpreter) runs 1.3 times faster than SYMBOLICS
LISP MACHINE (compiler).
If you are interested in these Kermits, please send me mail to
hplabs!kddlab!nttmecl!murakami@Berkeley
Is it useful for you to get Kermit sources for Japanese computers?
I hesitate to send these sources because of the following reasons.
(1) These Kermits will not be widely used in your country.
(2) Kermit on CP/M-80 is based on the old Kermit version.
We are translating an important part of the Kermit manuals into Japanese.
I would appreciate if you'd allow me to distribute these manuals in Japan.
Thank you for your attention
[Ed. - Does everyone agree that the programs listed above are not of general
interest outside of Japan? If not, I'll try to get them into the Kermit
distribution.]
------------------------------
DATE: 26 Aug 85 1735 WEZ
FROM: U02F%CBEBDA3T.BITNET@WISCVM.ARPA (Franklin A. Davis)
SUBJECT: Kermit for Sharp PC 1500 A?
Anyone know of a Kermit for the Sharp PC 1500 A? A colleague needs it, and
unfortunately isn't even sure if it uses CP/M, but our guess is that it may
be a close clone. Please answer directly.
Thanks -- Franklin <U02F@CBEBDA3T.BITNET>
Institute for Informatics and Applied Mathematics
University of Bern
Laenggassstrasse 51
CH-3012 Bern
Switzerland
------------------------------
End of Info-Kermit Digest
*************************
-------