SY.FDC@CU20B.COLUMBIA.EDU (Frank da Cruz) (09/25/85)
Info-Kermit Digest Tue, 24 Sep 1985 Volume 3 : Number 21
Departments:
ANNOUNCEMENTS -
Kermit for QNX
Kermit for Intel System 86/380 with iRMX-86
Kermit for HP-1000 A-Series with RTE-A
Kermit for Zilog System 8000 Zeus (Sys V)
Kermit for the HP Integral PC
Update of Fujitsu Micro-16s CP/M-86 Kermit
UNIX KERMIT -
Kermit for UUCP Mail
Changes to C-Kermit 4C(057)
Bug Fix for C-Kermit User Interface
C-Kermit on Masscomp Systems?
MS-DOS KERMIT -
Problem with Sanyo 555 Kermit
MsKermit Linking Idea
----------------------------------------------------------------------
Date: Mon, 23 Sep 85 13:14:33 edt
From: Frank da Cruz <fdc@cucca>
Subject: Kermit for QNX
A version of Kermit for the Quantum Software QNX operating system has been
contributed by Anthony J. Starks, Merrell Dow Research Institute,
Indianapolis IN; although he doesn't mention what system it's supposed to
run on in his transmittal letter, I believe it's for 8088-based systems like
the IBM XT or AT and/or the DEC Rainbow.
The program based on the "old" Unix Kermit, but the QNX-specific support is
sufficiently different from any other Unix code I've seen that I've
installed it as a separate set of files, rather than attempting to merge it
with C-Kermit. The files are in KER:QNX*.* on CU20B, available via
anonymous FTP.
------------------------------
Date: 23 Sep 85 13:44:04-EDT
From: Frank da Cruz
Subject: Kermit for Intel System 86/380 with iRMX-86
This is to announce Kermit for the Intel System 86/380 running iRMX-86,
written by Albert J. Goodman, Grinnell College, Grinnell, Iowa. The program
is written in PL/M-86. The source files (including built-in help) are
concatenated together into the file KER:I86KER.PLM, and a short external
help file is included as KER:I86KER.HLP, available from CU20B via anonymous
FTP.
------------------------------
Date: Mon 23 Sep 85 13:46:33-EDT
From: Frank da Cruz <SY.FDC@CU20B>
Subject: Kermit for HP-1000 A-Series with RTE-A
Announcing Kermit for the HP-1000 A-Series with RTE-A, written in
Pascal/1000, contributed by Tor Lillqvist, Technical Research Centre of
Finland. Here is his cover letter:
This is a Kermit implementation for the HP1000 A-series machines running the
RTE-A operating system (HPAKermit). It will probably also work on the older
E-series machines running RTE-6/VM.
The file HPAKERMIT.SRC is a large text file into which is merged all the
source files needed to build HPAKermit (just to keep the number of files
down).
HPAKermit is written in the Pascal/1000 dialect. (A note to Pascal purists:
this has many "useful extensions" which makes it more suitable to "Real
Programming", but of course removes any chance of an easy port to some other
Pascal system.) I would certainly prefer 'C', but the 'C' compiler for
HP1000 seems rather oldfashioned, and in any case, we don't have it.
HPAKermit must be compiled with the Pascal/1000 compiler of revision 2410
(or later).
HPAKermit is based on the (old) Unix Kermit, and has only basic features
(Send, Receive and Get). Connect mode is missing, as it is very hard, maybe
impossible, to implement successfully on a HP1000. Server mode is also
missing, but that is only a "Not-Yet-Implemented" issue.
HPAKermit has been tested extensively with MSDOS-Kermit version 2.27 and
HP3000 Kermit. Using 9600 bps and an IBM PC/XT a transfer rate of 470
chars/s is achieved.
Best regards,
Tor Lillqvist
Technical Research Centre of Finland
Lehtisaarentie 2 A,
SF-00340 HELSINKI, FINLAND
Phone: +358 0 4566132
Telex: 122972 vttha sf
I have no net address, but you can reach me through a friend of mine:
mcvax!hut!jtv
[Ed. - The files are in K2:HPA*.*, available via anonymous FTP.]
------------------------------
Date: Mon, 23 Sep 85 12:43:29 edt
From: Frank da Cruz <fdc@cucca>
Subject: Kermit for Zilog System 8000 Zeus (Sys V)
I received a tape from Mark E. Sunderlin, Internal Revenue Service,
containing C-Kermit 4C(057) revised to include support for the Zilog System
8000 with Zeus 3.20 and later. This will appear in the next release.
Meanwhile, if anyone can't wait, the trick seems to be to build it for
System III/V ("make sys3") in the normal way, but first change all
occurrences of "setjmp" to "setret" and "longjmp" to "longret". This might
be accomplished in the makefile without changing the program source by doing
something like...
zilog:
make wermit "CFLAGS = -DUXIII -Dsetjmp=setret -Dlongjmp=longret -i" \
"LNKFLAGS = -i -w"
(and also including -DDEBUG, -DTLOG, -O if desired); no one has tested doing
it this way, but the same trick works for some of the other systems.
------------------------------
Date: Mon, 23 Sep 85 12:43:29 edt
From: Frank da Cruz <fdc@cucca>
Subject: Kermit for the HP Integral PC
I received a tape from Robert Raymond of TransEra Corp, Provo Utah, with a
version of Kermit for HP Integral PC. It's based on the old Unix Kermit,
but a cursory inspection of the code suggests that he's simply added System
V support to it. Can anyone verify that the present C-Kermit runs on the HP
Integral via "make sys3"? If so, I'll simply include that system on the
list of those supported by C-Kermit; if not, I'll be glad to make Robert's
code available to anyone with an HP Integral who would like to adapt it to
the current C-Kermit.
------------------------------
Date: Mon, 23 Sep 85 12:43:29 edt
From: Frank da Cruz <fdc@cucca>
Subject: Update of Fujitsu Micro-16s CP/M-86 Kermit
This fixes an error in baud rate setting/selection. Submitted by the
original contributor, Chris Barker, WRIST Inc, Long Island City, NY. The
source file is in KER:C86XFJ.A86. Would anyone on the net would care to
build and test the result and supply a hex (.H86) file?
------------------------------
Date: Sat 21 Sep 85 14:35:52-EDT
From: Bdale Garbee <AG0B@TE.CC.CMU.EDU>
Subject: Kermit for UUCP Mail
I haven't finished doing it yet, but I am one of the people using/planning
to user Kermit on a UUCP host to move mail to other places.
The system in question is an Intel 86/330 running Xenix V2.2N, currently
working on getting implementation-specific bugs out of the latest C-Kermit.
More details when I'm done.
The idea is very simple. Just create a user on the Unix/Xenix system named
something like 'kserver'. Then build a .login or .profile for that user in
that user's home directory that fires up kermit in server mode, and then
terminates the process and hangs up when kermit exits. A remote machine
that wants to do file transfer, either of UUCP mail or anything else, just
dials in, logs in as user kserver, and issues the appropriate kermit server
commands. When done, he issues a server terminate command, which causes
Kermit on the Unix box to exit and kill the process... which should also
hang up the phone.
Using cron and shell scripts makes for easy packing and unpacking of bundles
of mail to/from the UUCP mail directory. The remote system just has to have
a similar sort of batch facility to use to do the dialup.
Bob Hartman of ...!vaxine!spark!bob fame is using this technique to
implement a UUCP/Fidonet bridge. I'm working on duplicating and then
expanding his work. Will pass along details when it works, and would
be most interested in talking to other people who have this sort of
thing working, or want help on making it work...
Bdale Garbee
arpa: ag0b@cmu-cc-te.arpa, soon to be ag0b@te.cc.cmu.edu
uucp: ...allegra!pitt!rensys!bdale
[Ed. - Thanks for the news. You may be interested in a customized Unix
Kermit server that they run at OK State as a login shell if you dial a
certain number -- have you been in touch with them...
vasoll%okstate.csnet@csnet-relay? Of course, none of this addresses the
real questions of mail since (I assume) you're just sending mail in batch
mode and not control information in interactive messages, like SMTP would
do. How do you handle the various situations that SMTP or UUCP would
handle, like bad routing information, can't connect to host, no such user,
etc etc?]
------------------------------
Date: Mon, 23 Sep 85 14:06:51 pdt
From: Ken Poulton <hpl-opus!poulton%hplabs.csnet@CSNET-RELAY.ARPA>
Subject: Changes to C-Kermit 4C(057)
[Ed. - Ken Poulton has submitted code for the following changes to C-Kermit.
Some of them are obviously desirable, some are in "sensitive" areas (where
opinions are divided); I'd like to solicit a concensus in these areas, if
possible.]
Fixes for HP 9000:
added "make s500" which does the things formerly listed in the make file
added code to disable HP's enq-ack handshaking (#ifdef IENQAK) in connect
Connect:
changed use of XON/XOFF slightly (now it works like BSD, and better
with HP terminals)
Set Handshake:
now turns off XON/XOFF (-t already does this)
!
merged ! and other uses of fork to call new routine zexecl in ckufio
zexecl does an exec, using 1) the shell defined by environment variable
SHELL, if any, or else 2) the user's login shell from /etc/passwd, or
failing that, 3) /bin/sh.
[Ed. - I guess this is better than the current method, which ignores the
SHELL variable because some Unix systems do not set it automatically.]
control chars
added conchr to ckutio and changes in ckucmd to support using the
user's predefined control characters as he expects
[Ed. - Seems like a good idea, assuming the method used works for the
systems the program tries to support. For Sys III/V, it does
ioctl(0,TCGETA,&x), and then sets the interrupt, character delete, and
line delete characters to x.c_cc[0], x.c_cc[2], and x.c_cc[3] respectively;
for all others it does gtty(0,&x) and ioctl(0,TIOCGETC,&y), and sets
interrupt, chardel, linedel to y.t_intrc, x.sg_erase, and x.sg_kill. In
the first case, x is a struct termio; in the second, x is a struct sgttyb
and y is a struct tchars. How many systems will this break?]
added code for VENIX11 to turn off driver's recognition of these
characters. Most Unices (BSD, SysIII, etc) do this anyway in raw mode.
[Ed. - I've heard reports about this before, but never saw this behavior
in Pro/Venix, which I thought was the same.]
prompt
settable with -DPROMPT=
startup files
1) ./.kermrc 2) ~/.kermrc 3) /usr/local/lib/kermrc
settable with -DKERMRC (as before) and -DSYS_KERMRC
Note that order of first two is intentionally changed
[Ed. - This looks like a touchy one. First, it might be argued that most
people would like the program to behave consistently, no matter what
directory you're connected to. Second, if there is to be a "system-wide"
startup file, does everyone agree that it should be in /usr/local/lib?
Third, the program searches for the startup file as above, and executes the
first one it finds. Maybe it should execute all of them? If there is to
be a system startup file, should the program ALWAYS execute it? Should
there be user-selectable options to specify the order in which startup files
are executed, and how many??? How to explain all this to users?]
eXIT command
added eXIT command - allows leaving Kermit w/o unlocking or dropping line
added ttnohu to close the tty w/o hangup
creates ~/UNLOCKttyxx to remind user
EXIT deleted to avoid confusion
(maybe this should be disabled on BSD systems as not needed)
[Ed. - This is the most controversial area of all. First of all, case-
sensitive commands are not in the spirit of Kermit. Second, giving the
user the power to lock a line permanently might be fine on a small friendly
system, but not on a big one with many users. The risk of a user leaving
a line locked (intentionally or not) is much higher with this method, and
the inconvenience to other users must be weighed against the advantages
of doing this. Opinions? (Here we go again...) ]
scripts
commented out most of the messages
user can use echo to write messages if he *wants* to
[Ed. - Opinions from script command users?]
#
added comment command
for documenting scripts
(done with % by 4C(057))
[Ed. - I used "%" for this to avoid confusion with shell scripts.]
locking
now accepts existing lock files owned by the user (to support eXIT)
[Ed. - This is probably not a bad idea, when it works... But some sites
keep the locks directory write-protected (or even read-protected), and
other sites want to run Kermit, UUCP, CU, TIP, etc, set[ug]id'd, so there's
no good way to tell for sure whose lock file it is. I truly believe that
"lock files" are the WORST thing about Unix... It continues to amaze me
that the system was designed NOT to give exclusive access by default to
serial devices automatically upon open().]
VOID
defined to null for V7, "(void)" for all others to avoid all the
V7 ifdefs
[Ed. - I thought I had removed all those (void)s; they were just there for
lint's benefit, but I guess a couple are still there (in ckutio.c and
ckuus3.c); they should go too.]
-g rfn -a name
changed ckcfns.c to try treating "-a name" as a directory name
bug: zopeno gives an err msg if the name is a directory
[Ed. - This is a little tricky, not sure it's worth it...]
logging
added better debug and transaction messages to clsif and clsof in ckcfns.c
[Ed. - Good messages are always nice.]
get
fixed to strip newline off of -a name in take script
[Ed. - Obviously desirable.]
------------------------------
Date: Sat, 21 Sep 85 21:28:25 PST
From: !!tweten@AMES-NAS.ARPA
Subject: Bug Fix for C-Kermit User Interface
We just got a new giant Amdahl machine, running the System V flavor of UTS.
So far, its only connection to the world is through 9600 baud lines.
Needless to say, my first order of business was building C-Kermit on it,
followed by Compress, followed by most of my files (it also has mucho disk).
It went mostly OK, though the lintish feature of the UTS C compiler fussed a
bit. That's not the story for today, though. While sending files to UTS, I
got fed up with Kermit's habit of double-spaceing between lines of dots.
I decided to fix it while waiting for the transfer. The context diff below,
for ckuus3.c, is the result. The problem arose from some confusion over
whether "p" was the position of the last character or of the next character
to go into the buffer. I tried to make everything consistant. My rules
were as follows: 1) "p" is the zero-based position of the next character to
be put on the line, 2) It is each message type's responsibility to determine
if there is enough space for it, and to leave "p" pointed at the next
available space when it is done. I also parameterized the line length, and
set it to 79 for our C-Kermit, so terminals with linewrap won't.
[Ed. - diffs omitted, but will be included in next release. Kermit was
also brought up recently on our own UTSV system, and worked ok, except for
some cosmetic problems with command echoing, which I think we can fix.]
------------------------------
Date: 23 Sep 85 16:34:00 EDT
From: STEVE KABERLINE <kaberline@ford-vax>
Subject: C-Kermit on Masscomp Systems?
Can you tell me, please, who is/has been working on the Masscomp specific
implementation of Unix Kermit? I have a few comments/suggestions I would
like to forward (A network address, if available, would be nice) to them. I
recall, at one time, seeing a list on CU20B of who-is-doing-what as far as
Kermit work goes, is there still such a file I can ftp over and look at?
[Ed. - I've lost the specific reference, but have had reports that Masscomp
systems can run the current release of C-Kermit just fine, when built with
"make sys3". Anyone know otherwise?]
------------------------------
Date: Fri 20 Sep 85 21:39:02-EDT
From: Andy R Raffman <EN4.AR-RAFFMAN@CU20A>
Subject: Problem with Sanyo 555 Kermit
I thought that I should tell you that I have tried the new Kermit 2.28 for
the Sanyo 555, and it has a bug: the backspace key does not move the cursor
back or erase the previous character in command mode. Given that many of
the other improvements in Kermit haven't helped the Sanyo version much (no
H-19 or VT-100 emulation, no set key, no mode line), unless you have fixed
some larger bugs in v.2.26 (I know that the log function doesn't work right),
you might consider going back to it until the backspace bug is fixed.
[Ed. - If any Sanyo users out there have a fix for this, please let us know.]
------------------------------
Date: Mon, 23 Sep 85 23:48:58 PDT
From: Samuel_Lam%UBC.MAILNET@MIT-MULTICS.ARPA
Subject: MsKermit Linking Idea
The following is the relevant part of a response in our local electronic
conference (*Forum) which I think may be of interest to part of the Kermit
community.
2723. MTS Kermit Now Available
Bruce Jolliffe 16:23 Mon Aug 13/84
2723/60. CORRIE KOST 21:16 Mon Sep 23/85 12 lines
I would like to suggest that all versions of KERMIT be linked
with Microsoft's LINK version 3.XX, so that they can be packed
with Microsoft's EXEPACK utility. This procedure can cut the
size of the .EXE file by up to 50 %, and the .EXE file is still
directly runnable from MS-DOS (...and it loads faster, too)
Note that EXEPACK will produce garbage (no warning !) if you
try to pack a file linked with LINK version 2.XX, or the
default IBM-PC linker supplied with PC-DOS 3.0 and PS-DOS 3.1
- Ya'akov
[Ed. - Does anyone know if a thus-packed file can be run transparently
under earlier versions of DOS? Also what would the expected savings be
on a program like MS-Kermit 2.28, which has got rid of most of its static
buffers and does memory allocation at runtime? Any other pitfalls to be
wary of?]
------------------------------
End of Info-Kermit Digest
*************************
-------