SY.CHRISTINE@CU20B.COLUMBIA.EDU (Christine M Gianone) (09/04/87)
Info-Kermit Digest Fri, 4 Sept. 1987 Volume 6 : Number 18
Today's Topic:
C-KERMIT -
Kermit 0.8(35)
Mac Kermit 0.8(35) report
Experimental C-Kermit 4E(066) Works on SCO Xenix
Test C-Kermit Feedback on SCO Xenix
C-Kermit 4E(066) on Convex C1
Experimental Kermit 4E(066) Mostly Works on Gould Powernode 6000
More about Experimental Kermit on Gould
Trouble with C-Kermit 4E(066) Init File???
New xkuker (C-Kermit) Bugs on Pyramid
C-Kermit 4E Amiga .BOO File
C-Kermit 4E(066) on Amiga, and Long Packet Problem
4E(066) Long Packet Problem Followup
C-Kermit on Pro 350 / Venix V1
C-Kermit Version 4E(066) Results on Celerity, Pyramid, 3B20
Bugfix for C-Kermit 4E(066) on Pyramid
C-Kermit 4E fixes for BSD 4.3
Problems with C-Kermit 4E(066) on VAX/VMS
C-Kermit 4E Problems on Tandy 16A/6000 and Arete 1200
C-Kermit 4E Feedback
C-Kermit Lock Files
----------------------------------------------------------------------
Date: Fri, 7 Aug 87 16:03:11 PDT
From: dplatt@teknowledge-vaxc.arpa (Dave Platt)
Subject: Kermit 0.8(35)
Keywords: Macintosh Kermit, C-Kermit
I've tested the Megamax version briefly on my Plus, talking to a 4D(061) on my
Sun 3/52, and it seems to work fine. I've posted a short note to
comp.sys.mac, reporting that 0.8(35) is now available and relaying your
request for people to complete the 4D(066) port and/or port the whole thing to
MPW or LightSpeed C.
------------------------------
Date: Fri, 14 Aug 87 16:03:11 EDT
From: Ben Cranston <ZBEN@UMD2.UMD.EDU>
Subject: Mac Kermit 0.8(35) report
Keywords: Macintosh Kermit, C-Kermit
Preliminary testing of Mac Kermit 0.8(35) indicates everything functional.
I STILL have to change the Inbound End-Of-Packet character from 13 to 10
(015 to 012) to communicate with one of our hosts, which insists on sending
even parity and terminating output "records" with both a CR and LF.
When I reported this problem over a year ago, we thought the problem was
parity bit related, based on some comments in the Kermit history file.
Based on an accidental observation in our latest testing, it now occurs to
me that there is another explanation.
Scenario one:
Packets from the host end with an even parity CR LF (0215 0012) but Kermit
erroniously thinks the 0215 from the serial port and the 0015 from the
"protocol" menu are not the same character. Setting 0012 to be the end of
packet character causes the end of packet to be correctly recognized,
as a LF already has even parity and thus needs no added parity bit.
A comment from the history file about "putting SCC into 8 bit mode always
and doing parity ourselves" started us thinking in this direction.
Scenario two:
Packets from the host end with CR LF. Kermit correctly recognizes CR as the
end of the packet, but incorrectly interprets the LF as the end of another
record. This empty record somehow confuses the protocol. Setting LF to be
the end of packet character causes the CR to be interpreted as just one more
data character after the packet but before the end of the record.
In checking out this new Kermit I grabbed a file of test data, downloaded it
to the Mac, uploaded it back, and compared it against the original version.
Unbeknownst to me, the particular file I chose had an explicit linefeed
character embedded in the data at one point. Somewhere in the
download-upload process this linefeed was changed into a real newline,
creating a one-line discrepancy between the two files.
Now, I'm quite sure the LF -> newline mapping was not happening on the host.
Nor is it a problem with Mac filesystem semantics, as the Mac uses CR and
not LF as its newline character. If some routine in Kermit is confusing
LF with CRLF it could cause this kind of behavior.
Another interesting observation was that the "retransmit" indicator on the
screen seemed to be incrementing by two. That is, it would read 1, 3, 5,
7, 9, 11, and so on until the transfer timed out. Like two records were
going by each time or something...
If anyone can suggest an experiment that would differentiate between these
two scenarios, and wouldn't take massive efforts to perform, I would be
interested in hearing about it...
I do have MPW installed, and have access to Lightspeed. Conversion from
Megamax might be complicated by the fact that Megamax has 16 bit INTs and
MPW has 32 bit INTs. I have converted a few simple programs and so have
some experience in the area. If nobody else takes up the gauntlet I suppose
I could be persuaded to take it on, if only to fix the aforementioned bug...
Ben Cranston <zben@umd2.UMD.EDU>
Computer Science Center Systems Group
The University of Maryland
[Ed. - There have been numerous complaints over the last couple years that
C-Kermit cannot properly cope with incoming packets that are delimited by
CRLF. We have never been able to reproduce the problem. Your descriptions
might help. Will try to track it down.]
------------------------------
Date: Sun, 9 Aug 87 15:28:56 edt
From: jl42+@andrew.cmu.edu (Jay Mathew Libove)
Subject: Experimental C-Kermit 4E(066) Works on SCO Xenix
Keywords: C-Kermit, Xenix
I brought the experimental sources to my SCO Xenix 2.1.3 system (running on an
IBM PC/AT compatible, made by PCs Limited) and compiled them directly, no
trouble (make xenix).
Jay Libove
Arpa: jl42@andrew.cmu.edu Bitnet: jl42@drycas.bitnet
UUCP: ...!{seismo, ucbvax, harvard}!andrew.cmu.edu!jl42
UUCP: ...!{pitt | bellcore} !darth!libove!libove
------------------------------
Date: Tue, 11 Aug 87 23:04:22 PDT
From: guyton%condor@rand-unix.ARPA
Subject: Test C-Kermit Feedback on SCO Xenix
Keywords: C-Kermit, Xenix
I'm running SCO Xenix 2.2 on a 386, and have (so far) three comments re the
new test version of kermit ...
1) Why all the wait(0)'s instead of wait((int *)0) as mentioned
in the comments? Any machine that has sizeof(int) != sizeof(* int)
is going to need that typecast, and there's no reason I can think
of why the code wasn't fixed when the comment was applied.
[Ed. - I wasn't sure if this should apply to all systems, guess it should be
changed as you suggest.]
2) A couple of files included "file.h" erroneously. I ifdef'd it out
for xenix, but I guess it should be omitted for others as well.
[Ed. - This is a horrible problem; no two systems seem to agree about what
is in file.h or where it is. Notice that other SCO Xenix people did not
report this problem...]
3) I've included a very quick implementation of modem support for Concord
2400 bps modems.
Oh, I modified the xenix make to use large model w/out even trying the
default, don't know if that would have worked or not.
Follows are my diffs,
Jim
[Ed. - Thanks! Diffs added to XKUKER.BWR for now.]
------------------------------
Date: Wed, 12 Aug 87 14:07 EST
From: Mark B. Johnson <CDTAXW@IRISHMVS>
Subject: C-Kermit 4E(066) on Convex C1
Keywords: C-Kermit, Convex
We got C-Kermit up and running without (so far) any problems on a Convex C1
minisupercomputer running Convex UNIX V6.0. The make bsd option worked
without change. I will report any problems as they crop up.
Mark Johnson
Univ of Notre Dame
------------------------------
Date: Mon, 10 Aug 87 17:56:50 MDT
From: Mike Niswonger <CNISWONGER@SIMTEL20.ARPA>
Subject: Experimental Kermit 4E(066) Mostly Works on Gould Powernode 6000
Keywords: C-Kermit, Gould Powernode 6000
Just picked up the experimental Kermit and brought it up on a Gould
Powernode 6000 (dual processor) running UTX 2.0. This system thinks it is
BSD 4.3, so i just made "BSD". So far everything looks good, but tests are
still incomplete - I'll post a complete report in a couple of days when I have
had a chance to test more options.
I had to try long packets first. Everything works fine at 1000 char
packets between MSKermit 2.29C and the new kermit at 9600 baud. The effective
baudrate was about 6800 baud, or about 71% efficency. I'll try and find the
optimum baud rate and packet length later this week.
Mike
------------------------------
Date: Wed, 12 Aug 87 18:24:37 MDT
From: Mike Niswonger <CNISWONGER@SIMTEL20.ARPA>
Subject: More about Experimental Kermit on Gould
Keywords: C-Kermit, Gould Powernode 6000
In continuing my debug on CKermit 4e(066) I found a problem in
trying to send with long packets. Negotiations look OK, but send packets
go to maximum size without long packets. Long packets are accepted in the
other (receiving) direction. Nice for uploads, but . . .
[Ed. - Probably related to "set send packet-length" command, see below.]
I'll get copies of the log files and send them to you. During debug
I also noticed a problem with F111 format debugs - sometimes they get a <CR>
in them at the end of the data which causes an overprint on the data when I
send it to the printer. I'll try and track these down. Let me know if you
hear of any other bugs.
Mike
------------------------------
Date: Tue, 11 Aug 87 14:36:38 CDT
From: moore@ncsc.ARPA (Moore)
Subject: Trouble with C-Kermit 4E(066) Init File???
Keywords: C-Kermit
have you folk heard any complaints about .kermrc being ignored in the new unix
release of kermit 4e(066) 4 aug 87, 4.2bsd? maybe i'm doing something stupid
(again).
jim
[Ed. - There have been a couple reports of this, but we can't reproduce on
our own 4.2BSD (really Ultrix 2.0) VAX. Kermit 4E(066) finds the .kermrc
file if it's in the home directory, even if you're cd'd to another directory,
or else in the current directory if there's not .kermrc in your home
directory. The way the program finds the home directory name has not changed
in many releases (it's just getenv("HOME");).]
------------------------------
Date: Tue, 11 Aug 87 17:00:12 EDT
From: MATTHEWS <matthews@vax1.acs.udel.edu>
Subject: New xkuker (C-Kermit) Bugs on Pyramid
Keywords: C-Kermit, Pyramid
I have found two problems so far with the newest version 4E(066) of kermit.
Here is what happens when you try to run it on Pyramids version of UNIX (OSx).
Script started on Sun Aug 9 23:56:57 1987
udccpyr1% cd
udccpyr1% cat .kermrc
echo
echo set file type BINARY
set file type BINARY
echo set file names LITERAL
set file names LITERAL
echo
set prompt "C-Kermit@pyr1>"
udccpyr1% cd /usr/tmp/kermit
udccpyr1% ./wermit
set file type BINARY
set file names LITERAL
C-Kermit, 4E(066) 4 Aug 87, 4.2 BSD
Type ? for help
set file type binary 8
bad
?Invalid - bad
Fatal: Kermit command error in background execution
udccpyr1%
script done on Sun Aug 9 23:58:00 1987
I get no prompt or anything, it just exits with this error message. It
appears as though it thinks I want to run it in the background. I compiled
kermit the same exact way with the "bsd" flag on both machines and it does
different things on each one.
[Ed. - I noticed some similar behavior on a system running 2.9BSD. The problem
can be traced to the conint() function in xkutio.c, where the program attempts
to determine whether it's running in the background by testing some signals,
etc. Apparently, there is no universally valid way (at least none that I know
of) for doing this, so the same test will give different results on different
systems. If Kermit thinks it's running in the background, then errors in
'take' files (including .kermrc) are fatal. Unix wizards are invited to take a
look at the conint() function and suggest a better way of checking for
background operation.]
The second minor bug that I discovered when trying to run kermit on our Vax
8650 running 4.3 BSD is that SET PROMPT isn't working correctly. A command in
a .kermrc file such as "set prompt C-Kermit@vax1>" doesn't change the prompt.
It appears to work okay when you type it at command line.
[Ed. - Yes, that's a bug. It'll have to be fixed. See below.]
Sorry I can't be specific to where exactly the problems are within the source;
I only kept it on the machines long enough to compile it. I have a 1000 block
quota.
John Matthews
------------------------------
Date: Sat, 29 Aug 87 15:37 EST
From: <RICK@QUCDNAST.BITNET> (Rick Pim)
Subject: C-Kermit 4E Amiga .BOO File
Keywords: C-Kermit, Amiga
The Aug 7 info-kermit digest mentioned a new release of C-Kermit
for, amongst other things, the Amiga. According to the directory I looked
at of cki* *, the BOO file is new. The digest requested comments/etc, so I
ordered the BOO file and decoded it today. According to the header once
it's running, the version is 4D. It has at least one of the same bugs as 4D
(parity does not work).
[Ed. - Right, we don't have an Amiga .BOO file based on the new version yet.
We were hoping somebody would make one. See next message.]
------------------------------
Date: Wed, 12 Aug 87 10:25:42 pdt
From: cit-vax!ametek!walton@RUTGERS.EDU (Steve Walton)
Subject: C-Kermit 4E(066) on Amiga, and Long Packet Problem
Keywords: C-Kermit, Amiga
Well, I grabbed C-Kermit 4E(066) from CU20B, and have been able to compile and
link a running version on my Amiga using Manx Aztec C V3.40b. In the process,
I added the appropriate include files and the DOSFH and FILENO macros for Manx
C to ckiutl.c and ckitio.c; diffs will follow shortly. (One thing which was
easy: parity can be ignored in ttinl(), since the Amiga's serial.device
handles it itself, and passes characters to Kermit with the parity bit already
stripped.)
However, I have hit what appears to be a major bug: 4E(066) will not use long
packets when talking to itself. I have built the BSD version of 4E(066) on
our 4.3BSD 780 using "make bsd", and tested it in a loop mode by phoning the
machine from one of its own dialout lines. After a "set send packet-len 150"
and "set receive packet-len 150" on both ends, it does not use long packets,
but rather the standard ones. This also happens when connected to the 780
from my Amiga at home.
One minor bug, easily fixed: the help information for set send packet-len
still says that the maximum packet length is 94.
Stephen Walton, walton@ametek.UUCP
Ametek Computer Research Div.
610 N. Santa Anita Ave.
Arcadia, CA 91006 USA
818-445-6811
[Ed. - See next message.]
------------------------------
Date: Fri, 14 Aug 87 14:28:04 pdt
From: Steve Walton <cit-vax!ametek!walton@RUTGERS.EDU>
Subject: 4E(066) Long Packet Problem Followup
Keywords: C-Kermit
After reading the docs for 4E(066) (RTFM, right?) I tested it again talking to
itself on my 4.3BSD 780. This time, the only set command I did was a "set
receive packet-length 300" on the receiver. This time, long packets were
used. If I also naively do a "set send packet-length 300" on the sender,
short packets are used. I think this is still a bug, but not quite the one
I'd reported previously.
[Ed. - "set send packet-length" is used to override negotiations. Apparently
it doth override them too much. This will have to be fixed.]
------------------------------
Date: Sat, 22 Aug 87 14:21:56 cst
From: ihnp4!sask!reid@seismo.CSS.GOV (Irving Reid)
Subject: C-Kermit on Pro 350 / Venix V1
Keywords: C-Kermit, Venix, Pro-3xx
Is anyone else running C-Kermit on Venix V1? I'm having all sorts of
problems - dial scripts always crash, crashes at >300 baud, etc. I'm
dragging down the new experimental version to see if it gets better; I'll
let the world know how that turns out.
[Ed. - We had Venix V1 systems here once, but no longer, so were unable
to test the new C-Kermit on them. Anybody?]
As an aside, for those of us with limited bandwidth to the outside world
would it be possible for new versions to come with a concise list of which
files have changed, so we don't need to take the whole thing? Better yet,
since many people in the Unix world have Larry Wall's "patch" program, new
versions could be distributed as diff's against the old; this should save
lots of network time for such a large program.
[Ed. - Desirable, but in this case, all the files changed, and in most cases
the diffs would be larger than the original files.]
- irving - (reid@sask.uucp or {alberta, ihnp4, utcsri}!sask!reid)
"Warning: don't use braces, tildes, circumflexes or double quotes as
delimiters - chaos will result"
------------------------------
Date: Tue, 25 Aug 87 16:08:53 PDT
From: Mick Laver (ACC Microconsulting) <zz1ml%sdcc3@sdcsvax.ucsd.edu>
Subject: C-Kermit Version 4E(066) Results on Celerity, Pyramid, 3B20
Keywords: C-Kermit, Celerity, Pyramid, ATT 3B20
The new C-Kermit compiled succesfully under BSD 4.3 systems on Vaxes and a
Celerity, under Sys V on a 3B20, and under the Pyramid 90X's "dual-universe"
bsd4.2/sys5. Also compiled under VMS 4.5, but I didn't test it there other to
determine that it compiled and ran.
Results:
Worked ok on all 4.3 and Sys V systems (see below).
Did NOT work on the Pyramid. While it would compile and run, if you said
"send file" or "receive" it would go back to the C-Kermit prompt. Command
line send or receive just went back to system prompt. One of our systems
programmers looked at it briefly and couldn't find the problem. He said he'd
look further and I'll send a follow-up if he gets anywhere.
[Ed. - See next message for Pyramid fix.]
Binary tranfer problem: Our 4.3 VAX C-Kermit would send binaries incorrectly
if no parity was used with extended packets. If 8th bit prefixing was used
(set parity space on MS-DOS Kermit 2.29b) the files would go OK. When
"normal" sized packets were used binary xfer worked fine either way.
[Ed. - This one will have to be checked...]
Mick Laver, ACC Internet: laver@sdcsvax.ucsd.edu
C-010 U.C.San Diego UUCP: ...!sdcsvax!sdcc3!zz1ml
La Jolla, CA.92093 Ph: (619) 534-4060
------------------------------
Date: Tue, 25 Aug 87 00:43:07 EDT
From: Paul Placeway <paul%tut.cis.ohio-state.edu@ohio-state.ARPA>
Subject: Bugfix for C-Kermit 4E(066) on Pyramid
Keywords: C-Kermit, Pyramid
I ftp-ed the sources for beta 4E from cu20b, and had a bit of a problem making
it work on a Pyramid 98x under the BSD universe. After poking around a bit, I
discovered that the ttpkt() routine was failing when everything seemed fine,
so I looked hard at the code and discovered what looks like a place where
someone forgot to flesh out an #ifdef. After changing ckutio.c in the
following way, C-Kermit seems to work fine. Here are my diffs...
*** ckutio.c.orig Thu Aug 20 11:43:52 1987
ckutio.c Mon Aug 24 23:54:58 1987
***************
*** 912,917
ttflui(); /* Flush any pending input */
return(0);
#endif /* bsd4 */
#endif /* myread */
#endif /* not uxiii */
912,920
ttflui(); /* Flush any pending input */
return(0);
#endif /* bsd4 */
+ #else /* myread */
+ ttflui(); /* Flush any pending input */
+ return(0);
#endif /* myread */
#endif /* not uxiii */
Paul Placeway
Department of Computer and Information Science
SNail: The Ohio State University
2036 Neil Ave. Columbus OH USA 43210-1277
ARPA: paul@ohio-state.{arpa,csnet}
(soon): paul@cis.ohio-state.edu
UUCP: ...!cbosgd!osu-eddie!paul
(soon): ...!cbosgd!cis.ohio-state.edu!paul
[Ed. - Many thanks!]
------------------------------
From: Markku Toijala <mcvax!kolvi!mto@seismo.CSS.GOV>
Date: Wed, 26 Aug 87 14:52:48 EET DST
Subject: C-Kermit 4E fixes for BSD 4.3
Keywords: C-Kermit
I have been setting up C-kermit 4E on microvax II running BSD 4.3. Here are
the modifications I found necessary:
1) Add seteuid/seteguid to allow (remote) shell commands when using
csh as login shell. In 4.3 it seems that csh checks for uid/gid
before starting itself. Effects can be seen when you run sgid to give
only kermit access to an outgoing line.
[Ed. - This area wasn't addressed by 4E(066); older releases are the same.]
2) KERMRC was defined only in ckuusr.c, but also ckuus2.c used it to
get init filename -> you did not get indication of it with "show para".
Moved the stuff to ckuusr.h
[Ed. - Right you are, "show" doesn't list the init file name. This will be
fixed.]
3) Moved setting of default prompt to take place before reading .kermrc.
Now you can have "set prompt" command in it ...
[Ed. - Right again.]
4) Removed . from Extendend-length packets ... - string.
There may still be something wrong with long-packets, but i have not had time
to look at that yet.
[Ed. - Yes, see above.]
Markku Toijala ! UUCP: kolvi!mto
Helsinki University of Technology ! Internet: mto@kolvi.hut.FI
Otakaari 5 A ! EARN: PUH-MT@FINHUT.BITNET
SF-02150 Espoo, Finland ! tel: +358 0 4512011
[Ed. - Many thanks! Diffs added to XKUKER.BWR.]
------------------------------
Date: 27 Aug 87 10:55:00 EST
From: "SRLVX2::KABERLINE" <kaberline%srlvx2.decnet@ford-vax>
Subject: Problems with C-Kermit 4E(066) on VAX/VMS
Keywords: C-Kermit, VAX/VMS
Recently downloaded the new experimental new release of C-Kermit, version
4E(066). I compiled and tested it on both systems I have access to, a
Masscomp (unix), and a VAX 8600 running VMS V4.5. I am writing this to report
a few minor problem I've noticed, mostly when running under VMS:
1. During the building of wermit under VMS, I got an error
message while linking:
%LINK-W-NUDFSYMS, 1 undefined symbol:
%LINK-I-UDFSYM, SYSCLEANUP
%LINK-W-USEUNDEF, undefined symbol SYSCLEANUP referenced
in psect $CODE offset %X00000B6E
in module CKUUSR file CKUUSR.OBJ;1
[Ed. - Right, a syscleanup() function should be added to CKVTIO.C. It doesn't
necessarily have to do anything...]
2. Under VMS, the "cwd" command does not appear to work?
[Ed. - This is done by the function system(), defined in CKVFIO.C, called
with the argument PWDCMD, which is apparently undefined for VMS. Oops!]
3. A "dir" command is *NOT* equivalent to a "dir *.*" command under
VMS; both commands produce identical output on the Masscomp.
4. Finally, I can't seem to get the long packets to work. I
set the send and/or receive packet size on both ends, then
try to send a file from/to VMS/Unix. The files transfer OK,
but when I then do a "show parameter" command, the packet
sizes displayed is 94??
[Ed. - You should avoid "set send packet-length" and only use
"set receive packet-length" on the receiving end, till "set send
packet-length" is fixed.]
Haven't noticed anything else yet, but I'll keep experimenting and report
anything else I might discover.
Thanks!
Steven Kaberline (Kaberline@ford-vax)
Ford Motor Company
Scientific Research Labs, Rm. S-3061
P. O. Box 2053
Dearborn, MI 48121 USA
(313) 323-2248
------------------------------
Date: Thu, 3 Sep 87 08:26:14 EDT
From: Marshall_DeBerry@um.cc.umich.edu
Subject: C-Kermit 4E Problems on Tandy 16A/6000 and Arete 1200
Keywords: C-Kermit, Tandy 16A/6000, Arete 1200
I've tried out the new 4E(066) release on a Tandy 16A/6000 and Arete 1200 under
System V.2. One problem I've noticed is that if you try to get the status
of the transfer, as soon as you type Cntrl A, the transmission begins to
send %T's, and eventually times out. This was during file transmissions
between the Arete and MTS Kermit. It was also reproducible between the
Arete and Tandy machines.
[Ed. - This sounds like something pretty specific to your machine; Ctrl-A
status reports work ok on the machines we've tested. I hope you can track it
down.]
Another had to do with setting long packets. If I set the Tandy end to send
at a length of 900, and the Arete end to receive at 900, when I put the Tandy
end into server mode, the transmission begins, but terminates immediately with
an OK. If I only put the receive end at a length of 900, things go fine. (900
is just an arbitrary number I picked) .
[Ed. - Right, see above.]
The program compiled cleanly on both machines, except that on the Tandy end
(running under Xenix 3.1.2), I had to include <sys/types.h> for one of the
files in which void is used.
------------------------------
Date: Mon, 17 Aug 87 21:45 MDT
From: <JRD@USU.BITNET> (Joe Doupnik)
Subject: C-Kermit 4E Feedback
Keywords: C-Kermit, ATT Unix PC
A couple of comments on the new test C Kermit:
1. signal() returns type "int" on my Unix PC running AT&T sys5r3, just like
everyone else, yet the conditionals in the code specify "void" for only
sys5r3. So here we have an exception to the cast in steel Standard Edition of
Unix from the horse's mouth. Btw, release 3 here means 3.0 whereas in-house at
AT&T they are up to 3.5 at last reading.
[Ed. - Oh, so sys5r3 is not the same everywhere... Well, since the type cast
for signal() is the only difference in Kermit between sys5r3 and sys5r2 (or,
for that matter Sys3), then use "make sys3" or "make sys5" (which is an alias
for "make sys3").]
2. The file statistics display indicates files are always transferred with
type 1 block check, even though I have type 3 set in both .rkermit and on the
remote machine and sometimes set it that way by hand in C Kermit.
[Ed. - Will investigate this.]
3. When the dust settles Lint (no pun intended) ought to be run across the
code to pick up the loose ends. My Lattice C compiler on the AT machine is
more picky than the standard Unix compilers and lets me know to do better next
time, sigh. You'd think it wanted us to be (gag) Pascal programmers. On the
other hand, you may have done so and we are seeing Unix vs ANSI in action.
Can't win either way.
[Ed. - No, I was scared to Lint it, but I will.]
4. Otherwise, it works just great! Throughput is way up. Whereas the
previous release yielded about 10-12Kbaud across STARLAN to my AT this version
indicates 18+Kb the same way. That's with 1000 byte packets.
Regards,
Joe D.
------------------------------
From: sob@watson.tmc.edu (Stan Barber)
Subject: C-Kermit Lock Files
Date: 20 Aug 87 21:26:17 GMT
Keywords: C-Kermit, Unix Lock Files
I should point out that C-Kermit(041) does handle lock files correctly under
BSD4.3 with the 4.3UUCP locking structure. This creates a lock directory
(/usr/spool/uucp/LCK) that is publically writable and each program (except
kermit) using the locking protocol is smart enough to test for dead locks
(coming from programs that aborted and did not remove its lock).
Stan
[Ed. - Presumably, this is also true for 4E?]
------------------------------
End of Info-Kermit Digest
*************************
-------