info-kermit@ucbvax.ARPA (03/21/85)
From: Frank da Cruz <SY.FDC@CU20B.ARPA>
Info-Kermit Digest Wed, 20 Mar 1985 Volume 2 : Number 13
Departments:
ANNOUNCEMENTS -
New Release of PDP-11 Kermit
Full-Featured MVS/TSO Kermit in PL/I from Rice University
MVS/TSO Kermit Has Series/1 Support
UNIX KERMIT -
Manual Page for C-Kermit
C-Kermit 4.2 comments
Bad Bug in C-Kermit?
C-Kermit on Pyramid?
Making C-Kermit Work on the SUN
C-Kermit on Four Phase 6300
C-Kermit on Callan Unistar 300
Want C-Kermit on PDP-11 with RT11
MISCELLANY -
Offer to Provide C-64 Kermit Diskettes
CP/M KERMIT and Start-of-Packet
Apple II Kermit for ProDOS?
Please help - Tandy 2000 Kermit
----------------------------------------------------------------------
DATE: WEDNESDAY, 20 MAR 1985
FROM: BRIAN AT UOFT02
TO: INFO-KERMIT AT CU20B
SUBJECT: New Release of PDP-11 Kermit
There is a new version of Kermit-11 available, version 2.26. The main
reason for this release is TSX+ support. The changes from v2.24 are:
1. 35% thruput improvement for RSTS/E from changes in packet reading.
2. Added ^E,^X and ^Z aborts for sending files.
3. Added SET CONSOLE 7/8 for stripping the high bit off of characters
in terminal emulation for P/OS to avoid odd characters.
4. More info in help file, particularily for binary file transfer.
5. Fix server replies (some replies had imbedded control characters.
6. Change default output record format to stream ascii for RSTS/E
7. Support is finished for TSX+. Sorry it took so long, but I do not
have a TSX+ system. Others had to do the work (Ned Rhodes and Tony
Movshon)
8. Changes % to ? in filenames for RSTS/E for GET and REMOTE DIR.
Needed since some Kermits mangle the filename if you say GET MS???.*
brian nelson
BRIAN@UOFT02.BITNET
------------------------------
Date: Tue 19 Mar 85 19:42:29-EST
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Full-Featured MVS/TSO Kermit in PL/I from Rice University
To: Info-Kermit@CU20B
There is an advanced version of Kermit for MVS/TSO written in PL/I (tested
in MVS/SP 1.1.1, MVS/SP 1.3, and MVS/XA) available from Rice University.
It is not included in the Columbia Kermit distribution because full source
is not provided, and the program cannot be built from the incomplete
source that is provided. While Rice is willing to furnish the load
module, this cannot be accommodated in our most common tape formats, like
ANSI Format D, nor on non-IBM file systems (such as the DEC-20 and
VAX/Unix systems from which Kermit is distributed). Therefore, those who
would like to obtain this version of Kermit should order it directly from:
Andrea Martin
P.O. Box 1892, Dept ICSA
Rice University
Houston, TX 77251
Phone 713-527-4005
If the full source becomes available, then this version of Kermit will be
included with the Columbia Kermit distribution.
------------------------------
Date: Tue 19 Mar 85 16:37:54-EST
From: Daphne Tzoar <Sy.Daphne@CU20B.ARPA>
Subject: MVS/TSO Kermit Has Series/1 Support
To: info-kermit@CU20B.ARPA
The assembler version of IBM MVS/TSO Kermit, which is an adaptation by the
University of Chicago of Columbia's original VM/CMS implementation, has
had support added by Charles Painter, University of Toronto Computing
Services, for the Series/1 front end running the Yale ASCII Terminal
Communications System V2.1. This allows PCs to transfer files using
Kermit even when they are connected to IBM MVS/TSO systems that believe
they are talking to 327x-style synchronous terminals, provided the
protocol emulation is done by the Yale IUP.
[Ed. - This replaces the Chicago TSO Kermit, since it is the same but with
the addition of Series/1 support. It's available in the files KER:TSO*.*
on CU20B and on BITNET via KERMSRV at host CUVMA. The documentation has
not been updated at all, and is somewhat dated. Thanks to Philip Murton
of U of T for submitting this new release. The forthcoming release of
VM/CMS Kermit will also have Series/1 support.]
------------------------------
Date: Mon, 18 Mar 85 16:09:43 CST
From: Stan Barber <neuro1!sob@rice.ARPA>
Subject: Manual Page for C-Kermit
To: sy.fdc@cu20b
Here is a possible manual page for Unix Kermit...
Stan
[Ed. - Stan's man page is available as KER:CKERMI.NR. We still don't have
the single source that generates both Scribe and Nroff input, but this
supplies the real man page that has been lacking up till now. Thanks, Stan!]
------------------------------
Date: Fri, 15 Mar 85 20:22:04 pst
From: Ken Poulton <hpl-opus!poulton%hplabs.csnet@csnet-relay.arpa>
To: Info-Kermit
Subject: C-Kermit 4.2 comments
I brought up C-Kermit 4.2 on my HP 9000 Series 500, at last.
First of all, wow! This is a great package. My complements, especially
on the command interface. It's really quite whizzy. In fact, I like it
more than I expected I would (being a Unix die-hard).
I also have a large number of comments on things that could go smoother.
Although the list is long, remember that you have really done the job
well, and I'm just working on perfection now.
Rather than wait for time to make this a lengthy letter, I'm going to send
you my notes on C-Kermit. Most of them are reasonably self-explanatory
(famous last words). I expect some of them are being addressed already,
and others I will be interested in doing.
send cmd
"send file [name]" is confusing syntax and precludes "send file file2..."
which is what the Unix user expects
"send file [-as name] [file [-as name]]..." more general
[Ed. - True, but the command package does not have a facility for parsing
alternates. I had to stop somewhere...]
wildcards
why not just use a shell to expand wildcards?
Then wildcards are complete and consistent with normal usage.
Surely speed is not an issue here.
[Ed. - No special reason. The current way is more efficient, but you're
right -- you miss the compatibility with the shell. Maybe somebody can
try writing zxpand() and znext() functions that do it with a shell. On
systems without shells or pipes, the present do-it-yourself model will
still have to be followed.]
! cmd
should use the shell defined by the env var SHELL, if defined
"!cmd" should work for Unix consistency (not just "! cmd")
"!" should get an interactive shell
[Ed. - The "!" command just does a system() of its argument. Rather than
write all the code to fork and pipe the desired shell, maybe users can
just live with typing "! csh xxx" or "! ksh yyy" if they want these
effects. A space is needed after "!" because "!" is a command keyword,
and whitespace must separate command fields. Removing this limitation
would probably make the command package a lot hairier. Maybe to alleviate
the confusion that this causes, the "!" should be renamed (back) to "shell".
Good point about this command invoking an interactive shell when no arg is
given -- just like it does now if you say "! sh" or "! csh".]
stat cmd
can't we get timing info to get effective baud rate?
[Ed. - If you have given a "set speed" command (or -b option), then this
would be reasonable. Otherwise, the program would not necessarily have a
reliable way of determining the baud rate. I really tried to avoid all
this kind of system-dependent hair (system clocks, baud rates, etc)
because it tends to make the program grow out of proportion to its
functionality.]
space cmd
should do a du for space used
[Ed. - Maybe; du can produce a lot of unwanted output if there are many
subdirectories. If you really want it, say "! du" instead of "space".]
command interface
Use the user's line kill char rather than hardwire to ^U.
Use the user's backspace char rather than hardwire to DEL/BS.
Respond to the user's interrupt char rather than hardwire to ^C.
Kermit not observing these is very annoying, since being able to
choose them is a nice (and often used) feature of Unix. This also
confuses novices.
[Ed. - But the last guy said you should use something OTHER than the
user's line and char kill characters; can't please everyone. Also,
again the point about system independence. C-Kermit 4.0 was a pretty
clean program. 4.2 already has tons of hair added to the system-dependent
portions, and every time we add a system-related feature like this, it's
got to be added for n systems, and soon the program will be an enormous
pile of verbiage, buried somewhere in the middle of which will be the Kermit
protocol.]
interrupts
behavior now is correct for interrupt in command-line mode
(error packet, close line, exit)
- you should not have to turn off interrupts in background -
the shell is supposed to do that for you
respond to the user's interrupt char rather than hardwire to ^C
interrupts should be caught when running interactively !!
(except in connect mode)
- should act as ^B when transfer running
- should *always* return to C-Kermit prompt after the first C-Kermit
prompt (setjump/longjump does this rather trivially)
- nearly every interactive program on Unix responds this way
^B doesn't work when send-init is failing
[Ed. - I'm not an expert on Unix interrupts. But I don't believe the program
is hardwired to trap ^C -- rather, it tries to catch SIGINT.]
prompt
default should be settable with cc -DPROMPT
does "set prompt" affect error messages - especially those sent
in error packets?
all error messages should use the prompt-string (maybe without the >)
to make errors easier to track down when running in the background
[Ed. - Agreed.]
line locking
locking upon startup for -l argument is more intuitive than waiting for
first connect command
should allow you to connect if you own the lock file
- maybe ask first in this case?
[Ed. - Line "locking" aficionados are enouraged to carry on this
discussion among themselves until the end of time. I already have a stack
of correspondence on the subject about an inch thick. It's impossible to
please everybody. In this case, you can't please ANYBODY.]
script
add ~d - delay for one second before sending next char
for talking to slow network controllers (w/o typeahead)
add ~x - XON (needed as the prompt char when talking to HP 3000 or IBM)
[Ed. - The ~d (and maybe also a ~w for wait-for-input timeout) escapes
are being added somewhere. Good idea about ~x.]
------------------------------
Date: Sun, 17 Mar 85 04:50:13 est
From: Ken Yap <ken@rochester.arpa>
To: sy.fdc@cu20b.arpa
Subject: Bad Bug in C-Kermit?
I have discovered that if C-Kermit is sending a file and it is interrupted
with ^C for example, that file gets deleted. Surely this should only
happen if the file is being received and "keep incomplete" is off?
Ken
[Ed. - You're right about what should happen, but on my 4.2 bsd system I
can't reproduce the problem. Has anyone else seen this happen?]
------------------------------
From: trwrb!trwspp!spp3!kurisaki@Berkeley (Lance R. Kurisaki)
Date: Mon, 18 Mar 85 09:36:24 pst
To: info-kermit@cu20b.ARPA
Subject: C-Kermit on Pyramid?
Am I the only one who has had problems getting C-kermit V4.2 running on the
Pyramid 90x (under 4.2 bsd)? It compiles fine, but doesn't do transfers.
Lance Kurisaki
{ucbvax|decvax}!trwrb!trwspp!kurisaki
[Ed. - See the next message. I thought this had been fixed, but apparently
it wasn't. Sorry!]
------------------------------
Date: Wed, 20 Mar 85 14:59:12 est
From: oconnor@dcn9.arpa (Mike O'Connor)
To: info-kermit@cu20b
Subject: Making C-Kermit Work on the SUN
I am in the process of installing 4.2 Kermit on my SUN system. There were no
problems in compilation or in using Kermit to login to our local VMS system.
File transfers, however, did not work. Kermit would send out the "send init"
packet and then time out waiting for a reply. The problem turned out to be
the definition of a local variable in the routine "ttinl". The variable "c"
is defined as an integer instead of a char.
Apparently when a byte is read and put into "c" the byte is placed in the
high order byte of the integer. But when "c" is assigned to "dest[x]" the low
order byte is used, filling "dest" with NULLs.
After making the change to "ckxunx.c" (which is where "ttinl" is located) I
used "make bsd" and am apparently up and running.
I've used this version of Kermit to move half a dozen ASCII files from the
SUN to the VMS system so far without any problems.
Mike O'Connor
[Ed. - Thanks, Mike! Presumably, this will also fix the Pyramid.]
------------------------------
Date: Tue, 19 Mar 85 13:45 MST
From: "Kevin W. Laurent" <KLaurent@DENVER.ARPA>
Subject: C-Kermit on Four Phase 6300
To: Frank da Cruz <SY.FDC@CU20B.ARPA>
I just wanted to drop you a short note to let you know that we got the
new C-Kermit running on a Motorola Four Phase 6300 under UNIX. I've
never seen a port go as smoothly as this one. We used `make sys3' and
only had two problems--3 doubly defined variables (ncmd, nprm, nrmt) in
ckcmd, and the problem in the makefile with ckprot mentioned in Digest
#13. Thanks for doing such a fine job, everyone!
[Ed. - Thanks to Herm Fischer for adding the Sys III/Sys V support, and
to the manufacturers for providing fairly consistent implementations.]
------------------------------
Date: Tue 19 Mar 85 17:49:40-EST
From: J. Eliot B. Moss <EBM@MIT-XX.ARPA>
Subject: C-Kermit on Callan Unistar 300
To: sy.fdc@CU20B
The second pre-release version seems to work fine on a Callan Unistar 300,
which uses the Unisoft System V port to the 68000. I have noticed nothing
strange (beyond the bugs already reported), and it compiled fine as received.
Thanks for the good work, everybody!
Eliot
[Ed. - I assume that one builds it with "make sys3", since it runs a System V
variety of Unix.]
------------------------------
From: Dave Yost <day@rand-unix>
Date: 19 Mar 85 16:36:30 PST (Tue)
To: info-kermit-request@cu20b
Subject: Want C-Kermit on PDP-11 with RT11
Is anyone doing this port? Thanks.
[Ed. - Somebody may try to produce a DECUS C version, nothing definite yet.]
------------------------------
Date: Sun, 17 Mar 85 20:48:14 est
From: Robert Scott Lenoil <lenoil@mit-eddie.ARPA>
To: sy.fdc@cu20b.ARPA
Subject: Offer to Provide C-64 Kermit Diskettes
I just posted the following message to USENET. Briefly, I offered to
provide copies of diskettes containing Kermit for the Commodore 64
for seven dollars, to defray my costs (diskette, mailer, postage,
wear and tear, and my time - which will be a lot, considering that I
only own a single disk drive, and therefore will have to swap disks
back and forth to perform a copy.)
To address your problem (how to obtain Kermit) I thought I'd let you know
that I am willing to provide Kermit diskettes to those people who are
reluctant or unable to go through the downloading procedure. For $7.00
(U.S. funds), I will provide a diskette containing the executable code and
documentation file. (Outside North America, please enclose an extra $1.00
to cover additional mailing expense.) Send requests and inquiries about
Commodore-64 Kermit disks to the address below.
Note that Kermit is written using the CROSS cross assembler which runs
only on DEC-10's and DEC-20's; hence enclosing the source code would not
be of much help. An additional problem is that the source code is larger
than an entire 1541 diskette, and therefore would be too much trouble for
me to copy.
Please note that I am not conducting a business. I am making this offer
to increase the availability of Kermit, which I hold to be a fine program.
I must stress that Kermit may be copied free of charge, so long as this
copying is not for "explicitly commercial purposes" (Taken from Columbia
University's policy document on Kermit distribution), and those of you who
wish to do so may download it free of charge from Columbia University
machine CU20B (on ARPANET), using BITSERVE (from BITNET), or via UUCP from
host OKSTATE.
If people have questions, they can contact me by sending mail to
lenoil@mit-eddie. Mit-eddie is on both the DoD internet and USENET, so
I'm fairly accessible. Also note that I will not be at my present U.S.
mail address for this summer, but my network mail will forward.
Therefore, starting in June, it would be a good idea to first send me
computer mail to obtain my current mailing address, rather than suffer the
problems of delay and lossage of forwarded U.S. mail.
Yours truly,
Robert Lenoil
229 Commonwealth Avenue
Boston, MA 02116 (USA)
------------------------------
Date: Fri 15 Mar 85 21:55:14-CST
From: Stuart Schmukler <STAFF.SAS@UChicago>
Subject: CP/M KERMIT and Start-of-Packet
To: sy.fdc@CU20B
I have finished modifing the CP/M 4.04 kermit to support SOP
(Start-Of-Packet) setting. The syntax I have chosen is:
SET START-OF-PACKET <cr>
enter character: !You type ^C, ^A etc.
The additional code adds about 1KB to the CP4KER.HEX file so that the
variable OVLADR is now 3600 for the CP4TYP.ASM file.
Now that I have a KERMIT that is working for our IBM, the users want to
be able to generate a BREAK. So I'll add BREAK code to the CP4TYP.ASM
file for the MORROW MICRO DECISION I (UDI in the TYP defines) and
others _IF_ some one sends me the code to do it. I have not been able
to findout from Morrow's doc what UART they use (the KERMIT code does
not help either).
SaS
PS: I have noticed that the RICE TSO KERMIT calls SOP 'marker'. Is there a
"standard" syntax?
[Ed. - "mark" is the term used for this field in the Kermit Protocol
Manual, chosen primarily for its shortness. "Start-of-Packet" is a better
phrase for users. Stuart's SOP changes for CP/M Kermit will be provided
to Charles Carvalho, the current CP/M Kermit keeper, when they arrive;
meanwhile, if anyone can help with the BREAK-sending code for the Morrow
or any other CP/M systems whose Kermits still can't send BREAK, please do.]
------------------------------
To: info-apple@BRL-TGR.ARPA
Subject: Apple II Kermit for ProDOS?
Date: 18 Mar 85 10:31:00 PST (Mon)
From: Stephen <willson@uci-icsc.ARPA>
Is there a ProDOS version of Kermit running about somewhere?
-- Stephen Willson
------------------------------
Date: 18 Mar 1985 23:32:31 EST
From: ABN.BOYD@USC-ISID.ARPA
Subject: Please help - Tandy 2000 Kermit
To: INFO-KERMIT-REQUEST@COLUMBIA-20.ARPA
Anyone feel charitable?
I am a novice Kermit user actually attempted user that owns a new
micro (TANDY 2000 w/256K,MASM,SOFTERM2000 comm package,BASIC,LOTUS, &
MULTIMATE) on the Arpanet via ABN.BOYD@usc-isid. I have had virtually no
success with either TA2000.ASM or MSGENER.ASM (modular) Kermit versions. I
downloaded these two versions from CU20B, assembled, linked and attempted
to download text and binary files with no success. TA2000.ASM would fail
but clearly attempt to execute via timeouts. Repeated tries with KERMIT-20
in server mode were not successful. MSGENERIC assembled and linked (I
double checked to insure all files were included) but it failed to
properly open or identify the com port each time. Not sure I understand
correct response to handle: prompt, but took program prompt/suggestion to
use "3" each time. No success.
Are there any Tandy 2000 users out there that could offer some
advice or assistance. I do have SOFTERM 2000 comm package that correctly
transfers micro to micro w/XMODEM protocol. I'll glady pay any phone
charges if someone has an executable (.EXE) version that will use MSDOS 2.0
capable kermit.
Joe Boyd
2109 Elvira St. Apt #902
Fayetteville, NC 28303
(919)-494-2203
------------------------------
End of Info-Kermit Digest
*************************
-------