SY.CHRISTINE@CU20B.COLUMBIA.EDU.UUCP (12/19/86)
Info-Kermit Digest Fri, 19 Dec 1986 Volume 5 : Number 19
Today's Topics:
New Kermit Program for IBM 370 Mainframes with MVS/TSO
Kermit-MPX version 2.3
Misuse of Okstate services
C-Kermit and Xenix
C-Kermit on Microport Unix
Uploading Macintosh Binhexes with Kermit
Bug in Apollo Pascal Kermit
Prime kermit connect
Kermit and X.25
Problem with HP9845 Kermit
HCP and HC6 Versions of Kermit
Need Fast De-BOOing Program for the Amiga
Data General MV2000
Kermit 3.1 - An interesting speed problem
Symbolics V7.0 Kermit
----------------------------------------------------------------------
Date: Thu 18 Dec 86 15:31:12-EST
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: New Kermit Program for IBM 370 Mainframes with MVS/TSO
Keywords: MVS/TSO Kermit
The new IBM 370-series mainframe MVS/TSO Kermit from the US National
Institutes of Health (NIH), announced in the previous Info-Kermit digest, is
now available in the Kermit distribution areas under the prefix TSN. There
are 21 files, comprising a total of about 3 megabytes, including three
documentation files and a TSO help file.
The program is written in "ALP", which is a preprocessor for 370 assembly
language developed at NIH. The ALP preprocessor, also supplied, is written
in PL/I. For those who do not have PL/I or do not wish to bother with the
source programs, a hexidecimal-encoded object file is provided, along with
an assembler program to decode it into a binary object file; this can be
linked with a tailorable module (written in straight assembler) in which
site dependencies, such as the ASCII/EBCDIC translations, are specified.
Before deciding to transfer all 3 MB from Columbia over a network, first get
the file TSNKER.TXT, which explains which files are which, and then only get
the ones you really need.
Thanks to Roger Fajman at NIH (RAF@NIHCU.BITNET) for submitting this program
to us. Roger participated in the design with Dale Wright, who then did the
programming. The new program has many advanced features over previous TSO
Kermit versions, including server mode, binary file transfer, file
interruption, 8th-bit prefixing, run-length encoding, alternate block check
types, and support for both 3705-style line mode and Series/1-style full
screen emulation. It is hoped that this new version will render the old
University of Chicago (linemode only, circa July 1984) and University of
Toronto versions (Series/1 only, March 85) obsolete. Reactions from TSO
sites will be appreciated, in the interest of keeping redundant Kermit
versions at a minimum. Reactions from users of the Pascal/VS version from
the University of Bern (linemode only, Sept 86) will also be appreciated.
For the present, the Chicago, Toronto, and Bern versions remain available in
the Kermit distribution under the prefixes TSO, TSO, and TS2, respectively.
For the future, there may still be another TSO Kermit program on the horizon, a
result of a cooperative effort among IBM mainframe Kermit sites to develop a
Kermit program that is portable among all IBM 370 mainframe operating systems
(no estimate as to when this will be ready, but IBM mainframe system
programmers who are interested in developments in this area may send mail
to IBM-KERMIT@CU20B or IBM-KERMIT@CUVMA).
------------------------------
Date: Sun 7 Dec 86 22:40:44-MST
From: Mike Niswonger <CNISWONGER@SIMTEL20.ARPA>
Subject: Kermit-MPX version 2.3
Keywords: Gould, SEL, MPX
The latest version of Kermit-MPX (GM2) for Gould machines is now
available for you to FTP from my directory at Simtel20. All files are found
in directory PD:<MISC.GOULD-KERMIT>GM2KERM.*. This release 2.3 of
Kermit-MPX, which is also being submitted to the Gould User's group library.
-- Mike Niswonger
[Ed. - Thanks Mike! The files are also available through KERMSRV at CUVMA
and on CU20B using FTP (user ANONYMOUS), any password. These files have
replaced the old KER:GM2*.* and the old files are now in KO:GM2*.*]
------------------------------
Date: Mon, 08 Dec 86 18:50:27 -0600
From: Mark Vasoll <vasoll%a.cs.okstate.edu@RELAY.CS.NET>
Subject: Misuse of Okstate services
Keywords: Okstate, Oklahoma State
Fellow Kermiters,
It saddens me to inform you all that various people have started to
abuse the UUCP login "uucpker" on Okstate by attempting to use us as a
jumping off point for mail. While we enjoy providing the home for Kermit
access via UUCP, we have no desire to become a major mail relay point for
various random systems. To this end, I have had to place a restriction on
our UUCP to not accept the "rmail" command from any system using the uucpker
account. This will, unfortunately, make it more difficult for people to
report problems to okstate!uucp-support, but there is very little I can do
about it. Please use the following mail paths when reporting problems with
the Kermit distribution (no phone calls please).
Internet: uucp-support@a.cs.okstate.edu
or: uucp-support%a.cs.okstate.edu@csnet-relay.arpa
UUCP : {cbatt, cbosgd, ihnp4, pesnta, rutgers, seismo}!okstate!uucp-support
Mark Vasoll
Computing and Information Sciences Internet: vasoll@a.cs.okstate.edu
Oklahoma State University UUCP: {cbatt, cbosgd, ihnp4, pesnta,
Stillwater, Oklahoma rutgers, seismo}!okstate!vasoll
------------------------------
Date: Tue, 9 Dec 86 08:05:48 EST
From: Marshall_DeBerry@um.cc.umich.edu
Subject: C-Kermit and Xenix
Keywords: Xenix, C-Kermit
RE: Info-Kermit Digest V5 #18
I recently put the latest C Kermit (4D(061)) up on a Tandy 16/6000 running
Xenix 3.1 with no problems. I used the make sys5 command to compile; only
changes needed were to include /sys/typedefs.h for the void identifier found
in one file. Everything seems to be working ok so far.
------------------------------
Date: Mon, 15 Dec 86 10:17:15 EST
From: es!Dan_Senie%anvil.UUCP@harvard.HARVARD.EDU
Subject: C-Kermit on Microport Unix
Keywords: C-Kermit
I just compiled 4D(061) using 'make sys3'. It work right from the start.
Many people have sent in messages about trouble getting Kermit to run on
XENIX. I had used XENIX for a time, but found the include files and compiler
contained many errors and incompatibilities with real system V Unix.
Microport Unix is a full System V for the IBM-AT. Unlike XENIX, it is based
on the current Sys V sources and therefore Kermit was easy to get running.
Those of you using XENIX may want to investigate this new package.
Dan Senie
PS. I am not connected in any way with Microport Systems, ATT, etc.
UUCP: ...!harvard!anvil!es!Dan_Senie (case is important!)
ARPA: anvil!es!Dan_Senie@harvard.harvard.edu
------------------------------
Date: Sun, 7 Dec 86 11:29:35 pst
From: gould9!joel@nosc.ARPA (Joel West @ Western Software Technology)
Subject: Uploading Macintosh Binhexes with Kermit
Keywords: UNIX, MacKermit, hqx
I've been meaning to send this along for a while, but I wasn't sure anyone
was interested. A query on INFO-MAC prompted this posting.
It is a UNIX csh script (MACKERM) that I use to upload binhexes using
kermit. If for a file foo.hqx, it first sends the header (before the
binhex) as 'About foo', then sends foo.hqx. I use the header to later note
the origin on the final unhexed file.
To make this work, you need to take the first file (usually a short About...
file) manually, selecting the target directory. Then place your MAC in
server mode, since each 'kermit' command at the UNIX side is a separate
session, and the Mac would otherwise quit file transfer mode.
Oh yeah, it also works on ordinary files, preserves actual names ('FooBar'
instead of 'FOOBAR') and NEVER transfers a directory. So it's real useful
to type
mackerm *
place the Mac in server mode, and walk away.
Joel West
joel%gould9.UUCP@NOSC.MIL ihnp4!gould9!joel
==File =====
#!/bin/csh
# by Joel West, ihnp4!gould9!joel, 11/14/86
# Script to send binhexes and other files
# Also preserves exact upper/lower case name
set noglob
foreach f ($*)
if (-d $f) continue
set typ=$f:e
switch ($typ)
case hqx:
case hex:
set r=$f:r
set T1=/tmp/kermdat_$$
set T2=/tmp/kermhqx_$$
rm -f $T1 $T2
cat $f | cutat '(This' $T1 $T2
kermit -s $T1 -a "About $r"
kermit -s $T2 -a $f
rm -f $T1 $T2
breaksw
default:
kermit -s $f -a $f
endsw
end
== EOF ==
[Ed. - Thanks. This hint has been added to the Macintosh Kermit .BWR
file, CKMKER.BWR.]
------------------------------
Date: Fri 14 Nov 86 10:34:23-PST
From: Ted Shapin <BEC.SHAPIN@USC-ECL.ARPA>
Subject: Bug in Apollo Pascal Kermit
Keywords: Apollo Kermit
We found that the Pascal kermit for the Apollo inserts extra line feeds
every 256 characters if there is no line feed carriage return in the file.
We traced it to the I/O in the Pascal program which can only read 256 byte
lines.
[Ed. - Thanks for the information. This message is now in the file
KER:APOLLO.BWR.]
------------------------------
Date: Wed 10 Dec 86 10:45:54-PST
From: Bob Larson <BLARSON@USC-ECLB.ARPA>
Subject: Prime kermit connect
Keywords: Prime Kermit
I have a partially working one, based on the old version of prime kermit.
I'm not even sure if I have a complete set of sources for it on tape any
more. Known bugs include dropping characters in connect mode, problems with
some of the message strings (incorect use of ioa$), and not supporting 2400
baud. (Writen before prime standardized the "optional" speeds at 2400 and
4800 baud for autobaud.)
I have been considering making improvements to the current prime kermit, with
support for amlc lines among them.
------------------------------
Date: WED, 10 DEC 86 17:17:13 BST
From: CJK @ UK.AC.SALFORD.R-D
Subject: Kermit and X.25
Keywords: C-Kermit, X.25
Points from infodigest 5/17. First Steve Walton & Telenet:
We over this side of the pond are quite used to using Kermit over
X.25 networks (posing as an X.29 terminal). It works fine, at least in
the micro-mainframe mode, with call originated by the micro. Efficiency
should not be affected much until the ratio:
time-through-network / front-end-delay
reaches about 5. The crucial thing is to set up the X.3 parameters in
the PAD so that the whole Kermit packet gets into a single X.25 packet;
it is bound to be shorter than the 128-byte maximum on X.25.
In general you have to use a transparent-type mode to let the SOH get
through, but there is no need at all to forward on every character (which
simply fills up the X.25 window with single-character X.25 packets).
Provided the EoL is a forwarding character, which it will be if it is CR,
all works fine. What you actually do depends on the user interface
provided by your PAD. This is in fact all covered in your book.
Of course, network congestion can slow things down. Our X.25s, the
public PSS and private JANET, have maximum time-through-networks of about
0.1 sec in all normal circumstances, so no problem. But I heard last week
in a different context that the congestion on ACCUNET was so severe that
holding transatlantic calls open was very difficult. If Telenet is in
the same state, then you've got problems. But blame the sizing of the
network, not X.25 or Kermit.
Does CKermit really limit you to 65% of line-speed? I tested
homegrown Kermits here (at up to about 30Kbaud) and found that, with
data-compression on, I always got better than 100% of linespeed. If
CKermit is really that slow, is it losing time somewhere that it
needn't?
Incidentally, switching over to Kuryan Thomas' problems with his
autodialler: Many UARTs will not receive if DCD is not high (it's a
protection against line-noise). If you have one of these, and an
autodialler which does not hold up DCD while it is trying to talk
to you, then you have no option but to strap DCD to one of the other
pins, e.g. DSR.
Chris Kennington.
------------------------------
Date: 11-DEC-1986 09:47:23
From: DGM1@UK.AC.YORK.VAXA
Subject: Problem with HP9845 Kermit
Keywords: HP Kermit
Cross-Ref: Hewlett-Packard Kermit
It's not a bug: it's a problem regarding some assumptions regarding the
machine configuration, which I should have spelt out when I sent it in.
We have explained/apologised to one or two people who contacted us directly,
and if in a fit of absent mindedness I had not deleted a note I had from
Chris regarding the configuration assumptions, I would forward it to you for
a BWR file. As I mentioned when I sent it in, it does not pretend to be a
full kermit, more a minmalist bulk data transfer utility conforming to the
kermit protocol.
It is probably possible to bypass the need for specific ROMs and so on by
the use of inline assembler, however, if the ROMs are available, it is
better to use the facilities provided by the HP virtual communication
device.
I'll get the precise details from Chris as soon as possible for you for
inclusion in a BWR
Sorry about the hassle,
Doug
------------------------------
Date: 11 Dec 86 13:42:00 EST
From: John Stewart <WAPJAS@CARLETON.BITNET>
Subject: HCP and HC6 Versions of Kermit
Keywords: Honeywell Kermit
I was looking at the versions file and noticed that two versions of
Kermit are listed for our machine, HCP and HC6.
HCP is a Pascal implementation of Kermit that was ported to the Honeywell
Cp-6 operating system by Bucknell University. It is a very minimal
implementation (it doesn't even do repeat counts, let alone advanced
features like server mode).
HC6 is much more complete then HCP, and both the original developer and
myself are continuing to enhance it.
I suggest that distribution of the HCP version of kermit be discontinued.
Regards.. jas
[Ed. - Thanks, this seems to be the concensus of opinion; the HCP version
was indeed retired to Tape C.]
------------------------------
Date: Wed, 10 Dec 86 10:33 EST
From: "John G. Ata" <Ata@RADC-MULTICS.ARPA>
Subject: Need Fast De-BOOing Program for the Amiga
Keywords: Amiga Kermit
Can somebody out there who has a C compiler on the Amiga please compile
CKIBOO.C and then make a BOO file out of it and send it in to Kermit
Distribution as, say, CKIBOO.BOO, so that those of us without a C compiler
only have to run the Basic de-booer once, on CKIBOO.BOO, and then can
subsequently use the compiled de-booer which should be much faster. It
takes about an hour to de-boo Amiga Kermit with the Basic de-booer.
John G. Ata
------------------------------
Date: Tue, 16 Dec 86 16:25:14 est
From: munnari!latcs1.oz!philip@seismo.CSS.GOV (Philip Lee)
Subject: Data General MV2000
Keywords: Data General
Has anyone sucessfully ported the unix kermit to Data General MV2000 running
DG/UX ver. 3.00? We've tried recompiling ver 4D on it. It compiled without
complaining, but gave link error. However it sort of work. We could do ascii
file transfer, but any compressed file or any of those using all 8 bits would
fail. The DG kermit would accept set file type binary quite happily and
indicate the same, but on file transfer it would just time out and fail.
In generating the DG/UX kermit we used the following:
make wermit \
"CFLAGS = -D_file=_fd -DUXIII -DDEBUG -DVER2 -DTLOG -O4" "LNKFLAGS ="
Could this be also related to the problem of 8 bit transfers between FIDOnet
Kermit and the Pyramid?
[Ed. - The FIDO question has still not been totally solved, mostly because
of lack of time, but it might help you to know there's a version of Kermit
specifically tailored for DG MV/UX (is that the same thing?), based on an
old release of Unix Kermit, available in the Kermit distribution under the
prefix DGM. There's also a C-Kermit implementation for AOS/VS on the way.]
------------------------------
Date: Sun, 14 Dec 86 14:56:29 +0200
From: Sam Gamoran <VSSAM@WEIZMANN>
Subject: Kermit 3.1 - An interesting speed problem
Keywords: CMS Kermit, PROCOMM
We just installed CMS Kermit 3.1 - appears to solve our problems with 2.1
particularly the program hanging and binary transfers.
We use CMS Kermit through a 7171 against PCs running either MS-DOS Kermit
2.28 or Procomm 2.3 with the Kermit file transfer option. Works great with
MS-DOS Kermit 2.28 but file transfer crawls with Procomm 2.3.
Every packet sent by CMS-KERMIT 3.1 ends with an X-ON character. The old
CMS-KERMIT 2.1 did not do this. It appears that this X-ON character causes
Procomm to delay a second or so before sending the next packet. We saw on a
line monitor packets going out from PC to mainframe and an instantaneous
response followed by a delay. With the old CMS-KERMIT, where the main
difference between packets is the absence of the final X-ON character no
delay occured and transfer throughput was 400% faster!
Do you know of anyone having experience with PC->Mainframe file transfer
using PROCOMM who has encountered similar problems? I am also sending this
query to the procomm folks. Thanks,
Sam Gamoran
------------------------------
Date: Tue, 16 Dec 86 15:39 CST
From: "David S. Cargo" <DSCargo@HI-MULTICS.ARPA>
Subject: Symbolics V7.0 Kermit
Keywords: Symbolics Kermit
Symbolics is upgrading their system software to version 7.0. The old
Symbolics Kermit no longer works with the new system revision. Has anybody
upgraded the existing version to run on the new system? I'm trying to avoid
some wheel reinvention.
------------------------------
End of Info-Kermit Digest
*************************
-------